Document Object Class 9 (Panels)

[dertseha]

Document the Panels objects:

• Level entry
• Class & Subclass info

[dertseha]

I'm suspecting that the first level entry field (marked unknown in TSSHP) is the trigger type for buttons. For instance, on level 1, the first button to switch the door at the side is a 9/0/3 with this field set to 0x0006. The panel specific information contains the object index of the triggered object (the door).
Whereas the two buttons in the hallway to switch the lights are 9/0/2 with the first field set to 0x0007. The specific fields then don't match up to trigger a level object.

It of course could also mean that specific data is not only class/subclass dependent, but also type dependent. For now I'm still tending towards a switch within the same subclass instead of type specific data. Thinking of it, this could easily be verified by simply changing the type of a button and see if it still works the same.

[dertseha]

That theory was crushed quickly: I just saw numberpad panels are 9/3/7 and elevator panels are 9/3/5 - so, the same class/subclass but different specific layout.

This then also means you can't go by object name alone, as the buttons above are all called "BUTTON". There's a door button, a light button, ...
Still, the test to switch button type might be helpful. Triggers for instance also share the same data layout for all their types. Perhaps it's a mixture. There are type-specific data layouts, but some share theirs.

[dertseha]

I played a little with the wire puzzles. It seems like there is some extra behaviour with the current and target states of the wires. If the state is set to be 0-0 for a wire, the engine picks something on its own.

I haven't figured out whether this is for one-wire puzzles only or there is some extra state somewhere. Also, there are different colors per wire possible, how to achieve that?

[dertseha]

After I started with the marker/trigger documentation, I quickly found recurring numbers. For standard buttons, the content seems to match that of a trigger. For instance, trigger action 0x06 is trigger other object (i.e. activate door) and 0x07 is change lightning. Matches perfectly.

Will need more investigation, though this seems to fit.

[dertseha]

Triggers and (many) buttons share the same action domain. Differences may be in what type of conditions are used (possibel?)

On the topic of conditions, I'm making progress. In a byte sequence of AA BB CC DD:
DD seems to be the error message to give when condition fails to apply. 0xFF is the "blocked by security" message.
AA is the condition type. 0x1x is security, with x equaling to the level number. There are a few buttons that refer to other levels, not yet clear how that works exactly.

[dertseha]

I cracked the majority of the conditions: They are comparisons on game variables after all! The security checks are against the security values, which are stored in the game variables, like any others.
The ones I mistakenly thought to be checks on the level of another level are actually referring to boolean game variables.

This is great, because those conditions were the most illusive ones. What remains should be those for specific objects or object IDs.

[dertseha]

One of the last conditions must make it difficult. The retinal ID scanner (9/1/6) has a condition of 06 00 00 00. While all other recepticles have an object type as condition, this seems to be a game variable condition.
And it doesn't work.
Setting the whole condition to zero lets it accept all heads (except that of the hacker). The value 6 is also not the image index of the head, as the head with which it works in the main game has index 0x0B.

[dertseha]

All of the main properties of panels have been documented. The following points are open:

• Some actions are not fully covered yet, this is to be handled in Document actions #54
• There are a few spurious bytes set to arbitrary values for three panels (first and next to last bytes). For now I'll leave them as anomaly without effect.
• The condition for the retinal ID scanner is still unsolved. This is the main reason for leaving this issue open with respect to level properties.
• generic properties still not covered.