-
Notifications
You must be signed in to change notification settings - Fork 22
Things that ss Specs.txt does not want you to know.
ss-Specs.txt a fantastic resource for decoding the data but it has gaps and ambiguous descriptions in places.
Appear to have different action types(like triggers) controlled by 0x06 (int16) of the switches/panels tables (3.2.12)
Trigger Choice This appears to be a toggle.
Trigger Change type. For something like a forcefield this trigger will turn the object into an invisible place holder (great lords!). The change is within a subclass.
There are also some triggers which only appear to happen rarely. Eg Awakening sleeping drones.
Value (int8) at offset 21d of the subclass table is the target height (if not set then it's up to the ceiling)
Value (int8) at offset 24d of the subclass table is for direction. 0 is for going up. 1 is for pushing down
Value (int8) at offset 22d of the subclass table is for flags?
Elevators can move the floor, move the ceiling or both. It appears that ridiculously high values indicate what you should ignore. If you are like me and think the big blast door (to the north of where you start) on level 1 is a good example for testing then keep in mind it's slightly bugged in SS1. It won't return to it's start position or appear to stop when it reaches the floor due to it's sloped ceiling.
ss-Specs is a slightly misleading in it's description of the master object list in 3.2.1. The object type is the subclass number and the class index at 0x03 is the index in the sub table
Big thing to watch out for. Object references to other objects are based on the master table index. Try and avoid using the xref table beyond positioning objects and save yourself some headaches when figuring out what is what.
ss-specs seem to think that the subclass contains a value linking to a trigger xref. I can't seem to match up my values with this (either master/xref values). However the value seems to be set for all locked doors. That opened via a trigger/switch. The value is cleared when unlocked. Could the reference be to a variable in memory that behaves like UW a_lock objects??
Previous assumption about lighting is wrong. Following quote is from the SSHP's mailing list archive
I believe that I have finally cracked the System Shock lightmap system. Each tile has 2 light (well, dark really) fields, "upper" and "lower" of 4 bits each, in the tile flags (bits 24-27 upper and 16-19 lower). The way this is mapped onto vertices is very simple, which is probably why I had such trouble figuring it out. If a vertex belongs to a ceiling or is one of the top vertices of a wall panel it gets the "upper" light value. If it belongs to a floor or is one of the bottom vertices of a wall panel it gets the "lower" light value. Surfaces are then Gouraud-shaded in the usual way.
Dynamic lighting uses the last "state" byte of a tile definition. The 2 nybbles of this byte are subtracted from the upper and lower dark values before performing any lighting calculations.
Flickering appears to be controlled by Null triggers. Some null triggers have an undocumented action type 11 which appears to be a repeating action. They are usually activated by the level entry trigger. I think the lighting action trigger has a number of shade values that it can cycle through. The area of effect is a rectangle drawn between the tiles occupied by the two control points. The control points need not be triggers but in some cases are things like land-mines that are stuck inside the walls! One cool bug/behaviour examples to see happening to is to play the game in very easy mode. Travel the long way around to the radiation trench on level 1 via Shodan's "hive" and when you arrive there the lights are not flickering. This is due to them being activated by an entry trigger at the door near the wire puzzle. Another example is the light switch directly to the east of the start point that you get at via the wire puzzle outside the med bay door. It's control points extend outside of the room it is in and light up the wall near the wire puzzle. Light switches can also control lights directly but are only set up to do so on level one. On all other levels it's handled by null triggers that are linked to the switch. Update:Maybe I'm wrong about the cycling. Perhaps the lighting trigger defines a target value for the light to change to from the tile shade value and there are different types of transition of this. Flickering, flashing and change.
Some open tiles (type 1) will have slopes on them. These should be ignored.
Understanding steepness: The number is the amount of "steps" up or down that the slope goes up/down.
The value at 0x10(int32) of the tile map is crucial as it controls the vertical scale of the levels. All heights need to be shifted based upon this value (HeightUnits) as follows:
SHOCK_CEILING_HEIGHT = ((256 >> HeightUnits) * 8 >>3); //the top of the level
and for individual tile heights:
LevelInfo[x][y].floorHeight = ((LevelInfo[x][y].floorHeight <<3) >> HeightUnits)*8 >>3;
Note: I cribbed my implementation of this from Abysmal for this bit of code.
Also from abysmal re slope flags in the tile map
// TSSHP's ss-spec.txt says bits 13-12 but it's bits 11-10