Major Airlock Hacking Code != Airlock Hacking Gameplay

[The Grim Sleeper]

So I was looking into how hacking doors works, and ended up looking at the v510 code to figure out why there are 2 seemingly useless wires.
The wiring for airlocks has changed since then, but this problem of the 'Backup Power Wires' has remained.


In the code, there are 4 power wires; 2 Main Power and 2 Backup Power. The following behaviour is implied the annotations :
When either Main Power wire is cut, the power goes down for 10 seconds and is then restored.
If either main power wire is intact, cutting a Backup Power wire has no effect.
When both Main Power wires are cut, and either Backup Power wire is uncut, power will be restored after 60 seconds (after the last disruption of Power)
When both Main Power wires are cut and both Backup Power wires are cut, the door is unpowered indefinitely.
Power would restore when any Power wire is mended.

During gameplay, behaviour is very different. It is almost as if there are 2 different types of Main Power wire.
If the first Main Power wire is cut, the power goes down for 10 seconds and is then restored.
If the second Main Power wire is cut and the first Main Power wire is intact, nothing happens.
But if the second Main Power wire is cut and the first Main Power wire is ALSO cut, the door is unpowered indefinitely.
Cutting either Backup Power wire has no real effect, except when trying to restore power after all 4 power wires have been cut;
After both Main Power wires are restored, the door remains unpowered!
It will remain so until 60 after either Backup Power wire is restored, after which power will restore.

I have a hunch on what is causing this behaviour.
All of the Power Checking 'proc's use short-cut || operators, which might behave slightly differently from full evaluation | operators.
I only know they do in Java, but I know bugger all about .dm.
There are also duplicate /proc's and var's to check whether a door is powered by main power or backup power.


Obviously, this can be pegged as 'a feature', but the code will remain, doing pointless math, which might be a problem.
Fixing this would take me more time then I have available atm (that is, if I even knew what I was doing), and also upset fans of the 'original implementation'.

Oh Great Goons, what say ye?

[Cirrial]

I haven't looked at this part of the code in exact detail but I'm fairly certain in DM that || is your standard lazy OR operator, which, as in Java, only evaluates both if absolutely needed. Whereas | is full evaluation in Java (something I previously did not know because I've never had a situation where I needed to use it) when applied to booleans and the bitwise OR when applied to numbers, the DM | operator is, uh, weird.

Code:

A and B must be between 0 and 65535 (2**16 - 1), giving an effective width of 16 bits.
If A and B are lists, the result is a list containing items that are in either list. list(1,2) | list(2,3) is equivalent to list(1,2,3). The items from A come first in the result, followed by any extra items from B.
If A is an icon or /icon datum, it is blended with B which can be either a color or another icon. Unlike the + or & operation, the result is transparent only in places where both icons were transparent.

Based on other things I've stumbled upon I'm reasonably sure the true culprit is inconsistencies across duplicate procs and vars.