[JeffR]

This came up when @

Duion noticed that splashes weren't clearing up properly when they should be, as per the github issue here: https://github.com/GarageGames/Torque3D/issues/1954

@

Azaezel rigged up a solution to shift stuff over to ditch 'splashes' and use the regular explosion system which is more standard and used elsewhere, so it's handled right. So basically, this is pretty much just a general 'Request for Information' thread for feedback/notions on handling for this sort of thing in the future. Does shifting over all that uncommon stuff to the common explosion class make the most sense? Should the whole thing be encapsulated in a generic Effects/Particles system?

Feel free to throw down ideas on what the best general handling for stuff like splashes, explosions, and other such things triggered by other objects would be.

[Azaezel]

There's basically 3 core queries when it comes down to it:

1) Definition: Given the present goals of the componetization work, do we wish to split explosions (Just generally refering to em as FX to make the discussion a bit clearer) into a spawned entity frame + particle/sound/light/camshake/decal (note decals can be animated for ripples), or keep running with an all-in-one baked c++ class. (An example of the latter would involve https://github.com/Azaezel/Torque3D/com ... e52533ba5b (https://www.youtube.com/watch?v=doqiI6AHs40) for various calls like splashes and footpuffs for terrain to cut down on unneeded redundancy, the former at minimum would require the same deal plus the equivalent of a datablock per aspect tied to an entity template.)

2) Application: One of the things Jeff and I have discussed off and on would be https://github.com/Azaezel/Torque3D/commits/FX (https://www.youtube.com/watch?v=Y7Br-vNaREY) which demonstrates a usage case I've used previously in prototypes for per-material effects. (Long story short, you feed a material an ID, and use FX[matID] for your calls. If that's a route folks would like to see explored further, what particular types of interfaces would one wish to see there to take into account things like water and the like.

3) Contributors: Assuming folks even want to see this stuff changed, would they wish to contribute a bit of elbow grease to speed this along? "the engine should" is easy to say, after all, but push comes to shove, as always, if not enough folks want it enough to actually roll their sleeves up, then the presumption is that folks just don't want it bad enough for it to be prioritized beyond the pet-project/Personal Company game level.

[Duion]

As long as there is no hidden deeper reason why it has to be different I see no problem replacing it.

An ID system sounds fine, so every object/material gets an ID and you can define an explosion for each case.
If one wants to go the total modular road, I would assign a generic event for each object/material and then you can add a particle, explosion, sound etc to it, depending what you need.
For example currently you have particles, explosions(which are multiple particles + sounds + some additional settings like lengths, radius etc), sounds, splashes, footpuffs, impacts, this could all be united into one object, but these are just ideas, I do not really want to dig into, I would be totally happy with an explosion per object and material.