Morphing Ray v0.01

[Moderator]

15:59, 11th Sep 2010
TriggerHappy:

Looked fine and was leakless.

 

[G00dG4m3]

I hope you will enjoy this one ^^
Suggestions, flaming and the stuff are all welcome here

 

[MortAr]

Creating the SFX on their chest/origin or else where but not on their location will maintain the effect as long as it is not destroyed, so the "SFX Abilities" are kinda useless.

As the tooltip above says "channels a stream of mana" maybe you could do it to actually drain a portion of the targets' mana and then deal the drained mana + % of Intelligence or whatever you want. This way it will much it's tool, cause I really don't see how the beam will turn them into sheeps.

Also you could do this call AddLightningEx ("ModelName", true, x1, y1, z1, x2, y2, z2)
Instead of putting it in a location.

4/5 for originality and clean code again.

 

[G00dG4m3]

"channels a stream of mana"

actually, description says channels a stream of mana AT TARGET.
this can also be seen as the lightning effect moves from caster to target, meaning you lose mana for the effect.
SFXes are easier to remove when they are in abilities, as you don't have to store it into hashtable/variable to destroy'em, but simply remove them, not to mention that I'd have to waste a pair of actions, like create sfx, then store it into hashtable, and only then repeat with the second one.

Also, I'd like that you actually rated this spell at the line above

 

[Maker]

You should rethink where this check should be made:

• (RayCasters is empty) Equal to True

Yes, there is the "stops casting" trigger to worry about too. You could add the check there too. But it's not that serious, just small optimization IMO.

NOTE 8: Never, EVER, make spells w/ hashtables which is casted by CASTER and all information is attached to TARGET, cause it will get bugged! A LOT!

Untrue.

 

[G00dG4m3]

You should rethink where this check should be made:

• (RayCasters is empty) Equal to True

Erm... If you do a loop with empty group, nothing really hapens, does it? After removing caster from casters' group, next loop will have no effect but turning off the Loop trigger.

Untrue

Oh really? it is Hashtable-specific stuff. and by saying that, I ment spells where different stuff is attached to same slots, like in one spell 0 is target (like in this spell) and another spell's 0 - real number (cast by self). If this spell is casted during effect of another spell, and all information is seriously attached to THIS spell's target and another spell's caster (I.E. our caster), this would bugg, wouldn't it?

 

[Maker]

Erm... If you do a loop with empty group, nothing really hapens, does it? After removing caster from casters' group, next loop will have no effect but turning off the Loop trigger.

Well, let me begin by saying that it's not a big deal.

But the check is made every 0.03 seconds if it's at the end of the trigger as long as the trigger is on. If it's on for one secon, the check is done 33 times.

But if you move it to after you remove the caster from the group, it will run only once per caster.

Oh really? it is Hashtable-specific stuff. and by saying that, I ment spells where different stuff is attached to same slots, like in one spell 0 is target (like in this spell) and another spell's 0 - real number (cast by self). If this spell is casted during effect of another spell, and all information is seriously attached to THIS spell's target and another spell's caster (I.E. our caster), this would bugg, wouldn't it?

Sure, if you overwrite keys it will bug. But that's a user error, not the fault of hashtables. You can use strings as keys instead of integers, or different hashtable for different spells.

 

[G00dG4m3]

Well, then I'd have to make a second looping trigger, which would run once a second and make the check, but it is faster to turn this off at the loop of the trigger IMO. It wouldn't waste .03 second loops until the next check, if there is no action made.


Maybe you're right, but then user would have to make a quite piece of job to make it working.