I'll continue work on them as soon as my two questions are answered:
How exactly does the $Tile Factor work in the code? What units does it use, because it doesn't seem to work well with either raw metre value for length of the tecture nor with fixed aspect ratio value.
How does the $Translation work in the code? What kind of values am I supposed to feed into the table? Integers? Decimal numbers? What units? Metres per second value was definitely not a very great success, so I'm kinda in the dark as to what it's supposed to use.
It's probably easy enough to make textured beams consist of several layers, of which the "base" layer would have greatest width and top layer being thinnest, with different $Zadd factor so they look like they are not on one layer but on top of each other. At least it should be easy in GIMP. The problem is that using two layers would basically double the memory requirement, depending on resolution of course, but still. Three layers, threefold memory use. With

beams, the sections didn't originally have big animated textures, they were generated on the fly by table values.
The other thing is that transparency blending feels rather weird to me when I tried to actually do this in-game. True alpha blending doesn't work, and when I stack two layers on top of each other they easily become overbright, somehow. Then again, my current animations were designed to be used as single layers. Ironically, the frames were actually originally made of three layers that were combined into single layer frames, but individual layers do not exist anymore. So basically, the beams should look 3D enough when viewed from side - save for the hitpoint, which sometimes looks a little... weird.*
So, the question is what are you ready to sacrifice - looks or memory? It's obviously no problem if you have RAM to spare. You could have ten layered beams if you really want that much 3D effect into them, but the thing is, the beams will still mostly look flat in most cases when you view them from sides, since your monitor will alway remain flat. Even looked from shallow angle, you really need to see the hitting point to see the fact that the beam only consists of a single layer. So I can try what gives with more layers, but the key problem right now is to get accurate information about what the table values are expected to be.
To any degree, I don't think rushing these beams to 3.6.9 mediaVP's would be such a marvellous idea, unless I get them worked to satisfactory condition with help of information from coder side before the new MVP's are released...
*Personal opinion: Beam hitpoint needs more explosions to cover the actual point of impact, where the one-layerness of the beam is apparent. Starting point is not a problem currently, because the beam blends nicely into brigh center of beamglow ani. How do I increase the amount of stuff released in the point of impact?
By the way, here's one of the cooler recent screenshots... Just for fun.
[attachment deleted by admin]