Best practice to handle particle spawners?

Post Reply
User avatar
Linuxdirk
Member
Posts: 3219
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Best practice to handle particle spawners?

by Linuxdirk » Post

Currently I develop a mod that adds a configurable particle spawners (minetest.add_particlespawner()).

All configuration is done via node meta data. Players place a node and the initial node meta data is set using a custom after_place_node function. This function also starts the particle spawner and writes it's ID to the node's meta data. A custom on_destruct function reads the meta data and removes the particle spa

Players now can right-click the "particle spawner node" and get a formspec where they can configure some options regarding particle spawning. When sending the formspec fields the existing particle spawner gets deleted, the altered configuration is set to the node's meta data and a new particle spawner gets configured using the same function that is called in the after_place_node function.

During testing I noticed that particle spawners seem to be deleted/disabled when the node is unload. So I registered an ABM that checks for my "particle spawner nodes" in every load and set the particle spawner according to the node's meta data using the same function that's used in after_place_node and after sending the formspec fields.

While all of this works as expected (particle spawners can be set and removed and configured and are showed to all users and all changes are seen by all users and restarting the spawners when unloading them) I wonder: what is practice to handle spawners?

User avatar
sorcerykid
Member
Posts: 1847
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: Best practice to handle particle spawners?

by sorcerykid » Post

I'd suggest using dummy entities to maintain the particle spawner states. The advantage of this approach is that on_activate callbacks are invoked during successive mapblock reloads, giving you the opportunity to re-add the particles spawners directly without the need for ABMs. I use this technique for a number of audio-visual effects in my worlds. Here's one of the implementations I use.

After the node is placed, I add an entity and store the hashed position of the node as a property of the entity.
https://bitbucket.org/sorcerykid/holobl ...

The on_activate callback of the entity verifies that the associated node still exists. adds the current object reference to a registry table. and then initiates the corresponding effect. The getstaticdata callback saves the hashed position of the parent node and removes the current object reference from the registry table.
https://bitbucket.org/sorcerykid/holobl …

User avatar
Linuxdirk
Member
Posts: 3219
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Best practice to handle particle spawners?

by Linuxdirk » Post

Nice idea for getting rid of the ABM, thanks. Can I modify an object's meta data like node meta data? My mod allows changing some of the particle spawner's attributes by setting metadata and have the particle spawner (re-)generated by using the meta data. Or do I still store the configuration in the node and just have the object read that data?

How reliable are entities in multiplayer situations and with loading/unloading and being unloaded/loaded while the server is rebooted? What about despawning? What's with the performance?

User avatar
sorcerykid
Member
Posts: 1847
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: Best practice to handle particle spawners?

by sorcerykid » Post

It's certainly possible to store the particlespawner settings in the object's staticdata along with the key, but I'd recommend using the node meta for that purpose since objects are more at risk of being purged (as with clearobjects). Ultimately, it's a matter of personal taste.

It's fairly easy for the methods of the entity to get and set the node meta as the code shows. And since the settings interface is available via an on_rightclick callback of the node, then it probably makes sense to keep storage and settings related functionality in the node definition. Creation, removal, and updating of the actual particlespawner within the environment then is the responsibility of the entity.

User avatar
Linuxdirk
Member
Posts: 3219
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Best practice to handle particle spawners?

by Linuxdirk » Post

sorcerykid wrote:... but I'd recommend using the node meta for that purpose since objects are more at risk of being purged (as with clearobjects).
But then the particle generators are lost too. So I need something that re-creates the entities when lost for some reason. With everything controlled by the node and an ABM it's more secure regarding accidental purging of the objects.

CalebJ
Member
Posts: 407
Joined: Sat Dec 29, 2018 19:21
GitHub: KaylebJay
IRC: KaylebJay
In-game: CalebJ
Location: Tunnelers' Abyss

Re: Best practice to handle particle spawners?

by CalebJ » Post

This sounds really interesting, I've been wanting an easier way for particle spawning for a long time!
Will the mod make it possible to attach particle spawners to entities, too? :)

User avatar
Linuxdirk
Member
Posts: 3219
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Best practice to handle particle spawners?

by Linuxdirk » Post

CalebJ wrote:This sounds really interesting, I've been wanting an easier way for particle spawning for a long time!
Will the mod make it possible to attach particle spawners to entities, too? :)
Nope, it’s a single-purpose mod that adds static particle spawners to nodes for having smoke effects on said nodes.

I just want to make sure to use the most standard and “best” method doing so. Unfortunately minetest.add_particlespawner() isn’t used anywhere similar to my use case in Minetest and Minetest Game so there is no “official” reference implementation.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests