Document Object Class 12 (Traps)

[dertseha]

Document the Marker objects:

• Level entry
• Class & Subclass info

[dertseha]

Added some lighting information.
The first value is interpreted either as a tile-radius or as a second object index.
In case of a second object index, the two objects describe a rectangle within which everything is illuminated. Example: The large button in the maintenance hallway south of the wakeup room.

The last bytes somehow seem to control how this is interpreted, but I haven't found the pattern yet.

[dertseha]

Action type 11 (0x0B) seems to be the timer action - the one regularly triggering other things, such as the door on level 1, near the resist area.

So far I haven't determined the complete field meaning. The action data would be so far:

    0000  int16      Object index to trigger
    0002  int16      Unknown
    0004  int16      Cycle time (one second ~ 0x10)
    0006  int16      Unknown
    0008  int16      Unknown. Cycles only when 0xFFFF

The field at 0008 is unclear. Perhaps this trigger has a limit?

[dertseha]

I had a look on the 4 unknown bytes marked as "condition". These fields do hold either references to object classes or game variables, but also a certain combination of values for SHODAN security limits.

I'd have guessed that they somehow have a common property to separate them, so far I haven't figured it out.

[dertseha]

Action type 17 (0x11) isn't used that often. One use is to let the monitor on level 2 display the layer safety override code. Other uses are not so clear yet.
It could modify an object parameter perhaps.

[dertseha]

Action type 18 (0x12) is used to show SHODAN for a brief moment on the monitors in the trap on flight deck (level 5). Another action to modify screen content?

[dertseha]

Action type 23 (0x17), which is meant to spawn things, isn't easily triggered as it seems. Neither through a button nor a trigger it would go off.
Does it only work through indirect events?

[dertseha]

...figures, the spawn action only works with combat minimum level 1. Still, the fourth parameter is unknown - changing it doesn't seem to make any difference.

[dertseha]

The trigger actions are coming together nicely. At one point the actions need to be refactored out, since most (if not all) are also usable as content for buttons - so, it's "actions" in general, not just for triggers. (Realizing this was a great help in testing.)

The actions missing now are 17, 18, 19, and 21.

The condition field is still unclear, as are some fields of the actions covered so far.

Still, a small milestone: this chapter already contains more information in both quantity and quality than TSSHP.

[dertseha]

Looking at action 18 (0x13), which is only called "Change object state" in TSSHP, I believe this is yet another dimension of actions. The first parameter seems to be the change-type, with 1 used to switch repulsors (keyed by param 2).

Changing the repulsors also changes the floor texture between the two texture indices stored in param 3 - but only if the current texture is the expected. This allows to have multiple switches toggle the same repulsor.

Speaking of repulsors, although they are in the same range as triggers (12/0/10) I don't think their data is an action.

[dertseha]

With change-type 9 starting the SHODAN pixelation overlay, I think this action is rather a general "change state" action. Fun time to suddenly see gray pixel appear :)

[dertseha]

Good progress on the state change action. Two are too elusive (state changes 7 and 8) and for now I treat them as non critical functions.

Two more state changes are missing as well, 13 and 14. 13 seems to be used to trigger other objects based on some level or bitfield. At least I found out that Diego is (or should be) capable of saying three different things at the final confrontation, as it is used on command level exclusively.
14 is used only once, on level R.

[dertseha]

I wonder why action 18 was created as 17 seems to be able to handle this as well. At least I'd expect it to, despite having not yet figured out what the second parameter of the screen actually is.

The final action, 21, seems to be a bit elusive for now. The second parameter seems to specify an area, but not always. The first parameter seems to be a bit field, but also a object reference.

Still, all in all there's more known than unknown already with the actions.

[dertseha]

I can't get behind this action 21. It's not used that often and only level 2 has a high use. Here are all occurrences (as triggers, I didn't check buttons):

UnknownAction 357: level 1: 0x15 -> 0x00080000, 0x01630164, 0x00000001, 0x00000000
UnknownAction  33: level 2: 0x15 -> 0x80000000, 0x014F0139, 0x00000001, 0x00000003
UnknownAction 168: level 2: 0x15 -> 0x00000106, 0x00020000, 0x00000002, 0x00000000
UnknownAction 314: level 2: 0x15 -> 0x00000106, 0x013A013B, 0x00000002, 0x00000000
UnknownAction 328: level 2: 0x15 -> 0x00000106, 0x00040000, 0x00000001, 0x00000000
UnknownAction 329: level 2: 0x15 -> 0x00000106, 0x00040000, 0x00000001, 0x00000000
UnknownAction 157: level 4: 0x15 -> 0x00000202, 0x009E009F, 0x00000002, 0x0000FFFF
UnknownAction 230: level 8: 0x15 -> 0x00080000, 0x00E700E8, 0x00000001, 0x00000001
UnknownAction 255: level 8: 0x15 -> 0x00020000, 0x01250126, 0x00000001, 0x00001111
UnknownAction 295: level 8: 0x15 -> 0x00020000, 0x01250126, 0x00000001, 0x00001111

If the first parameter can identify an object, level 2 refers with this 0x106 to a monitor in the library, showing static. The four triggers are entry trigger scattered around the main circle. Action 314 might refer to an area between itself (object 0x013A) and a dummy (?) object, covering the left storage with the droids.

The one use on level 1 would cover all the sleeping droids.

Is one use of this action to wake up enemies? Need to check with level 8 and possibly play level 1 with higher settings while not killing the sleeping drones.

[jramstedt]

Last 12 bytes in repulsor data are:

000A uint32 Start height
000E uint32 End height
0012 int32 Flags

Start height seems to be bottom and end height top. Repulsing is only done if player is between those.

[dertseha]

Thank you, @jramstedt - I'm still working on the editor performance rewrite, so taking this info in will still take a few weeks.

[dertseha]

The Critter AI Hint marker are interesting. They form a loop of such marker.

Could they describe areas within which critters should walk? unlikely, because there are only a few (4) of such areas in the archive - and critters do roam. Perhaps they are areas within which critters always see?

One area in level 9 has extra properties set at the end. No idea what they could mean.

Also, a few have their very first byte set to 6. Since there are more of such objects with the first byte 6 without meaning, I'm starting to believe this was a conversion early in the project, which blindly converted all bytes from zero to 6. Perhaps initially action type zero was to trigger other objects, that was changed to become the action 6...

I'll come back to them when I figured out how to spawn non-aggressive critters.

[jramstedt]

At the medical level one of the cyborg drone patrols around central hub. It matches the path. There must be index to one of the markers in that critters data or somewhere else.

[dertseha]

Ah, thanks for the hint! I yet have to come to the critters' data (soon to be), where I'll look for that.

[dertseha]

The "Music Voodoo Marker" (12/2/4) have only one byte set, in the range of [01..04]. So far I assume they may change the music patterns, I'm unsure about the affected area though.
Since construct so far doesn't have any music, I can't verify yet.

The game has only two such sets (two times four objects, each using 1 to 4 as their value), on level 3 and on level 5.

[dertseha]

Music voodoo marker described - I could finally play around with music in construct :)

[dertseha]

I figured out all fields of the Critter AI Hints, though their overall functionality is still shady at best. At least I could reproduce the one working example of such a path (the patrolling mutated cyborg on level 9).

My best guess is that because of critters only moving when the hacker is within their vicinity, which often makes them hostile anyway, these hints were rarely used. And the few ones meant for roaming critters could never be properly utilized.