Building "beams" or self-updating particles into the engine

All development conversation and discussion takes place here

Moderator: Moderator

Post Reply
Message
Author
Nagyhal
Wyrmic
Posts: 282
Joined: Tue Feb 15, 2011 12:01 am

Building "beams" or self-updating particles into the engine

#1 Post by Nagyhal »

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:
  • 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.
Now! There's one thing here. Normally I'd feel very capable about running off and hacking this sort of thing into the Lua engine and offering it up as a gory offering to DarkGod. The results might be a bit messy, but I'd get it done. And of course I'd comment it, clean it up and trim it down as best I could, but to an elite coder it'd probably still seem messy. Anyhow, the thing is, you see, that it seems someone's long had the idea of doing it before, and given up.

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
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? :mrgreen:

Post Reply