Adding modding folder with a hacked build.
This commit is contained in:
ml
@@ -0,0 +1,79 @@
|
||||
### Gun Properties
|
||||
|
||||
#### Generic Gun Properties
|
||||
|
||||
**Generic Gun Propertes** (`GunProp` struct) (2 bytes)
|
||||
|
||||
0000 uint8 Fire rate
|
||||
0001 byte Ammo type
|
||||
|
||||
For non-automatic guns, the `fire rate` specifies when the next bullet can be shot. For melee weapons it is the time until the next swing can be made.
|
||||
It is measured in game time, with a unit for this value of about 36 milliseconds. A value of ```0x00``` means 'as fast as you can press fire'.
|
||||
> Changing this value does not have any detectable effect for automatic guns (```0/1/x```).
|
||||
|
||||
|
||||
**Ammo type** (1 byte)
|
||||
|
||||
0xF0 Ammo subclass identifier
|
||||
0x0F Bitmask, which ammo types within the ammo subclass are compatible (0..3)
|
||||
|
||||
> Ammo type is ignored for beam and melee weapons.
|
||||
|
||||
|
||||
#### Specific 2 Properties
|
||||
|
||||
This subclass describes special projectile weapons.
|
||||
|
||||
**Specific 2 Properties** (`SpecialGunProp` struct) (16 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 uint8 Projectile travel speed
|
||||
0009 int32 Projectile triple (0x00CCSSTT)
|
||||
000D uint8 Attack mass
|
||||
000E sint16 Attack speed (kickback)
|
||||
|
||||
|
||||
#### Specific 3 Properties
|
||||
|
||||
This subclass describes melee weapons.
|
||||
|
||||
**Specific 3 Properties** (`HandtohandGunProp` struct) (13 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 uint8 Energy usage
|
||||
0009 uint8 Attack mass (impact force - pushback on hit)
|
||||
000A uint8 Range
|
||||
000B sint16 Attack speed (kickback; only applied if hitting something)
|
||||
|
||||
|
||||
#### Specific 4 Properties
|
||||
|
||||
This subclass describes energy beam weapons.
|
||||
|
||||
**Specific 4 Properties** (`BeamGunProp` struct) (13 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 uint8 Max charge
|
||||
0009 uint8 Attack mass (impact force - pushback on hit)
|
||||
000A uint8 Range
|
||||
000B sint16 Attack speed (kickback)
|
||||
|
||||
|
||||
#### Specific 5 Properties
|
||||
|
||||
This subclass describes energy projectile weapons.
|
||||
|
||||
**Specific 5 Properties** (`BeamprojGunProp` struct) (18 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 uint8 Max charge
|
||||
0009 byte Attack mass
|
||||
000A sint16 Attack speed (kickback)
|
||||
000C uint8 Projectile travel speed
|
||||
000D int32 Projectile triple (0x00CCSSTT)
|
||||
0011 byte Flags
|
||||
|
||||
|
||||
**Energy Projectile Weapon Flags** (1 byte)
|
||||
|
||||
0x02 Stun effect
|
||||
@@ -0,0 +1,9 @@
|
||||
### Level Gun Table (Class 0)
|
||||
|
||||
```L10``` is a table describing weapons and entries extend [the prefix](../../archives/levelObjects.md#class-specific-information) with their current ammo or charge.
|
||||
|
||||
**Level Gun Entry** (8 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 byte Ammo type / Charge
|
||||
0007 byte Ammo count / Temperature
|
||||
@@ -0,0 +1,12 @@
|
||||
### Ammo Properties
|
||||
|
||||
#### Generic Ammo Properties
|
||||
|
||||
**Generic Ammo Propertes** (`AmmoProp` struct) (14 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 uint8 Cartridge size
|
||||
0009 uint8 Bullet mass (impact force - pushback on hit)
|
||||
000A sint16 Bullet speed (kickback)
|
||||
000C uint8 Range
|
||||
000D uint8 Recoil force
|
||||
@@ -0,0 +1,7 @@
|
||||
### Level Ammo Table (Class 1)
|
||||
|
||||
```L11``` is a table for ammo clips. Since clips are always full, entries have no further fields.
|
||||
|
||||
**Level Ammo Entry** (6 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
@@ -0,0 +1,42 @@
|
||||
### Physics Properties
|
||||
|
||||
#### Generic Properties
|
||||
|
||||
**Physics Generic Properties** (`PhysicsProp` struct) (1 byte)
|
||||
|
||||
0000 byte Physics flags
|
||||
|
||||
|
||||
**Physics Flags** (1 byte)
|
||||
|
||||
0x01 Emit light
|
||||
0x02 Bounce off walls
|
||||
0x04 Bounce off objects (real world), Pass through objects (cyberspace)
|
||||
0x08 Bounce off projectiles; set for all cyberspace projectiles
|
||||
|
||||
|
||||
> Cyberspace projectiles can't emit light, though they can bounce off walls.
|
||||
|
||||
|
||||
#### Specific 0 Properties
|
||||
|
||||
"Tracer" objects.
|
||||
|
||||
> These are not used in the engine.
|
||||
|
||||
**Physics Specific 0 Properties** (`TracerPhysicsProp` struct) (20 bytes)
|
||||
|
||||
0000 [4]int16 X coordinates
|
||||
0008 [4]int16 Y coordinates
|
||||
0010 [4]uint8 Z coordinates
|
||||
|
||||
|
||||
#### Specific 1 Properties
|
||||
|
||||
These properties are set for some `2/1/x` objects. More specifically: For cyberspace projectiles, also called "slow physics". The other projectiles of this subclass have their specific bytes zero.
|
||||
|
||||
**Physics Specific 1 Properties** (`SlowPhysicsProp` struct) (6 bytes)
|
||||
|
||||
0000 [6]byte Colour scheme
|
||||
|
||||
`Colour scheme` contains 6 palette indices from the game palette. The index into this list comes from the geometry properties, specifically from the [Set Colour and Shade](../../media/Geometry#set-colour-and-shade) command.
|
||||
@@ -0,0 +1,50 @@
|
||||
### Grenade Properties
|
||||
|
||||
#### Generic Grenade Properties
|
||||
|
||||
**Generic Grenade Propertes** (`GrenadeProp` struct) (15 bytes)
|
||||
|
||||
0000 [8]byte [Generic Weapon Info](../GenericWeaponInfo.md)
|
||||
0008 byte Touchiness
|
||||
0009 byte Blast radius
|
||||
000A byte Blast core range
|
||||
000B byte Blast damage
|
||||
000C uint8 Attack mass (impact force - pushback on hit)
|
||||
000D int16 Grenade Flags
|
||||
|
||||
`Touchiness` defines how likely a grenade is going to chain-explode if another was exploding nearby.
|
||||
> This value influences a calculation, based on a random value, as well as damage percentage. If the resulting number is higher than 7, then a chain-reaction is caused.
|
||||
> In the main game, this value is always `0x00`.
|
||||
|
||||
`Blast radius` specifies in tiles how far the explosion reaches, including visual effects (EMP scroll, explosion flash).
|
||||
|
||||
The main damage (from the `Generic Weapon Info`) is applied within the `Blast core range` of the explosion. This damage falls off from the center to the edge of the core range.
|
||||
|
||||
The `blast damage` is fully applied within the `blast core range`, additionally to the main damage. This damage falls off from the edge of the core range to the edge of the blast radius.
|
||||
|
||||
|
||||
**Grenade Flags** (2 bytes)
|
||||
|
||||
0x01 Explode on contact
|
||||
0x02 unused
|
||||
0x04 Explode by timer
|
||||
0x08 Explode by vicinity (mine)
|
||||
|
||||
> The behaviour of grenades is not exclusively governed by the flags field. Some seems to be hardcoded.
|
||||
> For instance, regular grenades marked with "timer" don't offer a time setting in the HUD and explode right after being thrown.
|
||||
> Regular timed grenades marked as "contact" ignore their timer setting, explode on object-contact, but not on floor/wall contact.
|
||||
|
||||
|
||||
#### Specific 1 Properties
|
||||
|
||||
Properties for timed grenades.
|
||||
|
||||
**Specific 1 Properties** (`TimedGrenadeProp` struct) (3 bytes)
|
||||
|
||||
0000 uint8 Minimum time
|
||||
0001 uint8 Maximum time
|
||||
0002 uint8 Timing deviation -- always 0x00
|
||||
|
||||
`Minimum time` and `maximum time` specify the range, in seconds, timed grenades can be set to.
|
||||
|
||||
> `Timing deviation` is always set to 0x00. Since it may also let the grenade go off earlier than expected, this may happen while still in the hand - which is presumably why it is unused in the main game.
|
||||
@@ -0,0 +1,44 @@
|
||||
## Level Explosive Table (Class 3)
|
||||
|
||||
```L13``` is a table describing explosives.
|
||||
|
||||
**Level Explosive Entry** (12 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [6]byte Explosive data
|
||||
|
||||
**Explosive Data** (6 bytes)
|
||||
|
||||
0000 int16 Unknown; Only set for live explosives
|
||||
0002 int16 State
|
||||
0004 int16 Timer time
|
||||
|
||||
|
||||
**State** (2 bytes)
|
||||
|
||||
0x0000 Inert
|
||||
0x0001 Thrown live grenade
|
||||
0x0005 Landed live grenade (land mines only, can't be picked up)
|
||||
|
||||
|
||||
The timer settings of explosives are stored in the [game state](../../archives/gameState.md).
|
||||
|
||||
The ```Timer time``` field is set to the same value as in the [level schedules](../../archives/levelSchedules.md), though modifying this value doesn't have an effect. The level timer is the authorative entry when to trigger the explosive.
|
||||
|
||||
|
||||
### Contact explosives 3/0/x
|
||||
|
||||
Contact explosives start a timer, though its expiry does nothing with the grenade.
|
||||
Land mines can be catched mid-air and re-thrown, others explode. Land mines enter state ```0x0005``` when touching the ground, after which they can't be picked up safely anymore.
|
||||
|
||||
> Although the game state also keeps time settings for these explosives, they can't be changed. Their timer don't have an effect anyway.
|
||||
|
||||
|
||||
### Timed explosives 3/1/0, 3/1/1
|
||||
|
||||
These explosives keep the state at ```0x0001```, even when landed. Live explosives can be picked up and re-thrown, until their timer sets them off.
|
||||
|
||||
|
||||
### Object explosion 3/1/2
|
||||
|
||||
This item has not been encountered.
|
||||
@@ -0,0 +1,9 @@
|
||||
### Level Drug Table (Class 4)
|
||||
|
||||
```L14``` is a table describing Drugs.
|
||||
|
||||
**Level Drug Entry** (6 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
|
||||
This entry does not contain any more information.
|
||||
@@ -0,0 +1,9 @@
|
||||
### Level Hardware Table (Class 5)
|
||||
|
||||
```L15``` is a table describing hardware.
|
||||
|
||||
**Level Hardware Entry** (7 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 byte Hardware version
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
## Level Software Table (Class 6)
|
||||
|
||||
```L16``` is a table describing software - programs, logs, data...
|
||||
|
||||
**Level Software Entry** (9 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [3]byte Software data
|
||||
|
||||
|
||||
### Cyberspace programs 6/0/x, 6/1/x, 6/2/x
|
||||
|
||||
**Cyberspace program data** (3 bytes)
|
||||
|
||||
0000 byte Version
|
||||
0001 [2]byte Unused
|
||||
|
||||
|
||||
> The three subclasses can be considered "aggressive programs", "defensive programs" and "boosts". Boosts ignore the version.
|
||||
> Although several programs are defined, only a few are used.
|
||||
> Different version numbers also change the color of the cube.
|
||||
|
||||
|
||||
### Fun pack modules 6/3/0
|
||||
|
||||
**Fun pack module data** (3 bytes)
|
||||
|
||||
0000 byte Game mask
|
||||
0001 [2]byte Unused
|
||||
|
||||
**Game mask** (1 byte)
|
||||
|
||||
0x01 Ping
|
||||
0x02 Eel Zapper
|
||||
0x04 Road
|
||||
0x08 Botbounce
|
||||
0x10 15
|
||||
0x20 TriopToe
|
||||
0x40 Gameb (Not working, gives "not installed" message)
|
||||
0x80 Wing 0
|
||||
|
||||
|
||||
### Multimedia data 6/4/0, 6/4/1
|
||||
|
||||
**Multimedia software data** (3 bytes)
|
||||
|
||||
0000 byte Unused
|
||||
0001 byte Index
|
||||
0002 byte Type
|
||||
|
||||
**Multimedia type** (1 byte)
|
||||
|
||||
0x00 E-Mail
|
||||
0x01 Log
|
||||
0x02 Data
|
||||
|
||||
> In the game, e-mails are received through triggers, logs are only in real-world levels, and data only in cyberspace levels. The engine supports placing any of them in any level type.
|
||||
|
||||
|
||||
#### Logs
|
||||
|
||||
For logs, the ```Log resource offset``` is based on the resource ID ```0x09B8```. The high nibble is used as the level identifier - into
|
||||
which category the log should be put.
|
||||
|
||||
See [Electronic Messages](../../content/ElectronicMessages.md) for details on messages.
|
||||
|
||||
> 6/4/0 are called "TEXT", behave like 6/4/1 "EMAIL", and are only used as logs.
|
||||
|
||||
|
||||
|
||||
## Cyberspace "Scenery" Software (Class 7, in cyberspace)
|
||||
|
||||
In cyberspace levels, ```L17``` is a table for additional software. It acts as an overflow for software if the first table is full.
|
||||
|
||||
**Scenery Software Entry** (16 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [10]byte Scenery software data
|
||||
|
||||
|
||||
### Scenery software 7/3/2 ("GLOW BULB"), 7/2/0 ("SIGN")
|
||||
|
||||
**Scenery software data** (10 bytes)
|
||||
|
||||
0000 int16 Parameter
|
||||
0002 int32 Subclass
|
||||
0006 int32 Type
|
||||
|
||||
|
||||
For entries that specify a program, ```Parameter``` specifies the version. For fun packs, it is the game mask.
|
||||
|
||||
> This type is only used for software with a single parameter; Found only for programs and fun packs.
|
||||
@@ -0,0 +1,220 @@
|
||||
## Level BigStuff Table (Class 7)
|
||||
|
||||
```L17``` is a table describing big items in real-world levels.
|
||||
|
||||
Cyberspace levels may re-use "big stuff" entries for further software entries. These entries need to be
|
||||
interpreted differently. See [Software](../06_Software/levelSoftwareEntry.md).
|
||||
|
||||
|
||||
**Level BigStuff Entry** (16 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [10]byte BigStuff Info
|
||||
|
||||
### Displays
|
||||
|
||||
There are several big items that are capable of displaying (animated) content. They reuse the following common types:
|
||||
|
||||
**Display Info** (10 bytes)
|
||||
|
||||
0000 int16 Frame count
|
||||
0002 int16 Loop type
|
||||
0004 int16 Alternation type
|
||||
0006 int16 Picture source
|
||||
0008 int16 Alternate picture source
|
||||
|
||||
Animated screens are also controlled by the [Loop Configuration](../../archives/loopConfiguration.md). If not, they use their own loop type.
|
||||
|
||||
**Loop Type** (1 byte)
|
||||
|
||||
0x00 Forward
|
||||
0x01 Forward/Backward
|
||||
0x02 Backward
|
||||
0x03 Forward/Backward
|
||||
|
||||
> Other values have been found as well, without effect; The engine defaults to forward looping.
|
||||
|
||||
|
||||
** Alternation Type** (1 byte)
|
||||
|
||||
0x00 Don't alternate
|
||||
0x03 Alternate randomly
|
||||
|
||||
> Not all alternate source combinations work properly. Commonly it is used to alternate to a text.
|
||||
|
||||
|
||||
**Picture Source** (2 bytes)
|
||||
|
||||
This field specifies what shall be shown. It has the following cases:
|
||||
|
||||
0x0000 .. 0x00F5 Image frames, offset from resource 0x0141
|
||||
0x00F6 Static fading into SHODAN's face
|
||||
0x00F7 Unknown (only found to display static)
|
||||
0x00F8 .. 0x00FF Surveillance screens 0 .. 7
|
||||
0x0100 .. 0x017E Text message from resource 0x0877
|
||||
0x017F Random number for CPU rooms, level 1-6 before destroying nodes.
|
||||
0x0180 .. 0x01FF Text message, scrolling vertically
|
||||
|
||||
For surveillance screens, the sources of screens 0-7 are specified in the [Surveillance Sources Table](../../archives/surveillanceCameras.md).
|
||||
|
||||
|
||||
The following big items support displays:
|
||||
7/0/6 (TV), 7/0/7 (COMPUTER MONITOR),
|
||||
7/2/6 (SCREEN, small), 7/2/8 (SCREEN, large), 7/2/9 (SCREEN, medium),
|
||||
with variation: 7/5/5 (CONTROL PANEL), 7/5/6 (CONTROL PEDESTAL) (see below)
|
||||
|
||||
### Electronics 7/0/x
|
||||
|
||||
> Apart from some displays, nothing special
|
||||
|
||||
|
||||
### Furniture 7/1/x
|
||||
|
||||
#### Cabinets 7/1/2
|
||||
|
||||
**Cabinet Data** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 [2]int16 Object index
|
||||
0006 [4]byte Unused
|
||||
|
||||
Cabinets can contain up to two objects.
|
||||
|
||||
|
||||
#### Texturable furniture 7/1/5, 7/1/7, 7/1/8 (chairs and couches)
|
||||
|
||||
**Texturable Furniture Data** (10 bytes)
|
||||
|
||||
0000 [6]byte Unused
|
||||
0006 int16 Texture index
|
||||
0008 [2]byte Unused
|
||||
|
||||
If ```Texture index``` is not zero, it specifies the alternate texture to use for the "main" faces of the furniture.
|
||||
|
||||
|
||||
### Surfaces 7/2/x
|
||||
|
||||
These are big objects that are flat and should be placed at another surface.
|
||||
|
||||
#### Words 7/2/3
|
||||
|
||||
**Words BigStuff Data** (10 bytes)
|
||||
|
||||
0000 int16 Text index (within resource 0x0868)
|
||||
0002 int16 Font and size (bits 0-3 are font, 4-7 are size)
|
||||
0004 int16 Colour (palette index, 0 defaults to red)
|
||||
0006 [4]byte Unused
|
||||
|
||||
|
||||
#### Texture Maps 7/2/7
|
||||
|
||||
**Texture map big stuff** (10 bytes)
|
||||
|
||||
0000 [6]byte Unused
|
||||
0006 int16 Texture index
|
||||
0008 [2]byte Unused
|
||||
|
||||
Texture maps allow to place one tile from the level texture list at any arbitrary position.
|
||||
|
||||
### Lighting 7/3/x
|
||||
|
||||
### Medical equipment 7/4/x
|
||||
|
||||
#### Control Pedestals (buttons only) 7/4/0
|
||||
|
||||
These can trigger an object if used.
|
||||
|
||||
**Button Control Pedestal Info** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 int16 Trigger object index
|
||||
0004 [6]byte Unused
|
||||
|
||||
|
||||
#### Surgery Machines 7/4/3
|
||||
|
||||
**Surgery Machine Info** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Broken state; 0x00 = OK, 0xE7 = broken
|
||||
0003 [2]byte Unused
|
||||
0005 byte Broken message index; Broken default: 0x61
|
||||
0006 [4]byte Unused
|
||||
|
||||
With all bytes zero, the surgery machine works normally.
|
||||
|
||||
When the ```Broken state``` field is set to a certain value (the game has ```0xE7``` for the one on level 2, though some other work, too), then the machine wouldn't work. When not working, the message identified with ```Broken message index``` is displayed in the HUD. (```0x61``` = "This machine is broken").
|
||||
|
||||
|
||||
#### Textureable Furniture 7/4/5 (chairs)
|
||||
|
||||
These have the same layout as the general textureable furniture (see above).
|
||||
|
||||
|
||||
### Science and security equipment 7/5/x
|
||||
|
||||
#### Security Cameras 7/5/4
|
||||
|
||||
**Security Camera Info** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Panning switch; 0x00: stationary, 0x01: panning
|
||||
0003 [7]byte Unused
|
||||
|
||||
|
||||
#### Control Pedestals (with display) 7/5/5, 7/5/6
|
||||
|
||||
Control pedestals are similar to displays regarding the source of the display.
|
||||
Instead of having different loop options, they trigger an object if used.
|
||||
|
||||
**Display Control Pedestal Info** (10 bytes)
|
||||
|
||||
0000 int16 Frame count
|
||||
0002 int16 Trigger object index
|
||||
0004 int16 Alternation type
|
||||
0006 int16 Picture source
|
||||
0008 int16 Alternate picture source
|
||||
|
||||
|
||||
### Garden big stuff 7/6/x
|
||||
|
||||
### Bridges 7/7/x
|
||||
|
||||
#### Solid Bridges 7/7/0, 7/7/1
|
||||
|
||||
**Solid Bridge Info** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Size. Bits 0-3: X, bits 4-7: Y
|
||||
0003 byte Height. 0 is default, level height units otherwise.
|
||||
0004 byte Top/Bottom texture
|
||||
0005 byte Side texture
|
||||
0006 [4]byte Unused
|
||||
|
||||
The size fields are defined as 0: 3D model default, 4: tile width.
|
||||
The texture fields have bit 7 set to indicate texture from level texture list. If 0, the other 7 bits index
|
||||
into ```citmat.res```.
|
||||
|
||||
> If either textures are to be taken from the level list, the object description will be that of the textures.
|
||||
> If a texture is to be taken from citmat.res, the texture index must be > 0, otherwise it will still be the first
|
||||
> level texture, even if bit 7 is 0.
|
||||
|
||||
|
||||
#### Force Bridges 7/7/7, 7/7/8, 7/7/9
|
||||
|
||||
**Force Bridge Info** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Size. Bits 0-3: X, bits 4-7: Y -- see above
|
||||
0003 byte Height. 0 is default, level height units otherwise.
|
||||
0004 [2]byte Unused
|
||||
0006 byte Colour
|
||||
0007 [3]byte Unused
|
||||
|
||||
Object 7/7/8 is a placeholder for force bridges that have not been activated yet. These objects are invisible and are made to force bridges with the use of trigger action 24.
|
||||
|
||||
Force bridges of type 7/7/9 differ from the typical ones (7/7/7) in having a default height of zero and no animation when switched from type 8. They furthermore need a size explicitly set.
|
||||
|
||||
The engine supports several different values for ```Colour```. Used values are ```0x00``` for red and ```0xFE``` for green.
|
||||
|
||||
> Not all 256 colour possibilities have been tested, many resulted in dark red tones or solid colours. Usable variants were found from ```0xF7``` and above.
|
||||
@@ -0,0 +1,186 @@
|
||||
## Level SmallStuff Table (Class 8)
|
||||
|
||||
```L18``` is a table describing general small stuff.
|
||||
|
||||
**Level SmallStuff Entry** (16 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [10]byte SmallStuff data
|
||||
|
||||
### Junk 8/0/x
|
||||
|
||||
#### Papers 8/0/2
|
||||
|
||||
**Paper** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 int16 Paper ID
|
||||
0004 [6]byte Unused
|
||||
|
||||
The ```Paper ID``` refers to a paper text entry and is the offset from resource ID ```0x003C```.
|
||||
The referred text entries have multiple blocks and the engine simply concatenates all these strings to one text.
|
||||
|
||||
|
||||
#### Briefcases 8/0/7
|
||||
|
||||
**Briefcase** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 [4]int16 Object index
|
||||
|
||||
|
||||
### Broken Stuff 8/1/x
|
||||
|
||||
Nothing special.
|
||||
|
||||
|
||||
### Dead Bodies 8/2/x
|
||||
|
||||
#### Corpses 8/2/0 - 8/2/7
|
||||
|
||||
**Corpse** (10 bytes)
|
||||
|
||||
0000 byte Treasure type
|
||||
0001 byte Unused
|
||||
0002 [4]int16 Object index
|
||||
|
||||
The four ```Object index``` values determine the corpse's loot. More random loot can be added to empty slots based on the ```Treasure type```.
|
||||
|
||||
|
||||
**Treasure Type Enumeration** (1 byte)
|
||||
|
||||
0xF5 No treasure
|
||||
0xF6 Humanoid
|
||||
0xF7 Drone
|
||||
0xF8 Assassin
|
||||
0xF9 Warrior cyborg
|
||||
0xFA Flier bot
|
||||
0xFB Security 1 bot
|
||||
0xFC Exec bot
|
||||
0xFD Cyborg enforcer
|
||||
0xFE Security 2 bot
|
||||
0xFF Elite cyborg
|
||||
0x00 Standard corpse
|
||||
0x01 Loot-oriented corpse
|
||||
0x02 Repairbot
|
||||
0x03 Serv-bot
|
||||
|
||||
|
||||
> The treasure type values for corpses are the same as for [critter properties](../14_Critter/critterProperties.md), except offset by 11.
|
||||
|
||||
#### Severed Heads 8/2/13, 8/2/14
|
||||
|
||||
**Severed Head** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Image index
|
||||
0003 [7]byte Unused
|
||||
|
||||
If ```Image index``` is zero, the generic mutilated head is shown. Otherwise, it is the index for a picture of a person, using that of e-mails.
|
||||
|
||||
|
||||
### Consumables 8/3/x
|
||||
|
||||
Nothing special.
|
||||
|
||||
|
||||
### Access Cards 8/4/x
|
||||
|
||||
**Access Card** (10 bytes)
|
||||
|
||||
0000 int16 Unknown
|
||||
0002 sint32 Access mask
|
||||
0006 [4]byte Unused
|
||||
|
||||
All access cards work the same way: When consumed, they add the given ```Access mask``` to the current priviledges and give a message whether and which new access was gained.
|
||||
|
||||
**Access mask** (sint32)
|
||||
|
||||
0x00000001 "None" - This priviledge is none and will not be added. Should not be used.
|
||||
0x000000FE Various generic priviledges
|
||||
0x00FFFF00 Used for "group" priviledges; Typically used with 8/4/10 (Group access card)
|
||||
0x7F000000 Personal priviledges; 0x01: D'Arcy, 0x10: Diego
|
||||
|
||||
8/4/11 items (Personal access cards) have a special handling if personal priviledges are set; When identifying the object, the name of the person is appended to the title.
|
||||
|
||||
> 8/4/0 (Current access levels) works like any other access card, though it doesn't have a proper icon (only an 'X'). In the game it is used only on level 1 for a few cases, purpose unknown.
|
||||
|
||||
|
||||
### Cyberspace Items 8/5/x
|
||||
|
||||
#### Integrity Restorative 8/5/1
|
||||
|
||||
**Integrity Restorative** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Restoration amount
|
||||
0003 [7]byte Unused
|
||||
|
||||
Per default (```Restoration amount``` = 0), the item restores about 3/4 of integrity.
|
||||
|
||||
#### Security Defense Mine 8/5/2
|
||||
|
||||
**Security Defense Mine** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Damage amount
|
||||
0003 [7]byte Unused
|
||||
|
||||
Per default (```Damage amount``` = 0), the item removes little amount (about one chevron).
|
||||
|
||||
|
||||
#### Security ID Module 8/5/3
|
||||
|
||||
**Security ID Module** (10 bytes)
|
||||
|
||||
0000 int16 Unknown
|
||||
0002 sint32 Access mask
|
||||
0006 [4]byte Unused
|
||||
|
||||
Works like access cards - see above.
|
||||
|
||||
#### Cyber Info Nodes 8/5/6, 8/5/8
|
||||
|
||||
**Cyber Info Node** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 int16 Text index
|
||||
0004 [6]byte Unused
|
||||
|
||||
For 8/5/6 (information nodes), the text index is for text resource ```0x0878```.
|
||||
For 8/5/8 (data fragments), the text index is for text resource ```0x087A```.
|
||||
|
||||
|
||||
#### Cyberspace Barricades 8/5/9
|
||||
|
||||
**Cyberspace Barricade** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 byte Size. Bits 0-3: X, bits 4-7: Y
|
||||
0003 byte Height. 0 is default, level height units otherwise.
|
||||
0004 [2]byte Unused
|
||||
0006 byte Colour
|
||||
0007 [3]byte Unused
|
||||
|
||||
Layout and properties are the same as for force bridges (7/7/7).
|
||||
|
||||
|
||||
#### Cyberspace Decoys 8/5/10
|
||||
|
||||
**Cyberspace Decoy** (10 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 int16 Destroy object index
|
||||
0004 [6]byte Unused
|
||||
|
||||
Normally, these cannot be destroyed in cyberspace. However, if placed in a map and made vulnerable to damage, decoys can be made to destroy another object when destroyed.
|
||||
|
||||
|
||||
### Wear and Tear Stuff 8/6/x
|
||||
|
||||
Nothing special.
|
||||
|
||||
|
||||
### Quest Items 8/7/x
|
||||
|
||||
Nothing special.
|
||||
@@ -0,0 +1,11 @@
|
||||
### Small Stuff Properties
|
||||
|
||||
#### Specific 5 Properties
|
||||
|
||||
These items (```8/5/x```) are cyberspace items.
|
||||
|
||||
**Cyberspace Items Specific Properties** (`CyberSmallstuffProp` struct) (6 bytes)
|
||||
|
||||
0000 [6]byte Colour scheme
|
||||
|
||||
```Colour scheme``` contains 6 palette indices from the game palette. The index into this list comes from the geometry properties, specifically from the [Set Colour and Shade](../../media/Geometry#set-colour-and-shade) command.
|
||||
@@ -0,0 +1,266 @@
|
||||
## Level Fixture Table (Class 9)
|
||||
|
||||
```L19``` is a table describing fixtures and electrical stuff.
|
||||
|
||||
**Level Fixture Entry** (30 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0008 [24]byte Fixture Specific Info
|
||||
|
||||
|
||||
### Buttons 9/0/x
|
||||
|
||||
Buttons come in various shapes and forms. All of them are triggers for actions and the entry data that of [actions](../Actions.md).
|
||||
|
||||
**Button Fixture Specific Info** (24 bytes)
|
||||
|
||||
0000 [22]byte Action data
|
||||
0016 uint16 Access mask
|
||||
|
||||
|
||||
The conditions for buttons are based on [game variables](../Conditions.md#game-variable-conditions).
|
||||
|
||||
```Access mask``` is an additional condition for the button. If not zero, the lower five bits can specify one required access level the hacker must have. The remaining 7 bits don't work properly or resolve to the "None" level.
|
||||
|
||||
|
||||
### Receptacles 9/1/x, 9/4/x
|
||||
|
||||
Most receptacles work in conjunction with the quest items (8/7/x). With the exception of antenna relay panels, they contain regular actions as data.
|
||||
Unless noted otherwise below, the conditions for receptacles are based on object types, with an optional trap message if the wrong item is used.
|
||||
|
||||
**Receptacle Fixture Specific Info** (24 bytes)
|
||||
|
||||
0000 [22]byte Action data
|
||||
0016 [2]byte Unused
|
||||
|
||||
**Receptacle Fixture Condition** (4 bytes)
|
||||
|
||||
0000 byte Object type
|
||||
0001 byte Object subclass
|
||||
0002 byte Object class
|
||||
0003 byte Trap message (optional)
|
||||
|
||||
|
||||
#### Antenna Relay Panel 9/1/3
|
||||
|
||||
**Antenna Relay Panel Specific Info** (24 bytes)
|
||||
|
||||
0000 [6]byte Unused
|
||||
0006 int16 Trigger object index 1
|
||||
000A int16 Trigger object index 2
|
||||
000E int16 Destroy object index
|
||||
|
||||
The two ```trigger object index``` values work only with trigger objects, they can't trigger arbitrary objects.
|
||||
|
||||
> Behaviour of relays is hardcoded: After accepting the plastique, their type changes to 9/1/4 and a level timer is started. When the timer expires, the panel explodes, the type changes again to 9/1/5, the two objects are triggered and the object-to-destroy is removed.
|
||||
|
||||
|
||||
#### Retinal ID Scanner 9/1/6
|
||||
|
||||
When using a head item on the retinal scanner, the condition field is compared against the head's ```Current Frame``` value (for object 8/12/13), or ```Current Frame + 11``` (for object 8/12/14). Note that this is different from the ```Image index``` value which determines how the head appears in the MFD.
|
||||
|
||||
### Stations 9/2/x
|
||||
|
||||
The conditions for stations are based on [game variables](../Conditions.md#game-variable-conditions).
|
||||
|
||||
#### Cyberspace Terminals 9/2/0
|
||||
|
||||
**Cyberspace Terminal Specific Info** (24 bytes)
|
||||
|
||||
0000 byte State
|
||||
0001 byte Unused
|
||||
0002 [4]byte Condition
|
||||
0006 int32 Target X
|
||||
000A int32 Target Y
|
||||
000E int32 Target Z
|
||||
0012 int32 Target Level
|
||||
0016 [2]byte Unused
|
||||
|
||||
The orientation of the player in the target cyberspace level can not be specified. The orientation will be taken over from the real world.
|
||||
|
||||
**State** (1 byte enumeration)
|
||||
|
||||
0: Off
|
||||
1: Active (Normal state)
|
||||
2: Locked. Trying to activate it gives an electrical shock.
|
||||
|
||||
|
||||
#### Energy Charge Stations 9/2/1
|
||||
|
||||
**Energy Charge Station Specific Info** (24 bytes)
|
||||
|
||||
0000 [2]byte Unused
|
||||
0002 [4]byte Condition
|
||||
0006 int32 Power amount
|
||||
000A int32 Recharge time in seconds
|
||||
000E int32 Object index
|
||||
0012 int32 Recharged timestamp
|
||||
0016 [2]byte Unused
|
||||
|
||||
The object identified by ```Object index``` is triggered every time when energy is drawn from the station.
|
||||
|
||||
The ```Recharged timestamp``` will be set to the game time when the station is usable again. There is no dedicated timer running.
|
||||
|
||||
|
||||
### Input Panels 9/3/x
|
||||
|
||||
The conditions for input panels are based on [game variables](../Conditions.md#game-variable-conditions).
|
||||
|
||||
**Input Panel Info** (24 bytes)
|
||||
|
||||
0000 [2]byte Unknown
|
||||
0002 [4]byte Condition
|
||||
0006 [18]byte Input panel info
|
||||
|
||||
|
||||
#### Access Panels (Puzzles) 9/3/0 to 9/3/3, 9/3/9, 9/3/10
|
||||
|
||||
Puzzles are either "wire" or "block" puzzles. The type of the puzzle is determined by a bit within the info structure.
|
||||
|
||||
##### Wire Puzzles
|
||||
|
||||
**Wire Puzzle Input Panel Info** (18 bytes)
|
||||
|
||||
0000 int32 Target object index (object to toggle on success)
|
||||
0004 byte Puzzle layout
|
||||
0005 uint8 Target power level out of 0xFF
|
||||
0006 uint8 Wire properties mask
|
||||
0007 int8 Puzzle type - must be 0x00 for wire puzzle
|
||||
0008 uint32 Target state of wires
|
||||
000C uint32 Current state of wires
|
||||
0010 [2]byte Unused
|
||||
|
||||
**Puzzle Layout** (1 byte bitmask)
|
||||
|
||||
0x0F Wire count; 0 default to 4 wires
|
||||
0xF0 Connector count per size; 0 defaults to 6 connectors
|
||||
|
||||
**Wire properties mask** (1 byte bitmask)
|
||||
|
||||
0x0F Color wires; All pink if not set
|
||||
0xF0 Solved state
|
||||
|
||||
> For the properties mask, any of the respective four bits needs to be set to count for the whole nibble.
|
||||
> ```Solved state``` is always ```0xF0```, whereas ```Color wires``` is only set as ```0x01```.
|
||||
|
||||
Wire states are stored as three-bit pairs, ordered from LSB to MSB (right to left). The first pair describes the first
|
||||
wire and the lower triple specifies the left connector.
|
||||
|
||||
This allows for puzzles up to 5 wires and 8 connectors, although only up to 6 connectors are visible.
|
||||
|
||||
|
||||
##### Block Puzzles
|
||||
|
||||
**Block Puzzle Input Panel Info** (18 bytes)
|
||||
|
||||
0000 int32 Target object index (object to toggle on success)
|
||||
0004 int16 State store object index (refers to a null trigger)
|
||||
0006 byte Unused - 0x00
|
||||
0007 int8 Puzzle type - must be 0x10 for block puzzle
|
||||
0008 int32 Puzzle layout
|
||||
000C [6]byte Unused
|
||||
|
||||
**Puzzle Layout** (4 byte bitmask)
|
||||
|
||||
0x00000001 Puzzle solved flag ("Circuit Activated")
|
||||
0x0000000E Unknown
|
||||
0x00000070 Coordinate of source connector
|
||||
0x00000180 Source location
|
||||
0x00000E00 Unknown
|
||||
0x00007000 Coordinate of destination connector
|
||||
0x00018000 Destination location
|
||||
0x00700000 Width
|
||||
0x07000000 Height
|
||||
0x70000000 Side effect type
|
||||
|
||||
The location values are 0: top, 1: bottom, 2: left, 3: right
|
||||
|
||||
Side effects are:
|
||||
|
||||
0: Toggle all blocks horizontally/vertically from the changed one (across the board)
|
||||
1: Toggle all surrounding 8 blocks
|
||||
2: Toggle all blocks diagonally from the changed one (across the board)
|
||||
3: Toggle all blocks horizontally, vertically and diagonally across the board
|
||||
4: None
|
||||
|
||||
The state of the puzzle is stored in the referred ```State store object```, a trigger with no action.
|
||||
|
||||
The trigger info block is repurposed and at its offset ```0006``` there are 4 uint32 fields, concatenated to a 128 bit array.
|
||||
Starting with the LSB from this bit array, 3 bits are repeatedly taken to fill the blocks from left to right, top to bottom.
|
||||
This allows a maximum puzzle size of 42 blocks (6x7 or 7x6).
|
||||
|
||||
The blocks are:
|
||||
|
||||
0: Nothing (empty)
|
||||
1: Inactive (x)
|
||||
2: Active (+)
|
||||
3: Active (+) - not used
|
||||
4: Full node
|
||||
5: Full node - not used
|
||||
6: Hollow node
|
||||
7: Hollow node - not used
|
||||
|
||||
```Full nodes``` require only one incoming connection to forward power to the other three neighbours.
|
||||
```Hollow nodes``` require two incoming connections to forward power to the other two neighbours.
|
||||
|
||||
#### Elevator Panels 9/3/4, 9/3/5, 9/3/6
|
||||
|
||||
**Elevator Input Panel Info** (18 bytes)
|
||||
|
||||
0000 int16 Destination object index 2
|
||||
0002 int16 Destination object index 1
|
||||
0004 int16 Destination object index 4
|
||||
0006 int16 Destination object index 3
|
||||
0008 int16 Destination object index 6
|
||||
000A int16 Destination object index 5
|
||||
000C int16 Accessible bitmask (which floors are accessible)
|
||||
000E int16 Elevator shaft bitmask (which floors does the shaft connect)
|
||||
0010 [2]byte Unused
|
||||
|
||||
If a floor bit is set in the ```Elevator shaft bitmask``` field but not in the ```Accessible bitmask``` field, using
|
||||
that button gives the "Shaft damage" message. The MFD is capable of displaying up to 12 floors.
|
||||
|
||||
The ```Destination object index``` values refer to the object index of the elevator panels in the other levels. Note the swapped order of the index values. Presumably the six values are loaded as three int32 values first, and then the index values are extracted. The Nth bit from the accessible bitmask, counted from LSB, references the Nth destination object index.
|
||||
|
||||
For an elevator panel to work properly (and not crash the game), the following conditions must be met:
|
||||
* The panel must be in a tile which has the elevator music set. (Music index ```0xF``` in tile flags.)
|
||||
* The panels envolved in a level transition must reference each other. In other words, all panels of one connected elevator must have the same configuration.
|
||||
|
||||
> Referencing an object from another level requires an editor to keep track of inter-level references. Or burden the user.
|
||||
> The game uses only up to three active floors.
|
||||
|
||||
> The elevator panel on level 1 has the first byte of the input panel structure set to ```0x01```. Purpose and effect unknown.
|
||||
|
||||
|
||||
#### Number Pads 9/3/7, 9/3/8
|
||||
|
||||
**Number Pad Input Panel Info** (18 bytes)
|
||||
|
||||
0000 int16 3-digit combination 1
|
||||
0002 int16 Trigger object index 1
|
||||
0004 int16 3-digit combination 2
|
||||
0006 int16 Trigger object index 2
|
||||
0008 int16 3-digit combination 3
|
||||
000A int16 Trigger object index 3
|
||||
000C int16 Fail object index
|
||||
000E [4]byte Unknown
|
||||
|
||||
The 3-digit combinations are stored in [Binary-Coded-Decimal](https://en.wikipedia.org/wiki/Binary-coded_decimal) right-bound,
|
||||
so the combination ```451``` is stored as ```0x0451```.
|
||||
|
||||
A combination must be something else than "000" to be active ("000" is always wrong).
|
||||
Combinations must not be entered in sequence, any of the three combinations is valid at any time.
|
||||
|
||||
If the ```Fail object index``` refers to a valid object, this one is triggered when a wrong combination was entered.
|
||||
|
||||
> One number pad on level 0 has the first byte of the input panel structure set to ```0x06```. Purpose and effect unknown.
|
||||
|
||||
|
||||
### Cyberspace Switches 9/5/x
|
||||
|
||||
Cyberspace switches are triggers for actions and the entry data that of [actions](../Actions.md).
|
||||
|
||||
0000 [22]byte Action data
|
||||
0016 [2]byte Unused
|
||||
|
||||
The conditions for cyberspace switches are based on [game variables](../Conditions.md#game-variable-conditions).
|
||||
@@ -0,0 +1,29 @@
|
||||
## Level Door Table (Class 10)
|
||||
|
||||
```L20``` is a table describing doors and barriers.
|
||||
|
||||
**Level Door Entry** (14 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [8]bytes Door Data
|
||||
|
||||
|
||||
**Door Data** (8 bytes)
|
||||
|
||||
0000 int16 Lock variable index
|
||||
0002 byte Lock message
|
||||
0003 byte Force door colour index
|
||||
0004 byte Required access level
|
||||
0005 byte Auto-close time; in units of approximately 0.5 seconds - common default is 0x0C
|
||||
0006 int16 Second door object index
|
||||
|
||||
|
||||
The ```Lock variable index``` determines whether a door is locked. If the referenced boolean variable is 1, then the door won't open when used. If the door is triggered by other means, the door is unlocked and the index is reset to zero.
|
||||
Using the door while being locked, the message according to ```Lock message``` is shown. The message index is into the text resource ```0x0871```, with a block offset of ```7```. (```0x00``` gives the default "The door is locked" at index ```7```).
|
||||
|
||||
The ```Required access level``` indicates which [access level](../content/AccessLevels.md) the hacker needs to activate
|
||||
(open) the door. If zero, no special access is required. This values is ```0xFF``` for doors "locked by SHODAN level security".
|
||||
Such doors have a separate trigger referring these doors.
|
||||
|
||||
The ```Second door object index``` refers to a second door to trigger when activating this one.
|
||||
Bulkhead doors for instance reference each other this way.
|
||||
@@ -0,0 +1,27 @@
|
||||
### Animating Properties
|
||||
|
||||
#### Generic Animating Properties
|
||||
|
||||
**Generic Animating Propertes** (`AnimatingProp` struct) (2 bytes)
|
||||
|
||||
0000 byte Frame time
|
||||
0001 byte Flags
|
||||
|
||||
The `frame time` specifies the time of a single frame of the animation. A value of `0xFF` means a time of approximately 0.9 seconds. All animations have this value set to `0x1E` (30).
|
||||
|
||||
|
||||
**Animating Flags** (1 byte)
|
||||
|
||||
0x01 Emit light; The animation lights up the area with one tile radius for its duration.
|
||||
|
||||
|
||||
> Light is only emitted by objects placed by the engine. This flag is only set for such temporary animations, such as explosions (`11/2/x`), but works for impacts as well (`11/1/x`).
|
||||
|
||||
|
||||
#### Specific 2 Properties
|
||||
|
||||
"Explosion" animations.
|
||||
|
||||
**Specific 2 Properties** (1 byte)
|
||||
|
||||
0000 byte Frame explode
|
||||
@@ -0,0 +1,136 @@
|
||||
## Level Trap Table (Class 12)
|
||||
|
||||
```L22``` is a table describing trap items and general marker.
|
||||
|
||||
**Level Trap Entry** (28 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [22]byte Trap data
|
||||
|
||||
### Infrastructure 12/0/x
|
||||
|
||||
#### Critter AI Hints 12/0/7
|
||||
|
||||
**Critter AI Hint Data** (22 byte)
|
||||
|
||||
0000 [6]byte Unused; A few have the first byte 0x06
|
||||
0006 int16 Next object index
|
||||
0008 [10]byte Unused
|
||||
0012 int16 Trigger object flag -- 0: off, 1: on
|
||||
0014 int16 Trigger object index
|
||||
|
||||
AI hint marker are arranged to form a loop with their ```next object index``` fields. They describe a patrolling path for critters.
|
||||
If the ```trigger object flag``` is set to ```0x01```, the object identified by ```trigger object index``` will be triggered approximately 1.5 seconds after a critter entered the tile this marker is in.
|
||||
|
||||
> These patrolling paths appear to work only under special circumstances. They are rarely used in the main game and so far have been found to properly work only on level 9 for a mutated cyborg.
|
||||
> The main reason for these hints not properly working is that roaming critters only walk when the hacker is within their vicinity - which often already makes them hostile. The cyborg on level 9 initially is docile, thus not concerned about a (passive) hacker. Its 4 state bytes are ```00 00 04 00``` and requires the second loot object to point to the first hint.
|
||||
> Critters take these hints as such - they first walk into their direction, and continue to walk after passing them. Without a new hint, they will wander off in random directions. The cyborg on level 9 properly walks back and forth because its linear back-and-forth path has a hint for ever tile, and the two edges of the path are in coves, within which the cyborg bumps against the walls until properly turned around.
|
||||
|
||||
#### Repulsors 12/0/10
|
||||
|
||||
**Repulsor Data** (22 byte)
|
||||
|
||||
0000 [10]byte Unused; A few have the first byte 0x06 without effect
|
||||
000A int32 Start height
|
||||
000E int32 End height
|
||||
0012 int32 Repulsion flags; 0x00000001: disabled (float down); 0x00000008: strong repulsor
|
||||
|
||||
The ```start height``` and ```end height``` values have a unit of ```0x00010000``` for one tile height. An ```end height``` of zero means endless.
|
||||
Both values are measured from the floor. Repulsion only happens if the hacker is within these limits.
|
||||
|
||||
|
||||
#### Triggers 12/0/x (with exceptions)
|
||||
|
||||
The type of the trigger object determines its cause. The trap data is then that of [actions](../Actions.md).
|
||||
|
||||
Trigger Types:
|
||||
|
||||
0: Entry; Hacker enters tile (mid-air or per foot)
|
||||
1: Null; Must be set off externally. Also used as data storage.
|
||||
2: Floor; Hacker touches floor of this tile (per foot exclusively)
|
||||
3: Player Death; Used to resurrect Hacker
|
||||
4: Death Watch; When certain objects (or types of objects) are destroyed. Common for CPU nodes.
|
||||
5: Area Enter; Hacker enters (or leaves) a given radius
|
||||
6: Area Continuous; Hacker enters any tile inside (or outside) a given radius
|
||||
7: This is not a trigger! See AI hints above.
|
||||
8: Level Entry; Used for instance to initialize starting health
|
||||
9: Continuous; Unused
|
||||
10: This is not a trigger! See repulsors above.
|
||||
11: Ecology; Certain objects go extinct
|
||||
12: SHODAN; Triggered when level security changes
|
||||
|
||||
##### Conditions
|
||||
|
||||
Nearly all triggers have conditions based on [game variables](../Conditions.md#game-variable-conditions).
|
||||
|
||||
The following exceptions exist:
|
||||
* 4 (Death Watch Trigger): A union of [object type][obj-type-cond] and [object index conditions][obj-index-cond]
|
||||
* 5, 6 (Area Trigger): A radius around the trigger. See below.
|
||||
* 11 (Ecology Trigger): A combination of [object type][obj-type-cond] and a limit value. See below.
|
||||
|
||||
[obj-type-cond]: ./Conditions.md#object-type-conditions
|
||||
[obj-index-cond]: ./Conditions.md#object-index-conditions
|
||||
|
||||
##### Area Triggers
|
||||
|
||||
These triggers activate when the hacker enters or leaves a circular area around the trigger. The radius of this area is determined by the condition.
|
||||
|
||||
**Area Trigger Condition** (4 bytes)
|
||||
|
||||
0000 sint32 Radius (in tiles)
|
||||
|
||||
If the ```radius``` is between 1 and 4095, the trigger activates when the hacker is within a circular area of that size around the trigger's tile. A negative radius will activate the trigger when the hacker is outside of the circle instead (e.g. if the radius is -5, the trigger activates when the hacker is at least 5 tiles away from the trigger).
|
||||
|
||||
Trigger type 5 ("Area Enter") activates once the hacker either enters (positive radius) or leaves (negative radius) the area. Type 6 ("Area Continuous") activates when the hacker enters any tile that is either inside (positive radius) or outside (negative radius) of the area.
|
||||
|
||||
##### Ecology Triggers
|
||||
|
||||
These triggers watch a certain type of objects as their condition, together with a limit value. Whenever the current count of these objects is changed to a number below the limit value, the action is executed.
|
||||
|
||||
**Ecology Trigger Condition** (4 bytes)
|
||||
|
||||
0000 byte Type
|
||||
0001 byte Subclass
|
||||
0002 byte Class
|
||||
0003 byte Limit
|
||||
|
||||
Note: The action is executed more than once. How often the action is executed is dependent on the delta. If the new object count equals to (limit-1), then the action is executed twice. If the new object count is less than that, the action is executed three times.
|
||||
|
||||
> The layout for the C/S/T is the common one in an int32 value, with the high-byte representing the limit value.
|
||||
|
||||
> The game watches only critters, typically to spawn new ones. The trigger also works with other classes.
|
||||
|
||||
|
||||
### Trip Beams 12/1/x
|
||||
|
||||
These are not used in the game.
|
||||
|
||||
|
||||
### Map Marker 12/2/x
|
||||
|
||||
Only two types are used in the game.
|
||||
|
||||
|
||||
#### Map Notes 12/2/3
|
||||
|
||||
**Map Note Marker Data** (22 bytes)
|
||||
|
||||
0000 [18]byte Unused
|
||||
0012 int32 Entry offset
|
||||
|
||||
The ```Entry offset``` points into ```L46``` ([map notes](mapInformation.md#map-notes)) for the text entry. When a map note is removed and the whole table is defragmented, all the entry offsets are changed accordingly.
|
||||
|
||||
|
||||
#### Music Voodoo Marker 12/2/4
|
||||
|
||||
**Music Voodoo Marker Data** (22 byte)
|
||||
|
||||
0000 [6]byte Unused
|
||||
0006 byte Music flavour
|
||||
0007 [15]byte Unused
|
||||
|
||||
The ```Music flavour``` is an index, with a range of ```0x00```..```0x04```, referencing patches of "music" resembling industrial noise.
|
||||
They have a rectangular area of effect which covers 14x14 tiles, centered on the tile of the trap.
|
||||
The music is only played if the current tile has a music index of zero.
|
||||
|
||||
> This is used extensively on maintenance level, the 4 flight decks, as well as for the maintenance tunnels on the groves.
|
||||
@@ -0,0 +1,25 @@
|
||||
## Level Container Table (Class 13)
|
||||
|
||||
```L23``` is a table describing containers.
|
||||
|
||||
**Level Container Entry** (21 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [4]int16 Contained object indices
|
||||
|
||||
for crates (13/0/x):
|
||||
000E byte Width
|
||||
000F byte Depth
|
||||
0010 byte Height
|
||||
0011 byte Top/Bottom texture number
|
||||
0012 byte Side texture number
|
||||
|
||||
For the crate-specific values (dimensions and textures), if a value is 0, the default value from the 3D model is used.
|
||||
The textures are taken from the resources in ```citmat.res```, based on ```0x0884```.
|
||||
|
||||
> Texture numbers from ```0x80``` have been found to take the textures from the level texture list.
|
||||
> It is unclear if this is intentional or a side-effect of how data is arranged in the engine.
|
||||
|
||||
> Barrels (13/1/x) can not be inspected and may still contain items. Destroying a barrel drops its contents.
|
||||
> There is one radioactive waste barrel (13/1/0) on level 4 which "contains" a hornet clip, which is lying right next to it.
|
||||
> This is most likely the result of a mistake.
|
||||
@@ -0,0 +1,113 @@
|
||||
### Critter Properties
|
||||
|
||||
#### Generic Critter Properties
|
||||
|
||||
**Generic Critter Propertes** (`CritterProp` struct) (75 bytes)
|
||||
|
||||
0000 byte Intelligence; unused
|
||||
0001 [21]byte Primary attack info
|
||||
0016 [21]byte Secondary attack info
|
||||
002B uint8 Perception
|
||||
002C uint8 Defence
|
||||
002D sint8 Projectile source height offset
|
||||
002E int32 Flags
|
||||
0032 byte Mirrored views; unused
|
||||
0033 [8]uint8 Frame numbers; Amount for each posture
|
||||
003B uint8 Animation speed
|
||||
003C byte Attack sound index
|
||||
003D byte Near sound index
|
||||
003E byte Hurt sound index
|
||||
003F byte Death sound index
|
||||
0040 byte Notice sound index
|
||||
0041 int32 Corpse triple - 0x00CCSSTT; zero for "none"
|
||||
0045 byte View count; for multi-view postures
|
||||
0046 byte Secondary attack probability
|
||||
0047 byte Disrupt probability
|
||||
0048 byte Treasure type
|
||||
0049 byte Hit effect -- 0x00: meat, 0x01: plant, 0x02: robot, 0x03: cyborg, 0x04: generic
|
||||
004A byte Attack key frame
|
||||
|
||||
`Perception` is a probability whether an AI detects hacker when visible during an AI interval.
|
||||
|
||||
The `projectile source height offset` is a vertical offset specifying from where projectiles should be launched.
|
||||
> This is set to some positive values for the Elite Guard and Mutated Cyborg, so that their projectils appear from their heads.
|
||||
|
||||
The `animation speed` specifies the time of a single frame of an animation. A value of `0xFF` means a time of approximately 0.9 seconds.
|
||||
|
||||
For all `sound indices`, a value of `0xFF` indicates "no sound".
|
||||
> No enemy has a sound set for being hurt in the main game.
|
||||
|
||||
`View count` determines how many frames are available per viewing direction. Cyberspace entities, as well as unused critters, have this set to `0x01`, all others have `0x08`. Changing these values messes up rendering of the critter, and/or all subsequent critters. The sequence of the corresponding images will have to be adjusted accordingly.
|
||||
|
||||
The `secondary attack probability` determines how likely the critter will use its secondary attack when close to the hacker. `0xFF` means always, `0x00` will have the critter use the secondary attack only when farther away.
|
||||
|
||||
The `disrupt probability` determines how likely the critter will be interrupted when being hit. `0xFF` means always, `0x00` will have the critter execute its attacks and movement without interruptions.
|
||||
|
||||
`Treasure type` is an enumeration value (ranging from `0x00` to `0x0E`), pointing into a hardcoded pool of possible loot. See below for the possible constants. The concrete loot is randomized accordingly.
|
||||
|
||||
The `attack key frame` value is an index into the attack animation, when the corresponding attack should take effect.
|
||||
|
||||
|
||||
**Critter Attack Info** (`CritterAttack` struct) (21 bytes)
|
||||
|
||||
0000 uint8 Damage type
|
||||
0001 uint8 Special damage type
|
||||
0002 [2]byte Unused
|
||||
0004 int16 Damage modifier
|
||||
0006 uint8 Offence value
|
||||
0007 uint8 Penetration
|
||||
0008 uint8 Attack mass
|
||||
0009 int16 Attack velocity
|
||||
000B uint8 Accuracy
|
||||
000C uint8 Attack range
|
||||
000D int32 Reload time, with 0x100 being approximately 0.9 seconds
|
||||
0011 int32 Projectile triple -- 0x00CCSSTT; zero for "none"
|
||||
|
||||
The `damage type` seems to be compatible with the damage type of [generic weapon info](../GenericWeaponInfo.md). Yet all damage types that affect hacker are handled equally; The two damage types `0x04` and `0x08` have no effect at all.
|
||||
> The main game only uses damage types `0x01` and `0x02` (and some combinations). `0x04` is also set for Diego as well as SHODAN, though this has no further effect.
|
||||
|
||||
The `offence value` is compared to the defence value of the target object. See [common properties](../../fileFormat/PropertyFiles.md#common-table) for details.
|
||||
|
||||
An `accuracy` of `0x00` will still have the critter hit, though not that often and with less damage.
|
||||
|
||||
The critter will want to get within the `attack range` to perform its attack.
|
||||
|
||||
|
||||
**Critter Properties Flags** (4 bytes)
|
||||
|
||||
0x00000001 Flying
|
||||
|
||||
> There are further constants defined, though not in use by the engine.
|
||||
> The properties file has some critters with flag `0x00000004` set, which indicated "small" critters.
|
||||
|
||||
|
||||
**Treasure Type Enumeration** (1 byte)
|
||||
|
||||
0x00 No treasure
|
||||
0x01 Humanoid
|
||||
0x02 Drone
|
||||
0x03 Assassin
|
||||
0x04 Warrior cyborg
|
||||
0x05 Flier bot
|
||||
0x06 Security 1 bot
|
||||
0x07 Exec bot
|
||||
0x08 Cyborg enforcer
|
||||
0x09 Security 2 bot
|
||||
0x0A Elite cyborg
|
||||
0x0B Standard corpse
|
||||
0x0C Loot-oriented corpse
|
||||
0x0D Repairbot
|
||||
0x0E Serv-bot
|
||||
|
||||
|
||||
#### Specific 3 Properties
|
||||
|
||||
These critters (`14/3/x`) are for cyberspace.
|
||||
|
||||
**Cyberspace Critters Specific Properties** (`CyberCritterProp` struct) (6 bytes)
|
||||
|
||||
0000 [3]byte Colour scheme
|
||||
0000 [3]byte Alternative colour scheme
|
||||
|
||||
The `colour scheme`s contain 3 palette indices from the game palette. The 'alternative' colours are used for critters attacking or being hostile.
|
||||
The index into this list comes from the geometry properties, specifically from the [Set Colour and Shade](../../media/Geometry#set-colour-and-shade) command.
|
||||
@@ -0,0 +1,89 @@
|
||||
## Level Critter Table (Class 14)
|
||||
|
||||
```L24``` is a table describing critters.
|
||||
|
||||
**Level Critter Entry** (46 bytes)
|
||||
|
||||
0000 [6]byte Level object prefix
|
||||
0006 [40]byte Level critter data
|
||||
|
||||
|
||||
**Level Critter Data** (40 bytes)
|
||||
|
||||
0000 int32 Pending Z-rotation. Values up to 0x608000 seen.
|
||||
0004 int32 Fixed forward velocity. Rare values of 0x0D000 and 0x090000 seen.
|
||||
0008 [2]byte Unknown, Unused
|
||||
000A int16 Hastiness. Values of 0x0050 and 0x0030 seen.
|
||||
000C int16 State timeout
|
||||
000E int16 Unknown - set to 0x0002 for a few critters.
|
||||
0010 int16 Unknown - set to arbitrary values.
|
||||
0012 [2]byte Unused
|
||||
0014 byte Roaming critter state
|
||||
0015 byte Primary critter state
|
||||
0016 byte Secondary critter state
|
||||
0017 byte Tertiary critter state
|
||||
0018 [6]byte AI coordinates A
|
||||
001E byte Always 0xFF
|
||||
001F byte AI coordinates B
|
||||
0020 [2]int16 Loot object indices
|
||||
0024 [2]byte Unknown, Unused
|
||||
0026 [2]byte Unknown, set only for a few roaming critters.
|
||||
|
||||
|
||||
```Pending Z-rotation``` is a rotation value that the critter wants to perform next. Only when this value is zero, it continues with its regular state.
|
||||
|
||||
```Fixed forward veloctiy``` is used for a few critters to give them a fixed forward speed. This speed can be different than their normal speed, and even make them slower than regular.
|
||||
|
||||
```Hastiness``` makes a few critter appear as if they were under the effect of a speedup-stimulant. Their actions, including their animations, are quicker.
|
||||
|
||||
```State timeout``` is an indicator on how long the critter will stay in this state. Observed only in "cautious" state.
|
||||
This time is reduced as long as the hacker is in the vicinity. When the time reaches zero, the critter becomes hostile.
|
||||
The time value is typically quite low. A few high values like 0x0062 have been observed.
|
||||
|
||||
```AI coordinates A``` and ```B``` appear to be some sort of coordinates. Changing them has no visible effect, so they may be scratch values for the AI, determining where to go next. They are used only for roaming critters.
|
||||
|
||||
```Always 0xFF``` must always be set to ```0xFF```, otherwise the critter is immediately hostile, regardless of where it is on the map. All critters in the main game have it set to ```0xFF```.
|
||||
|
||||
### Critter states
|
||||
|
||||
The state a critter is in is goverend by four bytes, which have meanings on their own, as well as combined effects. For simple cases, only the ```Primary critter state``` is used. This value is also the one modified by the "Set critter state" action.
|
||||
|
||||
A roaming critter has the ```Roaming critter state``` value set, and also needs other states to be set. Working combinations found so far are:
|
||||
* ```03 01 01 00```
|
||||
* ```02 01 01 00``` (not found in archive.dat)
|
||||
A critter only roams on its own if the hacker is within a radius of about 6 tiles.
|
||||
|
||||
A patrolling critter follows a path laid out by ```Critter AI Hint``` marker (See [traps](../12_Trap/levelTrapEntry.md#critter-ai-hints-1207)). The first marker of such a path must be referenced in the second ```loot object index```.
|
||||
> The only working example of such a critter is initially docile, and has a state combination of ```00 00 04 00```.
|
||||
|
||||
The ```Primary critter state``` holds the state the critter is currently behaving in. This state is also reported by the targeting tool.
|
||||
|
||||
**Primary Critter State** (1 byte)
|
||||
|
||||
0x00 docile
|
||||
0x01 cautious
|
||||
0x02 hostile
|
||||
0x03 cautious (?)
|
||||
0x04 attacking
|
||||
0x05 sleeping
|
||||
0x06 tranquilized
|
||||
0x07 confused
|
||||
|
||||
> Various combinations of the state values can be found in the main game. While they have different effects, their pattern is not clear.
|
||||
|
||||
**Critter Mood Enumeration**
|
||||
|
||||
0 Friendly
|
||||
1 Neutral
|
||||
2 Hostile
|
||||
3 Isolation
|
||||
4 Attacking
|
||||
|
||||
**Critter Orders Enumeration**
|
||||
|
||||
0 Guard
|
||||
1 Roam
|
||||
2 Sleep
|
||||
3 Patrol between two points
|
||||
4 Highway - Follow path
|
||||
5 No move (guarding without moving)
|
||||
@@ -0,0 +1,786 @@
|
||||
## Actions
|
||||
|
||||
Level traps and various fixtures (buttons and the like) make use of actions that perform some state change and/or give some indication to the player. They are essentially what make a level (and the game in total) come to life.
|
||||
|
||||
Actions can be triggered by various sources. They may have conditions that first have to be met before the action is actually performed. The type of the action determines how to interpret the details (parameters) of the action.
|
||||
|
||||
|
||||
### Quest Value Key
|
||||
|
||||
Some actions make use of quest value keys, which are used to either resolve a raw value, or a value from the game variables ("quest values").
|
||||
|
||||
* If bit ```0x1000``` is set in the key, the current integer game variable value of index ```key & 0x0FFF``` is referenced.
|
||||
* If bit ```0x2000``` is set in the key, the current boolean game variable value of index ```key & 0x0FFF``` is referenced.
|
||||
* For resolving values, if the key is less than 0x1000, then the resulting value is the value key itself.
|
||||
|
||||
|
||||
### Action Data
|
||||
|
||||
**Action Data** (22 bytes)
|
||||
|
||||
0000 byte Action type
|
||||
0001 byte Use quota
|
||||
0002 [4]byte Condition
|
||||
0006 [16]byte Action details
|
||||
|
||||
The ```Use quota``` indicates how often more this action can be executed. ```0``` means endless.
|
||||
The value is only decremented if it is not zero and the condition was met.
|
||||
If the value is decremented to zero after the action was executed, the object where the action is in is deleted.
|
||||
|
||||
Internally the ```action details``` are processed as four sint32 values. This documentation dissects them further where appropriate.
|
||||
|
||||
### Action Type 1: Transport hacker
|
||||
|
||||
**Transport Hacker Action Details** (16 byte)
|
||||
|
||||
0000 int32 Target X
|
||||
0004 int32 Target Y
|
||||
0008 int32 Target Z
|
||||
000C int32 Target Level
|
||||
|
||||
For all three target axis values, if they are ```0x4000``` or greater, they are ignored and the respective axis is not changed in the transport.
|
||||
The ```X``` and ```Y``` axes specify tile numbers, the ```Z``` axis is interpreted in level units.
|
||||
|
||||
> In the main game, this axis-preservation is used only on level 2 for the Z axis on the experimental transporter,
|
||||
> which incidentally has both platforms at the same height.
|
||||
|
||||
If to be considered, the target values are then used as quest value keys to resolve the actual location for the respective axis.
|
||||
|
||||
> The main game does not make use of this quest value lookup feature. All encounterd values are direct values.
|
||||
|
||||
The ```target level``` specifies a cross-level transfer to the identified level if the value is smaller than ```0x1000```.
|
||||
If it is ```0x1000``` or greater, transportation is only done within the same level, regardless of the value.
|
||||
|
||||
> Cross-level transport is used only for a same-level transfer on level 4 (restoration chamber), and twice for two groves, to
|
||||
> transport the hacker to the restoration chamber on level 6. Other instances are set to ```0x2222```, which are ignored.
|
||||
|
||||
|
||||
### Action Type 2: Change Health
|
||||
|
||||
This action is also called "damage", probably based on the first parameter.
|
||||
|
||||
**Change Health Action Details** (16 byte)
|
||||
|
||||
0000 int32 Damage delta
|
||||
0004 int16 Health delta
|
||||
0006 byte Health change flag; 0: remove delta, 1: add delta
|
||||
0007 byte Damage type -- used if removing health
|
||||
0008 int16 Power delta
|
||||
000A int16 Power change flag; 0: remove delta, 1: add delta
|
||||
000C int16 Fatigue delta
|
||||
000E int16 Fatigue change flag; 0: add delta, 1: remove delta
|
||||
|
||||
All four ```delta``` values are used as quest value keys to resolve the actual delta value.
|
||||
|
||||
> The ```damage delta``` is not used in the main game.
|
||||
> Although intended to cause explosion damage, due to mixed up parameters in the code, a fixed amount of damage is done,
|
||||
> with the delta value being interpreted as damage type.
|
||||
|
||||
> Reducing health to/below 0 causes death. Reducing power below 0 causes an underflow and hacker is fully powered again.
|
||||
|
||||
|
||||
### Action Type 3: Clone/Move Object
|
||||
|
||||
> This action is internally called "Create Object". Name not kept to describe actual functionality better.
|
||||
|
||||
**Clone/Move Action Details** (16 byte)
|
||||
|
||||
0000 int16 Source object index -- quest value key
|
||||
0002 int16 Move flag
|
||||
0004 int32 Target X tile
|
||||
0008 int32 Target Y tile
|
||||
000C int32 Target Z
|
||||
|
||||
The ```move flag``` has a dual purpose. First, it is used to determine whether the object shall be moved or cloned.
|
||||
If it is zero, then the object is cloned; If it has bit ```0x1000``` set, then the object is cloned as well; All other values cause the source object to be moved.
|
||||
If the object is cloned, then the ```move flag``` parameter will be used as quest value key to store the object index of the newly created object.
|
||||
|
||||
> The game archive has various values for the ```move flag```.
|
||||
|
||||
For all three target axis values, if they are ```0x4000``` or greater, they are ignored and the respective axis is not changed.
|
||||
The ```X``` and ```Y``` axes specify tile numbers, the ```Z``` axis is interpreted in level units.
|
||||
|
||||
> In the main game, this axis-preservation is used with various values, including ```0x4400```.
|
||||
|
||||
If to be considered, the target values are then used as quest value keys to resolve the actual location for the respective axis.
|
||||
|
||||
The orientation and in-tile position of the source object will be kept.
|
||||
|
||||
|
||||
### Action Type 4: Set Game Variable
|
||||
|
||||
> This action is internally called "Quest Bit". Name not kept to describe actual functionality better.
|
||||
|
||||
**Set Game Variable Action Details** (16 byte)
|
||||
|
||||
0000 int32 Quest value key
|
||||
0004 int16 Value
|
||||
0006 int16 Operation
|
||||
0008 int32 Message 1 (within resource 0x0867)
|
||||
000C int32 Message 2 (within resource 0x0867)
|
||||
|
||||
Depending on the ```quest value key```, different sets of variables are modified.
|
||||
The variables are stored in the [Game State Structure](../../archives/gameState.md).
|
||||
If no bit in the nibble of ```0xF000``` is set, the quest value key defaults to boolean variables.
|
||||
|
||||
> For the most part in the main game, the boolean variable selector ```0x2000``` is not set and thus relies on this default handling.
|
||||
> There are a few cases where this boolean variable selector is set.
|
||||
|
||||
For the int16 variables, ```value``` must be in the range ```0..0x0FFF```. ```Operation``` can be one of the following:
|
||||
|
||||
0: Set value
|
||||
1: Add value
|
||||
2: Subtract value
|
||||
3: Multiply with value
|
||||
4: Divide by value (Resulting fractions are cut, divide by 0 is ignored)
|
||||
5: Modulo by value
|
||||
|
||||
For the boolean variables, ```operation``` is ignored and always ```0```.
|
||||
The values are either ```0``` or ```1``` to set that value, or ```2``` to toggle the current value.
|
||||
|
||||
If the resulting value is not zero, the (optional) ```message 1``` is played/shown. If the resulting value is zero, the (optional) ```message 2``` is played/shown. Both message parameters are quest value keys.
|
||||
|
||||
> Operations other than Set or Add are not used in the game for the int16 values.
|
||||
|
||||
|
||||
### Action Type 5: Cutscene
|
||||
|
||||
**Cutscene Action Details** (16 byte)
|
||||
|
||||
0000 int32 Cutscene index; 0: Death, 1: Intro, 2: Ending
|
||||
0004 int32 End game flag
|
||||
0008 [8]byte Unused
|
||||
|
||||
```End game flag``` must be ```1```. Setting it to ```0``` leaves the game in an unplayable state after the cutscene.
|
||||
|
||||
What happens after the cutscene is dependent on the cutscene itself: The death and intro cutscenes return to the main menu,
|
||||
the ending cutscene ends the game (showing score and credits).
|
||||
|
||||
> In the regular game, this action is used only once when defeating SHODAN.
|
||||
|
||||
|
||||
### Action Type 6: Trigger other objects
|
||||
|
||||
**Trigger Objects Action Details** (16 byte)
|
||||
|
||||
0000 int16 Object 1 index
|
||||
0002 int16 Object 1 delay
|
||||
...
|
||||
000C int16 Object 4 index
|
||||
000E int16 Object 4 delay
|
||||
|
||||
The delays are all relative to the execution start of the action. Their unit is 0.1 of a second.
|
||||
|
||||
All four object indices are quest value keys. They are resolved when this action is executed, not after the delay.
|
||||
|
||||
|
||||
### Action Type 7: Change lighting
|
||||
|
||||
**Change Lighting Action Details** (16 byte)
|
||||
|
||||
0000 int16 Light type extent - quest value key
|
||||
0002 int16 Reference object index - quest value key
|
||||
0004 int16 Transition type. 0x0000: immediate, 0x0001: fade, 0x0100: flicker
|
||||
0006 int16 Transition state
|
||||
0008 byte Light type
|
||||
0009 byte Unused
|
||||
000A int16 Light surface. 0x0000: floor, 0x0001: ceiling, 0x0002: floor and ceiling
|
||||
000C [4]byte Light type parameter
|
||||
|
||||
These actions modify the light deltas of the affected tiles. Such actions can not change the base darkness
|
||||
values of a tile. If a tile is fully bright by default, nothing can change that.
|
||||
The configured light parameters are absolute values.
|
||||
|
||||
The ```transition state``` is a bitmask storing the state for a change.
|
||||
|
||||
**Transition state** (2 bytes)
|
||||
|
||||
0x0FFF Step counter
|
||||
0x1000 0: light on, 1: light off
|
||||
|
||||
**Light type** (1 byte)
|
||||
|
||||
0x00 Rectangular
|
||||
0x01 Linear gradient (East-West smooth)
|
||||
0x02 Linear gradient (North-South smooth)
|
||||
0x03 Radial gradient
|
||||
|
||||
**Gradient light type parameter** (4 bytes)
|
||||
|
||||
0000 byte Off light begin intensity
|
||||
0001 byte Off light end intensity
|
||||
0002 byte On light begin intensity
|
||||
0003 byte On light end intensity
|
||||
|
||||
#### Rectangular light (type 0x00)
|
||||
|
||||
For this light type, the ```light type extent``` specifies a second object index. All tiles within this rectangle are affected.
|
||||
|
||||
**Light type parameter** (4 bytes)
|
||||
|
||||
0000 byte Off light value 0x00..0x0F
|
||||
0001 byte On light value 0x00..0x0F
|
||||
0002 [2]byte Unused
|
||||
|
||||
#### Linear gradient light (types 0x01, 0x02)
|
||||
|
||||
For this light type, the ```light type extent``` specifies a second object index to define the affected area.
|
||||
|
||||
For these types, the ```gradient light type parameter``` intensity values have a range of ```0x00```..```0x0F```.
|
||||
|
||||
> These light types are not used in the regular game.
|
||||
|
||||
|
||||
#### Radial gradient light (type 0x03)
|
||||
|
||||
For this light type, the ```light type extent``` specifies a radius, in tiles, of affected tiles. The begin of the gradient is always the
|
||||
tile of the triggering object (```reference object index``` is ignored).
|
||||
|
||||
The intensity values of the ```gradient light type parameter``` have a range of ```0x00```..```0x7F```.
|
||||
A value of around ```0x14``` lights a tile as if it were fully lit.
|
||||
Values above will spill over to the surrounding tiles.
|
||||
|
||||
|
||||
### Action Type 8: Effect
|
||||
|
||||
**Effect Action Details** (16 byte)
|
||||
|
||||
0000 int16 Sound index, based on 0x00C9; 0: Play nothing
|
||||
0002 int16 Sound play count; 0: endless
|
||||
0004 int16 Visual effect
|
||||
0006 [2]byte Unused
|
||||
0008 int16 Additional visual effect
|
||||
000A [2]byte Unused
|
||||
000C int16 Additional visual effect time; 0: endless
|
||||
000E [2]byte Unused
|
||||
|
||||
All parameters are used as quest value keys.
|
||||
|
||||
Visual Effects:
|
||||
|
||||
0: None
|
||||
1: Power on: Dim level lights and fade back to normal; Plays generator sound as well
|
||||
2: Quake: Shake cam and play rumble sound
|
||||
3: Escape pod: Shows launch sequence, cam shake and abort; Plays SHODAN message afterwards
|
||||
4: Red static (fullscreen)
|
||||
5: Red static (interference)
|
||||
|
||||
Additional Visual Effects:
|
||||
|
||||
0: None
|
||||
1: White flash
|
||||
2: Pink flash
|
||||
3: Gray static (fullscreen)
|
||||
4: Vertical panning (including HUD)
|
||||
|
||||
|
||||
### Action Type 9: Change tile heights
|
||||
|
||||
0000 int32 Tile X
|
||||
0004 int32 Tile Y
|
||||
0008 int16 Target floor height; 0..31, measured from floor absolute zero
|
||||
000A int16 Target ceiling height; 1..31, measured from floor absolute zero
|
||||
000C [2]byte Unused
|
||||
000E int16 Silent flag; 0: play sound, 1: no sound
|
||||
|
||||
Tile coordinates, as well as the heights, are used as quest value keys.
|
||||
|
||||
For the height fields a value equal to, or greater than ```0x0100``` indicates "don't move".
|
||||
|
||||
> The ceiling height has also been encountered to be ```0x0020```, also not moving.
|
||||
|
||||
The ```silent flag``` only works for floor changes. If the ceiling changes height, it makes sound regardless of this parameter.
|
||||
|
||||
|
||||
### Action Type 10: Change Terrain
|
||||
|
||||
0000 int32 Tile X
|
||||
0004 int32 Tile Y
|
||||
0008 int32 Tile type
|
||||
000C int32 Terrain parameter (slope height)
|
||||
|
||||
All four parameters are used as quest value keys.
|
||||
|
||||
If ```tile type``` or ```terrain parameter``` has the bit ```0x4000``` set, the respective property will not be changed.
|
||||
|
||||
> This action is not used in the main game.
|
||||
|
||||
|
||||
### Action Type 11: Scheduled Trap
|
||||
|
||||
**Scheduled Trap Action Details** (16 byte)
|
||||
|
||||
0000 int32 Object index
|
||||
0004 int32 Time interval
|
||||
0008 int32 Activation value
|
||||
000C int16 Variance
|
||||
000E [2]byte Unused
|
||||
|
||||
Parameters ```object index```, ```time interval```, and ```variance``` (if set != 0) are used as quest value keys.
|
||||
|
||||
The ```time interval``` specifies in 0.1 seconds units within which time span the identified object shall be triggered regularly.
|
||||
The ```variance``` adds some randomness to the interval. Usually low numbers are encountered in the main game.
|
||||
|
||||
> The unit of the variance is that of the engine-internal ticks.
|
||||
|
||||
The ```activation value``` has three different uses:
|
||||
* greater than or equal to ```0xFFFF```: endless scheduling.
|
||||
* bit ```0x1000``` set AND boolean game variable identified by this value key is true: schedule trigger
|
||||
* value between ```0x0000``` (exclusive) and ```0x1000``` (exclusive): remaining schedule amount, down to zero
|
||||
|
||||
> The game has the ```Activation value``` typically set to ```0xFFFF```, ```0x10000``` or ```0x11111``` in the main game.
|
||||
|
||||
|
||||
### Action Type 12: Cycle Objects
|
||||
|
||||
> Internally, this action is called "Alternating splitter"
|
||||
|
||||
**Cycle Objects Action Details** (16 byte)
|
||||
|
||||
0000 [3]int32 Object indices
|
||||
000C int32 Next object
|
||||
|
||||
All three ```object indices``` are interpreted as quest value keys.
|
||||
|
||||
This action triggers objects from the list of ```object indices```. The ```next object``` field indicates which entry to trigger next.
|
||||
Afterwards, the ```next object``` field is incremented. It is reset to ```0``` if it is either greater than ```2```, or it is ```2``` and the third object index is ```0```.
|
||||
|
||||
|
||||
### Action Type 13: Destroy Object
|
||||
|
||||
**Destroy Object Action Details** (16 byte)
|
||||
|
||||
0000 int16 Object 1 index
|
||||
0002 int16 Unused
|
||||
0004 int16 Object 2 index
|
||||
0006 int16 Unused
|
||||
0008 int16 Object 3 index
|
||||
000A int16 Unused
|
||||
000C int32 Message index (within resource 0x0867); 0: no message
|
||||
|
||||
All three ```object indices``` are interpreted as quest value keys.
|
||||
|
||||
|
||||
### Action Type 14: Unused
|
||||
|
||||
> This action is not used and does nothing.
|
||||
|
||||
|
||||
### Action Type 15: Receive EMail
|
||||
|
||||
**Receive EMail Action Details** (16 byte)
|
||||
|
||||
0000 int16 EMail index, based on 0x0989
|
||||
0002 [2]byte Unused
|
||||
0004 int16 Delay
|
||||
0008 [10]byte Unused
|
||||
|
||||
The ```Delay``` is roughly counted in seconds. Tests showed their actual unit seems to be somewhere at 0.9 seconds.
|
||||
|
||||
|
||||
### Action Type 16: Expose
|
||||
|
||||
**Change Effect Action Details** (16 byte)
|
||||
|
||||
0000 int16 Delta value
|
||||
0002 int16 Effect change flag; 0: add delta, 1: remove delta
|
||||
0004 int32 Effect type
|
||||
0008 [8]byte Unused
|
||||
|
||||
This action exposes the hacker to some typed hazard or treatment.
|
||||
|
||||
Effect types are:
|
||||
|
||||
4: Radiation poisoning
|
||||
8: Bio contamination
|
||||
|
||||
> The main game uses this only once to remove the radiation in level R - treatment area.
|
||||
|
||||
|
||||
### Action Type 17: Set Object Parameter
|
||||
|
||||
**Set Object Parameter Action Details** (16 byte)
|
||||
|
||||
0000 int16 Object index 0
|
||||
0002 int16 Object index 2
|
||||
0004 int32 Value 1
|
||||
0008 int32 Value 2
|
||||
000C int32 Value 3
|
||||
|
||||
Both object indices are treated as quest value keys.
|
||||
|
||||
This action sets parameters of target objects. Which value is applied to which parameter is dependent on the target.
|
||||
|
||||
The following table lists the mappings.
|
||||
|
||||
| Target Class | Value 1 | Value 2 | Value 3 |
|
||||
|:-------------:|-----------------|----------------------------------|-----------------|
|
||||
| Big Stuff | Cosmetic value | Data1 | Data2 |
|
||||
| Door | Locked | ```0xFF00```: Message index, ```0x00FF```: Cosmetic value | ```0xFF00```: Access level, ```0x00FF```: Auto-close time |
|
||||
| Fixture, Trap | Parameter Number (1..4) | Parameter Value | Unused |
|
||||
|
||||
For ```big stuff``` and ```door``` classes, if a value is ```-1``` it doesn't modify the respective target parameter.
|
||||
|
||||
> Which parameters are specifially affected for fixtures and traps depends on their respective interpretation of the 16 bytes.
|
||||
|
||||
|
||||
### Action Type 18: Set Screen Picture
|
||||
|
||||
> Internally, this action is called "animate".
|
||||
|
||||
**Set Screen Picture Action Details** (16 byte)
|
||||
|
||||
0000 int16 Screen 1 object index
|
||||
0002 int16 Screen 2 object index
|
||||
0004 int32 Single sequence source
|
||||
0008 int32 Loop sequence source
|
||||
000C int32 Unused
|
||||
|
||||
This action sets the picture source for the given screen object(s).
|
||||
|
||||
If provided, the ```Single sequence``` source is played first. If provided, the ```Loop sequence``` is played
|
||||
next and looped. If no loop is provided, the last frame of the single sequence will be kept.
|
||||
|
||||
|
||||
### Action Type 19: Hack
|
||||
|
||||
This action is a more generic one with several different interpretations, depending on the first field.
|
||||
|
||||
**Hack Action Details** (16 byte)
|
||||
|
||||
0000 int32 Hack type
|
||||
0004 [12]byte Hack parameter
|
||||
|
||||
|
||||
#### Hack Action Type 1: Toggle repulsor
|
||||
|
||||
**Toggle Repulsor Details** (12 byte)
|
||||
|
||||
0000 int32 Repulsor object index
|
||||
0004 byte "Off" texture index (into level texture list)
|
||||
0005 byte "On" texture index (into level texture list)
|
||||
0006 [2]byte Unused
|
||||
0008 byte Toggle type
|
||||
0009 [3]byte Unused
|
||||
|
||||
**Toggle type** (1 byte)
|
||||
|
||||
0x00 Toggle On/Off
|
||||
0x01 Toggle On, stay on
|
||||
0x02 Toggle Off, stay off
|
||||
|
||||
|
||||
#### Hack Action Type 2: Show Game Code Digit
|
||||
|
||||
**Show Game Code Digit Details** (12 byte)
|
||||
|
||||
0000 int32 Screen object index
|
||||
0004 int32 Digit number 1..6 (= level number)
|
||||
0008 [4]byte Unused
|
||||
|
||||
|
||||
#### Hack Action Type 3: Set Fixture Parameter from Variable
|
||||
|
||||
**Set Fixture Parameter From Variable Details** (12 byte)
|
||||
|
||||
0000 int32 Fixture object index
|
||||
0004 int32 Parameter number (1..4)
|
||||
0008 int32 Game integer variable index
|
||||
|
||||
> This hack is used only twice, exclusively to set the codes for the reactor in the base game.
|
||||
> Similar to the "Set Object Parameter" action, the interpretation of the modified parameter is depending on the action in the target fixture.
|
||||
|
||||
|
||||
#### Hack Action Type 4: Set Frame State
|
||||
|
||||
> Although this hack is called "fixture frame", it doesn't check for the type of the target object and allows to modify any object's frame state.
|
||||
|
||||
**Set Frame State Details** (12 byte)
|
||||
|
||||
0000 int32 Button object index
|
||||
0004 int32 New frame state; 0: off, 1: on
|
||||
0008 int32 MFD update flag; 0: ignored, != 0: update MFD
|
||||
|
||||
|
||||
#### Hack Action Type 5: Door Control
|
||||
|
||||
**Door Control State Details** (12 byte)
|
||||
|
||||
0000 int32 Door object index
|
||||
0004 int32 Control value
|
||||
0008 int32 Unused
|
||||
|
||||
Control values:
|
||||
|
||||
1: open door
|
||||
2: close door
|
||||
3: toggle door
|
||||
4: disable auto-close
|
||||
|
||||
|
||||
#### Hack Action Type 6: Return to main menu
|
||||
|
||||
This hack has no parameters (all 12 bytes 0x00) and directly returns to the main menu.
|
||||
|
||||
|
||||
#### Hack Action Type 7: Rotate Object
|
||||
|
||||
**Rotate Object State Details** (12 byte)
|
||||
|
||||
0000 int32 Object index
|
||||
0004 byte Amount
|
||||
0005 byte Type -- 0x00: endless, != 0x00: back/forth
|
||||
0006 byte Direction -- 0x00: forward, 0x01 when running backwards
|
||||
0007 byte Axis -- 0x00: Z (yaw), 0x01: X (pitch), 0x02: Y (roll)
|
||||
0008 byte Forward limit
|
||||
0009 byte Backward limit
|
||||
000A [2]byte Unused
|
||||
|
||||
This hack rotates an object along one axis. This rotation can be endless in one direction, or a back and forth rotation,
|
||||
depending on the ```Type``` field.
|
||||
|
||||
If the rotation type is back and forth, then the object is rotated between the two limits. Should the object start outside of these
|
||||
limits, then rotation continues normally until it is within the limits.
|
||||
|
||||
If the rotation type is endless, whenever one limit is reached, the object immediately jumps to an orientation as per the other limit.
|
||||
|
||||
|
||||
#### Hack Action Type 8: Remove Critters
|
||||
|
||||
> This hack is called "armageddon" internally, most likely in a reference to a similar action in the game Lemmings.
|
||||
|
||||
**Remove Critters State Details** (12 byte)
|
||||
|
||||
0000 int32 Object type - 0x00CCSSTT
|
||||
0004 int32 Radius
|
||||
0008 int32 Unused
|
||||
|
||||
This hack removes critters of the specified object type from the level.
|
||||
The ```radius``` specifies how many shall be removed around the tile of the action's object, in tiles.
|
||||
|
||||
> Avoid using high amounts. The engine can remove only a certain amount of objects in one tick (100) and has no guard if more are removed.
|
||||
> A memory overrun occurs in this case.
|
||||
|
||||
|
||||
#### Hack Action Type 9: SHODAN pixelation
|
||||
|
||||
This hack has no parameters (all 12 bytes 0x00) and fills the screen with an image. The used image is hardcoded.
|
||||
The game returns to the main menu after the screen is filled.
|
||||
It should be used only in cyberspace; Using it in real world messes up tile textures.
|
||||
|
||||
|
||||
#### Hack Action Type 10: Set Condition
|
||||
|
||||
**Set Condition Details** (12 byte)
|
||||
|
||||
0000 int32 Object index
|
||||
0004 [4]byte Condition
|
||||
0008 [4]byte Unused
|
||||
|
||||
Sets the condition values of specified object (fixture or trap).
|
||||
|
||||
|
||||
#### Hack Action Type 11: Show System Analyzer
|
||||
|
||||
0000 int32 Page index (0..2)
|
||||
0004 [8]byte Unused
|
||||
|
||||
|
||||
#### Hack Action Type 12: Make Area Radioactive
|
||||
|
||||
> Internally this hack is called "spew". Yet it only supports spillage of radiation.
|
||||
|
||||
**Make Area Radioactive Details** (12 byte)
|
||||
|
||||
0000 int32 Reference object index
|
||||
0004 int16 Watched object index
|
||||
0006 int16 Watched object trigger state
|
||||
0008 int32 Spew type. Only value of 0 supported (= radiation).
|
||||
|
||||
The rectangular area defined by ```reference object``` and the object of the action emits radiation while ```watched object``` is in given state (1 = active/open).
|
||||
|
||||
> This is used only once, on level 2 for the small room in Beta quadrant. The door is both the reference as well as the watched object.
|
||||
|
||||
|
||||
#### Hack Action Type 13: Oriented Trigger Object
|
||||
|
||||
> This hack is exclusively used on level 8 to trigger three different taunts from Diego.
|
||||
> Hence it is also called "Diego Taunt" in the source.
|
||||
|
||||
**Oriented Trigger Object Details** (12 byte)
|
||||
|
||||
0000 uint16 Horizontal direction
|
||||
0002 [2]byte Unused
|
||||
0004 int32 Object index
|
||||
0008 [4]byte Unused
|
||||
|
||||
This hack triggers the given object only if the player looks to the given ```Horizontal direction``` (+/- 45°).
|
||||
Value ```0x0000``` specifies north, going clockwise with increasing numbers, meaning:
|
||||
|
||||
0x0000 North (matches between NW and NE)
|
||||
0x4000 East (matches between NE and SE)
|
||||
0x8000 South (matches between SE and SW)
|
||||
0xC000 West (matches between SW and NW)
|
||||
|
||||
|
||||
#### Hack Action Type 14: Close Data MFD
|
||||
|
||||
**Close Data MFD Details** (12 byte)
|
||||
|
||||
0000 int32 Displayed object index
|
||||
0004 [8]byte Unused
|
||||
|
||||
If the specified object is currently displayed in the "Data" MFD, close it and return to previous display.
|
||||
|
||||
> This hack is used only once to close the keypad panel from the reactor if an invalid combination is entered.
|
||||
|
||||
|
||||
#### Hack Action Type 15: Earth destruction by laser
|
||||
|
||||
This hack has no parameters (all 12 bytes 0x00) and lets the player receive the message about the fired laser.
|
||||
The game continues after the message has played. Images and text are hardcoded.
|
||||
|
||||
|
||||
#### Hack Action Type 16: Change Critter Type Global
|
||||
|
||||
**Change Critter Type Global Action Details** (16 byte)
|
||||
|
||||
0000 int32 Critter type - 0x00CCSSTT
|
||||
0004 byte New type
|
||||
0005 [7]byte Unused
|
||||
|
||||
This hack morphs all critters of given object type in the level and changes their type to the given one.
|
||||
Class and subclass stay the same. Stats, such as healthpoints, are maintained as well.
|
||||
|
||||
If ```new type``` specifies a value greater than ```0x0F```, the object will be destroyed.
|
||||
|
||||
|
||||
### Action Type 20: Set Tile Textures
|
||||
|
||||
> This action is not used in the main game.
|
||||
|
||||
**Set Tile Textures Action Details** (16 byte)
|
||||
|
||||
0000 int32 Area
|
||||
0004 int32 Floor Operation
|
||||
0008 int32 Wall Operation
|
||||
000C int32 Ceiling Operation
|
||||
|
||||
The ```area``` defines a rectangular area of affected tiles.
|
||||
If ```area``` is less than ```0x10000```, then only one tile is affected, identified by ```0xXXYY```.
|
||||
Otherwise, ```area``` is interpreted as two object indices (interpreted as quest value keys), that define the area by their respective location.
|
||||
|
||||
The three ```operation``` fields identify, per texture, what to do.
|
||||
|
||||
**Texture Operation** (4 byte)
|
||||
|
||||
0000 int16 Source filter
|
||||
0002 int16 Destination texture
|
||||
|
||||
If ```source filter``` is either equal to or greater than ```0x1000```, or the tile uses the texture identified by this filter, then set the texture according to ```destination texture``` if this value is less than ```0x1000```.
|
||||
|
||||
Said differently, try to set ```destination texture``` only if the value is less than ```0x1000```, and consider only tiles if set as a flood-fill, or if the source matches.
|
||||
|
||||
|
||||
### Action Type 21: Set Critter State
|
||||
|
||||
**Set Critter State Action Details** (16 byte)
|
||||
|
||||
0000 int16 Filter parameter
|
||||
0002 int16 Filter type
|
||||
0004 int32 Area
|
||||
0008 int32 New critter mood -- ignored if value >= 0x1000
|
||||
000C int32 New critter orders -- ignored if value >= 0x1000
|
||||
|
||||
Sets the state of critters.
|
||||
See [Critters](14_Critter/levelCritterEntry.md) for the enumeration values of critter states.
|
||||
|
||||
The ```filter type``` parameter defines via bits which critters should be considered and how the ```filter parameter``` is interpreted.
|
||||
|
||||
**Filter Type Bitfield** (2 byte)
|
||||
|
||||
0x0001 Consider loner critters only. If not set, only consider pack critters.
|
||||
0x0002 Ignore loner/pack property of critter.
|
||||
0x0004 If set, ```filter parameter``` identifies one specific critter to affect (regardless of remaining bits). Use area otherwise.
|
||||
0x0008 Affect every critter in the area, regardless of subtype/type. (Note: only works for small areas)
|
||||
|
||||
If neither bits ```0x0004```, nor ```0x0008``` are set, then ```filter parameter``` specifies the subclass and type of affected critters (```0xSSTT```).
|
||||
|
||||
The ```area``` parameter defines the affected tiles in the following ways:
|
||||
* All zero: affect entire level
|
||||
* Lower 16 bits zero: upper 16 bits define half of the side-length of a square, with the tile of the action object at its center.
|
||||
* Two 16 bit values identifying reference objects that define a rectangular area.
|
||||
|
||||
Unless the ```new critter mood``` is ```friendly```, mood is ignored on combat level 0.
|
||||
|
||||
|
||||
### Action Type 22: Trap Message
|
||||
|
||||
> Internally, such messages are called "barks".
|
||||
|
||||
**Trap Message Action Details** (16 byte)
|
||||
|
||||
0000 sint32 Background image
|
||||
0004 int32 Message index (within resource 0x0867)
|
||||
0008 int32 Text colour
|
||||
000C int32 MFD suppression flag; 0: Show in MFD, 1: Show only in HUD
|
||||
|
||||
The ```Background image``` and ```Text colour``` are only considered for display in MFD. The user needs to have messages set to "text" or "both" to see them.
|
||||
|
||||
For the ```Background image```, the following values are possible:
|
||||
|
||||
-1 SHODAN (black and white)
|
||||
-2 Diego
|
||||
|
||||
> The game uses other image references as well, yet they don't work. This is due to the code being modified to ignore positive background image values.
|
||||
|
||||
|
||||
### Action Type 23: Spawn Objects
|
||||
|
||||
**Spawn Objects Action Details** (16 byte)
|
||||
|
||||
0000 int32 Object type; Format 0x00CCSSTT
|
||||
0004 int32 Area
|
||||
0008 int32 Quantity - quest value key
|
||||
000C int32 Flags
|
||||
|
||||
This action spawns a random number of objects, randomly distributed within an area.
|
||||
The spawned objects are placed at the floor in the center of the tile.
|
||||
|
||||
The ```area``` field specifies a rectangular area, either based on two objects, or a square.
|
||||
If ```area``` is less than ```0x10000```, then it specifies half of the final side-length of the resulting square, and the trap object's location is at the lower-right corner of this square. Otherwise, ```area``` specifies two object indices that define the rectangle with their locations.
|
||||
|
||||
Objects are only spawned if the ```Combat``` value is 1 or higher. If it is 3, then one more object than requested is spawned.
|
||||
Not all classes can be spawned.
|
||||
> Although the game uses enemies exclusively, ammo, explosives, and patches can be spawned as well.
|
||||
|
||||
**Spawn Objects Flags** (4 byte)
|
||||
|
||||
0x00000001 Avoid spawn if tile is within a distance of 7 based on the sum of X and Y deltas.
|
||||
0x00000002 Avoid spawn if hacker looks at the tile within a distance of 14 based on the sum of X and Y deltas.
|
||||
0x00000004 Allow spawn if tile is an elevator tile (identified by elevator music).
|
||||
0x00000008 Force spawn, even if the ceiling is too low, or the tile contains already a critter.
|
||||
|
||||
|
||||
### Action Type 24: Change Object Type
|
||||
|
||||
> Internally, this action is called "transmogrify".
|
||||
|
||||
**Change Object Type Action Details** (16 byte)
|
||||
|
||||
0000 int32 Object index
|
||||
0004 int16 New type
|
||||
0006 int16 Reset mask
|
||||
0008 [8]byte Unused
|
||||
|
||||
This action sets, or toggles, the type of an object. It is primarily used to extend and retract force bridges.
|
||||
> For bridges in their retracted state, the game uses "Elephant, Jorp" (```7/7/8```), an invisible placeholder type.
|
||||
|
||||
The ```Reset mask``` is used when the specified object is already at given type. If the specified object is already at given type,
|
||||
then the new type is calculated as ```New type``` XOR ```Reset mask```.
|
||||
> So, to toggle between ```0x08``` and ```0x09```, ```New type``` should be ```0x08``` and ```Reset mask``` must be set to ```0x01```.
|
||||
> To toggle between ```0x08``` and ```0x07```, ```New type``` should be ```0x07``` and ```Reset mask``` must be set to ```0x0F```.
|
||||
|
||||
> The first byte of unused field at ```0008``` is set to ```1``` for only one force bridge in the game (on level 2) and is ignored.
|
||||
> It appears that an earlier version of the code supported suppressing of animations.
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
## Conditions
|
||||
|
||||
Conditions are filters for [actions](Actions.md) and for some [fixtures](09_Fixture/levelFixtureEntry.md) that don't use actions.
|
||||
|
||||
Conditions can examine different aspects of the state of the game or (current) level.
|
||||
|
||||
|
||||
### Game Variable Conditions
|
||||
|
||||
These conditions check the value of a game variable (also called "quest value").
|
||||
|
||||
**Game Variable Condition** (4 bytes)
|
||||
|
||||
0000 uint16 Variable key
|
||||
0002 byte Value
|
||||
0003 byte Failure message
|
||||
|
||||
The ```Failure message``` is a message (or indication) the player shall receive if the condition was not met.
|
||||
```0x00``` means no indication, ```0xFF``` is used for security warnings (blocked by SHODAN security);
|
||||
All other values are interpreted as text/audio message index.
|
||||
|
||||
|
||||
**Variable key** (2 bytes)
|
||||
|
||||
0x03FF Variable index
|
||||
0x0C00 Unused
|
||||
0x1000 Variable type; 0: boolean variable, 1: int16 variable
|
||||
0xE000 Comparison
|
||||
|
||||
**Comparison**
|
||||
|
||||
0: Variable must be equal to value
|
||||
1: Variable must be less than value
|
||||
2: Variable must be less than, or equal to, value
|
||||
3: Variable must be greater than value
|
||||
4: Variable must be greater than, or equal to, value
|
||||
5: Variable must be not equal to value
|
||||
6: Value must be greater than a random value of range 0..254 (variable value is ignored)
|
||||
|
||||
|
||||
### Object Type Conditions
|
||||
|
||||
These conditions check for a specific object type.
|
||||
|
||||
**Object Type Condition** (4 bytes)
|
||||
|
||||
0000 int32 Class/Subclass/Type encoded as 0x00CCSSTT
|
||||
|
||||
Note that the most significant byte needs to be ```0x00```.
|
||||
|
||||
> These conditions are used for the quest items and for death watch trigger.
|
||||
|
||||
|
||||
### Object Index Conditions
|
||||
|
||||
These conditions are level-specific and only used for death watch trigger.
|
||||
|
||||
**Object Index Condition** (4 bytes)
|
||||
|
||||
0000 int16 Object index
|
||||
0002 byte Unused
|
||||
0003 byte Condition marker = 0x01
|
||||
|
||||
|
||||
As these conditions are used for the same type of triggers as the object type conditions, the ```condition marker``` identifies the class of condition.
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
### Generic Weapon Info
|
||||
|
||||
This structure is reused for various offensive items.
|
||||
|
||||
**Generic Weapon Info** (`COMBAT_DATA_FIELDS` macro) (8 bytes)
|
||||
|
||||
0000 sint16 Damage
|
||||
0002 byte Offence value
|
||||
0003 byte Damage type
|
||||
0004 byte Special damage type
|
||||
0005 [2]byte Unused
|
||||
0007 uint8 Armour penetration
|
||||
|
||||
The `offence value` is compared to the defence value of the target object. See [Common Object Properties](../fileFormat/PropertyFiles.md#common-table) for details.
|
||||
|
||||
If `Armour penetration` is equal or higher than the `Armour` value of the object being hit, the full `Damage` is applied. Otherwise, the difference is subtracted from `Damage`. If the resulting value reaches 0 or lower, "No Damage" is displayed.
|
||||
|
||||
`Special damage type` matches the `Special vulnerabilities` sub-fields from [Common Object Properties](../fileFormat/PropertyFiles.md#common-table);
|
||||
It is split up into `0x0F` primary damage (double damage) and `0xF0` super damage (quad damage).
|
||||
|
||||
> Similar to the vulnerabilities in the common object properties, the damage type is a single 32bit value from `0003` in the source.
|
||||
|
||||
|
||||
**Damage Type Bitfield** (1 byte)
|
||||
|
||||
0x01 Explosion (impact)
|
||||
0x02 Energy
|
||||
0x04 Magnetic (EMP)
|
||||
0x08 Radiation
|
||||
0x10 Gas
|
||||
0x20 Tranquilizer
|
||||
0x40 Needle
|
||||
0x80 Bio
|
||||
@@ -0,0 +1,99 @@
|
||||
## Level Objects
|
||||
|
||||
A level object is anything that is not part of the basic level layout (the tile map). The game knows about 476 different objects.
|
||||
|
||||
Objects are identified using three values. They are divided by class, subclass and type. In this documentation such an identifier will be written as ```c/s/t```. For example, the energy charge station is ```9/2/1```.
|
||||
|
||||
> In the original source, such an identifier is called a ```TRIPLE```.
|
||||
|
||||
Information about level objects exists in two places:
|
||||
* Static properties, describing an object in general
|
||||
* Instance data, describing the state of a specific object instance in the game
|
||||
|
||||
The static properties are stored in a separate file. See [Property Files](../fileFormat/PropertyFiles.md) for basic information.
|
||||
Instance data is stored as part of an archive. See [Level Objects](../archives/levelObjects.md) for basic information.
|
||||
|
||||
### Known Classes, Subclasses and Types
|
||||
|
||||
The following table lists the object classes together with the available types per subclass:
|
||||
|
||||
| Class | Name | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|
||||
|:-----:|------------------------------------|----|----|----|----|----|----|----|----|
|
||||
| 0 | Gun | 5 | 2 | 2 | 2 | 3 | 2 | - | - |
|
||||
| 1 | Ammo | 2 | 2 | 3 | 2 | 2 | 2 | 2 | - |
|
||||
| 2 | Physics | 6 | 16 | 2 | - | - | - | - | - |
|
||||
| 3 | Grenade | 5 | 3 | - | - | - | - | - | - |
|
||||
| 4 | Drug | 7 | - | - | - | - | - | - | - |
|
||||
| 5 | Hardware | 5 | 10 | - | - | - | - | - | - |
|
||||
| 6 | Software | 7 | 3 | 4 | 5 | 3 | - | - | - |
|
||||
| 7 | Big Stuff | 9 | 10 | 11 | 4 | 9 | 8 | 16 | 10 |
|
||||
| 8 | Small Stuff | 8 | 10 | 15 | 6 | 12 | 12 | 9 | 8 |
|
||||
| 9 | Fixtures | 9 | 7 | 3 | 11 | 2 | 3 | - | - |
|
||||
| 10 | Door | 10 | 9 | 7 | 5 | 10 | - | - | - |
|
||||
| 11 | Animating | 9 | 11 | 14 | - | - | - | - | - |
|
||||
| 12 | Trap | 13 | 1 | 5 | - | - | - | - | - |
|
||||
| 13 | Container | 3 | 3 | 4 | 8 | 13 | 7 | 8 | - |
|
||||
| 14 | Critter | 9 | 12 | 7 | 7 | 2 | - | - | - |
|
||||
|
||||
> This information is not stored within the resource files, it is hardcoded in the engine.
|
||||
|
||||
|
||||
### Static Properties
|
||||
|
||||
The following table lists the byte sizes of the generic and specific property structures per class.
|
||||
Many of these bytes are all zero in ```objprop.dat```; In these cases no detailed data definition will be linked.
|
||||
|
||||
| Class | Generic | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|
||||
|:-----:|---------------------------------------------|-----------|-----------|-----------|-----------|-----------|-----------|----|----|
|
||||
| 0 | [2](00_Gun/gunProperties.md) | 1 | 1 | [16][0/2] | [13][0/3] | [13][0/4] | [18][0/5] | - | - |
|
||||
| 1 | [14](01_Ammo/ammoProperties.md) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | - |
|
||||
| 2 | [1](02_Physics/physicsProperties.md) | [20][2/0] | [6][2/1] | 1 | - | - | - | - | - |
|
||||
| 3 | [15](03_Grenade/grenadeProperties.md) | 1 | [3][3/1] | - | - | - | - | - | - |
|
||||
| 4 | 17 | 7 | - | - | - | - | - | - | - |
|
||||
| 5 | 2 | 1 | 2 | - | - | - | - | - | - |
|
||||
| 6 | 2 | 1 | 1 | 1 | 1 | 1 | - | - | - |
|
||||
| 7 | 4 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
|
||||
| 8 | 2 | 1 | 1 | 1 | 1 | 1 | [6][8/5] | 1 | 2 |
|
||||
| 9 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | - | - |
|
||||
| 10 | 1 | 1 | 1 | 1 | 1 | 1 | - | - | - |
|
||||
| 11 | [2](11_Animating/animatingProperties.md) | 1 | 1 | [1][11/2] | - | - | - | - | - |
|
||||
| 12 | 1 | 1 | 1 | 1 | - | - | - | - | - |
|
||||
| 13 | 3 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | - |
|
||||
| 14 | [75](14_Critter/critterProperties.md) | 1 | 2 | 2 | [6][14/3] | 1 | - | - | - |
|
||||
|
||||
|
||||
> There is also the case of objects with a specific entry length of 0. This is the case for object types that didn't make it into the game (vending machines).
|
||||
> Though, this is only a guess. Yet, the serialization code of the source-port (based on the mac-port) shows a hack by shifting the offset back by 2 bytes after serializing the doors. So, something must have been done in the original engine.
|
||||
|
||||
[0/2]: 00_Gun/gunProperties.md#specific-2-properties
|
||||
[0/3]: 00_Gun/gunProperties.md#specific-3-properties
|
||||
[0/4]: 00_Gun/gunProperties.md#specific-4-properties
|
||||
[0/5]: 00_Gun/gunProperties.md#specific-5-properties
|
||||
[2/0]: 02_Physics/physicsProperties.md#specific-0-properties
|
||||
[2/1]: 02_Physics/physicsProperties.md#specific-1-properties
|
||||
[3/1]: 03_Grenade/grenadeProperties.md#specific-1-properties
|
||||
[8/5]: 08_SmallStuff/smallStuffProperties.md#specific-5-properties
|
||||
[11/2]: 11_Animating/animatingProperties.md#specific-2-properties
|
||||
[14/3]: 14_Critter/critterProperties.md#specific-3-properties
|
||||
|
||||
|
||||
### Object Names
|
||||
|
||||
The names are localized and [stored as texts](../media/Texts.md). The short names are stored in resource ```0x086D```, the long
|
||||
names are in resource ```0x0024```.
|
||||
|
||||
|
||||
### Object Bitmaps
|
||||
|
||||
Every object has bitmaps associated with it. The bitmaps are all stored in resource ```0x0546``` in ```objart.res```, starting with block 1 for the first object. Each object has at least 3 bitmaps associated, with additional in-world bitmaps specified as per ```Extra``` field of the [Common Object Properties](../fileFormat/PropertyFiles.md#common-table).
|
||||
|
||||
As a result, to determine the proper block number for a given object, the total number of previous (extra) bitmaps needs to be known.
|
||||
|
||||
The first image is the standard image, the second (and additional) bitmaps are in-world bitmaps, and the last one is a micro-image.
|
||||
|
||||
> The micro-images are sometimes fully transparent. This has been found for marker objects for instance.
|
||||
> Maybe a (future) mapping unit would have been able to show objects, except those that weren't meant to be seen by the player.
|
||||
> For such transparent bitmaps, the first bitmap shows some abstract presentation. For example, the "continuous trigger" has the infinity symbol as first image.
|
||||
> On the contrary, using the first bitmap exclusively for editors might not be usable either as they sometimes have the same image for different types (software instance).
|
||||
|
||||
Objects of render type ```Fragment``` have one extra bitmap. The first one contains the colour information and the extra bitmap the depth information; It is a "gray-scale" bitmap with ```0xD0``` as the center.
|
||||
Reference in New Issue
Block a user