Limit piston speed

[numberZero]

Fix #499.
The delay is configurable. Old behavior can be restored by using special settings, as described.

[Desour]

Such a change in behaviour will likely break constructions. Eg. think of piston doors or the double sticky piston driver: http://mesecons.net/uberi/projects/DoublePiston/index.html

I'd prefer a solution with overheating:

• Instantaneous (= with 2 steps delay, as always) reaction.
• Pistons can overheat. They won't drop but are replaced with an overheated piston node (or just overheated piston base if it's activated). Overheated pistons do not react to signals.
• Overheated pistons automatically cool down after ca. 1 second (eg. with node timer or action queue).

[numberZero]

Indeed, double piston becomes unreliable, not due to delays (interrupt times could be adjusted accoddingly) but due to imprecise timings. That’s not easily fixable, so yes, overheating may be better.

Overheated pistons automatically cool down after ca. 1 second (eg. with node timer or action queue).

Isn’t 1 second too little?
Also there is a crucial difference between action queue and node timers: the former runs everywhere while the latter runs in active blocks only. I’d prefer the latter although it might be problematic in the case of spurious overheats.

[Desour]

Isn’t 1 second too little?

Yeah, 5 seconds or whatever is fine too.

Hmm, action queue might be better.
A mesecons cable can go far away to an unloaded piston. That piston needs to cool down. (As long as it doesn't overheat it will already cool down in unloaded area.)

[numberZero]

That way a piston-oscillator would cool down and resume operation after these 5 seconds. It would overheat again ofc, but only for next 5 seconds after which it would resume again, ad infinitum. OTOH with node timers that would only happen when there is someone nearby (or the block is anchored but that’s admin-controllable).

[numberZero]

Note that adding several single-step delays seems to make the double piston work reliably:

piston_delay = 0.15
if event.iid == "pull1" then
  port.b = false
  interrupt(0, "push2")
elseif event.iid == "push2" then
  interrupt(piston_delay, "push3")
elseif event.iid == "push3" then
  interrupt(0, "push4")
elseif event.iid == "push4" then
  port.c = true
  interrupt(0, "pull3")
elseif event.iid == "pull3" then
  interrupt(piston_delay, "pull4")
elseif event.iid == "pull4" then
  interrupt(0, "pull5")
elseif event.iid == "pull5" then
  port.c = false
else
  if pin.a then --extend
    port.b = true
    port.d = true
  else --retract
    port.d = false
    interrupt(0, "pull1")
  end
end

(not sure are all these delays necessary; also there is no protection against too fast switch toggling)

Also it is possible to drive the double piston like that (the diode is used for the same, to add a single-step delay):

Note that due to the way Mesecons operate, it is important that the back piston is farther (wire-wise) from the signal source, that ensures the front piston retracts first.

Also there seems to be a bug in the action queue: when several delayed events expire, it ignores expiration time even if it was different (so an action with later time can fire earlier if it was added earlier); see #551.