Internal timer system rely on node position staying the same

[ryvnf]

Some simpler components (blinky plants and buttons) have been fixed to work with frames in Technic with a pull request in Technic. But it is impossible (or very difficult) to fix other components from Mesecons to work with frames in Technic, because of the way Mesecons implement timers for some components.

Mesecons uses an internal timer system (the mesecon.queue:add_action method`) for some components which rely on the node position being the same until the timer is triggered. Examples of components which rely on this are Delayers and Lua Controllers. This makes using these components unreliable with moving frames. One result of this is that a Lua Controller which controls a moving frame platform might freeze without a valid reason. This is really annoying when trying to build anything combining mesecons with moving frames.

[numberZero]

406

[ryvnf]

I wonder what the reason for this special internal timing API is. More flexibility? When was that required?

If it would be possible to rewrite all internal node timers to use the minetest.get_node_timer, that would completely solve the issue (assuming that the timer data is copied when the node moves, which should be the case). That would of course involve workarounds for more complex components like Lua controllers, which require multiple timers, but I think it would be worth it, to make the mod compatible with moving nodes.

[numberZero]

The original reason is that there was no node timers at the time. But currently, the API allows some nodes (Lua controllers primarily) to function continuously, independently of block activation.

[lolbinarycat]

additionally, if i understand correctly, nodes can only have one timer active at a time, no?