sart13

in log also nothing criminal. need normal crushdump.

but, i think, this - hardware problem.

Someone please correct me if I am wrong, but isn't "Hooks for Scripting Library for spells" moving the "tons of custom code in dummy, proc aura handlers which looks not nice" from core to the scripting library, which is also not nice?

no. "tons of code" be moved from one part of core to another part. aso heavy grow in size (and possible bugs count).

sart13, I happen to agree with you that the first step to fix a problem is to exactly define it. So, if you can find some time, could you point out in detail the limitations of the current Pet system somewhere? I, personally, would greatly appreciate this.

Shlainn

i publish my version of pets_rewrite over year ago, but his require much more rewrite. your may try this (and also over 8mb of other changes) in R2. including EOA.

inventing the wheel (again) - should be a very interesting process ...

I make ICC 1,5 years ago, and already not remember everything. aura (actually a combination of spells) for 37697 - 70459-70457 (need implementation in the core).

37652 has a similar effect from spells 70215 - 70672.

so that in most cases such an effect - it SPELL_AURA_DUMMY, without any other symptoms. not only in this, in other places too.

this crusdump - from crush in server loading procedure, not from game process.

blizz make this over auras (see on Putricide adds for example).

"Hooks for Scripting Library for spells" has much more more negative aspects than positive ones.

What negative aspects? Currently we have tons of custom code in dummy, proc aura handlers which looks not nice

I regularly look at these "tons of custom code". 90% of it is done without any problems in the usual way (by writing to standard spelleffects hooks), the remaining 10% - editing the database. TC spellscripts basically camouflage their ignorance or writing, or simply unwillingness to understand the mechanics of action. and sometimes (but this is quite funny) - to workaround core bugs.

for fun look at the chain spellscripts to priest shadowfiend (recently removed), as well as in R2. 'll laugh for a long time.

Hmm... Thx for idea, i think, HR chance may be (100%-(caster hit chance))/ticks_count at every aura update tick. If no one offers a better method, you have to do so.

anyone may correct define chances for heartbert resist on different CrowdControl effects? now i realize CC amount, but chances for HR is unknown for me.

calendar is very difficult to realize... over 12 undecoded combination of guds/unknowd data/absent in mangos data (like encounters mask). need own data store system, many (in my version - 8 ) special workers for check player conditions... i not has info about fully worked realization, max - 60-70%.

Joke. Your must true define problems, before stiky his. No "NPC on transport problem" exists, we has "Transport map" problem. "Better pet support" - may be semantic bad, need full rewrite pet support. "Hooks for Scripting Library for spells" has much more more negative aspects than positive ones.

Forget multithreading, calendar, etc...

a long, boring and uninteresting task that no one will do for me is not respected resource (I have about 25g sniffs with 3.3.5a, in 7 diffirent formats). so I have to act according to the Russian proverb - "не веришь, прими за сказку"

As for the cast - there are no questions, he really goes to a random target (including 2 and maybe 3 times). question only in the number of casts.

this is what I asked. What would happen if only one possible target? 9 casts? in sniff, the raid was only 7 live players, castes was only 7 times (instead of 9, which will be in your case).

in sniff i see 7 targets (players, no pet), 43153 casted 7 times - one per target. not 9.

however, should alert - information coming from me, on this forum is at least questionable.

mangos not use any CPU instructions, his writed on hi-level language. if you compile code wrong - this not mangos problem...

don't use heavy modified (or broken) items in your server. or DB is corrupt.

1. please, don't publish links to R2 in this forum without consulting with moderators. to me bring charges in the ad.

2. this only final commit. needed 2 previous. and this - not simple way...

A short note on censoring (actually I think it might be worth to split this to another thread..):

No, I think I never deleted any message from you sart13 on the mangos forums.

Then you look for a rat. I started to look up their posts in this forum after the announcement of SmartPtr in section "Core modification" was removed in less than 8 hours after writing. After counting found that lost more than 20 stations, most of which contained the code or linking to it. Even after it was removed at least 5 posts.

SD2 Forum on the picture is even worse - old references to ICC code deleted at all.

PS also i search for some posts from Insider42 (AKA Kapatelb), available to me in the archive. I not find at least 4 patches at all. Joke?

please, see on solution (mr216 + some - 4-5 - later, june 2011, distilled code be puplished in this forum, as i think), not related and not seems like TC code. Implemention of Shauren code possible, but not needed - this solve of other (not present in mangos at all) problems.

Short intermezzo:

I have split a bunch of posts that didn't lead to nowwhere from this topic into the trash bin;

PLEASE do PM me if you think this is bad style of moderating!

...

Actually this is - in my view - the thing that splits between power contributors and developers. A dev must be able to discuss and argue about the code, and I see not many ppl around to do so.

I think that in future you will continue to communicate only with themselves. I do not know how you have taken, but according to our traditions (and laws) deleting or editing posts of other authors is unacceptable to any excuses - it's not moderating, it's censorship. and this is what you are doing here on the this and SD2 forum.

If you can not find on this page you want a piece of code and the numbers of GO's (for which no need GoogleTranslate), then post links to more complicated solutions, I think, too - the brain may explode .

Problem in ObjectUpdates code. I publish possible solution long time ago. In R2 works fine.

i find sniff. Not correct, only one cast on one target.

may be find more shorter name?

PS not be accepted anyway

there is no reason to redo the whole as the method. all the same features are achieved by introducing only one flag in the existing structure, without correcting DB record.