I am pretty sure that this can be combined with the editor actions, too, very likely in a easy way. Looking back at what I wrote: It's not really an answer, just reflecting the problem and a proposal how to implement that, with a conclusion what I actually want to do.

-- Reflection:

I'll sum up the idea from Mimmo's thread again - on the other hand, this solution is most likely to create an (unnecessary?) inner platform, because the idea behind it comes from programmable logic controllers which have some restrictions compared to programming languages. There, you have input- and/or output signals in mechanisms, and you can connect this directly, or connect them with logic modules in between, the complexity of this logic is up to you. Basically it's a more complicated version of writing a program, but it is also very modular.

From the perspective of efficiency I'd say that's somewhat useless, because in many cases you can just write a script that does exactly what you want: If all four switches are on, then open the door.

From the perspective of easy scenario design via editor and even ingame options (you cannot simply write a script there, obviously), it makes sense to have something like that.

So, back to the doors and logics stuff. Here it should become apparent why that would create an inner platform, if we stick strictly to the way PLCs handle that:
* a switch would have a boolean output signal for it's current state (local variable/property internally)
* a switch could have a boolean input signal that sets it's current state and therefore the output signal (internally I'd just set the same local variable/property as for the output signal)
* a door has the same, so you can just access whether it is opened or closed.
* connect switch output to door input (whether in editor or ingame) => the door opens when the switch is set to true, and closes when the switch is set to false. In the editor you would/could have actions/triggers that are evaluated when the door opens/closes.
* when connecting a signal to another one you could choose whether to invert the signal (so that you can have one door that closes when the switch is on the left side, and another one that closes when the switch is on the right side)

Now, this is a really basic example, and I think it already illustrates where this PLC stuff seems more complicated than it needs to be. On the other hand, it allows doing some nice stuff really easily. Let's say the steam engine offered an output signal that says wether it is at full pressure or something. Then you could have a door that opens on this condition, or have something else happen. You could connect them to some other modules, so that the door opens if the steam engine has full pressure and the elevator is down, or something like that.

-- Proposal:

Anyway, this feels a lot like being things that you could already do now by accessing local variables or calling functions, just not in an ingame plug-and-play fashion. In order for this to work in a more generic way it might be sufficient to describe the mechanisms "interface" with a proplist (which will most likely look very similar to an editor action, please correct me), such as:

open_door = new Signal { // no idea what the "signal" prototype would look like, just a proposal for now
   Name = "Open door", // or some localized text, as an ingame and editor display
   Description = "Opens the door when the value is 'true', closes the door when the value is 'false'", // same as above, for ingame and editor display
   Action = ... // what happens when the signal is being set - I am being very vague here for now, because as I write this, it seems as if we already have all this in the editor actions, but I don't have access to that code right now
}


As you may guess, I am a little confused right now :) Actually, I want to not needlessly introduce new scripting formats and so on, if we already have such a thing, so if doing this is possible via editor actions, then I am glad.

-- Conclusion

First and foremost what I want is to remove the hardcoded interactions with doors from switches, and allow them to connect to and operate arbitrary mechanisms instead.