ToME: the Tales of Maj'Eyal

Everything about ToME
It is currently Mon Jul 22, 2019 9:40 am

All times are UTC

Post new topic Reply to topic  [ 1 post ] 
Author Message
PostPosted: Fri Jun 19, 2015 10:38 pm 

Joined: Tue Feb 15, 2011 12:01 am
Posts: 282
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:

function _M:loaded()
   self.update = fct

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:

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group