Building "beams" or self-updating particles into the engine
Posted: Fri Jun 19, 2015 10:38 pm
To explain what I mean by "beams", I'm working with talents that act like the Doomed's Feed talent. Feed works by both conceptually and visually maintaining a visible link or "beam" between source and target.
I'm working with a project that has many such beam effects - upward of 10. It doesn't make sense, in the logic of computer programming, to have each beam's temp effect come with its own written-to-order callbacks and update functions. It doesn't even make sense to substitute the fully written-out callbacks on each effect with 3 or 4 one-liners. That'd be still too much duplication. Rather, it's something that could be more efficiently written into the basic particle effect specification.
Feed doesn't even do the job well- it runs a test each turn to see if the player has EFF_FEED or EFF_FED_UPON. I've never seen it happen but I imagine an NPC trying to Feed one of the player's NPC allies would result glaringly badly - with a static, never-changing beam. This is further proof that the sort of operation I'm talking about is complicated and difficult enough to deserve embedding in the engine and out of the way of talent creators.
Currently, my talents work by:
In engine/Particles.lua, which would be the logical place to put the handling of any such "beam" effect:
An "update" field is clearly meant to be attached to each newly-loaded Particle object. However, this parameter "fct" is nowhere to be seen, and nor is "update" ever called or used on the particle, unless I'm missing key insights into the C engine.
Why was the code half-done? Does someone have the original? Was a particular implementation considered inefficient, or a different way of doing things envisaged? Or have I just missed something absurdly obvious?
And, more importantly! Does anyone fancy helping me get this done as best as possible?
I'm working with a project that has many such beam effects - upward of 10. It doesn't make sense, in the logic of computer programming, to have each beam's temp effect come with its own written-to-order callbacks and update functions. It doesn't even make sense to substitute the fully written-out callbacks on each effect with 3 or 4 one-liners. That'd be still too much duplication. Rather, it's something that could be more efficiently written into the basic particle effect specification.
Feed doesn't even do the job well- it runs a test each turn to see if the player has EFF_FEED or EFF_FED_UPON. I've never seen it happen but I imagine an NPC trying to Feed one of the player's NPC allies would result glaringly badly - with a static, never-changing beam. This is further proof that the sort of operation I'm talking about is complicated and difficult enough to deserve embedding in the engine and out of the way of talent creators.
Currently, my talents work by:
- maintaining the projections to and from the right grid locations with a callbackOnMove on both source and target
- using a callBackOnActBase on source to catch any other inconsistences - I'm not sure how many more would be optimal. callbackOnAct on both source and target might result in less visual glitches from the player's point of view.
- and of course, the removal of the source effect on death ensures the beam's originating effect is removed at the source end. This is something further to consider integrating into any new core functionality.
In engine/Particles.lua, which would be the logical place to put the handling of any such "beam" effect:
Code: Select all
function _M:loaded()
..
self.update = fct
...
end
Why was the code half-done? Does someone have the original? Was a particular implementation considered inefficient, or a different way of doing things envisaged? Or have I just missed something absurdly obvious?
And, more importantly! Does anyone fancy helping me get this done as best as possible?