The mesecons_compatibility doors erred in making steel doors, which
are meant to be locked, openable by anyone using a mesecon signal.
They also didn't handle mirror-paired doors, and nastily duplicated
lots of the standard door code rather than using it and adding to it.
Replace mesecons_compatibility with a new system, in which standard
doors are left alone and new types of door are added that have mesecon
behaviour. The new door types are each available in both wood and steel,
using the standard door textures.
The mesecon-operated doors open and close according to the mesecon
signal they receive: open when the signal is on and closed when off.
Unlike the old mesecons_compatibility doors, which only accepted the
signal to the bottom half, these accept the signal to either half of
the door. A convenient kind of control therefore is a wall-mounted
button just above the doorway: the signal flows diagonally down to the
top half of the door. The door cannot be operated manually.
The mesecon-signalling doors are opened and closed manually, and generate
a mesecon signal indicating whether they're open, on when open and off
when closed. Thus opening the door can trigger automatic activity.
Pairing a mesecon-signalling door with a mesecon-operated door results
in a door pair where right-clicking on one door operates both.
By making use of the pairing behaviour built into the standard doors mod,
which is inherited by the mesecon doors, and placing doors from sideways
angles, it is possible to effectively get mesecon doors with the opposite
signal sense. For example, a mesecon-signalling door that sends an on
signal when closed, turning the signal off when opened.
Some mesecon wires (the turned-on nodes) that were
not_in_creative_inventory and should never appear in an actual inventory
were also mesecon_conductor_craftable. This is liable to make a craft
guide show them as potential ingredients, due to the use of the group
in recipes.
The handling of the "quit" pseudo-field meant that the microcontroller
couldn't be programmed with explicit code, only with the examples.
The "quit" can actually be ignored: what matters for programming the
controller is whether the "code" field was supplied.
when powering off the delayer faster than the delay time.
Actually, delayers should have never worked since the ActionQueue update as
they always used the default rules for their output, which is obviously nonsense.
with comments. Also fixes a bug of lua- / microcontrollers not being updated when pushed by a
piston.
This could cause some bugs, even though I haven't found any while testing as it is a very core part of mesecons.
Why did we actually put the update action in a queue again? Whatever issue it that was for, I couldn't reproduce it.
Propably the ActionQueue fixed that...?
This adds a timer(<seconds>) function, which causes an event of type
"timer" to be fired after that many seconds has elapsed.
Because it's node timer based, it works properly across server restarts
and block unloading. Thus, simplest example, a blinky plant replacement
with a 10 second period:
if event.type == "program" then
timer(10)
elseif event.type == "timer" then
port.a = not port.a
timer(10)
end
Example of problem fixed by this: Edit lua code, press Execute. Now
(execute button has focus), hold down a key. Zillions of "program"
events are generated.
In the same way as for port settings, this queues up digiline messages
sent during the luacontroller's execution, and sends them afterwards.
This solves many problems, but one example:
1. Send a message, and receive a reply from another device.
2. While handling the reply event (effectively a nested invocation
on the same luacontroller) make a change to memory
3. Notice that the memory change has no effect, because after
completion of the reply handling, it stores the memory, but then
the original invocation completes and overwrites it with it's
own earlier copy of the same memory.
This introduces the ActionQueue, a new kind of MESECONS_GLOBALSTEP.
Circuits using delayers will now resume when restarting the server.
Also, large circuits should automatically resume if parts of them are
in unloaded chunks.
Old circuits e.g. using gates will not resume when mesecons is updated,
which means you have to restart them once. But after that, it should work
just like it used to.
This will fix a lot of stuff but may also introduce some new bugs.
So please report them!
This makes effectors nearer to the source of the action (the receptor) update first.
This defines behaviour for this piston circuit: http://i.imgur.com/9Pp2Mzb.png
And defines, that this memory circuit does not work from this direction: http://i.imgur.com/jJn0aFh.png
But it will work when using the switch from the other side: http://i.imgur.com/nvw0oZB.png
Only if two effectors have the same distance, there is nothing we can do about it, behaviour is not defined.
"Distance" is determined by the stack size of recursions in turnon / turnoff.
Priorities are between 0 (lowest) and 1 (highest).
Zefram
Jeija
Jeija
Ciaran Gultnieks
Anthony
Novatux
ShadowNinja
