Lightning System

This is a system that allows you to easily create various shapes out of lightning effects and manipulate them. The system is nearly MUI; it is limited to 8191 lightning effects at a time. Included in the map are instructions on how to implement the system and what each function in the system does.

Notice: You must be careful when passing values for the degree offsets in the sphere function, if they are too small, the amount of loops will become too large and will end in the middle of drawing the sphere. Also, I've had problems with using the RotateLightning function on a shape containing too many lightning effects, such as spheres. (Might work now, but I haven't tested it)

Update: Fixed bugs and increased performance on a function.

that... looks... AWESOME.

Neat

Looks good, with an original and bizarre back end. Through the magic of hash tables you manage to work around what might otherwise be a dynamic allocation nightmare. Fix the location hostage taking (e.g. store locations in integers and return bug them back to locations).

Hm, on second thought, you could have done this nightmare-free via lists. However, since lightnings have such a high display overhead to begin with I think the use of gamecache is appropriate; I doubt a more efficient implementation would make any difference.

I am skeptical at how well this scales due to the abuse of reals in a language with particularly poorly implemented real arithmetic. If I were you I would rewrite this using integers where the concept you are working with is quantized. For example, if you abandon locations and instead parcel two parallel arrays for the begin and end slots with a separate array for recycling indices, you could avoid the handle leak issues and improve speed & reliability.

The other place you use reals inappropriately is in looping around a circle, for example forming a polygon.

Finally I'd suggest using radians as the natural measure. This is just to taste. Either way the users need to decide whether they use radians or degrees. Since radians is the choice made by the warcraft engine it seems more natural to me.

right well, I for one completely understood pipedreams post right there.

>_>

anyways does it lag?

I would imagine it would if you decided to move several spheres very often, but thats just not a smart use of it(As Pipe mentioned, lightning aready sort of eats your computer as is, without moving them around like a fiend).

Anyway, I played with this some more and its pretty neat, but instead of a flat sphere it might be cool if you changed it to a spherical object instead and gave the user a little more control over the actual shaping.

I will work on adding more options to the system as well as trying to implement Pipe Dream's suggestions.

The only thing is, I have not a clue what Radians are because I probably won't learn them in school for another year or two. Also, could you explain a bit more on the arrays? I get how you would have two arrays containing the start and end values, but how would the third array be used for recycling indexes?

I would think that after you remove the pointer, both of the 2 arrays would be set to 0, and then when creating a new pointer, the system would go through the arrays until it found that both the start and end values had a value of 0, but I'm interested in what you're thinking.

Until I can better understand what you are saying with using radians and other things, I think for now I will just implement the 2 array suggestion you had.

http://en.wikipedia.org/wiki/Radians

Perhaps a bit weighty, bascially Radians are a (generally) prefered alternative to degrees.

Still fairly confused, but I think I know enough to make the system based off radians now. 2*PI radians = 360, that should be enough for me to convert all uses of degrees to radians in the system. Thanks for the link.

Still looks pretty to me =)

blizzard actually has the variables bj_DEGTORAD and bj_RADTODEG (degrees to radians and radians to degrees) already built in. They're simply 180/pi (RADTODEG) and pi/180 (DEGTORAD), as a radian is much larger than a degree.

Thanks for pointing that out, but I already know those variables. The system now uses radians only, and I'm currently working on no longer using locations as pointers. I could also use suggestions on functions that aren't already included.

Check the first post for updates and the new version.

Seems mostly good except you don't appear to remove your locations... ever. Also, it personally seems like overkill to prefix all your system functions with lgl. This isn't a JESP spell :P. As long as the names are unique, I don't think there is a reason for it (it's fine to keep them for the H2I-type functions if you want to make it easy to import).

Fixed the Remove/Move/Rotate Lightning functions to remove locations and added a variable I left out to the RequiredVariables trigger.