Change mesecons signals so that they update effectors only after a globalstep

[Ekdohibs]

It decreases server load, and is configurable to be on/off. It moreover allows pipelined circuits and precise timings, which were not possible before.

[Uberi]

I see a typo in settings.lua. If it was misspelled during testing, it's possible that the test runs didn't use the globalstep functionality at all.

I like the idea, anyways. Seems like it would simplify a lot of things that are currently done in a roundabout way. Would this break any existing circuits, such as high frequency oscillators, timing sensitive circuits, etc.? I am aware that it is configurable.

[Ekdohibs]

Just fixed that typo... The tests ran with the functionality, since I thought that configurability would be good after I made the tests (in fact, just before the pull request). It could break circuits because of delayers, but otherwise, it should work (but slower)

[Jeija]

I wonder if you could instead just make mesecon:receptor_on/off call
minetest.do_after(0, actually_receptor_on/off, pos, rules)

I haven't actually read through the whole code, but wouldn't that have the same effect?
(Sorry for not reading everything, I've been away as you may have noticed and got a lot of eMails and stuff to read and do now)

[Ekdohibs]

Almost, but there is one difference: with my pull request, if an effector an changes several times, there will be only one call for it (action_on if it went from off to on, action_off if it went from on to off, and action_change if it was updated)

[Uberi]

I imagine that rapidly flipping a switch on and off would no longer be detectable by any circuitry if it's faster than a single server step.

If there is a good use case for flipping a switch that fast or in general, making faster-than-server-step changes, I'd go with Jeija's proposed solution. Otherwise, predictable effector updating seems like a really useful feature too.

tl;dr +1 but have concerns about backwards compatibility.

[Ekdohibs]

The only use I saw so far was when I tried to make flip-flops that acted on rising edges... However, it was very difficult to make them work and it depended to the internals of mesecons so much that turning them 90° or changing the order of the default rules broke the circuit. For flipping a switch that fast, it is almost impossible, since globalstep is only 1/20 second, and I have seen so far no detector that made changes that fast. Moreover, with the old way, and with big circuits, half the circuit will be updated dozens of times, because it uses depth-first updating.
I do not see circuits that would be broken, except my computers, and even my multiplier, which is an quite big machine, would still work. As for machines using luacontrollers, they will still work, event if the luacontroller is updated faster than globalstep (since interrupts ans not affected). Finally, updates faster than globalstep are not far from overheating gates, etc...

[Uberi]

That seems reasonable. We'll deal with any issues as they come up.

[Uberi]

I had to revert this and put it in its own branch since it broke sticky pistons (see #104 for more information) and could potentially permanently break a lot of machines that depend on them. It also seems to lag upon retraction of any type of piston. This probably needs a bit more testing before use.

[Ekdohibs]

I tried the sticky pistons just now, and I haven't found a bug, even when the pistons push and pull large amount of blocks or mesecons conductors. They don't delete the blocks they pull, there is no more lag than before when flipping rapidly the state of lots of pistons, ...

[Uberi]

Are you sure you're using 49dcd97? VanessaE and I have independently confirmed the issues with that particular commit.

Here's the test case used:

Dirt Left-facing-sticky-piston Switch

When the switch is turned on, the piston extends as expected. However, when turned off, the piston retracts and the dirt disappears completely. In addition, the server lags for about half a second. I was using an empty test world, while VanessaE used the public creative server.

I can test it again and try to have more details when I get home. I am running minetest/minetest@e57dc4e, by the way.

[Ekdohibs]

I am sure of it, since I connected a clock generator composed of 7 inverters in a row (no delayer) to about 25 sticky pistons, and there was no lag... That clock generator would have overheated or crashed the server without that commit. Moreover, I downloaded the branch directly from GitHub, so I am sure it is the correct one. I am running a bit more recent version of Minetest, however (less than 10 days old). Moreover, I even tried complex circuits with pistons that involved moving mesecons conductors, like an RS flip-flop, and it worked perfectly. I tried it in a world with only mesecons things enabled, and with creative mode.

[Uberi]

Aha! When the MESECONS_GLOBALSTEP setting is false (not true as I previously thought), the lag and the disappearing issue shows up. When the setting is enabled again, it behaves perfectly as you described. That should be a lot easier to fix, since all that needs to be done is to switch between the old and new versions based on the setting.

The new behavior causes pistons to perform pretty impressively as well - most known piston glitches no longer show up.

tl;dr it's actually broken when the setting is false.

[Ekdohibs]

I know where it comes from: when I wanted to add a setting for the new behavior, I uncommented some code I had commented, but I perhaps forgot some of it. I will soon fix this.

[Ekdohibs]

The branch is fixed now, perhaps you should re-merge it.

[Ekdohibs]

Added code so that circuit won't be stopped on server stop or on area unload.

[Uberi]

Unfortunately, it seems that sticky pistons still make nodes disappear when retracting when the MESECONS_GLOBALSTEP setting is disabled. This is not the case when it is enabled. I am using minetest/minetest@4f6bec1 with Ekdohibs/minetest-mod-mesecons@50290ba. Perhaps it has something to do with mesecons:activate and mesecons:deactivate.

[Ekdohibs]

I just fixed it: it was some code I forgot to put in the if condition, try it now... I hope this works (I tested it this time, and there is problem).

[Uberi]

Done! afad592