Memory Zones
by AkyV

Which variable should I use for a field?
What should I do if I want to put the value of a variable into a field (in Case A )?
What should I do if I want to put the value of a field into a variable (Case B )?
Item Memory Zone fields
Savegame Memory Zone fields
Code Memory Zone fields
Slot Memory Zone fields
Animation Memory Zone fields
Inventory Memory Zone fields
Addendum

* Please note that there is a new tutorial containing fresher data available, which contains special information only contained there. Consider this tutorial for advanced level builders while the new tutorials were written for level builders looking for information quickly. Find the new tutorial here.

First of all, read the variable tutorial by Paolone to understand the variables and these phrases:
- memory zones and
- fields of memory zones

So, every memory zones have several fields. In each field, the game contains the value of a given property of the game. You can use the fields for two purposes:

- Put the value of a variable into a field. The property of that field will use that new value, so the property will change. - It is useful if you don't have a direct method to change that value. (For example, at the moment you don't have a Script command or a trigger to change the inventory coordinates of a weapon directly - but, using fields, you will be able to do that.) - Hereafter I call this purpose 'Case A'.
- Put the value of a field (i.e. a value of a property) into a variable, to examine the value in the variable. - It is useful if you don't have a direct method to examine the value of the property. (For example, at the moment you don't have a CONDITION trigger or a MultEnvCondition/GlobalTrigger Script situation to examine directly how many liters of water Lara just has in the waterskins - but, using fields, you will be able to do that.) - Hereafter I call this purpose 'Case B'.

So, in this tutorial, I will look through all the memory zone fields to show you how you can use them for Case A or B.

Note - things that won't be discussed in this tutorial:

1. There are 'alternative versions' of Case B. I mean, when you use the values not for a condition but something else. For example, you put the value of a field into a variable, and then show that variable value in a customized bar. Or print on the screen. Etc.
2. Though we are talking about variables and memory zones at the same time now, the connection between them is not constant. Because:

- For example, you can use a 'Variables. Numeric' FLIPEFFECT trigger to define a value of a variable, and then you can use a 'Variables' CONDITION trigger to compare that variable value to another number. - As you see, now you didn't use a memory zone field at all.
- For example, you will use a 'Variables. Memory. Set in' FLIPEFFECT trigger to define the value of a field, using directly a given number. - As you see, now you didn't use a variable at all. (Though, if you want, you can use Case A's the way like that. I.e. forcing a given number into a field, and not forcing a value of a variable into that field.)

Which variable should I use for a field?

You will use some 'Variables. Memory' FLIPEFFECT trigger to put the value of a variable into a field (in Case A ) or to put the value of a field into a variable (in Case B ). Those FLIPEFFECT triggers will always offer these variables to use:

Current Value
Global Byte Alfa1-4, Beta1-4, Delta1-4
Global Long Alfa, Beta, Delta
Global Long Timer
Global Short Alfa1-2, Beta1-2, Delta1-2
Last Input Number
Local Byte Alfa1-4, Beta1-4, Delta1-4
Local Long Alfa, Beta, Delta
Local Long Timer
Local Short Alfa1-2, Beta1-2, Delta1-2

It doesn't matter which variable you'll choose for the field - if you don't forget about these things:

1. The variables named 'Local' will lose their actual values

- if you modify them or
- if Lara jumps into another level (Level B ) from the level (Level A ) where you defined that variable. (So each level has its own local variables, and all of those variables have 0 default values when that level starts.) - But if Lara gets back to Level A, then the local variables will get back the values automatically that they lost at the level jump.

The variables named 'Global' will lose their actual values only if you modify them. (The default values of all of the global variables are 0.) - But be careful with ResetHUB Script command that may annul your values in global variables when leaving the level.

Current Value and Last Input Number are global variables.

2. 'Byte', 'short' and 'long' mean the number interval the variable is able to handle:

- The value of a 'byte' variable must be always between 0 and 255.
- The value of a 'short' variable must be always between -32 768 and 32 767.
- The value of a 'long' variable must be always between -2 147 483 648 and 2 147 483 647.

Important!
You have to observe these rules:

- If you use a 'Long' variable for a field then you can't use (for any other purposes in the game) other variables with the same locality ('same locality' means if these variables are all local variables OR if they are all global variables) AND the same Greek alphabet letter (alpha, beta, delta) at the same time. (So, for example, you can't use Global Long Beta with Global Short Beta1 at the same time. But you can use Global Long Beta with Local Long Beta or Global Long Alfa or Local Short Beta2 or Global Byte Delta4 or Current Value or Global Long Timer etc. at the same time in your game.)
- If you use a 'Short1' variable then you can't use 'Long' or 'Byte1' or 'Byte2' variables with the same locality and the same Greek alphabet letter at the same time.
- If you use a 'Short2' variable then you can't use 'Long' or 'Byte3' or 'Byte4' variables with the same locality and the same Greek alphabet letter at the same time.
- If you use a 'Byte1' or 'Byte2' variable then you can't use 'Long' or 'Short1' variables with the same locality and the same Greek alphabet letter at the same time.
- If you use a 'Byte3' or 'Byte4' variable then you can't use 'Long' or 'Short2' variables with the same locality and the same Greek alphabet letter at the same time.

Current Value and Last Input Number are working as 'Long' variables.

3. The 'byte', 'short' and 'long' words in the names of the fields indicate the number the field may have.
For example, if you can see the 'short' word in a field name then that means the smallest expected value in that field is -32 768 and the biggest expected value in that field is 32 767.
So, if you have a field with 'short' word then it's highly recommended to use a 'short' or a 'long' variable for that field, because 'byte' variables can't handle the value of the field if that is between -32 768 and 0 or if that is between 255 and 32 767.

4. If you use a variable for a given task in your level then you can't use that variable for another task in your level at the same time.
But if you don't use a variable for a given task in your level then you can use that variable for another task in your level at the same time.
(It also means:

- if you don't use a variable for a given field at the moment, because you will do that only later, then you can use that variable for any other thing now,
- if you don't use a variable for a given field at the moment, because you did that only before, then you can use that variable for any other thing now.)

5. Special variables:

- If it is not needed then don't use Current Value variable for a task if you can use another variable for that task. Why? Because - as you see in some FLIPEFFECT or CONDITION triggers - there are some special tasks in which you can use ONLY Current Value variable. (I mean, if you use Current Value for a task in which you can use any other variable, then you can't use Current Value for a special task at the same time.)
- Last Input Number is the number you typed last in your keyboard. (It works only with keypad switch at the moment.)
- Local/Global Long Timer values are values of the timers you can adjust by 'Variables. Timer' FLIPEFFECT triggers. (These timers have nothing to do with any other timers of the game.) - 1 second means Value 30 in the variable.

Notes:

1. The 'local/global' type of a variable and the local/global effect of it in the fields is not the same. - See two examples to understand:

a, The amount of the big medipacks is a global value, because, if you have X amount of big medipacks at the end of Level A, then you also have X amount of big medipacks of the start of Level B, if you jump at the end of Level A to the start of Level B.
So, if you use a local variable to define X medipacks at the end of Level A, and you jump to Level B, then the amount of the medipacks willl remain X - though that local variable will become 0 at the start of Level B.
b, The Speed value of an animation is always a local value, because every Speed value is defined by the WAD of the actual level (see the Speed boxes in Animation Editor of WADMerger). - But there's a possibility to modify Speed by variables:
Let's suppose, you have the same Lara-animation in Animation X slots of Level A and the following Level B, so the Speed values of both of them are Value Y. You will define Value Z in a global variable in Level A, and use a trigger to put that value in a field to turn the Speed of Animation X in Level A from Value Y into Value Z. But, if you jump to Level B, the WAD of Level B will turn back the speed into Value Y - though the value of the global variable will remain Z. (So, if you want Value Z in Level B, then you need to put that global variable value into that field again, in Level B.)

2. Every procedure has its own variable values. So Profile A (the game of Person A ) will have other variable values, compared to Profile B (the game of Person B ).
But, unfortunately, it also means if you define a global variable value in title then you can't carry it into your game, because 'starting a new game from title' means 'starting a new procedure'.

What should I do if I want to put the value of a variable into a field (in Case A )?

Using Item Memory Zone

1. The subject of this memory zone is always a given Moveable object placed in your level. You will define that object, using A54 trigger.
2. Then use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value in a variable.
3. Then use F257 trigger to set the value of the variable, in the field that is defined in Window E of the trigger.
Now the property of that field changes, using its new value.

Using Savegame Memory Zone

1. Use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value in a variable.
2. Then use F245 trigger to set the value of the variable, in the field that is defined in Window E of the trigger:
Now the property of that field changes, using its new value.

Using Code Memory Zone

1. Use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value only in Current Value variable.
2. Then use F278 trigger to set the value of the variable, in the field that is defined in Window & of the trigger:
Now the property of that field changes, using its new value.

Using Slot Memory Zone

1. The subject of this memory zone is always a given Moveable object slot of your WAD. You will define that slot, using F292 trigger.
2. Then use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value in a variable.
3. Then use F294 trigger to set the value of the variable, in the field that is defined in Window E of the trigger.
Now the property of that field changes, using its new value.

Using Animation Memory Zone

1. The subject of this memory zone is always a given absolute animation of your WAD. You will define that animation, using F307 trigger.
2. Then use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value in a variable.
3. Then use F296 trigger to set the value of the variable, in the field that is defined in Window E of the trigger.
Now the property of that field changes, using its new value.

(The absolute number of an animation is the position of the animation amongst all the object animations of your WAD.
To understand what the absolute animation is, see this example:
Naturally there are both LARA and PISTOLS_ANIM objects in your WAD. LARA object of the WAD has the lowest slot ID: 0. PISTOLS_ANIM has the next slot ID: 1. LARA has the lowest ID, so her ID0 animation is the ID0 absolute animation of the WAD.
Usually LARA's last animation has ID444, so it is ID444 absolute animation of the WAD.
There's no more animation for Lara now, so the next absolute animation index will be the lowest animation number of the next - used - object slot: Animation0 of ID1 PISTOLS_ANIM. It is the ID445 absolute animation, and, naturally, Animation1 of PISTOLS_ANIM is the ID446 absolute animation etc. - Use 'NG Center\Tools\Animation Watcher\Show PRESENT ANIMATIONS for current slot' to know the absolute animation numbers of a given object slot of your WAD.

However, as my experiences indicate, only the animations of LARA object will work properly in Animation Memory Zone operations.)

Using Inventory Memory Zone

1. The subject of this memory zone is always a given inventory item slot (whether the WAD just has that slot or not). You will define that slot, using F335 trigger.
2. Then use one or more 'Variables. Numeric' FLIPEFFECT triggers to define a value in a variable.
3. Then use F336 trigger to set the value of the variable, in the field that is defined in Window E of the trigger.
Now the property of that field changes, using its new value.

The recommended methods to force a value into a field:

1. Place an F118 trigger (as 'Single performing') to activate all the needed triggers at once, as a TriggerGroup. For example, in the case of Item Memory Zone, you will place an A54 trigger, 'Variables. Numeric' FLIPEFFECT triggers and an F257 trigger in the TriggerGroup in the Script. (When you place those triggers in the TriggerGroup in the Script, don't forget to place F257 trigger at the last place in the range of the triggers - so that is the last trigger that will be activated in that TriggerGroup. Which is important.) You may place one or more CONDITION triggers before A54 in the TriggerGroup, if you want the activation only under some circumstances (now F118 must be 'Multiple performing').
2. Use a TriggerGroup, but don't place an F118 in Room Editor. Instead of that, place that TriggerGroup in a GlobalTrigger in the Script (in IdPerformTriggerGroup field), and the condition in the GlobalTrigger will activate the TriggerGroup.

Notes:

1. See further 'Variables. Memory' FLIPEFFECTs. Using them (together with 'Variables. Numeric' FLIPEFFECT triggers), you will be able to make further operations on the new value of the field, modifying that value. (See for example 'Variables. Memory. Subtract' triggers.)

2. When you define the subjects of the memory zones (Item, Slot, Animation or Inventory Memory Zone) then you will always define a given subject by the triggers I mentioned above.
But, using some Savegame Memory Zone fields, the actual value of the field will be the actual subject of those zones. - The fields are:

- TRNG Index. Animation Index for Selected Animation Memory (Short)
- TRNG Index. Item Index for Selected Item Memory (Short)
- TRNG Index. Slot Index for Selected Slot Memory (Short)

See more about them below.
Inventory Memory Zone doesn't have a field like that.

(I will write sometimes below that you don't need to use a given field because you have a direct method for that forcing operation. But that's not true if the operation has an inconstant subject, because the direct methods always work with a constant subject.
So, if you want an inconstant subject for an operation, then define that subject by these 'TRNG index,' triggers then use that subject in the given field, avoiding the direct method.

And a similar thing: using any memory zones - so even Savegame or Code Memory Zone - you can define different forced values in another way, compared to as you can defined that with the direct methods. - See an explanation of an example to understand:

Direct method:
Condition A is true, then triggering with value 100
Condition B is true, then triggering with value 200

Memory zone method:
The value of Variable X is defined as Y.
Condition A is true, then triggering with value Y+50
Condition B is true, then triggering with value Y+150

As you see, the result of the methods is the same only if Y=50. The triggering value is always 100 or 200 at the direct methods but could be anything - i.e. 50 or 150 plus the actual Value Y - with the memory zone methods.
So if you want a more flexible value for the operation, then skip the direct method, and try to use the memory zone method - even when I say you don't need the memory zone method.)

3. If you defined a value in a variable but you don't want to use it right now in a field, then store it in a Store variable (by F236 trigger), so you can use it later (by F237 trigger).

4. Unfortunately, sometimes you may experience that memory zone fields will lose the values you forced on them by variables:

- sometimes at level jumps or
- sometimes, if you save the game and then you will load that saved game.

If it happens or not, that depends on which field you are using.
If you want to know more about this problem, see this part in the variable tutorial of Paolone: The wooden Door: how save and restore our changes.
(If you don't use that variable for other purpose in that level, then it's a more simple method if you force that value always into that field by a GT_ALWAYS GlobalTrigger. - Or, if you don't want the value to be forced into that field in the whole level, then disable the GlobalTrigger when that is not wanted.)

5. Some fields cannot be forced, so you can't use Case A with some fields.

What should I do if I want to put the value of a field into a variable (Case B )?

Using Item Memory Zone

1. The subject of this memory zone is always a given Moveable object placed in your level. You will define that object, using A54 trigger.
2. Use F256 trigger to put the actual value of a field (defined in Window E of the trigger) into a variable.
3. Then use a 'Variables' CONDITION to examine how the value of the variable (i.e. the actual value of the field) is related to another value.

Using Savegame Memory Zone

1. Use F244 trigger to put the actual value of a field (defined in Window E of the trigger) into a variable.
2. Then use a 'Variables' CONDITION to examine how the value of the variable (i.e. the actual value of the field) is related to another value.

Using Code Memory Zone

1. Use F277 trigger to put the actual value of a field (defined in Window & of the trigger) only into Current Value variable.
2. Then use a 'Variables' CONDITION to examine how the value of the Current Value variable (i.e. the actual value of the field) is related to another value.

Using Slot Memory Zone

1. The subject of this memory zone is always a given Moveable object slot of your WAD. You will define that slot, using F292 trigger.
2. Use F293 trigger to put the actual value of a field (defined in Window E of the trigger) into a variable.
3. Then use a 'Variables' CONDITION to examine how the value of the variable (i.e. the actual value of the field) is related to another value.

Using Animation Memory Zone

1. The subject of this memory zone is always a given absolute animation of your WAD. You will define that animation, using F307 trigger.
2. Use F295 trigger to put the actual value of a field (defined in Window E of the trigger) into a variable.
3. Then use a 'Variables' CONDITION to examine how the value of the variable (i.e. the actual value of the field) is related to another value.

Using Inventory Memory Zone

1. The subject of this memory zone is always a given inventory item slot (whether the WAD just has that slot or not). You will define that slot, using F335 trigger.
2. Use F339 trigger to put the actual value of a field (defined in Window E of the trigger) into a variable.
3. Then use a 'Variables' CONDITION to examine how the value of the variable (i.e. the actual value of the field) is related to another value.

The recommended methods to study a value of a field as a condition of some executable trigger(s):

1. Place an F118 trigger (as 'Multiple performing') to activate all the needed triggers at once, as a TriggerGroup. For example, in the case of Item Memory Zone, you will place an A54 trigger, an F256 trigger and a 'Variables' CONDITION trigger in the TriggerGroup in the Script. (Place CONDITION trigger at the last place in the range of the triggers.) And then, also place one and more executable triggers in this TriggerGroup (after CONDITION): these triggers will be activated, if the condition will be true. (You may place one or more other CONDITION triggers before A54 and F256: so the value of the field will be studied only if those other conditions are true.)
2. Use a TriggerGroup, but don't place an F118 in Room Editor. Instead of that, place that TriggerGroup in a GlobalTrigger in the Script (in IdPerformTriggerGroup), and the condition in the GlobalTrigger will activate the TriggerGroup. (So the value of the field will be studied only if the condition in the GlobalTrigger is true.)

Notes:

1. After you have put the field value into a variable, you don't need to study it in a CONDITION trigger at once. I mean, maybe you want to modify it before that study.
Let's see for example the case of Item Memory Zone: use one or more 'Variables. Numeric' or 'Variables. Memory' FLIPEFFECT triggers to modify the value you got by F256. Place those Numeric/Memory triggers between F256 and the 'Variables' CONDITION trigger in the TriggerGroup.

2. Item#2-#4 of the notes in Chapter 'What should I do if I want to put the value of a variable into a field (in Case A)?' can be valid in the present chapter as well.

3. Some fields are senseless to be studied, so you can't use Case B with some fields.

4. F339 trigger probably doesn't work, so you can't use conditions for Inventory Memory Zone fields. - Moreover, my experience: if you use (some fields of) this trigger and Lara collides with the objects then the game will crash.
(However, using conditions for inventory items is not a really useful thing, so we don't lose much if we skip this trigger.)

Item Memory Zone fields

Animation Now (Number of current animation) (Short)
It defines the actual animation of the subject (i.e. a Moveable object). (Note: it works with absolute animation ID's.)

Case A: it seems buggy for me. So, if you want to force an animation on Lara or another Moveable, then use A15, A16, A17 or F77, F80, F169, F170, F171 triggers.
Case B: you don't need to use that, because if you want to know if the actual animation of Lara or another Moveable is a given animation, then use C21, C23, C24 or C30 triggers. (Please note you can't examine an animation of Lara if that animation is not an animation of the placed LARA object, but it's an animation of her from VEHICLE_EXTRA or any other 'animation store' objects.)

Contact Flags ($2400 = damage lara on touching) (Long)
It defines if Lara is just colliding with a Moveable object or not. If the value is 0 then she's not colliding, but if it is not 0 (but any other number) then she's colliding. (In fact, it works in a different way at different objects. I mean, the value will always be updated at creatures, but at ANIMATINGs it will be updated only at newer collisions. It means, after the first collision between them, the value will never be 0 again at the given ANIMATING. And, for example, at traps this field seems not really useful.)

Case A: there is only one case when it's worth forcing a value here: it is Value 0 at creatures. The collision will happen now, but Lara will be invulnerable against the given enemy. (You have F91 trigger if you want to force invulnerability on Lara. But that trigger is general. I mean, if you want Lara to be invulnerable only against a given enemy - the subject -, then put 0 into this field.)
Force the 0 continuously, i.e. using a GlobalTrigger, while the enemy is alive - or till you want the invulnerability to work.
Please note it is useful only at collision, i.e. at direct contact (eg. a sword hits Lara), so it won't work if a bullet of the enemy hits Lara.
Case B: if the 'Variables' CONDITION trigger confirms the value is 0 then that is an 'if Lara is just not colliding with the subject Moveable' condition. If that confirms the value is not 0 then that is an 'if Lara is just colliding with the subject Moveable' condition. (See similar conditions in "GT_COLLIDE" type GlobalTriggers or "Collision" tpye CONDITION triggers.)
(That Value $2400 did not work for me the way as Paolone wrote that.)

Custom Flags (Different flags in according with object type) (Byte)
It tells you about the activity state of the subject. (0: not activated/deactivated, 62: active, 191: dead enemy.)

Case A: you don't need to use that, because if you want to trigger/antitrigger objects then you have a lot of other triggers for that.
Case B: you don't need to use that, because C14 trigger will examine if an object is active or not.
(Note: in C14, all the conditions work for creatures - 'active' and 'living' seem to be the same for them -, but use only 'active' and 'not active' conditions for non-creature Moveable objects.
Important: if a non-creature doesn't move after having been activated that doesn't mean it is 'not active'. I mean, eg., if a door has opened or a boulder has stopped at the end of its track, then they are active objects, because we didn't deactivate them after activating them. So, use an antitrigger to close the door or to make the stopped boulder do nothing - and now they are 'not active' again.)

Custom_A (Different usage in according with type of item) (Short)
The game calculates here some movement-related things of some Moveable objects that are not creatures but more than simple ANIMATINGs.

Let's see how this works in the case of rollingball subjects:
The game calculates here how many length units the moving rollingball subject must 'travel' in the north or south direction (Room Editor facing) in the given moment, until that stops. (Negative numbers= moving northwards, positive numbers= moving southwards.) I think (approximately?) 512 length units is 1 square now. (Naturally, the bigger the number is the more the speed of the ball is.)

Case A: the length will be calculated again and again, in every moment, according to the actual speed and direction. That's why if you want to force a value into this field, then you want to force it again and again - or else the game will overwrite your new value at the next moment. - So here's an example about what you should do - type a GlobalTrigger into your Script:

GlobalTrigger= 1, FGT_DISABLED, GT_ALWAYS, IGNORE, IGNORE, 1, IGNORE
TriggerGroup= 1, A54: the subject is the rollingball, 'Variables.Numeric' FLIPEFFECTs: the variable value is 6144, F257: the field is this 'Custom_A,' field

In the game, the ball has been activated and starts rolling southwards on a non-sharp slope. It reaches a HEAVY trigger that enables GlobalTrigger#1. 6144(=12x512) means a big speed (because you need a big speed for a 6144 units long travel), so the ball will pushed southwards hard now. In the next moments, the length is still 6144, so the ball remains fast. Later, the ball reaches another HEAVY to disable GlobalTrigger#1, so the ball moves 'in the regular way' again now, and will stop soon by itself.
Case B: it's hard to create a nice Case B condition, if the rollingball has a complicated track. For example, if the ball moves southwards, but a slope will divert it westwards, then the value of the field will remain 0 continuously after that, saying 'the ball is still moving, but will move neither northwards nor southwards from now on, until it stops'.
But if the track is easy then the condition is clear. For example, if the ball just rolls southwards and then stops, then 0 condition means 'if the ball stops' now.
(It is interesting to use a non-0 value here. For example, -512 means 'if the ball stops in 1 square distance'. - But, don't forget: values are calculated again and again, so, if the speed and/or the direction changes during the 'traveling', then the field may be -512 more than one time, during the 'traveling'.)

And now let's see a TEETH_SPIKES subject here:
Though this seems a bit inaccurate statement now, the value in the field indicates how many height units are between the actual positions of the tips of the spikes and the totally extended positions of them - in which 1024=1 square, positive number: moving towards the bottoms of the spikes, negative number: moving towards the tips of the spikes. (It doesn't matter in which direction the spikes are indicating.)
The point is the value is 1024 when the spikes are totally drawn back (even if they haven't been activated), and 0 if they are totally extended.

Case A: I don't think you should force the position on teeth spikes by this field. If you want to do that then you'd better use 'Move' ACTION triggers or similar Parameters Script commands.
Case B: the useful values now seem to be 1024 ('if the spikes are totally drawn back' - even if they are just active) or 0 ('if the spikes are totally extended' - even if they are just active). (But be careful: each time the spikes jumps out and back, they are extended twice, because they are 'bouncing' a bit - see it in the game. So before they are drawn back, they will reach the Position 0 twice.)

And now let's see a PUSHABLE_OBJECT subject here:
Now this value here indicates the distance of the object from a given base (in which 1024=1 square). Unfortunately, I don't know where that base is exactly. (Maybe that is an east-west axis of the Room Editor Window.)

Case A: the base is undetermined so you'd better avoid forces coordinates on Pushable by this field. Besides, use 'Move' ACTION triggers or similar Parameters Script commands instead, to force the coordinates.
Case B: the base is undetermined (so we can't really comprehend the values here - by the way, if you need an 'if the PUSHABLE is in a given position' condition, then use HEAVY/HEAVYSWITCH triggers, as usual). But the field will always be refreshed if the player hits CTRL to make Lara push/pull the object. - It means 0 is a useful value now. Why? Because, while Lara doesn't push/pull the object at all, the value is 0. So Value 0 means an 'if Lara hasn't pushed/pulled this object before at all' condition.

Further values I experienced with some further objects (as you see they are not always 'movement-related' things):

- BIRD_BLADE: 0: inactive/just opening, 6: just closing.
- FLOOR_4BLADE: 30: blades move upwards (both the first movement and when the blades will clap together), 0: in any other cases.
- PUZZLE_HOLE: 1: if Lara is just placing the puzzle item here, 0: in any other cases.
- STEAM_EMITTER (with OCB values to blow the harmful, horizontal steam): 480xA+8 OCB value is needed, in which A=the seconds of the pause. So, for example, 480x1+8=488 OCB means 1 second pause. This 1 second=30 frames will appear in this field (as 30) and starts counting down.
- FLAME_EMITTER: blowing a horizontal or vertical flame, also the same type timer is in this field, as at STEAM_EMITTER (i.e. it's a pause timer).
- EARTHQUAKE: the actual intensity of the earthquake. (109 seems the biggest one.) - Just think about this nice condition in a GlobalTrigger: if the intensity of the earthquake is bigger than X then the rollingball will fall down.
- AMBER_LIGHT: if the pulsing light is active then the value runs continuously from -32768 to 32767, again and again. (So each value means the actual degree of the pulsing intensity.) - It changes Value 2048 after each frame. So each cycle is 32 frames long.
- WHITE_LIGHT: it's a timer, in frames. It starts from 0 when the object is activated. When this 'neon light that starts lighting in a blinking mode' lights continuously at last, then that means the timer stops at 160, and remains that.

If you want to know how other objects work in this field then follow these instructions:

1. Create a GlobalTrigger. The condition is GT_ALWAYS. And that is in the executable triggergroup: 'an A54 trigger that defines the subject of the memory zone and then another trigger (F256) that puts the actual value of this Custom_A field into a variable'.
2. Enable Diagnostic mode and use DGX_COMMON_VARIABLES DiagnosticType.
3. Build the Script and start the game and the level with that object.
4. You can see a lot of variable values on the screen, including the variable with the actual Custom_A value of the subject item.
5. Activate the item or interact with it and see how the variable (field) value will change (continuously) if the item does this or does that.

But sometimes the value changes in the variable too fast so you can't read the values from the screen. If you encounter this, then you need to do some more things:

6. See the ID of the variable (that you put the value of the field into) in NG Center\Reference\Variable Placefolders. Put this ID into a (any) ExtraNG String.
7. See the executable triggergroup of that GT_ALWAYS GlobalTrigger. Put F308 trigger after F256 here, with that ExtraNG String.
8. Build the Script.
9. Start TOMB4_LOG.exe from Tools folder and then start the game and the level with that object. The window of the log program is also on the screen now.
10. Activate the item or interact with it - you can see: the variable (field) values are changing not only on the screen but also in the log program window.
11. Quit the game and the log program.
12. Study the tomb4_log.txt in Tools folder. This is the latest log file of the game (made by TOMB4_LOG.exe just before) so you can examine the field values here. (Each entry means a new frame. So you can see how the value changed frame by frame.)

If you want to know more about this diagnostic/log method, then read that in the 'How discover the sense of some memory fields' chapter in the variable tutorial of Paolone.
(Naturally, the method is useful for other Item Memory Zone fields as well.)

Custom_B (Different usage in according with type of item) (Short)
It's similar to 'Custom_A,' field. - Let's see some examples:

- ROLLINGBALL: the horizontal 'travel' of the moving rollingball eastwards (positive numbers) or westwards (negative numbers), with the same units as above.
- TEETH_SPIKES: 0: the spikes are totally drawn back, 5120: the spikes are totally extended. (So this is a similar thing as at Custom_A, but the numbers are other numbers.)
-RAISING_BLOCK2: 0: the block is totally descended, 4096: the block is totally ascended (i.e. 2048=ascended 1 square). - So, for example, forcing 6144 in Case A into the field, the too extended block will be ascended 3 squares (12 clicks) - but the block loses the collision.
- STEAM_EMITTER: a countdown timer in frames. It starts when the emitter starts blowing the steam, and stops when it starts stopping blowing that.
- FLAME_EMITTER: when it starts blowing a flame, then the value starts running from 0 to -8192. When it starts stopping blowing flame, then the value starts running from -8192 to 0. - It's the actual length of the flown flame. (-8192=2 squares long.) You can't use positive number to flow the flame in the opposite way.
- EARTHQUAKE: the actual intensity of the earthquake, but not as precise as in Custom_A. I mean, there are only two values now: 20: low earthquake, 100: high earthquake.

Custom_C (Different usage in according with type of item) (Short)
It is also similar to Custom_A.
For example, if you use a PUSHABLE_OBJECT2 here, then you see here its distance from a given base (which may be a north-south axis of the Room Editor Window this time) again.

Or use TEETH_SPIKES here. When the 'bouncing' spikes reach Position 0 (see above) at the second time, then a timer will start. It's 64 now (as frames) and counts down. The spikes will be drawn back, and remains there until the timer reaches 0. Now the spikes jump out again.
Case A: for example, use this GlobalTrigger:

GlobalTrigger= 1, IGNORE, GT_CONDITION_GROUP, IGNORE, 1, 2, IGNORE
TriggerGroup= 1, A54: the subject is the TEETH_SPIKES object, F256: the field is 'Custom_A,' field (putting it into Local Short Alfa1), C43: 'if Local Short Alfa 1 is 0'
TriggerGroup= 2, 'Variables. Numeric' FLIPEFFECTs: the value of Local Short Alfa2 variable is 32, F257: the field is 'Custom_C,' field (putting Local Short Alfa2 into it)

(Note: in TG2, the subject is still that TEETH_SPIKES, so we don't need to define that again.)

That's what happens in the game now: the ascending spikes reach Position 0 (see: if Local Short Alfa1=0). The GlobalTrigger starts the timer (with 32 as a start value). But then the bouncing spikes reach Position 0 again, so the timer starts again: 32, 31 etc. 32 is 50% of the original 64, so this TEETH_SPIKES object will jump out/back twice fast, compared to the 'default TEETH_SPIKES speed'. (Anyway, I think the 'bouncing part' has changed a bit now.)

(Note: if the timer is too short then there is no time for the spikes to be drawn back totally. So they will be drawn back a bit - more or less for halfway - and then jump out again.)

Case B: for example, Value 30 means now an 'if the moving spikes have 1 second before the next jump-out' condition. (Because 30 frames=1 second.)

An example shows when the field doesn't indicate some movement-related thing but something else:

Use a BADDY_1 here. (Yes, a creature!)
When he's not active then the field value is 24. Then he 'awakes' and starts shooting Lara. Every time when he pulls the trigger, it subtracts 7 from that 24: 24, 17, 10, 3, -4 - and now he takes his sword.
Case A: the baddy always stops shooting if his ammunition is not a positive number. So, if we force Value 20 on him now, then he can shoot three times before taking the sword: 20, 13, 6, -1. (Of course, you can give much more ammunition to the baddy - forcing a big number in the field. Or, force any number, but make it unchangeable by a GT_ALWAYS Globaltrigger - and the starting ammo of the baddy will be unlimited.)
Case B: for example, not forcing any number in Case A, Value 10 means now an 'if that BADDY_1 has shot twice at Lara just after having been activated' condition.

Some other values:

- FLAME_EMITTER: it's 256, with blown type flame, even if it is not activated. When the emitter starts blowing, then it counts down to 0 fast. When the emitter starts stopping blowing, then it counts to 256 fast.
- STEAM_EMITTER: when the emitter starts blowing, then it counts from 0 to 4096. When the emitter starts stopping blowing, then it counts down from 4096 to 0. - It's the actual length of the flown steam. 4096=1 square long.
- EARTHQUAKE: it's a countdown timer. It starts from a value, and, reaching 0, it will start again from a different value. I think every phase from the start point to 0 means an intensity range. (So when the timer counts down the next phase from the start to 0 then the earthquake will have another intensity range, with bigger or smaller quakes as in the previous phase.)

Custom_D (Different usage in according with type of item) (Short)
It is also similar to Custom_A. - Some examples:

- BIRD_BLADE: from 0, the value becomes 100 'forever' after the trap has been activated. (So, for example, Value 100 means an 'if the trap is active or deactive, but has been activated at least once before' condition in Case B.)
- FOOR_4BLADE: from 0, the value becomes 20 when the blades (moving upwards) stops first, and becomes 200 when they (moving upwards more) clap together. (It remains 200, and repeats the sequence at newer activations: 20-200, 20-200 etc.)
- CATWALK_BLADE: the value is 100 when the blades are just moving, in any other cases it's 0.
- PLINTH_BLADE: from the start to the final stop the value is 200, in any other cases it's 0.
- STARGATE: from 0, the value becomes 50 'forever' after the trap has been activated. (So, for example, Value 0 means an 'if the trap has never been activated' condition in Case B.)
- FLAME_EMITTER: it's a countdown timer in frames. It starts when the emitter starts blowing the flame, and stops (reaches 0) when the emitter stops (totally) blowing the flame.

Facing Horizontal (Short)
Facing Rotation (Only for Lara) (Short)
Facing Vertical (Short)
There are some methods to turn the objects around their axes (see: Turn ACTION triggers or Parameters Script command). They are different type of rotations (more or less) that's why they can have different effect on the different objects. It means, for example, sometimes they don't really like affecting Lara. - But these three 'Facing' fields are great tools to rotate Lara. So I'll show now how they work with her (though you can try them with other objects).

a, 'Facing Horizontal' defines how Lara will be rotated around her vertical axis.
Some accentuated values are:

Lara faces east exactly (Room Editor facing) = 0 degrees turn (default state) = Value 0 ($0000) = 360 degrees turn (full circle) = Value 65535 ($FFFF)
Lara faces south exactly (Room Editor facing) = 90 degrees turn = Value 16384 ($4000)
Lara faces west exactly (Room Editor facing) = 180 degrees turn = Value 32768 ($8000)
Lara faces north exactly (Room Editor facing) = 270 degrees turn = Vale 49152 ($C000)

(Note: see Lara in the Animation Editor of WADMerger. As you see, Lara's face looks in the different direction, compared to that long blue line. So, if you say 'an object faces east in Room Editor' that means 'the side of the object that looks in the different direction, compared to that long blue line, faces east in Room Editor'.)

Case A: an example - use this TriggerGroup in the Script:

TriggerGroup= 1, A54: the subject is Lara, 'Variables.Numeric' FLIPEFFECTs: the variable value is 16384, F257: the field is this 'Facing Horizontal,' field

Let's suppose Lara runs eastwards and then she steps on the square where an F118 activates this TriggerGroup. She will be rotated to face south at once - but it doesn't mean the player loses the control on her so the player can modify how she faces, at once, if (s)he wants.
And now, type this GlobalTrigger into the Script:

GlobalTrigger= 1, IGNORE, GT_ALWAYS, IGNORE, IGNORE, 1, IGNORE

So Lara will face south when the level starts and the player can't modify it, because GT_ALWAYS will force the south side again and again. (It doesn't mean the left or right arrows are disabled. So if you hit left/right arrows then the game will try to move Lara - but then nothing will happen.)
Case B: for example, Value 32768 means an 'if Lara faces west exactly' condition.

b, 'Facing Rotation' defines how Lara will be rotated around her horizontal axis that is perpendicular to her shoulders and drawn in the level of her soles.

Some accentuated values are:

Lara stands vertically exactly = 0 degrees turn (default state) = Value 0 ($0000) = 360 degrees turn (full circle) = Value 65535 ($FFFF)
Lara leans totally right = 90 degrees turn = Value 16384 ($4000)
Lara stands upside down exactly = 180 degrees turn = Value 32768 ($8000)
Lara leans totally left = 270 degrees turn = Vale 49152 ($C000)

(Notes:

1. The game will correct the new position at once automatically - back to the default one -, so you want to force it continuously - by a GlobalTrigger - so Lara will hold the position.
2. If Lara is rotated then maybe some of her animations - for example: doing interactions with objects - are impossible to do.
3. Hair object may be buggy a bit with this kind of rotation.
4. When Lara swims in water, then the field works in another way:

Facing Rotation' defines how Lara will be rotated around her vertical axis - I mean that is not vertical now, for example, if she swims forward under water: now that is the longitudinal axis of her body.

Some accentuated values are - supposing she swims forward under water:

Lara swims with her face down exactly = 0 degrees turn (default state) = Value 0 ($0000) = 360 degrees turn (full circle) = Value 65535 ($FFFF)
Lara swims with her face left exactly = 90 degrees turn = Value 16384 ($4000)
Lara swims with her face above exactly = 180 degrees turn = Value 32768 ($8000)
Lara swims with her face right exactly = 270 degrees turn = Vale 49152 ($C000)

5. Whatever the field name says - 'only Lara' -, this field works well with other objects.)

c, 'Facing Vertical' defines how Lara will be rotated around her horizontal axis that is in the line of her shoulders and drawn in the level of her soles.

Some accentuated values are:

Lara stands vertically exactly = 0 degrees turn (default state) = Value 0 ($0000) = 360 degrees turn (full circle) = Value 65535 ($FFFF)
Lara leans totally back = 90 degrees turn = Value 16384 ($4000)
Lara stands upside down exactly = 180 degrees turn = Value 32768 ($8000)
Lara leans totally forward = 270 degrees turn = Vale 49152 ($C000)

(Note: some 'serious state changes' - for example, jumping into deep water - may annul the effect of the rotation, if you don't force it on Lara continuously, by a GlobalTrigger.)

Flags of Item (Long)
This field shows lots of flags for the object. - Thanks to Paolone's tutorial, (some of?) the flags are identified (renewed by me):

1 ($0001): the object has been triggered and has not been killed. ('Kill' doesn't mean 'antitriggered' now.)
2 ($0002): the object has the collision.
4 ($0004): the object has not been triggered or has been killed.
8 ($0008): the gravity affects the item (so it's just falling down)
16 ($0010): the object is just being hit.
32 ($0020): the object has not been killed.
64 ($0040): Paolone says it indicates if an object has been killed by an explosion. According to my experiences, that is wrong. I mean I experienced the independent (i.e. 'camera-less') CAMERA_TARGET objects have this flag, if they are activated at least once.
128 ($0080): supposedly an existing flag. But it's unknown.
256 ($0100): the object has been poisoned.
512 ($0200): the object is in AI_GUARD mode.
1024 ($0400): the object is in AI_AMBUSH mode.
2048 ($0800): the object is in AI_PATROL mode.
4096 ($1000): the object is in AI_MODIFY mode.
8192 ($2000): the object is in AI_FOLLOW mode.
16384 ($4000): Paolone says it indicates if the object is 'self-created' such as GRENADE or CROSSBOW_BOLT. (I suppose FLARE_ITEM is also one of them.) I can't examine that, because if I place an object like that intentionally in the map (and then make it to be the subject of the field) then the flag doesn't work.

The non-creature objects use these flags in a bit peculiar way, so, I think it's better if I talk about first how the creatures use the flags:

See a simple case:
The aggregated flag value of the living creatures is mostly 35, because:

1: they are living, and
2: they have their collisions, and
32: they haven't been killed.

And 1+2+32=35.

If Lara shoots at an enemy and hits the target, then the creature mostly has Value 51, because 16 (he's been hit)+35 (1+2+32)=51.
When the enemy has been killed, his flag value is 4 mostly (and remains that forever, of course, because the flags of a dead enemy will not change). But he will take a situation flag on if he had that when he was killed. I mean, for example, if a poisoned arrow of Lara poisons the creature, then he will have 291 (256 'poisoned'+35 'lives') flag value, and then he will die, having 260 (256 'poisoned'+4 'dead') flag value.

But, for example, what if the creature is alive, and keeping guard at an AI_GUARD object? - Well, then he has Value 547, because 512 (AI_GUARD mode)+35 (1+2+32)=547.

It's a bit complicated to understand the value of the creature before he has been triggered.
I mean, mostly 38 is the flag value of a 'still not living' enemy, because:

2: he has the collision, and
4: still not triggered, and
20: still not dead.

Yes, he has the collision. I mean, creatures always have their collisions if they are not killed. ('Die' means, actually: he is frozen at the last frame of his dying animation, he loses his collision, and he becomes invisible, having Value 4 flag.) So, if they are not triggered, they have collision, but the collision won't be realized until triggering the creature, so Lara won't bump into a non-triggered, invisible creature.

(Naturally, for example, if a 'still not living' enemy is placed on a square with an AI_GUARD object, then he will have the 512 'AI_GUARD'+38= 550 flag value.)

Case A: for example, if the creature keeps guard at an AI_GUARD point with 547 flag value, you will force Value 35 on him, dropping the 512 'AI_GUARD' flag. So the creature will leave his post - though Lara has not disturbed him, being too far away from him.
(But don't forget two things: not all the flags or flag-combinations can be forced, and don't force flags on an object, if the object is not active.)
Case B: for example, Value 51 means an 'if the enemy has just been hit' condition or Value 260 means an 'if the enemy is dead, but he was poisoned' condition. (It's not sure that he was killed by the poison. I mean, for example, Lara poisoned him and then drew Uzis to make him die sooner.)

Other remarks about creatures:

- Some creatures will use not Value 38 but 32 ('has not been killed') before being activated. These are the creatures that are visible before activation (eg. skeletons lying on the floor - i.e. with Value 3 in the OCB window -, or wraiths if you forget to hit 'Invisible' button on the OCB panel) or the emitter creatures (such as scarabs, locusts etc.).
- Hit (16) flag always works if a bullet has hit the creature. So even when he's immortal or he's blocked the hit or if the aggressor is not Lara (but, eg., TROOPS shoots at SCORPION). - Notes:

a, Other harms (arrows, grenades or if the SCORPION grabs TROOPS etc.) are not calculated in this flag.
b, If Lara shoots the horseman on the horse then the hit is calculated at both the horseman and the horse.
c, If Lara is too close to the enemy but not close enough to aim automatically, but she shoots and hits with 'automatic targeting' adjusted, then that is also calculated in this flag.

- If a creature has been killed by an explosion then his flag is 18=2+16. (An interesting case: the creature was poisoned but killed by an explosion: 256+2+16=274 - so Flag 4 is missing now.)
- When the skeleton has been shot off the ledge by the shotgun, and is just 'falling into the death', then the flag is 43 (8 'gravity'+35). When he's gone, fallen into the pit, then the flag is 42 (8 'gravity'+2+32). (But the 'headless' skeleton remains 35.)
The harpy is similar: Lara has shot him, so he's just falling down by Flag 43. Then he lands, but still visible, so the flag changes into 35. Then he dies 'totally' (becoming invisible), so the flag is 4 now.
- The 'dead' (gone) guide has Value 38.
- If the Ahmet has been killed, he remains 35, whether he will be transported back into his cage or not.
- Little beetles remain 35 after having been killed by an OldFlip FLIPEFFECT. Unfortunately, saving and loading the game now resets their activating trigger, so the flag turns into 32. (To avoid the unwanted, newer activation of this trigger, use ACTION+One Shot trigger to activate them.)
- If the locusts have been all activated, then the value becomes not 35 but 34=2+32. (I mean, if Lara is just standing on their trigger - even they are activated or all gone - the value will be 35 till she leaves that square. Use One Shot trigger to avoid Value 35 when they are activated/all gone.)
- If the skeleton/baddy jumps aside when triggered (see: OCB 1 or 2) then he adopts AI_GUARD flag (temporarily, while he's doing that).
- If the enemy stops at the second AI_AMBUSH nullmesh, then his AI_AMBUSH flag turns into AI_GUARD flag.
- If SETHA can't find Lara (try that, using DOZY to fly above him), then he adopts AI_AMBUSH flag forever.
- Patrolling (AI_PATROL) enemies are harmless. And, if they are distracted by Lara, then lose their AI_PATROL flag (and remain harmless).
- AI_MODIFY nullmesh is interesting. It's almost the same as AI_GUARD, but the creature has less head-movements now, so it's harder to him to notice Lara. Moreover, eg., a BADDY_1 here won't leave this place, having been distracted, and shoots Lara with infinite ammo. And, as the baddy won't leave his post, he won't ever drop his AI_MODIFY flag. - But, eg., a crocodile will leave this place - though, he also won't drop the flag.
- AI_MODIFY with AI_GUARD mean the creature won't move the head at all here. If Lara distracts him, he'll drop AI_GUARD flag, but won't drop AI_MODIFY flag, and act as if he were in a simple AI_MODIFY mode.
- If the guide arrives to an AI_FOLLOW nullmesh, temporarily loses AI_FOLLOW flag - till the game adjusts his position to the nullmesh.
- In the horse-horseman connection, only the horseman has the AI_FOLLOW flag - till he climbs up the horse. (It's interesting, but during the battle of Lara and the mounted horseman, he rides back sometimes to the AI_FOLLOW nullmesh 'to rest a bit'. In these moments, he temporarily has the AI_FOLLOW flag again.) - By the way, after having been activated, the horse has value 34 forever.
- If any of the baboons have died by a flash, then they have a strange flag: 38+AI_FOLLOW=8230.
- AI_X1 and X2 have no flags in this field.
- Gravity (8) flag is the only flag in this field that works with Lara as well. (Even when she's just jumping up.)

And this is what you need to know about non-creature Moveable objects:

- Most of the Moveable objects are seeable in the map when the level starts. (Of course, if you hide an object, using 'Move' ACTION triggers or some other tricky way, then that doesn't matter now as 'non-seeable'.) They have Flag 32 now. The non-seeable ones (such as teeth spikes, for example) will have Flag 38 (2+4+20) before activation.
- Activating the seeable ones, they'll mostly have Flag 35 (1+2+32) 'forever' - so, eg., even if you stop them and then restart them. But this is not true if Lara has interaction with them. I mean, if Lara is just moving a pushable object (or a SAS_DRAG_BLOKE), a switch, a death slide (zipline), 'scales' object (see: setup of Ahmet creatures) etc., then the value is 35, but after that, it is 32 again. - Exceptions I revealed:
If Lara used a switch without triggers (!) at least at once, then the flag is always 37 (1+4+32) if Lara is just not using the switch.
If Lara used a timed switch, then the flag remains 35, and changes back into 32 only if the switch has been switched off automatically. (If that automatic motion happens when Lara isn't on the square of the trigger then the value is 37 and not 32 - till Lara comes there again.)
If Lara uses a 'hole in the wall' switch to get an item from it, then she doesn't use it as a switch, so the value remains 32.
If Lara poured the wrong amount of water into the scales, then the value remains 35, and gets back to 32 only if she's 'killed' the Ahmet.
If Lara used them, the element puzzle 'scales' remains 32 constantly - except the one you've ignited the petrol on it (35).
If Lara places the puzzle item in the (subject) puzzle hole then the value becomes 35 only if the hole has been replaced by the puzzle done object. (And, if the animation has ended - because Lara's lowered her hands - then the value becomes 37. It is 35 again if Lara leaves the trigger zone, but changes back into 37 again and again, if she comes back there. It doesn't matter if KEY trigger is One Shot or not.)
If Lara activates a trigger to send back the zipline into the start position, then the value is 35 while Lara stands on the trigger. (As you see it is the same problem I mentioned at locusts. Moreover, for example, the trigger of a GAME_PIECE of the Seneth game has the similar property.)
The motorbike remains 32 if Lara using that, but the flag becomes 36=4+32 if the bike has been exploded in water.
The kayak needs a technical trigger. The kayak never will be 35 when triggered but will be 34=2+32.
- I think the value of the activated non-seeable ones is always individual. - Some examples I found:
When the teeth spikes are moving out or back then the value is 35. If they are just in the start (hidden) position, during the moving, then the value is 39=1+2+4+32. (Deactivating the spikes, they will keep the actual 35 or 39 value till the next start.)
Or see the objects that have Invisible button on (eg. pickable items, waterfalls). They are usually 32 constantly (I mean, if the pickable activates a PICKUP trigger, then it becomes 38, having been picked up), but having that button on, they start the level with Flag 38. Activating them (i.e. making them seeable) they become 35. - Then, if you pick up a pickable item that was invisible before, its flag turns into 34 (or 38, activating a PICKUP).
- The non-triggered 'real' nullmeshes - flame emitters, earthquake etc. - are 32, and they become constantly 35 after triggering. ('Not real' nullmeshes are the technical nullmeshes: see eg. AI objects. This field can't identify them.)
You may reveal exceptions. I found ropes that - triggered or not - will always have Flag 33 (1+32).
- Having been exploded, Smash Objects only have Flag 4.
- If you use an independent CAMERA_TARGET object, then that will have 96=32+64 flag forever, after having been activated.
- As you know, waterfallmists stop working if you load the game. It's because the game loses 'the mist is activated' (35) value when loading, turning it back into 32 ('the mist still isn't activated'). (By the way the problem could be solved by, for example, a simple GT_LOADED_SAVEGAME GlobalTrigger, that activates the mist again and again if the game has just been loaded.)
- If you have a problem with the unwanted collision, then switching 'Clear Body' button in the OCB panel seems a good solution. But it isn't. It's buggy. (See more about it below: 'Pointer for Collision Procedure (Long):' field.) Moreover, if you use Clear Body then that will affect the values of the present field.

Case A: I don't think it's a useful thing to force values on non-creatures now.
Case B: for example, using a pushable subject, Value 35 means an 'if Lara is just pushing/pulling the given object' condition.

Please, don't forget it is a very complicated field here, so whatever you read now, they are only some products of some of my tests, and there may be more values (even about further objects).

Frame Now (warning it's an abs value) (Short)
It defines the actual FrameID of the actual animation. - Attention! It works with absolute FrameID's.
If you understood above what absolute animations mean then it's also easy to understand the absolute frames. - Let's see an example:
The studied frame has ID8 in its animation, which is Animation2. So the object has two animations with lowest ID's (Animation0 and 1) and they have 48 frames aggregated. So the first frame of Animation2 (ID0) has Frame49 absolute ID. It means the ID8 frame of the animation has Frame57 absolute ID.

See 'NG Center\Tools\Animation Watcher\Show PRESENT ANIMATIONS for current slot', where you can identify easily the absolute frame ID's:
For example, you want ID11 frame of Animation6 of SAS objects as a condition. Find SAS and his Animation6 here, in this NG Center tool. See the green window below. You'll see a FrameStart=120 field here - it means the first frame (ID0) of the animation is the ID120 absolute frame of the SAS. It means ID11 frame of the animation is the ID131 absolute frame of the SAS - so, if you use a Case B with this field (with a SAS as a subject), then Value 131 means an 'if the actual frame of the given SAS is his Animation6 ID11 frame' condition.

Case A: forcing a frame on an object seems buggy.
Case B: why should you use a frame as a condition, with this method? I mean, this is what AnimCommands should do, instead of this method, don't they? - Well, this Case B isn't illogical, if you don't want AnimCommands to be always activated at the given frame.
I mean, if you place a trigger into the SAS Animation6 ID11 frame in WADMerger Animation Editor (as an AnimCommand), then that frame will activate that trigger at all the SAS Animation6 ID11 frames.
But, using an 'if the actual frame of the given SAS is his Animation6 ID11 frame' CONDITION trigger, only the Animation6 ID11 frame of the given (subject) SAS will activate the trigger.
Moreover, place that trigger in a disabled and GT_CONDITION_GROUP type GlobalTrigger as an executable trigger. The condition in the GlobalTrigger is this 'if the actual frame of the given SAS is his Animation6 ID11 frame' CONDITION trigger. Even the given SAS Animation6 ID11 frame won't activate that trigger, either - until you enable the GlobalTrigger by an F109 trigger.

Height Floor below the item (Long)
This field contains the actual floor level below the subject item. 1024=1 square vertical distance, negative number=above the 0 floor level, positive number=below the 0 floor level. - For example:
The harpy is activated in a room on a point which has 12 clicks (3 squares) floor value. (Now the field value is 1024x-3=-3072.) He flies over the next square which is a portal towards the room below it. The room below has 2 clicks (0,5 square) floor value at that point. (Now the field value is 1024x-0,5=-512.) The harpy flies through the portal, and over the next square, but the floor value is still 2 clicks under him. (So the field remains -512.) Now he flies through the room, above a pit which has -5 clicks (1,25 squares) floor value. (Now the field value is 1024x1,25=1280.)
Notes:
- Objects keep their actual values before activation (comes to life etc.) or after deactivation (death, picked up etc.).
- If the object moves but without AI (such as ziplines, rollingballs etc.) then it will keep the start value in this field.

Case A: no effect if you want to force this floor data on an object.
Case B: for example, with a creature subject, Value 6400 means an 'if the floor level below the creature is just -25 clicks' condition. It is a useful condition, for example, in a GlobalTrigger, if the harpy is flying around in a room with a -20 clicks average floor level, but with a lot of pits there, having -25 clicks floor levels, and you want the harpy to activate things only if he just flies above a pit like that. And if you don't want to place HEAVY triggers for the harpy in the pits, saying, there are PAD triggers in the pits, because Lara will activate things, climbing down into any of the pits.

HP (Current life level. $C000 = unkillable) (Short)
This field shows the actual life points of the given enemy.

Case A: if you want to force a new maximal life point for an object slot, then use Enemy Script command. But if you want to force a new actual life point on a given enemy, then just use this Case A, any time before killing the enemy.
Case B: C19 trigger studies Lara's life points. But if you want to study a life point of a given enemy, then use this Case B.

Notes:

- The subject enemy has its maximal life point in this field, before coming to life. (So you can use Case A before triggering him.)
- After having been killed, the life points of the enemy turns from 0 into $C000. Seeing the field name, the enemy is 'unkillable' now. (The value is -1 at Lara if she's dead.)

Object buttons. Five buttons + invisible button (Short)
This field contains the states of the OCB panel buttons of the given object. (Despite of the name of the field, Invisible button isn't calculated in this field - but Clear Body button is.)

The values are:

Button1 is on: 512
Button2 is on: 1024
Button3 is on: 2048
Button4 is on: 4096
Button5 is on: 8192
Clear Body is on: -32768

So, for example, if only Button1, 2 and 4 are on at the given object, then the field value is 512+1024+4096=5632.
Important! If all the five number buttons is on, then the value is not 15872 (though, this is their aggregate) but 16416.

Case A: no effect if you force a value in this field.
Case B: for example, Value 12188 means an 'if only Button 4 and 5 are on at the given object' condition, but - because Case A doesn't work - usually I can't see where this condition could be useful. (I mean, the OCB value of the object is always the same you adjusted in Room Editor.) But if you don't define a concrete subject by A54 trigger but you define a 'random' subject by the 'TRNG Index. Item Index for Selected Item Memory (Short)' Savegame Memory Zone field then it's worth studying the OCB buttons of the subject item in the game.

OCB Code (The value you typed in OCB of this item) (Short)
This field contains the value in the OCB window of the Moveable objects.

Case A: theoretically, you don't need to use this Case A, because using A79 will force a new OCB number on the object. But this property is one of the (possibly) instable properties I mentioned above (see: The wooden Door: how save and restore our changes.) So if you experience the forced OCB is instable during the loading procedure, then don't use A79 but use this Case A, according to The wooden Door: how save and restore our changes. (Or use a GT_LOADED_SAVEGAME type GlobalTrigger to activate A79 every time when a Savegame has been loaded.)
Case B: because Case A is useful now, Case B is also useful now, to examine the actual OCB value of the subject item in the game.

Note: the field contains the number before the activation as well. But creatures lose their OCB values, having been activated.

Position X (Long)
Position Y (Long)
Position Z (Long)
These three 'Position' field define the actual coordinate of the object.

1. Position X
It shows the horizontal position of (the pivot of) the object, compared to the north ('upper') edge of Room Editor Window. 1024=1 square.
2. Position Y
It shows the vertical position of (the lowest point of) the object, compared to the Floor 0 level. 1024=1 square. Negative numbers=above Floor 0 level. Positive numbers=below Floor 0 level.
3. Position Z
It shows the horizontal position of (the pivot of) the object, compared to the west ('left') edge of Room Editor Window. 1024=1 square.

Case A: a 'usual' transportation with LARA_START_POS objects always forces a new X, Y and Z coordinates on the subject item. But in this Case A you will be able to force, for example, only Position X and the transported creature will keep its actual Position Y and Z.
Case B: if you use a coordinate-condition, it's always recommended to use it with tolerance. I mean, for example, an 'if the creature is at Position X=44205' is a too precise condition, i.e. the creature may never reach that point exactly, during its lifetime. So, a 'duplicated condition' is more useful. For example: 'if the creature is at a bigger Position X value than 44150' and, at the same time 'if the creature is at a smaller Position X value than 44250'.

Notes:

1. Naturally, it's not easy to find out so complicated values as that '44205'. So I recommend this method: use Diagnostic mode with DGX_LARA diagnostic type. Start the game and use DOZY mode to take Lara into the position where you want to transport your object to. You can see the required X, Y or Z value (Cx, Cy, Cz) typed on the screen. Use that value in the forcing trigger.
2. Whatever transporting method you use, never transport your objects out of their rooms (i.e. where they are placed). I mean, you can transport creatures if they left the room where they'd been placed but you can transport them only inside the room where they just are.
3. You may ask why we want to complicate this thing. I mean, if you can't take the object out of the room, then a simple 'Move' ACTION trigger or a Parameters command would be more simple to force the position, wouldn't it? - Well, those features move the object with a given distance, but this Case A moves the object into a given position. That is not always the same.
4. You can take Lara out of any room with this Case A. But don't forget: the transportation is a move from Point A to Point B. This move vector must be going through portals between the rooms. If the vector crosses a wall, then the transporting operation fails - except if you also force the destination room number (see below: 'Room (Room where is the item) (Short)' field) on Lara at the same time.
5. Never force a vertical (Y) position on Lara or other creatures.
6. If the animation has a SetPosition AnimCommand (see for example: LARA object Animation 97), changing a coordinate, then that coordinate won't be refreshed in this field while the animation is being performed.

Room (Room where is the item) (Short)
This field contains the index of the room in which the object is just located at the moment.

Case A: see about it just above.
Case B: using ENV_ROOM_IS type MultEnvCondition you can study the actual room of Lara. But, if you want to study the actual room of another Moveable object, then use this Case B.

Notes:

1. This index is the index from the game ('tomb index') and not the one from the Room Editor ('NGLE index').
Let's say you have a room named 'Big Room' in your project. Click on 'Select' button to open the list of the rooms. For example, this is what you see at 'Big Room':

Big Room (30:23)

It means the NGLE index of the Big Room is 30 (that's why the original name of the room was Room30 in the Room Editor) and the tomb index of the Big Room is 23.
See F298 or F299 trigger to convert tomb room index to NGLE room index or vice versa.
2. If an object cannot be transported out of its room (see above) then that doesn't mean that object won't leave its room during its 'regular working'. (For example, a zipline can slide from one room to another.)
3. The border between the rooms seems not too exact sometimes. For example, if Lara is standing in a 1 click deep pool, then she's in the room above the water surface. But, when she's standing in a 2 clicks deep (waist-deep) pool, then she's in the pool. - I think it's because the pivot of the object what matters to define the position. And, when Lara is standing in a 1 click deep (knee-deep) pool, then her pivot (her butt) is above the water surface.

Slot Id (number of slot) (Short)
This field contains the slot index of the object. (By the way, you can also find them here: 'NG Center\Reference\SLOT MOVEABLES indices list'.)

Case A: forcing a new slot number on an object means the subject item will put the look of the object in the new slot on. But it is buggy.
Case B: for example, Value 73 means an 'if the object slot of the subject is WILD_BOAR' condition, but - because Case A doesn't work - usually I can't see where this condition could be useful. (I mean, the slot value of the object is always the same.) But if you don't define a concrete subject by A54 trigger but you define a 'random' subject by the 'TRNG Index. Item Index for Selected Item Memory (Short)' Savegame Memory Zone field then it's worth studying the object slot of the subject item in the game.

Speed in horizontal movements (Short)
This field shows the actual horizontal speed value of the object. - Let's see an example to understand that:
When Lara's standing, then she's performing her ID103 animation (Speed value in WADMerger Animation Editor: 0.) Then she starts running, performing her ID6 animation (Speed value: 23.) The she's running, performing her ID0 animation (Speed value: 47.)
When she starts running (Animation6) then the Speed jumps from Value 0 of the previous animation to Value 23 of this Animation, at once. But Animation6 has an 'Accel: 1' value. It means the speed will be increased by 1 per frame in the game: 24, 25 etc. When Animation6 has ended and Lara starts performing Animation0 then the last speed of Animation6 (it's probably 36) will jump from the 47 constant speed value of Animation0. - So these speed values are shown in this field.

Notes:

1. For example, 25 in this field means Lara will move horizontally 25 units during that frame. (This time 1024 units seems a bit less than 1 square.)
2. Naturally negative Accel value means decreasing speed.
3. The theory above doesn't always seem true. I mean, see for example the 'stand jumping forward' animation combination of Lara:

Animation73: she's ready to jump, Speed: 0, Accel: 0
Animation76: she starts jumping forward, Speed: 99, Accel: 0
Animation77: she's jumping forward, Speed: 0, Accel: 0

But, when you study this field in the game, that's what you'll see:

Animation76: Speed is constantly 99.
Animation77: Speed is constantly 50.

But that is logical. I mean the Speed of Animation77 is hardcoded, because the value is 50 when Lara's performing a stand jump, and 75 when Lara's performing a run jump.

Case A: it is interesting, but it seems you can force the value on an object only if the animation has that 'hardcoded case'. (But it will work only with a continuous forcing, by a GlobalTrigger.) For example, forcing Value 100 on Lara when she's performing Animation77 (started from standing), that means Lara will perform a long jump forward if the player hits ALT+up arrow.
(Notes:
1. It's not easy to define the 'started from standing' condition, because you can't find an exact condition like 'if Lara started the jump standing'. So you need to define that condition in a tricky way. For example: a variable will be 1 when Lara is running. When she's performing Animation77 and the variable is 1 then that means a running jump. But when she's performing Animation77 and the variable is 0 then that means a standing jump.
2. Be careful! You have to study the speed of other animations as well in complex cases: when Lara will grab a ledge at the end of the jump, when she turns around in midair during the jump etc.)
Case B: the maximum horizontal speed of the motorbike is about 130. But, with nitro, it's about 190. So, for example, Value 190 with motorbike subject in this field means 'if Lara reached the maximum speed riding the bike with nitro' condition.
(Note: when Lara uses a vehicle then you need to calculate her speed as the speed of the vehicle object.)

Speed vertical movements or underwater (Short)
This field shows the actual vertical speed value of the object. - It is similar to the horizontal moves but vertical values (either Speed or Accel) aren't shown in Animation Editor.
This example will help you to understand:

Lara jumps up. The energy is the biggest when she starts jumping, naturally, that's why the value (moved units per frame) here's the biggest. Approaching the upper point, the energy decreases, that's why the higher Lara has jumped the smaller the value is. (Moving upwards, the values are negative numbers.)
And now Lara starts falling down. The energy is the smallest when she starts falling naturally, that's why the value (moved units per frame) here's the smallest. Approaching the ground, the energy increases, that's why the lower Lara has fallen the bigger the value is. (Moving downwards, the values are positive numbers.)
(The largest values are about -100/100 when Lara jumps up/falls down from jumping up.)

Now the 'vertical' doesn't always mean 'the object moves up or down'. For example, when Lara's swimming forward, then she also moves towards her head, just as if she were jumping up - so 'swimming forward' is calculated as a vertical movement. - That's how it works:
Animation109 starts when Lara starts swimming forward. The vertical speed starts increasing fast. Then the animation changes into Animation86, that is the 'real' 'swim forward' animation. The speed reaches 200, and remains that, while the player holds ALT pushed down to swim continuously forward.

Case A: if you want to force Lara on a vertical jumping speed then you'd better use F136 trigger. But be careful in other cases. I mean, for example, according to my experiences you can force a swimming forward vertical speed on Lara (continuously, by a GlobalTrigger) only if that is less than the default 200. - For example you want Lara to swim slowly in the 'too thick liquid', that's why you force Value 50 on her when she's in that pool and performing Animation86 or 109. (But you can be more precise, for example, if you calculate different speeds in Animation86, simulating the acceleration from 0 to 50. For example, using 'Frame Now (warning it's an abs value) (Short)' field as a condition to calculate different speed for each frame of Animation86.)
(And don't forget: the speed will decrease by degrees when Lara stops swimming. That's why you must study the speeds of the animations that follow Animation86.)
Case B: when the jump-up phase reaches the top, then the lowest energy (the vertical speed) is -2, and then, when the fall-down phase starts from the top, then the lowest energy (the vertical speed) is 4. So, for example, with Lara as a subject, Value -2 (together with the 'if Lara is just performing the jumping-up/falling-down animation i.e. Animation28' condition) in this field means 'if Lara has just reached the top of her fly'.

State Id Next (Short)
This field shows the state of an animation. This state is the state of the animation that will be performed after the actual animation. This state is the state of the animation you can see in 'Next Animation' box of the actual animation, in Animation Editor.

Case A: if you want to force a next state ID on Lara then use F78, F170 or F171 trigger instead. If you want to force a next state ID on another object, then use A39 trigger instead.
(Note: I don't know all the cases when it's worth forcing a new State ID on an animation. But I know it's worth it if you want to use an animation under other circumstances in a cutscene - embedded in your 'real level' -, compared to as you use that under 'normal' circumstances. - For an example, see the tutorial Talking to Zip, its demo project and its readme).

Case B: sometimes this Case B with states is better than a Case B of another field with animations. For example: you need a condition if Lara picks up an object. But there are more picking-up animations so you need more picking-up animation conditions at the same time. Instead of that, you'd better use the State ID 39 (that is the state of these picking-up animations: swimming, standing, crouching, crowbar, high/low pedestal) and the State ID 67 (that is the state of picking up the dropped flare swimming, standing, crouching) at the same time, as conditions. And, at the same time, you use only the other picking-up animations (sarcophagus, wall hole etc.) as single conditions.

State Id Now (Short)
This field shows the state of an animation. This state is the state of the actual animation. This state is seen in 'StateID' box of the actual animation, in Animation Editor.

Case A: if you want to force an actual state ID on Lara then use F78 trigger instead.
Case B: see the comment about Case B just as above with 'State Id Next (Short)'. - If you want to study Lara's actual StateID then use C31 trigger instead of this Case B.

Transparence level (0 = opaque / 126 transparent / over 127 removes item) (Short)
This field contains how transparent the subject item is.

Case A: use A53 trigger instead of this Case A.
Case B: use C37 trigger instead of this Case B.

Unknown (Light_A) (Long)
Unknown (Light_B ) (Long)
Unknown (Light_C) (Long)
Unknown (Light_D) (Long)
Unknown (Light_E) (Long)
Unknown (Light_F) (Long)
Unknown (Light_G) (Long)
Unknown (Light_H) (Long)
These 'Unknown' fields show values about the ambience light of the room in which the subject item is just located.

1. Light_A, B and C fields
Each field is a color component (red, green or blue) value of the ambience light:

Light_A: red
Light_B: green
Light_C: blue

It's easy to understand the values there. - Because, for example:

1024 Field Value = 128 Color Value
512 Field Value = 64 Color Value
8 Field Value = 1 Color Value

So, for example, Value 120 in Light_B field means Value 15 (=120/8) green color component in the ambience light of that room.
(Note: in fact, that is not always the green ambience value of the room. So that is the actual green ambience value - that just affects the object in that moment - in that room. For example, when Lara steps from a room with Value 10 green factor into a room with Value 30 green factor then the new green factor will accept her by degrees: 11, 12, 13, 14, 15, 16 etc. - though, very fast.
So, if we want to be exact, then Value 120 in Light_B field means: 'if the green component of the ambience color, that is just affecting the item, is 15 - either that is the adjusted color of the room or the effect is just realized when the item is stepping through a door' condition.
Of course, I can say the same thing on the red or blue components.)

2. Light_D field:
This field shows a long number for the whole RedGreenBlue ambience light value of the room. - For example:

The value is 1336370 in the field. Turn it into a hexadecimal number with your Windows calculator. The solution is $146432. Read that number split into three blocks: $14/$64/$32. Turn each number back into a decimal value. The solution is: 20/100/50. - And this is the RedGreenBlue value, I mean Red=20, Green=100, Blue=50 now.
(See the same note just as above.)

3. Light_E, F and G fields
Each field is a color component (red, green or blue) difference value of the ambience light:

Light_E: red difference
Light_F: green difference
Light_G: blue difference

For example, the blue ambience component in Room Editor in Room A is 60 and in Room B is 45. When Lara (as the subject of Light_G field) steps through the door between the rooms from Room A into Room B then the field becomes -15, because 45-60= -15.

4. Light_H field
This field shows how much the object has adopted the ambience color value of the room after having just arrived here from another room. - The lowest degree is 7.
For example:
Lara is the subject. The value of the field is 0. Lara is going through a door from Room A into Room B. A fast countdown timer starts running (one new value per each frame): 7, 6, 5, 4, 3, 2, 1, 0. When the value is 0 again then that means the ambience light shining on Lara is totally the ambience light of Room B. - So this is the procedure:
0: the ambience light shining on Lara is totally the ambience light of Room A.
7: the ambience light has started turning into the ambience light of Room B.
6: the ambience light continues turning from Room A color to Room B color.
5: the ambience light continues turning from Room A color to Room B color.
4: the ambience light continues turning from Room A color to Room B color.
3: the ambience light continues turning from Room A color to Room B color.
2: the ambience light continues turning from Room A color to Room B color.
1: the ambience light is almost totally the ambience light of Room B.
0: the ambience light shining on Lara is totally the ambience light of Room B.

Case A: you can force a color only in Light_D field. The force in other fields seems more or less useless.
You should force the value in Light_D only with continuously (by a GlobalTrigger). But it doesn't mean the game won't try continuously to turn back the value into the default value. That's why the forced color will be realized on the object as a blinking color: the forced color that turns continuously back into the default color that turns continuously back into the forced color etc.
Case B: with Lara as a subject, eg. Light_D Value 1336370 doesn't mean an 'if Lara is a room with RGB=20/100/50 ambience light' condition, under any circumstances. Why? Because, when she's just stepping through a door, then (see that 7-1 timer above) sometimes the field adopts that 1336370 for a frame, so, even if neither the room where Lara comes from, or the room where Lara goes into has RGB=20/100/50 ambience color value adjusted. To prevent that problem, use another condition with that: 'if the actual ambience light shining on the item is exactly the one that is defined in the room', so if Light_H is 0. (This is also true with Light_A, B or C conditions. But Light_E, F or G values will be realized at once when the object is stepping through the door.)
Some other interesting conditions:
- 'If Light_E is -100 or more and if Light_F is -100 or more and if Light_G is -100 or more': it means when Lara (the subject) steps from one room into another, then the new room is too dark, compared to the previous one.
- 'If Light_H is 7' means the subject item has just come through a door.

Notes:

- There are some tiny bugs about these fields. I mean, some values won't be realized until the subject item comes through doors between rooms at least once or twice:

= Light_A, B, C, E, F, G value in the field won't be realized till then.
= The change from one Light_D value to the other is immediate, so it won't use the change by degrees till then.
= Light_H value is not 0 but -1, and the 7-1 timer won't start till then.

It means you should use only the items in these fields that could move through two doors at least, during their lifetime: Lara, enemy, rollingball etc. And, use the value with them only if you are sure that they have moved through two doors at least so far.
(Don't misunderstand: it doesn't matter how many doors the item will cross or which ones those doors are. Which matters is the number of crosses so far, but through any doors.)
- These values won't be affected if another light source (light bulb, fog bulb etc.) also shines on the subject item.
- The 7-1 timer is not so clear when the subject item is not Lara. For example, the timer runs from 7 to 1, then will be paused, and some seconds will pass when it will turn into 0 at last. - It means, the last step will be late a bit for the item to realize perfectly the ambience light of that room. (It is not a bug - this is how the engine works.)

Unknown (Pheraps accelleration on falling) (Short)
This field has something to do with objects that are controlled by AI_FOLLOW nullmeshes. - I did some tests. These are the outcomes:

HORSEMAN: when he went back during the battle to AI_FOLLOW's and starts coming ride back to Lara fast, then the field value is 17 for a short while. ('For a short while' means the value is 17 then it is 0 again very soon.)
GUIDE: when the moving GUIDE reaches a square on which there's an AI_FOLLOW then the field value is 41 for a short while. When he's got the torch and steps further to ignite it, then the value is 11 for a short while. When he's performing his crouching animation with OCB 2 AI_FOLLOW codebit, then the value is 43 for a short while. Etc.

The values seem mystical but they are not: they are the State ID values of the actual animation. (If you want to know what could Case A or B mean now, then see above 'State Id Next (Short)' or 'State Id Now (Short)' fields. - But the present field is a bit more than that. I mean, for example, with HORSEMAN subject: an 'if the HORSEMAN State ID now is 17' condition means 'if the horseman is riding fast'. But an 'if this Unknown, field is 17' condition means 'if the Horseman starts riding fast back to Lara from AI_FOLLOW'.)

Unknown (Sprite1 Id) (Byte)
Unknown (Sprite2 Id) (Byte)
These fields have a constant value (255), regardless of which Moveable object is the subject item of the field. (So even if it is an item with sprites: flame emitter, rope etc.) Whatever that object is doing, whatever are its properties.

Unknown (Used when enemy shot a granade = $c210) (Short)
This field has a constant value (-1), regardless of which Moveable object is the subject item of the field. (Even if that is a SAS or an ENEMY_JEEP shooting a grenade.) Whatever that object is doing, whatever are its properties.

Unknown Countdown (Some counter, not yet discovered) (Short)
This field contains the (positive or negative) timer value of the object (in frames) - that you can see in the trigger of the object (in seconds).

Case A: you don't need this Case A. Just use another timed trigger to overwrite the original trigger timer value.
Case B: for example, if the subject is a door and the value is -300 then it means 'if the door will open in 10 seconds' condition - because 30 frames=1 seconds. (Of course, you can trick this condition: for example, 10 seconds remained in the timer, so the condition will activate the executable trigger, but then you change back the timer into -20 seconds, so the door won't open after 10 seconds.)
(This Case B has nothing to do with these conditions of GlobalTriggers: GT_SCREEN_TIMER_REACHED, GT_TRNG_G_TIMER_EQUALS, GT_TRNG_L_TIMER_EQUALS.)

Note: the positive timer counted down is -1 and not 0 in this field. This is the value here till the next activation of any timer of the object.

Visible Mesh Flags (each mesh a different bit) (Long)
This field defines the visible meshes of a Moveable object (except Lara).

Each mesh of the object has a codebit in this field. - It is easy to understand:

Only Mesh0 is visible: Bit 0=Value 1
Only Mesh1 is visible: Bit 1=Value 2
Only Mesh2 is visible: Bit 2=Value 4
Only Mesh3 is visible: Bit 3=Value 8
Etc.

If more meshes are visible at the same time, then their aggregate what matters. (So, for example, if only Mesh2 and Mesh4 are visible, then the value is Bit 2+Bit 4= 4+16=20.)
If all the meshes are visible at the same time, then the value is -1.
If none of the meshes are visible at the same time, then the value is 0.

Case A: use A50 or A51 trigger instead of this Case A to force (in)visibility on a given mesh.
(Note: you can use NEF_SAVE_MESH_VISIBILITY Script constant so the value won't be lost when you save and then load the game.)
Case B: for example, as I said, Value 20 means an 'if only Mesh2 and Mesh4 are visible' condition.

Savegame Memory Zone fields

Inventory. Ammo Explosive CrossBow (Short)
Inventory. Ammo Flash Grenade (Short)
Inventory. Ammo Normal CrossBow (Short)
Inventory. Ammo Normal Grenade (Short)
Inventory. Ammo Normal Shotgun (Short)
Inventory. Ammo Pistol (Short)
Inventory. Ammo Poisoned CrossBow (Short)
Inventory. Ammo revolver (Short)
Inventory. Ammo Super Grenade (Short)
Inventory. Ammo UZI (Short)
Inventory. Ammo Wide-shot Shotgun (Short)
These fields contain the actual amount that the given ammunition has in the inventory:

- Note the value is not the clips amount but the ammunition amount.
- The -1 value means: 'unlimited'.
- The shotgun ammo amount in the field is always six times bigger than the amount in the inventory. - So, for example, if the 'real' amount is 20 bullets, then the value of the field is 6x20=120.

Case A: there are more methods to force a new amount on a given ammunition (see: Equipment Script command, CUST_AMMO Script constant or 'Inventory-Item' FLIPEFFECT triggers). But if you want to force a bigger, given amount in the inventory (including: unlimited) but any time during the game, then use this Case A.
Case B: C3 and C4 triggers are always examine a minimum/maximum amount of an inventory item. Use those two conditions at once if you want to use an exact amount of the given ammo as a condition. (So you don't need to use this Case B.)

Inventory. Pistols Mask. (Byte)
Inventory. UZI Mask (Byte)
Inventory. Revolver (Byte)
Inventory. Shotgun (Byte)
Inventory. CrowBow (Byte)
Inventory. Greanade-Gun (Byte)
These fields define the presence/the state of the given weapon in the inventory. - The values are:

Pistols/Uzis:

0: the weapon is not in the inventory,
9: the weapon is in the inventory.

Revolver:

0: the revolver is not in the inventory,
9: the revolver is in the inventory,
13: the revolver is in the inventory, combined with the lasersight.

Shotgun:

0: the shotgun is not in the inventory,
9: the shotgun is in the inventory, loaded with normal bullets,
13: the shotgun is in the inventory, loaded with wideshot bullets.

Crossbow:

0: the crossbow is not in the inventory,
9: the crossbow is in the inventory, loaded with normal arrows,
13: the crossbow is in the inventory, loaded with normal arrows, combined with the lasersight,
17: the crossbow is in the inventory, loaded with poisoned arrows,
21: the crossbow is in the inventory, loaded with poisoned arrows, combined with the lasersight,
33: the crossbow is in the inventory, loaded with explosive arrows,
37: the crossbow is in the inventory, loaded with explosive arrows, combined with the lasersight.

Grenade gun:

0: the grenade gun is not in the inventory,
9: the grenade gun is in the inventory, loaded with normal grenades,
17: the grenade gun is in the inventory, loaded with super grenades,
33: the grenade gun is in the inventory, loaded with flash grenades.

Case A: use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger to force the weapons into the inventory, instead of this Case A. - Notes:

a, To remove any weapon, any time during the game, use F96 trigger to remove all the weapons. - But never use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger or this Case A with Value 0!
b, Usually the value is 9 when a weapon gets into the inventory. But you may want to change that, saying, for example, you want the crossbow to be loaded with poisoned arrow and combined with lasersight when that has just been picked up. LOAD type Script constants will solve this problem, but only at the Equipment command. So if you want to force the weapon into the inventory in the game, but with not according to Value 9, then use this Case A and not the 'Inventory-Item' FLIPEFFECTs. (By the way, if the weapon is already in the inventory, you also use this Case A to modify the actual adjustments of ammo/lasersight.)

Case B: to examine the presence of the weapons in the inventory, use C1 or C2 trigger instead of this Case B. (But if you want more information - i.e. which type of ammo is just loaded?, is the lasersight just attached? - then use this Case B.)

Inventory. Large Medikit (Short)
Inventory. Small medikit (Short)
Inventory. Flares (Short)
These fields contain the actual amount of the given item in the inventory.

Notes:

- The value at flares is not the box of flares amount but the flares amount.
- The -1 value means: 'unlimited'.

Case A: there are more methods to force a new amount on the item (see: Equipment Script command, 'Inventory-Item' FLIPEFFECT triggers). But if you want to force a bigger, given amount (including: unlimited) but any time during the game, then use this Case A.
(Note: you can't define flares by 'Inventory-Item' FLIPEFFECT triggers, because those triggers use FLARE_ITEM [which is useless] and not FLARE_INV_ITEM - so use this Case A instead, if you want to define the amount during the game.)
Case B: C3 and C4 triggers are always examine a minimum/maximum amount of an inventory item. Use those two conditions at once if you want to use an exact amount of the given item as a condition. (So you don't need to use this Case B.)
(Note: C3 and C4 triggers use FLARE_ITEM and not FLARE_INV_ITEM - so use this Case B instead of them, if you want a 'given amount of the flares in the inventory' condition.)

Inventory. Binocular (1= present) (Byte)
Inventory. Crow Bar (1= present) (Byte)
Inventory. Laser Sight (Byte)
Inventory. Examine Item 1 (Byte)
Inventory. Examine Item 2 (Byte)
Inventory. Examine Item 3 (Byte)
These fields examine the presence of the given item in the inventory. - The values are:

0: the item is not in the inventory.
1: the item is in the inventory.

Case A: use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger, instead of this Case A.
Case B: to examine the presence of the item in the inventory, use C1 or C2 trigger instead of this Case B.

Inventory. Keys 1 - 8 (Byte)
Inventory. Keys 9 - 12 (Byte)
Inventory. Combo items 1 - 4 (Byte) - for PUZZLE_ITEM_COMBOs
Inventory. Combo item 5 - 8 (Byte) - for PUZZLE_ITEM_COMBOs
Inventory. Pickup Items 1 - 8 (Byte)
Inventory. Quest items 1-8 (Byte)
These fields examine the presence of the given item in the inventory. - The values are:

Keys1-8:

0: none of them is present
1: KEY_ITEM1 is present
2: KEY_ITEM2 is present
4: KEY_ITEM3 is present
8: KEY_ITEM4 is present
16: KEY_ITEM5 is present
32: KEY_ITEM6 is present
64: KEY_ITEM7 is present
128: KEY_ITEM8 is present

Keys9-12:

0: none of them is present
1: KEY_ITEM9 is present
2: KEY_ITEM10 is present
4: KEY_ITEM11 is present
8: KEY_ITEM12 is present

Puzzle Combo1-4:

0: none of them is present
1: PUZZLE_ITEM1_COMBO1 is present
2: PUZZLE_ITEM1_COMBO2 is present
4: PUZZLE_ITEM2_COMBO1 is present
8: PUZZLE_ITEM2_COMBO2 is present
16: PUZZLE_ITEM3_COMBO1 is present
32: PUZZLE_ITEM3_COMBO2 is present
64: PUZZLE_ITEM4_COMBO1 is present
128: PUZZLE_ITEM4_COMBO2 is present

Puzzle Combo5-8:

0: none of them is present
1: PUZZLE_ITEM5_COMBO1 is present
2: PUZZLE_ITEM5_COMBO2 is present
4: PUZZLE_ITEM6_COMBO1 is present
8: PUZZLE_ITEM6_COMBO2 is present
16: PUZZLE_ITEM7_COMBO1 is present
32: PUZZLE_ITEM7_COMBO2 is present
64: PUZZLE_ITEM8_COMBO1 is present
128: PUZZLE_ITEM8_COMBO2 is present

Pickup1-4:

0: none of them is present
1: PICKUP_ITEM1 is present
2: PICKUP_ITEM2 is present
4: PICKUP_ITEM3 is present
8: PICKUP_ITEM4 is present

Quest1-6:

0: none of them is present
1: QUEST_ITEM1 is present
2: QUEST_ITEM2 is present
4: QUEST_ITEM3 is present
8: QUEST_ITEM4 is present
16: QUEST_ITEM5 is present
32: QUEST_ITEM6 is present

If more items are in the inventory at the same time, then their aggregate what matters. - So, for example, if only PUZZLE_ITEM1_COMBO1, PUZZLE_ITEM1_COMBO2 and PUZZLE_ITEM3_COMBO2 are present in the inventory, then the value is 1+2+32=35 in 'Inventory. Combo items 1 - 4 (Byte)' field.
But it isn't calculated as presence if you combined the items. For example, if you combine now PUZZLE_ITEM1 from PUZZLE_ITEM1_COMBO1 and PUZZLE_ITEM1_COMBO2, then 1 and 2 will be subtracted from 35 and the field value will be 32.

Case A: use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger, instead of this Case A.
Case B: to examine the presence of these items in the inventory, use C1 or C2 trigger instead of this Case B.

Note: as I see, there are no fields for KEY_ITEM_COMBO or PICKUP_ITEM_COMBO objects.

Inventory. Puzzle Item 1 (Byte)
Inventory. Puzzle Item 2 (Byte)
Inventory. Puzzle Item 3 (Byte)
Inventory. Puzzle Item 4 (Byte)
Inventory. Puzzle Item 5 (Byte)
Inventory. Puzzle Item 6 (Byte)
Inventory. Puzzle Item 7 (Byte)
Inventory. Puzzle Item 8 (Byte)
Inventory. Puzzle Item 9 (Byte)
Inventory. Puzzle Item 10 (Byte)
Inventory. Puzzle Item 11 (Byte)
Inventory. Puzzle Item 12 (Byte)
These fields contain the actual amount that the given item has in the inventory.

Case A: there are more methods to force a new amount on a given item (see: Equipment Script command, 'Inventory-Item' FLIPEFFECT triggers). But if you want to force a bigger, given amount but any time during the game, then use this Case A.
Case B: C3 and C4 triggers are always examine a minimum/maximum amount of an inventory item. Use those two conditions at once if you want to use an exact amount of the given item as a condition. (So you don't need to use this Case B.)

Inventory. Big Skin Bag (Byte)
Inventory. Little Skin Bag (Byte)
These fields define the state of the big/small waterskin in the inventory. - The values are:

0: the waterskin is not in the inventory.
1-6: the big waterskin is in the inventory and contains X-1 liters of water. (So, for example, Value 4 means the waterskin is in the inventory, with 3 liters of water.)
1-4: the small waterskin is in the inventory and contains X-1 liters of water.

Case A: usually use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger, instead of this Case A. But, for example, when Lara picks up the big waterskin, then activate a PICKUP trigger, that activates a TRIGGER that uses this field, with Value 2. So this time it's not an empty waterskin Lara has picked up, but a waterskin with 1 liter of water. (By the way, you don't need to pick the item up or that PICKUP trigger to force a waterskin with some water into the inventory. Just use Case A, if you want.)
Case B: for example, Value 3 means now an 'if there are 2 liters of water in the waterskin in the inventory' condition.

Inventory. Mechanical Scarab (1=full item; 2=key;4=only scarab) (Byte)
This field defines the state of the mechanical scarab in the inventory. - The values are:

0: the scarab with key or the parts are not in the inventory.
1: the scarab with key is in the inventory, combined.
2: only the key is in the inventory.
4: only the scarab is in the inventory.
6: the scarab with key is in the inventory, separated.

Case A: use an Equipment Script command or an 'Inventory-Item' FLIPEFFECT trigger, instead of this Case A.
Case B: to examine the presence of the item in the inventory, use C1 or C2 trigger instead of this Case B.

Inventory. Remaining usage of Mechanical Scarab (Short)
The field name tells exactly what this field does. - The values:

0: the scarab with key is not in the inventory (combined) or if it is, then you can't use that any longer.
1-3: the remaining usage amount of the scarab is 1-3.

Case A: you can force here even a bigger or a smaller number than 3 to use the scarab maximum not by the default value.
Case B: for example, Value 2 means an 'if the mechanical scarab can be used maximum 2 times now' condition.

Lara. Air for Lara (0 - 1800) (Short)
This field contains the amount of air in Lara's lungs (when she is swimming).

0: Lara has no air.
1800: Lara's lungs are full of air.

Case A: you can also adjust Lara's air by F104 or F110 triggers. But if you want to define a given air amount for Lara then use this Case A. (Adjusting Lara's air has no effect if she's not swimming/floating on/in water.)
Case B: for example, Value 900 means an 'if there is 50 % air in Lara's lungs' condition. (Note this is also true, if Lara has come up to the water surface with low air, and her air has started to increase, and then it has reached 50 %. So, if you want this condition to be true only if Lara is under water then also use an 'if Lara is under water' condition.)

Lara. Current Weapon (not necessarly in the hand) (Short)
This field shows which weapon

- is just in Lara's hand or
- will be drawn if you hit SPACE now.

The values are:

0: no weapon is selected (that's what will happen, for example, after you have made Lara to throw flare/torch by F83 trigger). - Now Lara can draw a weapon only with shortcut keys or directly from the inventory.
1: pistols (the default value)
2: revolver
3: Uzis
4: shotgun
5: grenade gun
6: crossbow

Case A: for example, if there are pistols in Lara's hands and you force Value 4 in this field, then nothing will happen (so you cannot force the value to make Lara draw another weapon) - but if you holster the pistols now and then hit SPACE then Lara will draw the shotgun. (So the value can be forced only for the next SPACE.)
Case B: for example, Value 6 means now an 'if Lara has the crossbow in her hand or will draw the crossbow if you hit SPACE now' condition. But if you also use an 'if there is no crossbow in Lara's hand' condition (i.e. a C35 trigger in 'Holding_Crossbow' mode, in a TriggerGroup, in which you attach a TGROUP_NOT flag to it or a similar GlobalTrigger) then Value 6 only means 'if Lara will draw the crossbow if you hit SPACE now' condition.
But if you want Value 6 to mean only an 'if Lara has the crossbow in her hand' condition, then use C35 trigger in 'Holding_Crossbow' mode (or HOLD_CROSSBOW type GlobalTrigger) instead.

Lara. Environment where lara is. (ground, underwater ecc,) (Short)
As the name says, this field defines the environment in which Lara just is:

0: Lara is on dry land.
1: Lara is swimming/floating under water.
2: Lara is swimming/floating on water surface.
3: Paolone says this is the value if Lara is in DOZY mode, riding motorbike or in hardcoded cutscenes. I can confirm the DOZY mode but I can't the motorbike (it is 0 for me when she's riding). (I didn't test the cutscene.)
4: Lara is wading in water/quicksand.

Case A: forcing these values seems buggy.
Case B: if you want to study Lara's environment, then you don't need this Case B, I mean there are some similar and nice tools, for example: PLACE constants with Animation Script command, C5, C30 or C81 triggers etc.

Note: as I said above, Lara in knee-deep water is in the 'air room' above the water surface (so she will walk/run here as if she were on dry land) but in waist-deep water is in the pool (so she can't walk/run but wade here).
But there's a well-known bug about that: if Lara's standing in a waist-deep water and then step up on a ledge in knee-deep water, then she will wade on the higher ledge as if she were in waist-deep water.
Please note when you encounter that bug then the field value is 4, though, Lara is in the room above the room surface. It results a very peculiar case: while Lara is working by the bug, she is neither in 'air' (see ENV_ONLAND constant of MultEnvCondition Script Command), nor water (see ENV_ROOM_IS constant of MultEnvCondition Script Command, with ROOM_WATER room type). - And the bug also exists in quicksand.
And one more thing: you also encounter this 'neither air/nor water' situation in the short moment when Lara swimming upwards is just breaking through the water surface.

Lara. Hands. Attached Lara Status (Short)
This field defines the situation Lara's hands are engaged with. - The values are:

0: empty hands or holding a flare
1: being on all fours, grabbing a ledge, a ladder, a monkey bar, a rope, a polerope, a parallel bar, a zipline, driving a vehicle (or getting in/on/out), picking up (first moves) a torch or a working flare, picking up other items (in any way), placing items, using switches, interacting with doors (including kicking in), pushing/pulling pushable objects (or ready to move them), using a crowbar, using a waterskin/jerrycan/bag of sand, using the nitro, using the mechanical scarab
2: drawing a weapon, igniting a flare
3: holstering a weapon, throwing automatically a flare
4: holding a weapon, a torch, igniting*/throwing a torch, igniting* with a torch, picking up (last moves) the torch
5: picking up (last moves) the working flare

*: just ending this movement, the value will be 0 for a frame.

Case A: the value only sometimes can be forced. - The cases I revealed:

- Forcing 0 or 1 when Lara is holding weapons, she will lower (but not holster!) the weapons. (This is the same effect just as F12 can do.)
- Forcing 3 when she's holding flare or weapon she will throw flare/holster weapon. (Nothing will happen with torch in the hand. With empty hands, the game will crash.) - This is what F83 trigger does, anyway.

Case B: You can study some values by direct conditions. For example Value 0 as a condition can do the same thing as ENV_FREE_HANDS Script constant can do. Or, Value 2 is the same as 'if the keyboard command is Extract flare or Extract current weapon' condition. Etc.
But there also are some interesting things here. For example: use all these conditions at once: 'when Lara is performing the animations of picking up the working flares crouching, standing, swimming' and 'if the value of Lara. Hands. Attached Lara Status (Short) field is 1'. This 'multi-condition' will mean 'if Lara reaches for the working flare to pick it up'.

Lara. Hands. Item in the Hands of Lara (Current) (Short)
This field is similar to 'Lara. Current Weapon (not necessarly in the hand) (Short)' field, but not exactly. - The values are:

0: this is the value if Lara has dropped the torch, and didn't extract a weapon or a flare after that
1: the default value and if pistols are the latest chosen weapons (even if they are not in Lara's hands now)
2: revolver is the latest chosen weapon (even if it is not in Lara's hand now)
3: Uzis are the latest chosen weapons (even if they are not in Lara's hands now)
4: shotgun is the latest chosen weapon (even if it is not in Lara's hand now)
5: grenade gun is the latest chosen weapon (even if it is not in Lara's hand now)
6: crossbow is the latest chosen weapon (even if it is not in Lara's hand now)
7: there's just a flare in Lara's hand
8: there's just a torch in Lara's hand*

*: just ending this movement, the value will be the latest chosen weapon for a frame.

Case A: you shouldn't force this field ever. The solution sometimes is buggy, sometimes is illogical (eg., this way Lara can drop the torch that is NOT in her hand) and sometimes is something you can do with other methods as well (eg. extracting/lowering the actual weapon).
Case B: Use C35 trigger (or a similar GlobalTrigger) instead of Value 7 or 8. And use 'Lara. Current Weapon (not necessarly in the hand) (Short)' field instead of Value 1-6. But Value 0 could be a useful and strange condition now.

Lara. Hands. Item in the Hands of Lara (Following (Short)
The values of this field are exactly the same as the previous one - except: that remark with * doesn't exist now.

Case A: you can force all the values (except Value 8 which would be buggy). - Two examples:

a, Lara has the pistols in her hands. You force Value 7 - and now she will holster the pistols and ignite a flare.
b, Lara's hands are empty, but the shotgun is the latest weapon. You force Value 5 - and now she will draw the grenade gun.

Case B: see Case B just above.

Lara. Hands. Remaining time with lighted flare in the hand (Short)
This field is a timer counting from 0 to 900. It is a timer for the flare that is in Lara's hand. It starts counting from 0 when Lara has ignited it and stops at 900 when the flare is totally dead and Lara will throw it. (30 means 1 second.)

Case A: the timer maximum value can be customized by CUST_FLARE Script constant. But, that constant will work on all of the flares.
If you want to manipulate the timer of a given flare (always the one that just is in Lara's hand), then force a value into this field:

- if the value is bigger than 900 (or the customized maximum value) then the flare will be out suddenly, at once, and Lara will throw it,
- if the value is smaller than 900 (or the customized maximum value) then the actual position of the timer will be adjusted ahead/back to that value, at once (not stopping counting).

Case B: for example, Value 600 means (with the default 900 maximum value) an 'if the flare in Lara's hand has 10 seconds before it will be totally out - supposing we won't manipulate the timer value' condition.

Lara. Hands. Weapon in the hand (Short)
The value is usually -1. But becomes some other value if Lara has the shotgun or the grenade gun or the crossbow in her hand. - This 'some other value' is the actual value of the Moveable objects that are just placed in the map.
I don't think this field is useful for us. Unless you're just making your level and want to know the number of Moveables that are just placed. (It's not always the Moveable number you see in Room Info Box in Room Editor. I mean it's the aggregate of the placed objects in TXT file of the project in graphics\wad folder. - It's because some placed objects, eg. AI objects, are not calculated in the TXT file as placed objects.)

Lara. Item Index of Lara (Short)
This index shows the game index ('tomb index') of LARA object.
Put it into a variable, if you want - maybe you can use it in a condition.

Note: if you have an object index in the Current Value variable, then you can transform it. I mean F300 turns game ('tomb') index into Room Editor ('NGLE') index or F301 turns Room Editor index into game index.

Lara. Poison1 (giant scorpion = 2048) (Short)
Lara. Poison2 (Short)
Two similar fields to calculate Lara's degree of poisoning - in these ways:

1. Let's see for example the poison of SMALL_SCORPION and SCORPION:
Though both Poison1 and Poison2 fields show the actual value of the poisoning, this value is calculated in an exponential way in Poison1 field and in a linear way in Poison2 field:

At the SMALL_SCORPION in Poison1 field, the difference between the first and the second value (one value for each frame) is 32, the second and the third value is 30 (+/-1) etc. The difference will decrease frame by frame and will be constantly 1 at last. - So this is how the procedure will happen (eg. if the small scorpion bites - and poisons - Lara when she has the full life points):

1000 value of life bar - 0 poisoning value
next life value: 980 - 32 poisoning value - the small scorpion has bitten and poisoned Lara (the life bar has gone green)
still life value: 980 - 62, 90, 116, 141, 518, 520, 522 poisoning value - the poisoning value is changing though the life value is still the same
next life value 978 - 524, 526, 528,595, 596, 597 poisoning value - the life value starts decreasing continuously, due to Lara being poisoned
next life value: 976 - 598, 599, 600, 659, 660, 661 poisoning value
next life value: 974 - 662, 663, 664, 723, 724, 725 poisoning value
Etc.

(Notes:

- The poisoning situations cannot be repeated exactly, under any circumstances. So, for example, if you saved the game before the bite, and now load it, and the small scorpion bites Lara at 1000 life points again, then maybe eg. 679 - and not 662 - will be the value when 976 life points turns into 974 life points.
- Both in Poison1 and Poison2 field, the life values will change in an increasing exponential way. - So, eg., that's why 972 was the next value in the case above, but then 969 came, and then 966 - so the difference changed from 2 to 3. Etc.
- As you see, when the small scorpion bites Lara that means minus 20 life points and starting an exponential poison value sequence: 32, 30, 28 etc. differences. If that bites her again that will mean newer minus 20 life points, and if that bite is a poisoned bite then the sequence differences will start again. - For example:

life value: 850 - poison value: ,1241, 1242, 1243
life value: 830 - poison value: 1276, 1307, 1337, 1365, - now the small scorpion has bitten/poisoned Lara again.)

And that is what will happen in Poison2 field, in the same situation - so the differences are 1 constantly (but a poisoning bite means a Value 512 jump in the poison value):

1000 value of life bar - 0 poisoning value
next life value: 980 - 512 poisoning value - the small scorpion has bitten and poisoned Lara (the life bar has gone green)
still life value: 980 - 513, 514, 515, 542, 543, 544 poisoning value - the poisoning value is changing though the life value is still the same
next life value: 979 - 545, 546, 547,606, 607, 608 poisoning value - the life value starts decreasing continuously, due to Lara being poisoned
next life value: 977 - 609, 610, 611, 670, 671, 672 poisoning value
next life value: 975 - 673, 674, 675, 734, 735, 736 poisoning value
Etc.

At the SCORPION in Poison1 field, the difference between the first and the second value (one value for each frame) is 128, the second and the third value is 120 (+/-1) etc. The difference will decrease frame by frame and will be constantly 1 at last. - So this is how the procedure will happen (eg. if the scorpion bites - and poisons - Lara when she has the full life points):

1000 value of life bar - 0 poisoning value
next life value: 880 - 128 poisoning value - the scorpion has bitten and poisoned Lara (the life bar has gone green)
still life value: 880 - 248, 360, 465, 564, 657 poisoning value
then the life value starts decreasing continuously, due to Lara being poisoned
Etc.

But that is what will happen in Poison2 field, in the same situation - so the differences are 1 constantly (but a poisoning bite means a Value 2048 jump in the poison value):

1000 value of life bar - 0 poisoning value
next life value: 880 - 2048 poisoning value - the scorpion has bitten and poisoned Lara (the life bar has gone green)
still life value: 880 - 2049, 2050, 2051, 2090, 2091, 2092 poisoning value
then the life value starts decreasing continuously, due to Lara being poisoned
Etc.

2. Though the poisoning will change (increase) and the life energy will also change (decrease) above 4097 poison value, both Poison1 and Poison2 field will usually stop showing the increasing poison sequence at Value 4097. (If Lara was poisoned with full life energy and bitten only once then she will has half of her life energy points at this Value 4097.)

Notes:

- Naturally, if Lara has been poisoned with low life energy, then the poison value will never reach 4097, because Lara will die before that.
- If some 'special effect' happened then there can be values after 4097 in these fields. ('Special effects' eg. if more than one poisoning bite hit Lara or if you force a value into this field.) - So, eg. if the scorpion bites and poisons Lara when Poison2 running value is 4000 then the poison value jumps to 4000+2048=6048 value, and stops, because that is bigger than 4097 - though, life energy and poisoning continue changing.
But be careful: values above 4097 can be inaccurate to calculate with them, so e.g. you'd better avoid them in conditions.
- Now you can understand why the small scorpion linear sequence starts from 512 and the scorpion sequence starts from 2048: the scorpion sequence will reach 4097 sooner, demonstrating 'this is a stronger poison'. - The bigger jumps between the starting values in the scorpion exponential sequence result the same.

3. Using a small medipack, the life energy stops decreasing and jumps up to +50 %.
Using a big medipack, the life energy stops decreasing and jumps up to the full energy.
Using any medipack, the screen stops flickering in about 1-2 seconds.
Using any medipack, the value in Poison1 field stops increasing, and starts decreasing fast to 0 in an exponential way. (The life bar remains green till reaching this 0.)
Using any medipack, the value in Poison2 field stops increasing, and jumps to 0 at once.

Case A:
a, Poison1: if you force a value into this field then the life energy will continue changing as if nothing had been happened. The poison value will run fast to its normal value - for example: the 'real' value is just 687 when you force 4000 into the field. After that, the value will run fast to - no, not to 687, because the 'real' poison value continues increasing so far. So it will run fast to eg. 808, that is the actual real poison value now. And then, the poison value continues increasing in this field.
But all of this seems senseless. Or it is not? - Well, it's worth forcing a value here, because the screen will always flicker according to the value in the poison fields. So, a jump from 687 to 4000 and then a fast run to 808 will result this: 'the screen is flickering only a little, but with a sudden jump, it will flicker hard for a moment, then soon, it will flicker only a little again'.
Forcing a value here when Lara is not poisoned results the screen will flicker for a moment (eg. if the forced value is 4000 then it will flicker hard) and the life bar will be poisoned for a moment.
b, Poison2: if you force a value into this field then the life energy will continue changing as if nothing had been happened. The poison value will jump (ahead or back) to the forced value, and continues the increasing change, keeping the rhythm.
Forcing a value here when Lara is not poisoned results she will be poisoned, according to the forced value. (So, eg. forcing 4000 here now results a hard screen flickering, with a 4000 poison value that is increasing towards 4097.)
c, forcing a value continuously (see: GT_ALWAYS GlobalTrigger) either in Poison1 or Poison2: the life energy will continue changing as if nothing had been happened. The poison value will be constant (the forced value) with a constant flickering. (So, eg. forcing 600 here now results a constant low screen flickering.)

Case B: for example, a 'value is bigger than 4000' means an 'if Lara is poisoned hard and the screen is flickering hard' condition in both fields. (C25 trigger examines only if Lara is poisoned but doesn't care about the degree of the poisoning.)

Lara. Rope. Speed sliding on the rope (Short)
This field shows Lara's actual horizontal coordinate, compared to the original vertical axis of the rope, when she's just hanging on that rope.
The values change in an interval in which the maximum value is about 11000, and the minimum value is about -11000. (I think 4096 means 1 square distance.) Positive values mean 'Lara swings forwards', negative values mean 'Lara swings backwards'.
(The value won't be updated, so the last value will be 'frozen' in the field

- while Lara is turning around the rope or climbing up or down, or
- if Lara had left the rope and then didn't catch this rope or another one.)

Case A: this value cannot be forced.
Case B: don't forget the rope also moves a bit with Lara when she's just hanging on it. So she will also produces positive or negative values in this field if she's not swinging. That's why, eg. a 'Value is smaller than 0' is not a proper definition for an 'if Lara's just swinging backwards' condition. So, if you want to define an 'if Lara's just swinging backwards' condition, then use this 'Value is smaller than 0' in this Case A, and a 'usual' 'if the keyboard command is dash' condition as well - so the game will study if the value is smaller than 0 only if the player holds Key 'Dash' down to swing the rope. (Naturally, the game won't study Value 0 now if Lara swings on the rope, but due to the momentum after the player have released Key 'Dash'.)
Naturally, if Lara is just hanging on the rope then the value will never be too big in this field. So, eg. a 'Value is bigger than 10000' always mean an 'if Lara has just swung forwards very long' condition (either if Key 'Dash' is just pushed down or only if the momentum took Lara forward a so big distance after Key 'Dash' being pushed down or if Lara has left the rope after the swing and the value is 'frozen' in the field).

Lara. Special Status of Lara (Byte)
This field contains some flags for Lara.
I think it's pretty complicated - but that's what my experiences are:

0: she jumps aside, steps aside, the moment when standing and facing the wall (or in a low angle) touches/bumps that, shimmying around the corner (both on ledges and ladders), dead, the moment when getting the parallel bar, ignites the torch/with the torch, picks up the item (in any way), places the item (except nitro), uses sandbag/waterskin/jerrycan, interaction with doors/switches*/pushables, uses the crowbar, uses the mechanical scarab
+1: this flag is added if she holds the flare/torch in her hand** - but only if she does that according to FLARE_ANIM or TORCH_ANIM. (So, eg. the flag is not used if she holds the flare jumping or swimming etc., because her hand movements are different from ANIM object hand animations.)
+2: supposedly an existing flag. But it's unknown.
+4: this flag is added if she does anything that is not mentioned at Flag0.
+8: this flag is added if she is burning.
+16: I couldn't identify this flag. Paolone says the flag may be added if she's on all fours - but 'all fours' state is calculated in '+4' flag.
+32: this flag is added if Lara starts an interactive animation (to pick up an item etc.) and she needs some automatic aligning (sidesteps etc.) to start the animation. (The flag is added even if the aligning is so little that you can't see any aligning on the screen.)***
+64: this flag is added if Lara is over a square having the monkey attribute. (So the flag is also added if Lara is not doing monkey swing there.)****

*: it seems +4 flag in the case of buttons, instead of 0.
**: with the torch in Lara's hand, the flag is usually 5 (+1+4). When Lara ignites the torch/with the torch then these will be the new flags before getting back to 5: 4 (moving hand to the fire), 0 (igniting), 1 (moving hand back from the fire).
***: if this flag exists, then the flag will turn into picking up '0' flag a bit later, naturally, if the interactive animation starts. But, not at once. I mean, if +32 flag exists, then the flag turns into 4 or 32 before the 0. (If it's 4 or 32 that depends on the type of the aligning.)
****: this flag will be dropped for a frame if the player releases monkey bars during Lara is moving.

Note: as you see, some flags will appear only for one or two frames. I mentioned some of them - but only the more important cases. (So maybe you encounter other cases in which the flags will change only for some moments.)

Some examples, to understand the flags:

Lara is running over some flat squares, with a flare in her hand when there are monkey bars above her - the flag is now: +64+1+4=69.
Lara bumps to the wall while burning, or lying dead on the floor while burning - the flag is now: 0+8=8.

Case A: forcing these values could be buggy. (Anyway, use 'real' triggers instead of them, if it's possible. E.g. use F63 if you want Lara to be burning etc.)
Case B: as this field is very complicated, you'd better be careful, if you want to define a condition here. - By the way there are 'real' and clear CONDITION triggers if you want this kind of condition (e.g. C5 or C30 etc.) and even 'the monkey bar above Lara' condition can be found in ENV_MONKEY_CEILING Script constant.
But, for example, +32 flag could be an interesting condition if you want to study the existence of aligning.

Lara. Special2 Status of Lara (Byte)
This field contains some flags for Lara - that's what my experiences are:

+1: Lara is over a square having a grey frame (by Room Editor 'B' button) for the mechanical scarab.
+2: supposedly an existing flag. But it's unknown.
+4: Lara is crouching - after standing or on all four.
+8: Lara shoots. (The effective shooting. I mean, it doesn't matter now, eg., if Lara loads the shotgun.)
+16: the screen is seen through the binoculars or the lasersight graphics.
+32: Lara has a burning torch in her hand.
+64: Lara uses/used a ladder (and didn't hang on a ledge after that).

Some examples, to understand the flags:

Lara has climbed up a ladder and drawn her crossbow and now she's shooting - the flag is now: +64+8=72.
Lara has climbed down a ladder then grabbed a ledge to hang and fallen down. Now she's crouching on a square with a grey frame - the flag is now +1+4= 5.

Note: when there is the lasersight graphics on the screen and Lara's shooting with the revolver then +8 won't be added to +16. I.e. it will only with the crossbow.

Case A: forcing these values could be buggy. (Anyway, use 'real' triggers instead of them, if it's possible. E.g. you can force the crouching animation on Lara, if you want.)
Case B: there are some conditions instead of this Case B. For example, 'if Value is +8' is the same as 'if Lara is shooting' in C5 trigger.
But, for example, studying if Lara is over a grey framed square or if there is the lasersight graphics on the screen (removing the binoculars-usage, that has the same flag, by another condition) are possible only with this Case B now.

Lara. Test. Climb sector Test (=1 yes; =0 no) (Short)
It defines if Lara is over a square that has the climb attribute at any wall around it (1) or not (0).

Case A: if you don't want to use a flipmap to create/remove a climbable wall in a room, then force 0 (continuously!) in this field (which will remove the climb attribute all around the actual square where Lara just is) or force 1 (continuously!) in this field (which will create the climb attribute all around the actual square where Lara just is).
Case B: you can use this Case B as a condition if all you want to know if Lara is in a climbable place or not. But see ENV_CLIMB Script constants for more exact conditions.

Lara. Test. Lara has a flare in the and (1 = yes) (Short)
It defines if Lara has a working (!) flare in her hand (1) or not (0).

Note: if the flare is almost totally out, so it will start flickering, then the value also starts 'flickering' between 0 and 1.

Case A: forcing values here is buggy or effectless.
Case B: Value 1 means an 'if Lara has a flare in her hand' condition. Value 0 means an 'if Lara hasn't a flare in her hand' condition. (This 0 could be pretty useful to use it with an 'empty hand' condition together, if you want a 'totally empty hand' condition, because a simple 'empty hand' condition means 'totally empty or a flare in it' condition.)

Lara. Test. Lara is on rope (different than -1 lara is on the rope) (Long)
It defines if Lara is on a given (!) rope (not -1) or not on any rope (-1).
The values depend on the Room ID (the lower room ID's have the lower field values) and when the given rope was placed in the given room (the sooner placed ropes have the lower field values). - For example, in a level that has these five ropes:

Room6:
- Rope placed in the first place of the ropes that are just placed in this room: field value is 0
- Rope placed in the second place of the ropes that are just placed in this room: field value is 1
Room14:
- Rope placed in the first place of the ropes that are just placed in this room: field value is 2
- Rope placed in the second place of the ropes that are just placed in this room: field value is 3
Room15:
- The only one rope in this room now: field value is 4

So it is NOT the object ID that matters when you want to define the first, the second etc. rope of the room!

Case A: forcing these values is buggy.
Case B: for example, in the example above, Value 2 means an 'if Lara is hanging on one rope of Room14, which rope was placed in the first place of the ropes that are just placed in that room' condition.
But if you use a 'Value is bigger than -1' condition that means 'if Lara is hanging on a rope'. (This condition is realizable with animation and/or stateID conditions, as well.)

Note:
See another method for this, here, below: 'TRNG Index. Index of last item used by Lara (Short)' field.

Lara. Test. Lara is placing the weapon on the back (1 = yes) (Short)
It defines if Lara is aiming at any enemy (1) with any weapon or not (0).

Notes:
- Only the 'real aiming' is what matters. So, if the enemy is aimed only because you force the aiming with the lasersight, that doesn't calculated now.
- If Lara is aiming but holstering the weapons then the value will remain 1 during the holstering move.

Case A: this value cannot be forced.
Case B: Value 1 means an 'if Lara is aiming at an enemy' condition. Value 0 means an 'if Lara isn't aiming at an enemy' condition.

Lara. Test. Throw out item from the Hands (1 = lara is throwing out item) (Short)
This field contains flags for the torch:

0: Lara picks up/holds the torch / torch is (in NGLE position/thrown/dropped) on the floor
1: Lara throws the torch by hitting SPACE
2: Lara drops the torch by drawing a weapon (with shortcut keys or in inventory)
3: Lara ignites the torch with the flame / the flame with the torch

Case A: some of these properties can be forced with 'normal' triggers. See more about this in the tutorial on The Torch.
Case B: see the same tutorial if you want to know about how to use these values as conditions.

Lara. Weapon on the back of Lara (Short)
It indicates if a weapon is just seen placed on Lara's back. - The values are:

0 - there's no weapon on Lara's back
3 - the shotgun is on Lara's back (because object slot ID3 is SHOTGUN_ANIM)
4 - the crossbow is on Lara's back (because object slot ID4 is CROSSBOW_ANIM)
5 - the grenade gun is on Lara's back (because object slot ID5 is GRENADE_GUN_ANIM)

Case A: forcing a value here, the required weapon will be seen on Lara's back. (It has nothing to do with which weapon Lara will draw, hitting SPACE.)
Case B: for example, Value 5 means an 'if the grenade gun is seen on Lara's back' condition.

Statistics. Distance (Long)
This field contains the distance Lara has traveled in the whole game (!) so far.
Each 419 means a new meter. - So, for example:

If the value is 2095 (5x419=2095) then Lara has traveled 5 meters exactly, the Statistics show '5m'.
If the value is 2514 (6x419=2514) then Lara has traveled 6 meters exactly, the Statistics show '6m'.
If the value is 2407 then Lara has traveled more than 5 meters but less than 6 meters, the Statistics show '5m'.

Horizontal and vertical distances are both calculated.
(Please note what I said above: if the animation has a SetPosition AnimCommand, changing a coordinate, then that coordinate won't be refreshed in this field while the animation is being performed - so, till the end of the animation, the distance won't be refreshed either.)

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the distance in the new level will be counted from 0 meter (as if the counter worked on only the actual level and not the whole game) - because this forced 0 affected the distance value in Statistics as well!
Case B: for example, Value 209500 means 'if Lara has traveled exactly 500 meters so far' condition.
(This condition may seem to be dumb first, but it isn't under any circumstances. I mean, for example you will open a secret level for the player only if he/she was clever and found all the tasks of the level without too much sauntering. I.e. you will use an 'if the Value is smaller than,' condition.)

Statistics. Killed Enemies (Short)
This field contains the number of the enemies Lara has killed in the whole game (!) so far. - But please note:

- Each killing by explosive ammunition now is calculated as if Lara had killed 2 enemies at once.
- 'Special' deaths (killings by ACTION triggers, WRAITH1 disappears in the water, poisoned death, 'headless' skeleton etc.) isn't calculated in this field.

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the number of the killed enemies will be counted from 0 (as if the counter worked on only the actual level and not the whole game).
Case B: for example, Value 15 means an 'if Lara has killed 15 enemies' condition - if she didn't kill one by explosive ammunition or some 'special' death.

Statistics. Secrets (Byte)
This field contains the number of the secrets Lara has revealed in the whole game (!) so far.

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the number of the found secrets will be counted from 0 (as if the counter worked on only the actual level and not the whole game) - because this forced 0 affected the secret value in Statistics as well! (Don't misunderstand: CUST_SET_SECRET_NUMBER will define the maximum secret number of a level, and not the starting number of the found secrets on that level.)
Case B: use C18 (or C17) trigger instead of this Case B.

Statistics. Used Ammos (Short)
This field contains the number of the ammunition Lara has shot in the whole game (!) so far.
(Each shot bullet means +1 value in the field. Even if that is a crossbow arrow or a grenade. - But don't forget: each shot with a dual weapons means 2 shot bullets.)

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the number of the shot ammunition will be counted from 0 (as if the counter worked on only the actual level and not the whole game) - because this forced 0 affected the ammunition value in Statistics as well!
Case B: for example, Value 500 means 'if Lara has shot 500 bullets so far' condition.
(This condition may seem to be dumb first, but it isn't under any circumstances. I mean, for example you will open a secret level for the player only if he/she was clever and did all the killings only with a few amount of ammo, aiming precisely. I.e. you will use an 'if the Value is smaller than,' condition. - Of course, it will be a nice condition only if Lara doesn't have some 'super ammo' just as grenades.)

Statistics. Used MediPacks (Byte)
This field contains the number of the small AND big medipacks Lara has used in the whole game (!) so far.

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the number of the used medipacks will be counted from 0 (as if the counter worked on only the actual level and not the whole game) - because this forced 0 affected the medipack value in Statistics as well!
Case B: for example, Value 20 means 'if Lara has used 20 small or big medipacks so far' condition.
(This condition may seem to be dumb first, but it isn't under any circumstances. I mean, for example you will open a secret level for the player only if he/she was clever and did the things without too much loss in the health. I.e. you will use an 'if the Value is smaller than,' condition.)
Similar conditions - see: GT_USED_BIG_MEDIPACK or GT_USED_LITTLE_MEDIPACK type GlobalTriggers.

System. Auto-Aiming for Enemy (Byte)
This field shows if the auto-aiming is just enabled (2) or not (0).
(Note: if the auto-aiming is enabled then Value 2 won't show up in the field till drawing a weapon at the very first time.)

Case A: this value cannot be forced.
Case B: for example, Value 2 means an 'if the auto-aiming is enabled' condition.

System. Core Game Timer (one unit = 1/30 of second) (Long)
This field contains the time (in frames) that has passed in the whole game (!) so far.

Notes:
- This value is updated only if you have just saved the game (or if you have just loaded that savegame).
- The 'dead time' (i.e. when the game is paused because there's a menu on the screen) is also calculated in this field.

Case A: this value is meaningless to be forced.
Case B: for example, Value 1200 means an 'if 40 seconds has been passed since starting the game, including when the menus were open' condition (because 1200/30 frames=40 seconds). - But I can't see where this condition could be useful.

System. Disable special keys (15 disable inventory pause f5) (Short)
This field starts counting the frames (from 0) when Lara starts a dying animation. When the counter reaches 301 (i.e. 10 seconds+one more frame) then the game will load you back to the title. (Of course, with some buttons, the player can force this load to happen sooner after the dying animation has ended.)
(No, I don't know what Paolone meant when he said Value 15 has a disabling effect now.)

Case A: forcing a value is useless or sometimes buggy.
Case B: for example, Value 210 means an 'if 7 seconds has passed after Lara starting a dying animation' condition.
And this is a very nice Case B, because, usually, you can't activate anything after Lara died. But, if a dying animation is shorter than that 7 seconds, then this Case B with Value 210 will activate anything AFTER the dying animation has ended, so if Lara is 'totally' dead!

System. Fog Bulb Color (Long)
The value of the field is the actual color code of fog (whether the distance fog or fog bulbs just have that) that is defined by an F28 or an F224 trigger. (So if the fog color isn't defined by a trigger, then the value is 0.)
The meaning of a color code is simple, Just see what I said above at 'Unknown (Light_D) (Long)' field: so, for example, 1336370 code means RGB=20/100/50.

Case A: this value cannot be forced.
Case B: for example, Value 16107580 means an 'if the fog color (defined by a trigger) is RGB=245/200/60' condition, because 16107580=$F5C83C=$F5/$C8/$3C=245/200/60.

System. Item Memory address of enemy aimed by Lara (Long)
The value of this field is some kind of identification of the enemy that is just aimed (automatically) by Lara.
Honestly, I don't know what that value means (for example, 52551314?) but we don't need to understand that. So, if you want to identify the enemy that is just aimed by Lara, then put that value into the Current Value variable. And then F351 trigger will turn that long number into the game ('tomb') index of the object, and then F300 trigger will turn the game index into the Room Editor ('NGLE') index of the object - and that is already a useful value in a condition ('if the enemy aimed by Lara has XX NGLE object index').

System. Number of current Level (Byte)
This field shows the ID of the level - but updates that only if you save the game or loading that savegame.
(The ID of the level depends on the position of the [Level] block of the level in the Script. So title ID is 0, the level with the first [Level] block has ID1, the level with the second [Level] block has ID2 etc. - these 1, 2 etc. are the ID's that FINISH triggers use.)

Case A: this value cannot be forced.
Case B: it is senseless to use these values as conditions. I mean, the conditions of a level always work only in that level, so you don't need to study if you are in the given level.

System. Screen Timer (Increased only when it is different than 0) (Long)
This field shows (in frames) the actual value of the so-called 'Screen Timer'.
Please note the Screen Timer will show up on the screen only if you use 'Timer= ENABLED' Script entry - but, without that entry, the F86 trigger of the Screen Timer will also start and stop the timer in this field. (So, without that entry, you can use the Screen Timer in a hidden way.)

Case A: either you use the Screen Timer in a hidden way or not, you can force a value in this field. The timer will jump ahead/back at once to the forced value, continuing running.
(If you force the value when the timer is not running, then the timer will start running, from the forced value.)
Case B: for example, Value 1500 means an 'if the Screen Timer has just reached 50 seconds' condition. - But, if you don't use the timer in a hidden way then use C20 timer instead of this Case B. (Note: in TRNG 1.2.2.6 there's a clerical error in C20, i.e. you must change the 'lower' and the 'higher' conditions with each other. When I'm making this tutorial, the problem is solved in 1.2.2.7 beta.)

System. Unknown (Item chosen from Inventory? (Long)
The default value here is -1 - but will change if Lara chose anything from the inventory:

0: Uzis
1: pistols
2: shotgun
3: revolver
4: revolver with lasersight
,
19: standalone lasersight
20: big medipack
21: small medipack
22: binoculars
23: flare
,.
25: load game
26: save game
,
44: PUZZLE_ITEM8
,
There are a lot of values here. I didn't want to find all of them, so I wrote only some examples now. So if you want to know the value of an inventory item after you've chosen that, then put the field value in a variable and study the variable value after you've chosen the item.

Notes:

- the field won't be updated if you change something by keys and not directly from the inventory.
- the value will change even if there is no effect (i.e. if you chose the weapon that just is in Lara's hand or if you chose a medipack when Lara is totally healthy etc.).

Case A: this value cannot be forced.
Case B: usually there are better methods than this Case B if you want to examine if an item is chosen or not (see C59 trigger or GT_USED type GlobalTriggers). But I think there are some special items when none of them work, so you can try this Case B somehow.

TRNG Index. Animation Index for Selected Animation Memory (Short)
The subject of a field of the Animation Memory Zone is usually a constant animation number, defined by F307 trigger.
But you can put this or that animation number into a variable during a game, and then put that variable value into this 'TRNG Index,' field. Doing that, you've defined the subject animation - so you don't need F307 trigger now.

TRNG Index. Index of last item found with testposition or condition (Short)
This field contains the game ('tomb') index that is just found by a condition.
For example, use a GT_COLLIDE_SLOT type GlobalTrigger, with BADDY_1 slot. If Lara collides with a BADDY_1 then a TriggerGroup will be activated. In this TriggerGroup, you will put an F244 trigger that puts the value of this 'TRNG Index,' field into a variable. This value is the game index of the object that is defined by the latest condition. This condition is GT_COLLIDE_SLOT-BADDY_1 so this game index is the game index of the BADDY_1 Lara has just collided with now.
Use an F300 trigger to turn the game index into the Room Editor ('NGLE') index of the object - and that is already a useful value in a condition ('if the BADDY_1 Lara collides with has XX NGLE object index').
(Okay, there is an easier way for this concrete operation - see: GT_COLLIDE_ITEM type GlobalTrigger - but now we understand how this field works. Besides, if you don't want to study that index in a condition, but want to know the actual BADDY_1 index Lara collides with, then this example could be useful the way it is written.)
Please note that the field will be updated only at the next find of an index.

TRNG Index. Index of last item used by Lara (Short)
This field contains the game (!) index of the object Lara has interaction with last.
So if she grabs a rope or a parallel bar or pushes a button or gets on a motorbike etc. then the game index of the object will show up in the field.

Please note that the field will be updated only if Lara has a new interaction and some interactions (picking up an item, placing an item, using a lever switch, climbing on a polerope etc.) are not working in this field. So, if you want to know what kind of object interactions are useful in this field then put the field value in a variable and study if the variable value changes if you use that object.

Case A: this value cannot be forced.
Case B: after you transform that game index into NGLE index (by F300 trigger) then that index is useful in a condition. For example, having a big wall button (just as in the original catacomb.prj Room84) with 63 NGLE object index: an 'if the object NGLE index is 63' and an 'if Lara is doing the big wall button-pushing animation' mean 'if Lara is using ID63 button'. (The animation-condition is necessary. Without that, the index-condition would also be true after using the button - because, as I said, the field won't be updated after the usage, only at the next interaction with anything.)

TRNG Index. Index of moveable performing last AnimComand (Short)
For example, your BADDY_1 slot has an AnimCommand at a frame of AnimationX. This AnimCommand is a TriggerGroup that contains two triggers: one of the triggers (T1) is the one the baddy will execute at that frame. The other trigger (T2) is an F244 trigger that puts the actual value of this 'TRNG Index,' field into a variable. It means T2 puts the game index of the baddy just executing T1 into that variable.
Let's suppose there are more than one BADDY_1 (A, B and C) are living at the same time. Create a GlobalTrigger that transforms the game indices in that variable into NGLE indices continuously while the baddies are living.
Let's suppose you want to activate something only if 'A' BADDY_1 executes T1 and don't want activate that if 'B' or 'C' baddies do that. So now you study the NGLE index in the variable (in the same GlobalTrigger), and if that is the index of 'A' baddy then the true condition activates what you want.
Please note that the field will be updated only at the next performing (by anyone) of that AnimCommand.
(See some similar thing above: 'Frame Now (warning it's an abs value) (Short)' field.)

TRNG Index. Item Index for Selected Item Memory (Short)
The subject of a field of the Item Memory Zone is usually a constant object, defined by A54 trigger.
But you can put this or that object game (!) index into a variable during a game, and then put that variable value into this 'TRNG Index,' field. Doing that, you've defined the subject object - so you don't need A54 trigger now.
(Use F301 trigger if you don't know the game index of an object.)

TRNG Index. Slot Index for Selected Slot Memory (Short)
The subject of a field of the Slot Memory Zone is usually a constant object slot, defined by F292 trigger.
But you can put this or that object slot index into a variable during a game, and then put that variable value into this 'TRNG Index,' field. Doing that, you've defined the subject object slot - so you don't need F292 trigger now.

TRNG Organizer Timer. (Increased always in game but not in inventory and pause) (Long)
This field contains the time (in frames) that has passed in the whole game (!) so far.

Notes:
- This value is updated continuously.
- The 'dead time' (i.e. when the game is paused because there's a menu on the screen) is NOT calculated in this field.

Case A: sometimes it is worth forcing a value here. For example, if you start a new level then you force 0 here so the number of the passed time will be counted from 0 (as if the counter worked on only the actual level and not the whole game).
Case B: for example, Value 1200 means an 'if 40 seconds has been passed since starting the level, excluding when the menus were open' condition (because 1200/30 frames=40 seconds).
This condition is a nice tool to activate things in the given moments of the level. Or to give some reward to the player if (s)he accomplish the level during a given time.

Code Memory Zone fields

Audio Track Number on Channel 1 (only for read) (Short)
Audio Track Number on Channel 2 (only for read) (Short)
These fields (using the new sound system) show which audio file just plays on channel1 or channel2. (-1 means no audio file is just playing.)

Case A: this value cannot be forced. (By the way, there are the 'Sound' FLIPEFFECTs to play an audio file.)
Case B: for example, Value 80 in Channel2 field means an 'if ID80 audio file of the audio folder is just playing on channel2' condition.
(But be careful! If the file stops in single mode because it has ended by itself and not because it has been stopped, then the value remains the file ID, not -1, and will be updated only when the next file will play.)

Camera Mode Next (0='follow me', 1='fixed', 2='look'; 3 ='combat') (Long)
Camera Mode Now (0='follow me', 1='fixed', 2='look'; 3 ='combat') (Long)
The 'now' field shows the actual camera type that is being used:

0: chase camera
1: placed Camera or Fixed Camera
2: look camera or standalone TARGET
3: combat camera

Notes:

- Do some tests if you want to know how this field works with flyby cameras. (I mean it seems a bit messy for me. Anyway, it uses 0 and 1.)
- Special camera effects use the camera value of the camera they use. (Eg. standby effect uses chase camera so standby effect uses the value of the chase camera.)

Case A: the 'next' field value seems a constant 0. However, the 'next' field is useful, because you can't force the camera values in the 'now' field. So, if you want your actual chase camera will adopt the position of the look camera, then force Value 2 (continuously) in the 'next' field, or, if you want your actual chase camera will adopt the position of the combat camera, then force Value 3 (continuously) in the 'next' field.
(An interesting fact: forcing Value 2, if you move the look camera view with look button and cursor keys, and then release those buttons, then the chase camera position will keep the last camera view you've adjusted by the buttons.)
Case B: for example, Value 3 in the 'now' field means an 'if the combat camera is just active' condition.

Current Level number (more updated than savegame memory) (Byte)
This field shows the ID of the level.
So this is the same thing as 'System. Number of current Level (Byte)' has. The difference: the value in the present field is always updated.
(Though this time it may be worth forcing a value here - if you have a hardcoded limitation due to level ID. - Thanks sapper for the information.
For example, as you know, small scorpions won't poison Lara if the level ID is smaller than 4. So if you are in the first, second or third level of your game, and you want the small scorpion to poison Lara then force a value that is bigger than 3 in this field.
However, be careful: it will disturb the working of the FINISH triggers. So, before a level jump, force back into this field the 'real' level ID.)

Dash Bar Value (0 - 120) (Short)
This field contains Lara's power to dash:

0: Lara has no power to dash.
120: Lara has full power to dash.

Case A: force Value 120 here continuously (it doesn't matter if she's just sprinting or not), and Lara will have infinite power to dash - without the dash bar appearing (because when the value is 120, the game removes the dash bar automatically). (If you force another value here continuously when Lara's making the sprint animations, then the power will be infinite and the bar will appear. But now you will see in the bar that is not full.)
Or force any other value here (not continuously) when she's sprinting, to remove/add some dash power (i.e. to adjust the actual power to the forced value).
Case B: for example, Value 60 means an 'if there is 50 % power of Lara to dash' condition. (Note this is also true, if Lara has finished the sprint and the dash bar started increasing. So, if you want this condition to be true only if Lara is sprinting then also use an 'if Lara is sprinting' condition.)

Earthquake vertical movement (negative values) (Long)
This is the same I told you at 'Custom_A (Different usage in according with type of item) (Short)' field, about EARTHQUAKE object. I mean this field shows the actual intensity of the earthquake. (But this time the values are negative.)
The difference between that field and this field is this is a 'general' field, so works with any earthquake, and not only a given EARTHQUAKE object.

Case A: forcing these values is useless. (I mean, any value here starts an earthquake at once when being forced, but that won't affect the 'real' intensity in the game.)
Case B: for example, Value -50 means an 'if the earthquake intensity just reached a middle-sized intensity' condition.

Frame 3d Counter. (It works in game and inventory but not in pause) (Long)
This field contains the time (in frames) that has passed in the whole game (!) so far.

Notes:
- This value is updated continuously.
- The Pause/F5/F6 menu 'dead time' is not calculated in this field, but the inventory 'dead time' is.

If you want to know more about game timers then see above 'System. Core Game Timer (one unit = 1/30 of second) (Long)' or 'TRNG Organizer Timer. (Increased always in game but not in inventory and pause) (Long)' fields.

Frame System Counter. (Works always, in game, inventory and pause screens) (Long)
This is almost the same as 'Frame 3d Counter. (It works in game and inventory but not in pause) (Long)' field. The difference is this time every 'dead time' is calculated in the field.

Inventory Item just chosen from inventory (example a key to open a door) (Long)
The purpose of this field is troubleshooting. To understand that, I quoted some short (and edited) part of TRNG 1.2.1.9. readme file:

'Inventory. The item selected from inventory is <#>Item' condition is interesting when you wish to create a custom interactive item, where it's necessary to use some inventory item to engage it. It works like the keys for the doors, the combo items with some hole combos, or the crowbar for some wooden doors.

Remark: when you manage the correct selected item remember to perform also this field: 'Inventory Item just chosen from inventory (example a key to open a door) (Long)', with -1 as a Value in Window E.

The reason is that otherwise you'll hear the "NO" sound sample after using this inventory item.

Inventory Item required in game (example, crowbar for door) (Long)
This field has usually Value -1. But if the inventory opens when the player hits CTRL at an object to interact with that, then the value will be the slot ID of the object that needs for the interaction, till the inventory is open.
For example: Lara is standing in front of a door that will open with crowbar (value: -1). Now the player hits CTRL, the inventory will open at the crowbar (value: 246=crowbar slot ID). The player chooses the crowbar, the inventory closes (value: -1) and Lara opens the door with the crowbar.

Case A: there are some receptacles where nothing will happen if you hit CTRL (see eg. element puzzles), and you need to choose the item will be placed there manually. Forcing the proper ID in this field in the proper moment (and when the player hits CTRL), the inventory will open at the required item. - But use F306 trigger instead for this purpose.
Case B: to study the just selected item you should use C59 instead this Case B.

KeyBoard Game Command hit (Use bit operations with KEY1_ constants) (Long)
When the player moves Lara (or does anything) by the keys then you will see here the code of that key command.
See KEY1 and KEY2 constants in NG Center\Reference\Mnemonic Constants if you want to know the meaning of the codes. For example, the code of KEY1_LEFT is 4, so when the value of the field is 4 that means the player holds the left arrow pushed down.

Notes:

- If you customize keyboard commands in Options menu, then both (!) the original key and the new key will have the code of the key command.
- If the players hits more than one key at the same time then the aggregate what matters. For example, hitting up arrow and SHIFT to walk forward=1 (up code) +128 (SHIFT code)=129.
- Be careful, if you have an 'alternative solution' for that key command. For example, PAGE DOWN is an alternative solution for right arrow+SHIFT, as you know. Right (8) plus SHIFT (128) is 136 - but PAGE DOWN/Right+SHIFT will show 2048 (?) plus 128 (SHIFT)=2176 value in the game. (DELETE is 1024+SHIFT=1152.)
- The KEY2 codes in this field must be read this way:
For example, the code of KEY2_DASH is 16384. It's $4000 as a hexadecimal code. Put four times Digit 0 to the end. It's $40000000. Now turn it back into a decimal value: 1073741824 - and this is the 'real' code of this key command in this field.
- Unfortunately, keyboard commands aren't detected when the menus are open. That's why there isn't a KEY1/KEY2 code for, eg., ESC in the Mnemonic Constants. (Though ESC just being pressed will be detected, if you hit that to close a menu, and the menu is closed now, but the ESC still is being pushed. The code is 2097408.)
- Value 0: if the player is just not hitting any key.

Case A: try F53 trigger instead of this Case A.
Case B: try C13 trigger instead of this Case A. (And see a similar condition: C12.)

Music volume (max = 100) (Long)
This field has nothing to do with C133 trigger that adjusts the volume on a given audio channel. I.e. this field (working perfectly only in the new sound system) contains the 'general volume' of the audio - the one you see in Options menu.

0: audio is mute
100: audio with max volume

Case A: you can force a preset audio volume for your game, with SoundSettings Script command. But use this Case A if you want to force a new volume, during the game.
Case B: for example, Value 40 means an 'if the audio volume in Options menu is 40%' condition.

Screen. Height game screen in pixel (only for read) (Short)
Screen. Width game screen in pixel (only for read) (Short)
These fields aren't really useful. I mean they inform you about your screen resolution - but you can't modify that in the fields.
For example, at 1024x768 resolution, 'height' field is 768 and 'width' field is 1024.

Script Dat. Level Flags (Use bit operation to read or change) (Short)
This field contains information about a lot of old Script commands (either they are well-known or unused in our Level Editor) you can find in [Level] blocks.
If a command like that is present in a level with numeric or ENABLED values then that command will have a value in this field.
But if a command like that is not present in a level or is present but with DISABLED value (or is disabled with a semicolon) that command won't have a value in this field.

For example, a 'Horizon=ENABLED' command in your [Level] block has a value (4) in this field, and a 'Layer1= 160, 160, 192, 7' in your [Level] block will also have (8). The 'real' value of the field is the aggregate of the values of the commands here.
So, eg. if only that 'Horizon=ENABLED' and 'Layer1= 160, 160, 192, 7' have values in this field, then the 'real' value of the field is 4+8=12.

All the values are:

1: YoungLara
2: Weather
4: Horizon
8: Layer1
16: Layer2
32: StarField
64: Lightning
128: Train
256: Pulse
512: ColAddHorizon
1024: ResetHUB
2048: LensFlare
4096: Timer
8192: Mirror
16384: RemoveAmulet
32768: NoLevel

Case A: be careful - some of the values can be forced in this field, but some of them can't. However, this field is a nice tool to enable/disable properties you can't enable/disable by a direct method (at all or in a nice way). - Let's see an example:
The field value is 2060=Horizon (4)+Layer1 (8)+LensFlare (2048). You want a moment in your level, when the sun effect (i.e. LensFlare) will be switched off in all the outside rooms. You can do that, if you create a flipmap version for all your outsides rooms, switching off the NL button in all those flipped rooms. - Or another method: you force Value 12 in this field (4+8), leaving horizon and layer values alone, but removing the value of LensFlare (2048).
Or another nice possibility: You don't have a Train=ENABLED entry in your Script, so this is not a train level - though, there is a train formed here. Lara will get into the train, you force the value of Train (128) in the field - and 'the train will start'.
Unfortunately, you cannot force something to switch on in an easy way if that thing uses numeric values in the Script. For example, you don't have a LensFlare entry in your Script, so if you make LensFlare become enabled in this field, then that will be useless (because the game won't know which numeric values to use). - The problem could be solved, if you place a LensFlare entry in the Script, but remove its value from the field when the level will start, and later, in the required moment, you will add its value to the field.
Case B: this Case B is a bit complicated, but usable. So, eg. Value 5120 (1024+4096) is an 'if this level is a ResetHUB level and if it is possible to print the Screen Timer on the screen here, but there aren't other command values' condition.

Script Dat. Option Flags (Use bit operations to read or write) (Byte)
I don't know what to say. I mean, in my levels, this field always has a constant, long value (270055424) and if I try to force another value here then nothing will happen. If I try the same things in the [Title] block then the solution will be buggy.
Paolone says, Option flags (FlyCheat, LoadSave etc.) are written in this field, but whatever I do (i.e. eg. disabling flycheat) then the value will remain the same in the levels.

Sound SFX volume (max = 100) (Long)
This field contains the 'general volume' of the sound - the one you see in Options menu.

0: sound is mute
100: sound with max volume

Case A: you can force a preset sound volume for your game, with SoundSettings Script command. But use this Case A if you want to force a new volume, during the game.
Case B: for example, Value 40 means an 'if the sound volume in Options menu is 40%' condition.

Speed Layer1 (4th field of Layer1= script command) (Byte)
Speed Layer2 (4th field of Layer2= script command) (Byte)
Layer1 and Layer2 are sky patterns. You can define their preset values in the Script. - This is what 'speed' means now:

0: the clouds are still
from 1 (minimum speed) to 127 (maximum speed): the clouds are drifting northwards (Room Editor facing)
from 128 (maximum speed) to 255 (minimum speed): the clouds are drifting southwards (Room Editor facing)

I mean, using Layer2, the north/south intervals are swapped with each other. (So 1-127 is the south interval, and 128-255 is the north one.) Except: if both of the layers are being used at the same time.

Case A: use F153 trigger instead of this Case A, to force a new speed/direction for the clouds.
Case B: for example, Value 60 in Layer1 field is an 'if Layer1 sky pattern is drifting northwards, according to Room Editor facing, with an average speed' condition.

Test. Disable Fog Bulbs (1 = disable) (Byte)
This field contains information about Volumetric FX option:

0 - option is checked (i.e. fog bulbs are enabled, the distance fog is disabled)
1 - option is unchecked (i.e. fog bulbs are disabled, the distance fog is enabled)

Case A: instead of this Case A, use the setup of the game, the ForceVolumetricFX Script command or F61/F62 triggers.
Case B: Value 0 means an 'if fog bulbs are enabled and the distance fog is disabled' condition, Value 1 means an 'if fog bulbs are disabled and the distance fog is enabled' condition.

Test. How entered in current game (New level=0; From savegame = 4) (Byte)
Whatever I do the value of this field is always 0 for me. Even after a savegame has been loaded.

Test. There is a Flyby in progress (1 = true / 0 = false) (Long)
This field informs you if a (any) flyby camera sequence is just

0 - not being performed
1 - being performed

Note: if the sequence is endless, in a loop mode, because Lara is standing on the flyby-activating trigger continuously, then the value will be 0 for a moment when the sequence is just being restarted.

Case A: forcing these values is buggy.
Case B: Value 0 means an 'if any flyby sequence is just not being performed' condition, Value 1 means an 'if any flyby sequence is just being performed' condition.

Slot Memory Zone fields

Explosion Mask. (Each bit a type of weapon able to do explode it (Long)
The most of our objects don't have a shatterable mesh. But if you have a value here that is not 0 then one or more meshes of the object is shatterable - but only if that is aimed by lasersight. (Thanks sapper for the information.) - The values are simple bits:

Bit0 (1) - Mesh0 is shatterable
Bit1 (2) - Mesh1 is shatterable
Bit2 (4) - Mesh2 is shatterable
Bit3 (8) - Mesh3 is shatterable
Bit4 (16) - Mesh4 is shatterable
Etc.

For example, you can shatter the head (Mesh9) and the shield (Mesh11) of the skeleton, that's why the value of the skeleton in this field is 512+2048=2560, because Mesh9 has Bit9 (i.e. 512) and Mesh11 has Bit11 (i.e. 2048).

Case A: force a value here to make one or more meshes of an object become shatterable. (Still having the collision after the crash.)
(Note: you cannot place a HEAVY under this object to activate something if the mesh has been crashed. But you can use a trick:
As I said, if all the meshes of the object are visible, then the value of 'Visible Mesh Flags (each mesh a different bit) (Long)' field is -1. Let's suppose all the meshes are visible now and Lara has shot Mesh9 using the lasersight. Now the value of Mesh9, i.e. 512 will be subtracted from the field value, that is -1-512=-513 now. - So a Value -513 condition in 'Visible,' field means an 'if all the meshes are visible and Mesh9 has been shot" condition.
The formula will also work if not all the meshes are visible.)
Case B: it's worth studying if a mesh shatterable or not if you force the 'shatterable' property on that mesh only in a given moment of the game.

First Animation Index (Short)
This field helps you to identify the first animation ID of an object slot (if you don't want to identify that from NG Center\Tools\Animation Watcher).
For example, if the Animation0 of BADDY_1 has Animation656 as the absolute animation index of X.wad then the value of this field is 656.
It helps you, eg. in 'Animation Now (Number of current animation) (Short)' field (see above):

Actual absolute animation ID minus first absolute animation ID equals actual (non-absolute) animation ID.

First Mesh Index (Short)
Open the 'Select Object' panel in the Room Editor. Let's suppose this is what you see at BADDY_1: #RMI=80, #AMI=332.
If you find Mesh #80 in StrPix, then this is the first mesh of that BADDY_1 (i.e. the mesh you find as Mesh 0 in WADMerger Animation Editor). Value 332 is the so-called 'absolute index' of this mesh.
The value of the field is always 'twice #AMI'. It means this time the field value is 2x332=664. - But I don't know where it could be useful.

Flags. Main flags (Short)
This field seems complicated - so I'll just write my experiences:

1: if the object slot has this flag then the object slot will be present in the TR4 file. (So if you converted a PRJ file having this slot in its WAD into a TR4 file, then the slot will have the flag - even if you didn't place an object of the slot in the map.)
2: object slots with AI (not only creatures, but eg. ENEMY_JEEP) will have this flag. (Creatures with hardcoded animations - see emitter creatures or wraiths - aren't included.)
4: I didn't find this flag in any of the slots. Maybe doesn't the flag exist?
8: if an object slot doesn't have this flag then its position won't be saved in a savegame file when you save the game.
However, this is not the whole truth, because, eg. LITTLE_BEETLE doesn't have the flag, in spite of (naturally) the positions of the little beetles will be saved in the savegames.
16: Paolone says maybe this flag means the slot is a 'Moveable of the ground'. Well, flying and swimming creatures will also have the flag, so I'd rather say if the object slot having this flag moves then its position will be defined compared to the floor. (Or maybe it means the gravitation will be calculated at these objects?)
32: almost all the slots have this flag, but mostly the technical objects (LARA_SKIN, MIP objects, AI objects, GUN_FLASH etc.) don't have. So I think the flag means the slots with the flag are 'real' Moveable objects. (Though LITTLE_BEETLE, BRIDGE objects and MINE also don't have the flag.)
64: Paolone says maybe this flag has something to do with collisions. I don't know what to say. I'd rather say this flag is on if the (dis)appearance, working, animation, collision (?) of the object slot is NOT controlled in a hardcoded way.
However, this is not the whole truth, because, eg. some 'hardcoded type' object slots will have the flag (FALLING_BLOCK, WRAITH, SMASHABLE_BIKE_FLOOR, PUZZLE_HOLE etc).
128: I didn't find this flag in any of the slots. Maybe doesn't the flag exist?
256: only water creatures (see: CROCODILE, HAMMERHEAD) have this flag - so they can move not (only) in 'air rooms' but in water/quicksand rooms (as well).
512: I think this flag means the object slot will look in the game as it looks in the Room Editor. I mean they don't have the flag because the condition isn't true about them: Lara is an 'ugly mesh pile' in Room Editor, nullmesh effects are 'small red pyramids' there, the meshes of some object (RAISING_BLOCK, EXPANDING_PLATFORM, TEETH_SPIKES, JOBY_SPIKES) will be extended in the game, PLANET_EFFECT will glow in the game. (Self-created objects - such as FLARE_ITEM, CROSSBOW_BOLT, GRENADE - will also not have the flag.)
1024: I think this flag has something to do with targeting and/or hitting. I mean the creatures can be killed in the 'usual way' (i.e. can be aimed in the automatic way and can be killed by pistols) have this flag. But DEMIGOD2 or 3 don't have the flag. But eg. SPHINX or MUTANT (immortal but can be aimed in the automatic way) also have the flag. But eg. MUMMY or SKELETON (can be killed in the explosive way and can be aimed in the automatic way) don't have the flag. And, on the top of all that, MINE also has the flag.
2048: I think the object slot will have the flag if the slot 'works like a creature, actually, but it's not a usual creature'. I mean LARA_DOUBLE, MUMMY, KNIGHTS_TEMPLAR, ENEMY_JEEP, SPHINX, MUTANT, DEMIGOD1, SENTRY_GUN, SKELETON and HORSEMAN has the flag, and, anyway, MINE too. However, eg. DEMIGOD2, 3 and SETHA don't have the flag.
4096: the immortal creatures (including ENEMY_JEEP and SENTRY_GUN) have this flag. (HORSEMAN also has it. I think because while he's riding the horse he can't be killed.)
8192: I suppose the object slot will have this flag if one or more meshes of the slot can be changed in the game (in a hardcoded way): PLANET_EFFECT will glow, ELEMENT_PUZZLE will look according its OCB and will change when having been filled, Mesh0 of SWITCH_TYPE7 can shatter, the head or the shield of the skeleton can shatter, baddies or the guide has a meshswap.

Notes:

- If an object isn't present in a TR4 file then maybe Flag 1 is not the only one it will not have. I mean, all the creatures will always have only Flag 512 when not being in TR4 (including eg. LITTLE_BEETLE), moreover, some other objects (eg. GAME_PIECE) will do that as well.
- That 'position' of Flag 8 means if the X, Y or Z coordinates of the object will change. So, for example, when the spikes of a TEETH_SPIKES object will jump out and then jump back, then the position of the object will remain the same the same, so the position of the object doesn't need to be saved in the savegame - hence, eg. TEETH_SPIKES doesn't have the flag.
(If you move an object without Flag 8 by an ACTION trigger then the object won't have Flag 8 - though, the changed X-Y-Z position will be saved now.)
- Defining the flags it doesn't matter if how any 'secondary factor' is presented - i.e. for example which skin Lara has, the creature has its meshswap, MIP etc. in the WAD or not etc.
- It's always the actual slot that matters when we're talking about an object. I mean, eg. if I place a SCORPION into an ANIMATING slot to move it like an ANIMATING then the scorpion will drop the flags of SCORPION slot and accept the flags of the ANIMATING slots.

And these are the flags (supposing the given object slot is present in the TR4 file):

1 (1): LITTLE_BEETLE, DARTS, FLAME, LENS_FLARE
33 (32+1): RAISING_BLOCK, EXPANDING_PLATFORM, TEETH_SPIKES, JOBY_SPIKES, some nullmeshes (LOCUST_EMITTER, FLAME_EMITTER, DART_EMITTER, LIGHTING_CONDUCTOR, SMOKE/STEAM_EMITTER, EARTHQUAKE, LIGHT objects, ROPE, TRIGGER_TRIGGERER)
41 (32+8+1): FLARE_ITEM, CROSSBOW_BOLT, GRENADE
121 (64+32+16+8+1): LARA
513 (512+1): HORIZON, BRIDGE objects, the most of the technical objects (LARA_SKIN, LARA_SCREAM, CROSSBOW_ANIM, FLARE_ANIM, LARA_HOLSTERS, HAIR, VEHICLE_EXTRA, SETHA_MIP, WATERSKIN1_1, MEMCARD_LOAD_INV_ITEM, BUBBLES, GUN_FLASH, AI_GUARD, LARA_START_POS, MESHSWAP, BINOCULAR_GRAPHICS etc.)
545 (512+32+1): KEY_HOLE, POLEROPE, WATERFALL, SLICER_DICER, SMASHABLE_BIKE_WALL
553 (512+32+8+1): ROLLINGBALL, PUSHABLE_OBJECT, TWOBLOCK_PLATFORM, all the pickable items (including BINOCULARS_ITEM and COMPASS_ITEM in the inventory at the game start), BURNING_FLOOR, OBELISK, ENEMY_PIECE
569 (512+32+16+8+1): GAME_PIECE
609 (512+64+32+1): all the door types (DOOR_TYPE, PUSHPULL_DOOR, KICK_DOOR, UNDERWATER_DOOR, DOUBLE_DOORS, any TRAPDOOR), the most of the traps (CHAIN, PLOUGH, STARGATE, SPIKEBALL, HAMMER, COG, SQUISHY_BLOCK, BLADE traps), PUZZLE_HOLE, PUZZLE_DONE, the most of the switches (SWITCH_TYPE - except: 7 -, UNDERWATER_SWITCH, TURN_SWITCH, COG_SWITCH, LEVER_SWITCH, JUMP_SWITCH, CROWBAR_SWITCH, PULLEY), SARCOPHAGUS, HORSE, SCALES, FIREROPE, SMASH_OBJECT, WHEEL_OF_FORTUNE, MAPPER
617 (512+64+32+8+1): FALLING_CEILING, FALLING_BLOCK, SMASHABLE_BIKE_FLOOR, JEAN_YVES, SAS_DRAG_BLOKE
633 (512+64+32+16+8+1): MOTORBIKE, JEEP, WRAITH
635 (512+64+32+16+8+2+1): DEMIGOD2, 3
1659 (1024+512+64+32+16+8+2+1): SCORPION, SMALL_SCORPION, TROOPS, BABOON, WILD_BOAR, HARPY, BIG_BEETLE, BAT, DOG, SAS, AHMET
1915 (1024+512+256+64+32+16+8+2+1): CROCODILE, HAMMERHEAD
3585 (2048+1024+512+1): MINE
3707 (2048+1024+512+64+32+16+8+2+1): LARA_DOUBLE
4731 (4096+512+64+32+16+8+2+1): SETHA
6779 (4096+2048+512+64+32+16+8+2+1): MUMMY, KNIGHTS_TEMPLAR, ENEMY_JEEP
7803 (4096+2048+1024+512+64+32+16+8+2+1): SPHINX, MUTANT, DEMIGOD1, SENTRY_GUN
8225 (8192+32+1): PLANET_EFFECT
8737 (8192+512+32+1): ELEMENT_PUZZLE
8801 (8192+512+64+32+1): SWITCH_TYPE7
9851 (8192+1024+512+64+32+16+8+2+1): BADDY_1, 2
12923 (8192+4096+512+64+32+16+8+2+1): GUIDE, VON_CROY
14971 (8192+4096+2048+512+64+32+16+8+2+1): SKELETON
15995 (8192+4096+2048+1024+512+64+32+16+8+2+1): HORSEMAN

But be careful with the new, TRNG object slots (that were transported into the Level Editor by Paolone) because they could have weird flags. - For example, some of them won't have Flag 1 even when they are present in the TR4 file:

33 (32+1): TIGHT_ROPE, FISH_EMITTER
96 (64+32): PANEL_BORDER
104 (64+32+8): MOTOR_BOAT
513 (512+1): PARALLEL_BARS, HYDRA_MISSILE, FROG_MAN_HARPOON
553 (512+32+8+1): SUB_MARINE_MISSILE
608 (512+64+32): LASER_HEAD_BASE/TENTACLE
617 (512+64+32+8+1): KAYAK
891 (512+256+64+32+16+8+2+1): FROG_MAN
7803 (4096+2048+1024+512+64+32+16+8+2+1): HYDRA
8059 (4096+2048+1024+512+256+64+32+16+8+2+1): ENEMY_SUB_MARINE
11897 (8192+2048+1024+512+64+32+16+8+1): LASER_HEAD

Attention! This overview is not all-embracing so not all the object slots have been studied.

Case A: forcing these values here will result nothing or will be buggy. (It doesn't mean you can't solve a problem - when a flag is missing - in some other way. For example, HORSE should be 617 and not 609, i.e. Flag 8 is missing here, the horse may disappear below the horseman riding it when loading a savegame. Activate an A60 and the game will save the coordinates of the horse.)
Case B: because you can't use Case A now, then Case B can be used only in very special cases. For example Value 1659 means an 'if the object slot is SCORPION, SMALL_SCORPION, TROOPS, BABOON, WILD_BOAR, HARPY, BIG_BEETLE, BAT, DOG, SAS or AHMET' condition - though there are other methods to identify a slot (see eg. GT_COLLIDE_SLOT type GlobalTriggers).

FootStep (Shadow below Lara or enemies) (Short)
This field contains the size of the shadow below Lara or other creatures. (I mean, during the moves, the shadow will change, naturally. So this field contains the maximum size of the shadow in 'the default state'. I think this state is Animation103 - 'standing and still' - at Lara, with Value 160. To understand this 160, you must know that 1024 is - approximately - 1 square now.)

Case A: for example, if you put a bigger enemy in BADDY_1 slot then you need a bigger shadow below him - so force the proper value in this field.
(Or - thanks Titak for the information - please note that the actual value of the collision box and the size of the shadow are related. So try a bigger box for a bigger shadow or remove the box if you don't want a shadow. - Though maybe those operations will not always be successful to change the shadow.
So you may use this Case A only if you can't change the shadow the way you want by changing the collision box - or if you want a shadow size that is not related to the collision box.)
Case B: this Case B could be useful, eg. if you want to study if an enemy is too big or not. (I.e. a bigger creature has a bigger shadow.) So, for example a 'Value is smaller than 250' means an 'if the size of the creature is average or little' condition.

HP. Max Vitality at start (Short)
This field contains the maximum life points of Lara or other creatures.

Case A: these values cannot be forced. However, if you want to adjust a new maximum life energy for a creature, then use Enemy Script command.
Case B: this Case B could be useful, eg. if you want to study if an enemy (having all its power) is weak or strong. So, for example a 'Value is smaller than 100' means an 'if the maximum life energy of the creature is relatively low' condition.

Number of Meshes (Short)
This field contains the amount of the meshes of the slot. (For example, the lowest mesh of LARA object is Mesh0 and the highest mesh is Mesh14, so the value here at LARA is 15.)

Case A: it's worth forcing a value here eg. if you want some meshes of all the placed objects of the slot will be invisible from a given moment of the level. - Because:

Forcing 1 - only Mesh0 is visible
Forcing 2 - only Mesh0 and Mesh1 is visible
Forcing 3 - only Mesh0, Mesh1 and Mesh2 is visible
Etc. (Forcing 0 will result nothing if you want all the meshes to be invisible.)

Case B: for example, an object has 26 meshes, but you forced 25 so Mesh25 is invisible. Now Value 25 here is a good condition if you want to study if all the meshes of the objects of the slot are visible or Mesh25 is not visible in the given moment.

Pointer for Collision Procedure (Long)
Honestly, I don't really understand the long value in this field, but I know if that value is 0 then the object won't have the collision.
Please note forcing this 0 is not equal with the 'disabled collision' situation. I mean, if you have a disabled collision at the object then the object may keep its collision under some circumstances. For example, if you want to push/pull a PUSHABLE_OBJECT over a (burning or non-burning) flame or a pickable item then the actual TRNG won't let you (though Lara can walk through the flame or the item), because the pushable will collide with that small object. (It seems some kind of new problem, perhaps will be removed from the next TRNG.)
It doesn't help if you remove the collision box or empty the mesh. Clicking on Clear Body button on the OCB panel of the object will help - but the effect will be removed if you load a savegame. Forcing 0 in this field will have the same effect as if you click on Clear Body button - but, force continuously so you will remove the saving bug. (Please note you can't force continuously if the 'obstacle' is a pickable item, because Lara can't pick up an item if this value is 0. To solve a problem, I think there could be more good choices, this must be one of them: you will force 0 just while Lara's pushing/pulling the pushable over the item, and restore the long value when she's not doing that.)

And one more thing: as an innovation in the actual TRNG, the motorbike has the collision with the objects - but only if they don't have Value 0 in this field.
(Though it is peculiar. I mean, eg. if I turn a pickable item by A13 trigger into invisible, not using Value 0 in this field, then Lara can't pick that up, pushable can be pulled/pushed over it, and motorbike will collide with it.)

Pointer for Draw Extra Procedure (used by jeep, sidecar) (Long)
As Paolone says, this field has a (long) value if the subject of the memory zone is JEEP or MOTORBIKE slot.
However, I don't know what I can do with this value. And I tried but nothing will happen (?) if I force 0 here.

Pointer for Emitter Procedure (Long)
When I tried this field, all the Moveables (except nullmeshes and Lara) produced the same long value (4519424).
The only number I could force here successfully was 0. With 0 in this field, only the emitted effects (eg. the beam of the motorbike headlight) were seeable, the object itself was totally invisible.

Pointer for Initialization Procedure (Long)
Each Moveable has some long value in this field. Whatever that number means it's not worth trying to force to change that.

Pointer for Main Control Procedure (Long)
Another field with a long number for the Moveables. Force 0 here if you want to 'freeze' the animation of the subject slot - though A58 and A59 triggers are more useable tools for that.

Pointer for Special Ceiling Procedure (Long)
I studied more object slots here. But I found a (long) value here only at TWOBLOCK_PLATFORM.
Then I forced 0 here - and nothing happened (?).

Pointer for Special Floor Procedure (Long)
I had similar experiences with this field to the previous one. (This time forcing 0 'kills' the DUMMY trigger below TWOBLOCK_PLATFORM.)

Test Attack Lara (1=attack, 0 =ignore lara) (Short)
I found Value 1 only at BADDY_1 and BADDY_2. So, knowing the name of the field, I suppose this flag means the enemy is able to deflect Lara's bullets. (Though BADDY_1 doesn't use his deflecting animation.)
It's not useful to force 0 or 1 because nothing (?) will happen. That's why it's not worth studying the value of the field by a condition.

Unknown1 (Perhaps distance to enable the MIP version) (Short)
This field is used for enemy and ANIMATING MIP objects. For example, the value of BADDY_2 is 5120 here. It means if the distance between Lara and the baddy is more than 20 squares (because 256=1 square now and 5120=20x256) then the BADDY_2 will be turned into his MIP version - if there is a BADDY_2_MIP object in the WAD.

Case A: use this Case A if you want to force a new value when the enemy will be turned into its MIP version. (In the case of ANIMATING MIP's, use AnimatingMIP Script command instead.) - It is a nice tool if you want to use a trick with two totally different objects: 'if Lara is closer to the object then the object will look as Object A, but if Lara is farther from the object then the object will look as Object B'.
Case B: if you used Case A, then it's worth using this Case B to know which 'MIP distance' is used in the given moment.

Unknown2 (Usually it has value 50) (Short)
This field contains the horizontal distance in which the enemies will detect Lara in front of them when attacking her. (Yes, it's usually 50, and 1024 means 1 square.)
For example, force 1024 in this field at BADDY_1 slot - and BADDY_1 will wield his sword to hit the air in 1 square distance from Lara, without hurting her.
Though I don't know where it could be useful. (I mean, it's not the whole truth. I.e. with that 1024 value an AI_GUARD type BADDY_1 will detect Lara in his post when she comes toward his back only if she is really close to him.)

Unknown3 (It will be copied in Custom_B field of Item structure) (Short)
The values in this field must be some kind of 'creature flags'. I mean Lara, non-creatures, creatures with hardcoded animations (wraith etc.) and creatures not in the TR4 file seem to have Value 10 (Flag 8+2). Baddy, SAS, troops and bat have Value 102 (Flag 64+32+4+2), small scorpion, skeleton, Von Croy or the guide have Value 128 (Flag 128), mummy has Value 170 (Flag 128+32+8+2), dog, hammerhead and the ahmet have Value 341 (Flag 256+64+16+4+1), crocodile, horseman have Value 409 (Flag 256+128+16+8+1), scorpion has Value 512 (Flag 512). - And I studied only some objects now.
I have no idea what those flags are supposed to mean, so I didn't feel I had to dig myself into them to analyze them.
However, it's not worth forcing them, because nothing will happen then.

Unknown4 (Long)
I tried a lot of slots here but whatever I did the value of this field was always 0.

Animation Memory Zone Fields

Absolute Index of first AnimCommand (Short)
You can also find some not too useful fields in Animation Memory Zone and this is one of them. I mean, this field shows a so-called 'absolute index of first AnimCommand'.
However, I don't really understand this value. I mean, for example, studying Animation1 of LARA object, the value here is 18. Either in absolute or in relative meaning, there is only one animation before this animation: Animation0 of LARA. That Animation0 has 6 AnimCommands, so the first AnimCommand index of Animation1 must be 7.
By the way, you can find this value (as 'AnimCommandsInd') in the green window of NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot.

Absolute Index of first State Change (Short)
For example, studying Animation1 of LARA object, the value here is 7. Either in absolute or in relative meaning, there is only one animation before this animation: Animation0 of LARA. That Animation0 has 13 state changes, using 7 State ID's. Each State ID here has a 'change index' from 0 to 6, that's why the 'absolute index of first State Change' in Animation1 is 7. - Though I don't know where this value could be useful.
By the way, you can find this value (as 'StateChangeIndex') in the green window of NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot.

First absolute Frame index (Short)
For example, studying Animation1 of LARA object, the value here is 22. Either in absolute or in relative meaning, there is only one animation before this animation: Animation0 of LARA. That has 22 frames from 0 to 21 - that's why the 'first absolute frame index' in Animation1 is 22 (i.e. this is the absolute index of Frame0 of the animation).
By the way, you can find this value (as 'FrameStart') in the green window of NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot. - See more about it above in 'Frame Now (warning it's an abs value) (Short)' field.

Frame Rate (Byte)
This field contains the FrameRate value (see: WADMerger Animation Editor) of the animation.

Case A: using this Case A, you can force a new FrameRate value for the animation, in the game. (Be careful - some forcing could be buggy.)
Case B: if you used Case A, then it's worth using this Case B to know which FrameRate is used in the given moment.

Frame Size (Byte)
This is not a useful field, because, as Paolone says, the field contains the byte/frame value of the animation.
By the way, you can find this value (as 'FrameSize') in the green window of NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot.

High Accelleration (Short)
This field contains the Accel value (see: WADMerger Animation Editor) of the animation.

Case A: using this Case A, you can force a new Accel value for the animation, in the game.
Case B: if you used Case A, then it's worth using this Case B to know which Accel is used in the given moment.

Last absolute Frame index (Short)
If you understood 'First absolute Frame index (Short)' field, then it's easy to understand the present field:
So, for example if the first frame of the animation (ID0) has 65 absolute ID then the last frame of that animation (eg. ID25) has 90 (65+25) absolute ID. - Maybe it is a useful base in some formulas if you want to define a given (other) frame of an animation.

Low Accelleration (Short)
It is the value you can see in the green window of NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot (as 'AccelerationLO'). It is mostly 0.
I don't know what this value means and where it could be useful.

Next Animation index (Short)
This field contains the Next Animation value (see: WADMerger Animation Editor) of the animation.

Case A: forcing these values is buggy.
Case B: you can't use Case A, so it's not worth using this Case B because the Next Animation value of the given animation is always constant. (Maybe it is if you use a 'random' subject by the 'TRNG Index. Animation Index for Selected Animation Memory (Short)' Savegame Memory Zone field.)

Next Frame index (Short)
This field contains the Next Frame value (see: WADMerger Animation Editor - but this time with the absolute ID of the frame you can find as 'FrameNext' in that green window) of the animation.

Case A: using this Case A, you can force a new Next Frame value for the animation (with absolute frame ID!), in the game.
Case B: if you used Case A, then it's worth using this Case B to know which Next Frame is used in the given moment.

Next High Acceleration (Short)
This value is not the Accel value of the Next Animation of the given animation.
Whatever value this is, you can also (?) find it here: NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot (as 'InertAccelHI' (?)).

Next Low Acceleration (Short)
Whatever value this is, you can also (?) find it here: NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot (as 'InertAccelLO' (?)).

Next Speed (Short)
This value is not the Speed value of the Next Animation of the given animation.
Whatever value this is, you can also (?) find it here: NG Center\Tools\Animation Watcher\Show Present Animations for Current Slot (as 'InertSpeed' (?)).

Number of Animation Commands (Short)
This field counts the amount of the AnimCommands in the given animation. - For example, Animation0 of LARA object has AnimCommands with ID 0, 1, 2, 3, 4 and 5 so the value of the field is 6 now.
Though I don't know where this value could be useful.

Number of State Changes (Short)
This field counts the amount of the State Changes in the given animation - counting every State ID only once. - For example, Animation0 of LARA object has 13 state changes, using 7 State ID's so the value of the field is 7 now.
Though I don't know where this value could be useful.

Speed (Short)
This field contains the Speed value (see: WADMerger Animation Editor) of the animation.
If you want to know what we are talking about now, then see 'Speed in horizontal movements (Short)' field above. - But this time:

- the present field works with a given animation and not always the actual animation,
- now you don't need continuous forcing,
- this time probably you can't use the 'hardcoded animations' (but can the other ones).

State Id (Short)
This field contains the StateID value (see: WADMerger Animation Editor) of the animation.
If you want to know what we are talking about now, then see 'State Id Now (Short)' field above. - But this time the present field works with a given animation and not always the actual animation.

Unknown1 (Short)
Unknown2 (Short)
I don't know what these fields are (but you can also find them in that green window).

Inventory Memory Zone fields

Distance of Cam. {Little values bigger items and vice-versa) (Short)
Let's suppose your eye is a camera that is looking at the item in the inventory. This time the item is a big medipack and you can see it 2 centimeters height if you type Value X in this field.
But how should you know what that value is?
Well, imagine that 'eye-camera' as a camera that is placed in the ground, in the game. If the big medipack is X distance from that, then the eye-camera will see the medipack 2 centimeters height.
In this Value X 1024 means (supposedly) 1 square distance.

Note:
A lot of pickable objects (key, puzzle item combo etc.) have their own Script entries in which you can adjust this distance by a hexadecimal value. So force a value into this field only if the pickable item (eg. ammo, medipack, weapon etc.) has no Scipt entry to define its inventory coordinates there.

Slot of Mesh to show in Inventory (Short)
This field contains the ID of the subject inventory item - see the ID's in Slot Moveables indices list, in NG Center\Reference. (Forcing another slot ID here - to see another item at the item name in the inventory and not the item Lara picked up - is buggy. And useless.)

String index of Name (Short)
When you want to rename a pickable item having a Script entry (key, puzzle item combo etc.) then you type that new name in that Script entry.
But if you want to rename a pickable item not having a Script entry (eg. ammo, medipack, weapon etc.) then force a string ID here in which you typed the new name. (That string must be an unused string in [Strings] section of English.txt.)

Top Border in 2d plane. (Negative numbers move up the item) (Short)
This field contains the vertical coordinate of the item in the inventory, in the line of items.
If you want to understand that coordinate, then let's define BLEP ('Blue Line End Point') first: open the item in Animation Editor of WADMerger. See the item there in 'Animation0' state (at Frame0). The BLEP of this item is where that long, blue line ends at the item.
If the value of this field is 0 that means the BLEP of the item is (approximately?) halfway between the upper edge of the screen and the name of the item.

If you force a negative number here then the object will move so many pixels upwards, compared to Level 0.
If you force a positive number here then the object will move so many pixels downwards, compared to Level 0.

Note:
In the case of pickable items having a Script entry, use that Script entry instead of this field.

Type Flags. (4 = USE, 32 = EXAMINE, $1000 = LOAD ect) (Short)
This field contains the command and other text types (except the name of the item) typed below the item in the inventory, using flags to define the text types.
If you want to know the flags then know them in Paolone's variables tutorial. I mean I don't really want to take care about the flags, because:

- It is disturbing that the values don't always have the same result. For example, forcing Flag 8 at BIGMEDI_ITEM, there won't be command (!) below the item, but forcing Flag 8 at CROSSBOW_ITEM, COMBINE command will appear there.
- It is useless to force any flag to an item. So, for example, if you try to force Flag 32 (the flag of EXAMINE text) to a PUZZLE_ITEM, that doesn't result the PUZZLE_ITEM becomes an EXAMINE item.

Unknown. (It may be only 1 or -1) (Long)
I don't know the meaning of this field.

View Flags. (2 = turn endless, $4000 = usable?) (Short)
This field defines how the object will act when is just selected in the inventory. - The used flags (values) from The Last Revelation:

2 ($0002): the selected item is rotating around the vertical median axis of the screen (that is just going through the BLEP of the item)
10=8+2 ($000A): this flag is equals with Flag 2 except you must use it if Lara uses a crowbar to get the item so the item has an 'I've been pried off the wall so I'm falling down now' animation. (My experience with some other objects: using this flag, the object will be a bit lower in the right bottom corner of the screen just after Lara has picked up the item.)

And some special flags (using them, the item will work in the inventory just as with Flag 2, but not using them, maybe the item cannot be placed into its 'special receptacle'):

8194=8192+2 ($2002): PUZZLE_ITEM8 Mine Detonator
16386=16384+2 ($4002): PICKUP_ITEM2 Jerrycan
32770=32768+2 ($8002): PICKUP_ITEM1 Bag of Sand

If you don't add Flag 2 (so if you use Flag 0 instead Flag 2, Flag 8 instead of Flag 10 etc.) then the selected item will be still in the inventory (as if it were non-selected).

Note:
In the case of pickable items having a Script entry, use that Script entry instead of forcing a value into this field.

X Facing about the cam view on X Axis (Short)
Y Facing about the cam view on Y Axis (Short)
Z Facing about the cam view on Z Axis (Short)
These fields define the X, Y and Z position of the item in the inventory.
Please note when you rotate the item around Axis X, Y or Z then the other axes will be rotated with the item together. That's why it's not easy to define the position of the axes. That's why I'll define the position of the axes only in one position, i.e. in the default state of the object.

The definition of 'the default state': see the item in Animation Editor, in 'Animation0' state (at Frame0). The item is at one end of the long, blue line. Imagine a camera at the other end of the blue line. The longitudinal axis of the camera is the blue line. - Now the camera sees the item in the default state of the item.
If I say the camera is your eye and the item you can see in the default state now is the item in the inventory then you know what I'm talking about.
So, I can define the axes now:

- Axis X position (in the default state of the object): it's the vertical axis of the object. It's going through the BLEP of the object.
- Axis Y position (in the default state of the object): it's one of the horizontal axes of the object: perpendicular to the longitudinal axis of the camera. It's going through the BLEP of the object.
- Axis Z position (in the default state of the object): it's one of the horizontal axes of the object: the extended longitudinal axis of the camera.

When you rotate the item around one of the axes then a whole circle (i.e. 360 degrees) means Value 65535 (i.e. $FFFF). So, for example, if you rotated them item 90 degrees from the default state, then the value is 16384 ($4000), 180 degrees is 32768 ($8000) and 270 degrees is 49152 ($C0000).
(The values must be meant as clockwise rotations, seeing the axes - in the default state of the item - this way:

- Axis X: from above
- Axis Y: from the left hand side of the camera
- Axis Z: from the camera.)

Note:
In the case of pickable items having a Script entry, use that Script entry instead of forcing a value into this field.

Addendum

About: The values of a placed object from any Moveable object slot in Custom_A, B, C or D fields (Item Memory Zone).

So some time has passed by since I've created the tutorial, so now I examined all the (non-Lara) Moveable object slots (that can have placeable objects) about what their values are in Custom_A, B, C and D fields of Item Memory Zone.

Abbreviation:
A=Custom_A field
B=Custom_B field
C=Custom_C field
D=Custom_D field

ENEMY_JEEP
A: when the jeep starts from an AI_FOLLOW object then a counter will start from 0. There is a point when the game 'jerks' the moving jeep into the next AI_FOLLOW. Reaching that point, the counter stops counting up, and starts a fast counting down, so the counter will be 0 again when the jeep is at that new AI_FOLLOW. (From the start to the 'jerking point', I think 1024 means 1 square. So eg. if the value is 4096 before the 'jerking point' that means the moving jeep has traveled 4 squares from the latest AI_FOLLOW.)
B: none
C: if the jeep is at an AI_FOLLOW then a frame counter is running here, from 149 to 0, again and again. If it reaches 0 then the jeep shoots a grenade. (Note: if the jeep starts from an AI_FOLLOW, then the counter won't stop till reaches 0.)
D: the actual AI_FOLLOW ID (typed in the OCB window of the AI_FOLLOW) is in here (at which the jeep is or for which the jeep is heading).

GUIDE
A, C: none
B: I think it has something to do with the 'state of his torch'. I mean when he starts, then the value is 0. When he reaches for the torch to grab it then the value becomes 1 (and remains that). A bit later, when he ignites the torch (successfully, at the second attempt) then the value becomes 2 (and remains that).
D: the actual AI_FOLLOW ID (typed in the OCB window of the AI_FOLLOW) is in here (at which the guide is or for which the guide is heading). (Moreover, if he is performing a task at an AI_FOLLOW, then the ID turns into the ID of the next AI_FOLLOW. - Note: if this performance happens at the last AI_FOLLOW, then +1 will be added, but only if that task is not the disappearance.)

BADDY_1, BADDY_2
A, D: none
B: -1: still not active. Other number: the room game (tomb) index where he just is (dead or alive).
C: his actual Uzi ammo (default BADDY_1 value even before getting alive: 24). Pulling the trigger once means minus 7 bullets. (So, the default BADDY_1 is able to shoot four times at Lara before his ammo is running out: 24 - 17 - 10 - 3 - -4.)

SETHA
A: a frame counter runs here from 0 to an end value, several times. Each sequence is a shooting sequence, so if the value starts running from 0 that means SETHA has just started a shooting operation against Lara. (I think three operations exist, they are 151, 161 and 199 frames long. If the counter stops at the end value - 151, 161 or 199 - then the counter value won't change till starting the next shooting operation.)
B, C, D: none

SPHINX
A, B: none
C: it contains the actual X horizontal coordinate (i.e. the actual distance from the north edge of the Room Editor Window) of the living SPHINX (in 'units', i.e. Value 1024 means 1 square distance).
D: it contains the actual Z horizontal coordinate (i.e. the actual distance from the west edge of the Room Editor Window) of the living SPHINX (in 'units', i.e. Value 1024 means 1 square distance).

CROCODILE
A, C, D: none
B: if he's at an AI_GUARD object then he moves his tail to left or right. When he is just moving it leftwards, then the value is -12. Moving it rightwards, the value is 12. (Note: disturbing him when the value is not 0 he leaves his post, keeping the actual value 'forever'.)

HORSEMAN
A: -1: still not active. Other number: active or dead. (This 'other number' is probably 15, but maybe depends on the amount of the AI_FOLLOW objects in the level.)
B: 0: not on the horse (either still not or fallen down), 1: on the horse (or just getting on it).
C: none
D: it's the ID of his AI_FOLLOW written here. (If there are other horse-horseman couples in the level then the horseman will be riding to rest to their AI_FOLLOW's as well. In these cases this field accepts the ID of those AI_FOLLOW's when the horseman is heading for there, and, after that it keeps that value until he's riding for another rest to another AI_FOLLOW.)

MUTANT
A, B, D: none
C: some moments after the mutant has come to life, a frame counter starts here from 0. It will stop when reaching 600. Until that, the mutant won't care about Lara, only will be raging. Some moment after the counter has reached 600, the value jumps to 999 suddenly (and remains that) - and now the mutant notices Lara at last.

BABOON_NORMAL, BABOON_INV, BABOON_SILENT
A: the horizontal coordinate is contained here in which the baboon is placed in the Room Editor. Each square distance from the west edge of the Room Editor Window means +256 value and each square distance from the north edge of the Room Editor Window means +1 value. (So, eg. if the baboon is in the 'most northwestern' square of the level, then the value is 257=256+1.)
B, D: none
C: 0: still not active or dead, 1: alive.

HARPY
A: the shooting operation frame counter (see: SETHA) runs here from 0 to 118. (After shooting, the counter turns back into 0.)
B, C, D: none

LITTLE_BEETLE
A: the value is 1 if the beetles will be emitted from the floor (i.e. with +1000 OCB value).
B: the value is 2 if the beetles will be emitted from the ceiling (i.e. with +2000 OCB value).
C: the value is 4 if the beetles will be emitted from the wall (i.e. with +4000 OCB value). This value is not constant, will be decreased by 1 and 1 again and again, till 0. (I think 1 will be subtracted if a smaller or bigger 'bunch' of beetles is just starting being emitted from the wall. When the last 'bunch' comes out, then the value will turn from 1 to 0.)
D: none

WRAITH1, WRAITH2, WRAITH3
A: none
B: if the fire wraith collides with Lara then a newer value will be added to the actual value of this field. The starting value is 0 and the 'newer values' are about 3000 or less. (The 'newer value' is bigger if the collision is 'harder'. I think, at least.) If the field value is less than (about?) 10000 then the wraith won't ignite Lara at the collision. But, if bigger, then each (either smaller or bigger) collision ignites her. (At the same time, this field is a count-downing frame counter. So, if the value is not 0, but there is no collision in this moment, then the field value will decrease, 1 per frame.) - When the wraith dies in the water, the value turns into -2 at once. (If the wraith is not a fire wraith then only this last '-2' step happens with him.)
C: I'm not sure but I think this is a frame counter that counts the two sequences of the wraith:

- from 0 to a bigger positive value: the wraith (seeing him from above) is just rotating clockwise,
- from 0 to a bigger negative value: the wraith (seeing him from above) is just rotating anti-clockwise.

Usually the game doesn't seem to let the counter step over 1000, so the wraith always change his direction before 1000 frames (or sooner, or much sooner). Except: if the wraith starts circling around Lara fast (always clockwise?), with less and less radius (because eg. Lara's burning?).
(Note: the last value will be 'frozen', if
- the wraith dies, or
- probably, for a shorter/longer time, if Lara is too fast - try it, fleeing from the wraith in DOZY mode -, and the game can't - ? - count a correct radius.)
D: You can find positive and negative values in this field. It seems an increasing positive value if the wraith is going farther from Lara and seems an increasing (i.e. numbers farther from zero come after each other) negative value if the wraith is coming closer to her. (Probably the bigger numbers mean a bigger radius for the wraith. Usually the biggest positive/negative numbers are between 300 and 400.) - When the wraith dies the value will be 'frozen'.
(Note: till the first collision between them, I think these rules are not quite true. For example, it seems the signs are inverted till the wraith attacks at the second time after the first collision.)

AHMET
A: it contains the west-east row of squares in which the AHMET is placed. (So, for example, if it is the 16th row of squares from the north edge of Room Editor Window then the value is 16.)
B, D: none
C: it contains the north-south row of squares in which the AHMET is placed. (So, for example, if it is the 7th row of squares from the west edge of Room Editor Window then the value is 7.)

WHEEL_OF_FORTUNE
A, B, C, D: it seems all the four fields do the same:
After the 'wheel' having been rolled, the field value is always 0 or -32768 but when the 'wheel' is just rolling, positive or negative bits or aggregated bits (256, 512, -384, 4096, -20864 etc.) appear and disappear fast in the field one after another. (I suppose the bit value and sign depends on a plate being just black or white and in which angle being just rotated.)

SCALES
A, C, D: none
B: 0: empty (not filled before or reset) or filled by the right amount of water, 1: filled by the wrong amount of water

FALLING_BLOCK
A: when it starts shivering (due to Lara stepping on it but not due to triggering) then the value jumps from 0 to 60 and a frame counter starts counting down. Reaching 1 (keeping the value) the block will fall down.
B, C, D: none

TRAPDOORs
A, B: none
C: 0: opened/opening/closing, 1: closed
D: see this value as a hexadecimal value. For example, $504A. Split it into two parts: $50 and $4A. Turn them into decimal values: $50=80 and $4A=74. Now 80 is the tomb (game) index of the room just above the portal in which the trapdoor is placed and 74 is the tomb (game) index of the room in which the trapdoor is placed. (Note: the value is 0 if the trapdoor is not in the right place, i.e. not in a vertical portal between rooms.) - Thanks sapper for the information.

ROLLINGBALL
A: the game calculates here how many length units the moving rollingball must 'travel' in the north or south direction (Room Editor facing) in the given moment, until that stops. (Negative numbers= moving northwards, positive numbers= moving southwards.) I think (approximately?) 512 length units is 1 square now. (Naturally, the bigger the number is the more the speed of the ball is.) - Don't forget: the length will be calculated again and again, in every moment, according to the actual speed and direction.
B: the horizontal 'travel' of the moving rollingball eastwards (positive numbers) or westwards (negative numbers), with the same units as above.
C: 0: the ball is on land, 1: the ball is in water (with OCB=32).
D: none

TEETH_SPIKES
A: values are changing here when the spikes are moving. Crucial values: 1024 when the spikes are totally drawn back (even if they haven't been activated), and 0 if they are totally extended.
B: values are changing here when the spikes are moving. Crucial values: 0 when the spikes are totally drawn back (even if they haven't been activated), and 5120 if they are totally extended.
C: the spikes are 'bouncing' when being extended so they reach 'Position 0' (see Custom_A value) twice during one extension. When they reach Position 0 at the second time, then a frame counter will start. It's 64 now and counts down. The spikes will be drawn back, and remains there until the counter reaches 0. Now the spikes jump out again.
D: none

JOBY_SPIKES
A: a counter starts from 0 (in an increasing exponential way) when the spike has been triggered. It stops at 4149 - I think this is the moment when the speed of rotation reaches its maximum (very soon, the spike is only a bit expanded now).
(Note: it is very interesting, but the sign of the counter will be inverted and the counter will stop at -4135 if the frame/second rate of the game is just - relatively - low.)
B: a counter (it seems Value 3 changes at each frame) starts from 0 when the spike has been triggered. It stops at 6303 - I think this is the moment when the expansion of the spike reaches its maximum. (So eg. forcing a constant Value 3150 here the length of the spike will be standard, and the expansion of the spike will be the 50 % of the maximum size, because this is the size that the spike will reach at Value 3150=approximately 6303/2.)
C: sometimes I find Value 1 in this field and not 0. But I can't find any logic in that. (I.e. when I place a spike then convert the Script then that spike will have that 1.)
D: 6301 the default value - it is the length of the maximal extension, in which probably 1024 means 1 square. (Naturally other Custom_D field value means other Custom_B field maximum value automatically.)

SLICER_DICER
A: it contains the X horizontal coordinate (i.e. the distance from the north edge of the Room Editor Window) in which this trap is placed. The values start from 4. Each square is 4 values long and the coordinate is calculated at the end of trap that faces south just when it has been placed. (So if you place a trap on one of the northest squares then the values could be between 4 and 8 on that square. The concrete value will be 8 - because this is the value at the south end of the square and the trap south end touches the square south end now. If you rotate the trap by 45 degrees then the value will be 7, and after newer 45 degrees that will be 6 etc.)
B: it contains the vertical coordinate in which this trap is placed. Each value means a distance in clicks from its Level 0. This Level 0 is at Floor=-18 level. Negative values are above Level 0, positive values are below it.
C: it contains the Z horizontal coordinate (i.e. the distance from the west edge of the Room Editor Window) in which this trap is placed. The values start from 4. Each square is 4 values long and the coordinate is calculated at the end of trap that faces south just when it has been placed.
D: the default value is 50. (I don't know what it is because nothing will happen if I try to force another value here.)

CHAIN
A: 0: the chain is not active, 1920: the chain is active. (I suppose there is some other meaning in Custom_A, B, C or D field for this kind of strange constant values with traps as this 1920, for example. Maybe is this the maximum length of the swinging of the chain? Or some kind of bitcode of a feature? I don't know, nothing will happen if I try to force another value here: the game will overwrite it with the original values - even if I force the value by a GT_ALWAYS GlobalTrigger -, i.e. I can't examine, for example, if a given, less value means a shorter length or not.
So all we can do is to use these values in a basic way. So, because this time the chain will accept 1920 only if it is active, that's why this 0/1920 couple is a good possibility for a deactive/active condition.)
B, C: none
D: 0: the chain hasn't been activated before, 25: the chain is active, or deactive but has been activated at least once.

PLOUGH
A: 0: the plough is not active, -4096: the plough is active.
B: 0: the plough is not active, 3: the plough is active.
C: none
D: 0: the plough hasn't been activated before, 50: the plough is active, or deactive but has been activated at least once.

STARGATE
A: 0: the stargate is not active, -18944: the stargate is active.
B: 0: the stargate is not active, 877: the stargate is active.
C: none
D: 0: the stargate hasn't been activated before, 50: the stargate is active, or deactive but has been activated at least once.

HAMMER
A: 0: deactive, or ascending, or has just (almost) finished the shivering after striking, 2016: just striking or the first part of shivering after striking
B: none
C: 0: the hammer (active or not) is just in the starting (highest) position, 60: the hammer is active, or deactive but has been activated at least once (except in both cases: if it is just in the starting position). (This time there is an effect if you force a number here continuously, but it's just disturbing the working of the hammer.)
D: 0: the hammer hasn't been activated before, 150: the hammer is active, or deactive but has been activated at least once.

BURNING_FLOOR
A: a counter starts from 0 (Value 4/frame) when the floor starts firing (some short moments after the flaming torch has been landed on it). When the fires reach their maximal intensity then the counter will stop (at 255). A bit later, when the fires start extinguishing then the counter starts again from 255, counting down (Value 4/frame). When the fires are almost (!) totally extinguished, the counter stops at 2, and remains that.
B: it's almost the same as Custom_A field. But this time it counts Value 3/frame down, i.e. it reaches Value 2 later. (I.e. when the counter stops at 2 that will be closer to the total extinguishing than with Custom_A field.) (And one more thing: it starts the counting-up from 0 a bit later, when the fires are a bit burning.)
C: this is the same again, but this time the counter counts Value 2/frame down, so reaches Value 2, actually, exactly at the total extinguishing. (And one more thing: it counts up Value 8/frame that's why it starts from 0 when the fires are a bit burning - but maybe a bit later, compared to Custom_B field.)
D: it's a frame counter. It starts running from 0 when the floor starts firing, and stops at 450 (and remains that) when the fires start extinguishing.

SPIKEBALL
A: -2048: the moment when the double doors of the spikeball are opening or if the knives of the spikeball are extended, 0: in any other cases.
B: 127: the moment when the double doors of the spikeball are opening or if the knives of the spikeball are extended, 0: in any other cases.
C: none
D: 0: the spikeball hasn't been activated before, 50: the knives of the spikeball are extended or the spikeball is antitriggered, 150: the spikeball is falling down or has been fallen down but the knives aren't still extended.

FLAME_EMITTER (only blowing a horizontal or vertical flame)
A: a frame counter starts from a bigger value to 0, then another frame counter starts from a bigger value to 0, etc. This 'bigger value' seems random (each sequence has its own one), chosen from an interval. (The low and the high limit values of the interval depend on which number is typed in the OCB window of the flame.) The first 'bigger value' is in the field before the fire has been triggered. If that has been triggered, the counter will start. If the counter reaches 0 (and remains 0), then the flame will start being blown. When the flame starts stopping being blown then another 'bigger value' appears on the field, and the counter starts at once. The flame stops being blown before the counter reaches 0. If it reaches 0 then the flame will start being blown again etc. (Antitriggering means a pause in the counter. Triggering the flame again, the counter restarts from the value where it was interrupted.)
B: when the emitter starts blowing a flame, then the value starts running from 0 to -8192. When it starts stopping blowing a flame, then the value starts running from -8192 to 0. - It's the actual length of the flown flame. (-8192=2 squares long.) (Antitriggering the flame, the actual value will be 'frozen' in the field.)
C: it's 256, even if the emitter hasn't been activated before. When the emitter starts blowing, then a counter (Value 8/frame) will count down to 0. When the emitter starts stopping blowing, then it counts back (Value 8/frame) from 0 to 256. (Antitriggering means a pause in the counter.)
D: the starting value is 0. When the emitter starts blowing the flame then it jumps to a bigger value, and a frame counter starts from this value to 0: it is 0 when the emitter (almost) stopped blowing the flame. Then the sequence will be repeated. (Each sequence has another value, in a random way, because each flowing operation has a different length.) (Antitriggering means a pause in the counter.)

FLAME_EMITTER2 (only with negative OCB number)
A: if you use it to trigger a flipmap (see the Scales-puzzle from 'Temple of Horus'): 0: flipmap isn't triggered, 1: flipmap is triggered. (The value won't be affected if you trigger/antitrigger the flipmap in the 'usual ways'.)
If you use it to divert the lightning (see the special Lightning conductor-setup from the 'Street Bazaar'): 1: the pushable object is pushed/pulled to the special place to divert the lightning, 0: before that.
B, C, D: none

FLAME_EMITTER3
A: as flames: when the flame object is triggered then the Value 0 will jump to 11 (or 10) and as a frame counter, it counts down to 0 - and the cycle will be repeated again and again. I think each burst of flame is attached to one number, and if that number shows up in the field than its burst of flame will be burst. (Antitriggering means a pause in the counter.)
B: as flames: when the flame object is triggered then numbers with one or two digits will show up here one after the other. For example: 59, 62, 54, 3, 16, 45 etc. I think they are codebits for which bursts are burst in the given moment. (Antitriggering means a pause in the counter.)
C: as electric arches towards ANIMATING3 objects (OCB=3): Custom_D field value minus the two ANIMATING3 objects for the setup.
D: as electric arches towards ANIMATING3 objects (OCB=3): the amount of the placed Moveable objects (according to the TXT file of the level in graphics\wads folder), minus Lara.

FIREROPE
A, C: none
B: two sequences run here. One from 1 to 32 and the other one from 0 to 16. The default value is 0 that will jump to 1 when the rope catches fire. The first sequence starts increasing. (+1 per unit. One unit is more frames now.) Some moments after it has stopped at 32, it jumps to 0 (when the rope starts crumbling), and the second sequence (a frame counter) starts counting the time while the flaming rope is crumbling (that ends at Value 16).
D: the default value is 0. A frame counter starts here from 150 when the rope catches fire. Reaching 0, the rope starts crumbling.

TWOBLOCK_PLATFORM
A: usually there's a constant value here that doesn't mean too much. But, if the platform will descend half a click if Lara steps on it, then the point is this:
The number here means the default position compared to Floor Level 0. ("Default": the position if Lara is not on the platform.) 1024=1 square=4 clicks. Negative numbers are above Level 0. So eg. -1536 means the default position of the platform is 1,5 square (6 clicks) above Level 0.
- Force any number here that means a higher position for the platform. Which causes the platform will be ascending to that position right away, when triggered. That ascended position will be the new, modified "default position". (So eg. if you force -2048 when the "original" default value is -1536 then the platform will ascend 2 clicks right away, when triggered, and, after that, that will descend half a click when Lara steps on it. If Lara gets off that then the platform will ascend half a click, as usual.)
- Force any number here that means a lower position for the platform. Which causes the platform will do nothing when triggered. But if Lara steps on the platform after that, then the platform will descend to the forced position - and the usual half a click after that. (So eg. if you force -1024 when the "original" default value is -1536 then the platform will descend 2,5 clicks, when Lara steps on it. If Lara gets off that then the platform will ascend half a click, as usual.) If Lara gets off the platform before that reaches the forced position then the platform will be "frozen" in the actual position but continues descending when Lara steps on that again.
B: if it will descend half a click if Lara steps on it: 1: the platform is in the base (ascended) position, -1: the platform is in the descended position. (Values will be refreshed only at new positions.)
(This 1 is a constant value with the other types of the platform, including an elevator.)
C, D: none

RAISING_BLOCK1, RAISING_BLOCK2
A, D: none
B: activating the block, a counter starts here from 0. If the block is totally ascended, then the counter will stop at 4096. The value remains that, but when antitriggering the block, the counter will run back to 0. (So 4096 means '1 square high' with BLOCK1 but '2 squares high' with BLOCK2.)
C: 0: the block is totally descended, 1: in any other cases.

EXPANDING_PLATFORM
A, D: none
B: activating the platform, a counter starts here from 0. If the platform is totally expanded, then the counter will stop at 4096. The value remains that, but when antitriggering the platform, the counter will run back to 0. (So 4096 means 'expanded the distance of 1 square'.)
C: 0: the platform is totally drawn back, 1: in any other cases.

SQUISHY_BLOCK2
A: activating the block, the level starts shaking, and a frame counter starts from 0. Reaching Value 60, the shaking and the counter stops (and remains 60), and the block falls down.
B, C, D: none

PUSHABLE_OBJECTs
A: I think this value is a horizontal position from a west-east line (as a base), because when Lara's moving the pushable in a north-south direction, the value jumps 1024 forth or back. But not always. And sometimes (!) the value also jumps so much when she's moving it in a west-east direction. And, top of all that some squares has more values, depending on from which direction Lara will move the pushable there. (The value of the square - whereto the move just happens - will be refreshed in the field when Lara starts moving the pushable. The default value - so if Lara hasn't moved that pushable at all - is always 0.)
B, D: none
C: the same thing as above but this time the game counts west-east moves from a north-south base.

SENTRY_GUN
A: Value 1 and 2 will change with each other fast if the gun is shooting bullets. 0: in any other cases (even if it's throwing flames).
B: There is always a 768 (this is the starting value) or a -768 value in this field (so even if the gun isn't activated or has been exploded). It depends on in which direction the radar of the gun is turned. If it is turned exactly to the gun then the value turns into 768, or, if it is turned exactly in the other direction then the value turns into -768.
C: there is a strange counter in this field. I.e. if the gun starts shooting bullets at Lara then it starts increasing (per frame) this kind of 'two steps ahead, one step back' way: 0, 224, 192, 416, 384, 608 etc. (I suppose it's 'two sequences is one', i.e. 192, 384 etc. is a sequence when Custom_A field is 1, and 224, 416 etc. is a sequence when Custom_A field is 2.) When it reaches 6112 it can't increase any more, just repeats the two last numbers: 5952, 5920, 5888, 6112, 6080, 6112, 6080, 6112, 6080, 6112 etc. When it stops shooting (including when it is throwing flames on Lara) then the counter starts counting down (Value 32/frame) and stops if it reaches 0 again - or starts increasing again, if the gun starts shooting at her again.
D: none

MINE (only to blow it up by triggers, i.e. if OCB=1)
A: when a trigger ignites the mine then a frame counter starts from 0. If it reaches 150 (and remains that) the mine will explode.
B, C, D: none

OBELISK
A, B, C: none
D: a frame counter runs here from 0 to 347 (and remains that) while the electric arch (see the obelisk-puzzle in 'The Great Hypostyle Hall') is coming from the obelisk. (It's about 260-270 when the ANIMATING3 shatters.)

FLOOR_4BLADE, ROOF_4BLADE
A: 30: floor blades move upwards, roof blades move downwards (both the first movement and when the blades will clap together), 0: in any other cases.
B, C: none
D: from 0, the value becomes 20 when the floor blades (moving upwards) or the roof blades (moving downwards) stop first, and becomes 200 when they (moving up/downwards more) clap together. (It remains 200, and repeats the sequence at newer activations: 20-200, 20-200 etc.)

BIRD_BLADE
A: 0: inactive/just opening, 6: just closing.
B, C: none
D: 0: the blade hasn't been activated before, 100: the blade is active, or deactive but has been activated at least once.

CATWALK_BLADE
A, B, C: none
D: the value is 100 when the blades are just moving, in any other cases it's 0.

MOVING_BLADE
A, B, C: none
D: 0: the blade hasn't been activated before, 50: the blade is active, or deactive but has been activated at least once.

PLINTH_BLADE
A, B, C: none
D: from the start to the final stop the value is 200, in any other cases it's 0.

SETH_BLADE
A: 0: the blades are inactive or the double blades are moving upwards, -1: the double blades are moving downwards, 448: the double blades just hit the ground.
B: -1: the double blades are moving downwards, 0: in any other cases.
C: the (positive or negative) number you typed in the OCB window of the trap shows up in this field. (If you typed a negative number the sign will be inverted in the field now.) When the trap has been activated then a frame counter will start from this value. Reaching 0, the trap starts moving. When the blades have got back to its starting position, then (only if you typed a positive number) that typed number shows up here again, and the counter starts at once again. (Antitriggering means a pause in the counter.)
D: 0: the blade hasn't been activated before, 1000: the blade is active, or deactive but has been activated at least once. (Till the counter of Custom_C field reaches 0 at the very first activation of the trap, the value will remain 0.)

LIGHTNING_CONDUCTOR
A: short frame counters run here again and again if the conductor is active (starting from about a 4-7 interval randomly to 0). One or two frames after the counter has been started, the lightning appears and hits the ground when the counter reaches 0. (Though the value is 0 now you can see the lighting for further some frames.)
B: the default value is 0 but a newer and newer random (maximum three digits long), positive or negative number will show up in this field (till the next lightning) if a newer and newer lightning blasts. I think the numbers mean the coordinate wherefrom the actual lightning comes towards the conductor object.
C: only with OCB=2 (see the special setup in the 'Street Bazaar' level): a constant four digits number is here (eg. 8968). I think it's some kind of code number for the room in which this conductor is placed.
D: only with OCB=2: if you've placed the pushable object to the proper place to divert the lightning, then a frame counter will start running here from 0. It stops at 120 (and remains that) and now the lightning will blast into the conductor with OCB=2 value to crash the ANIMATING8 object.

ELEMENT_PUZZLE
A: 0: the scale is not used, 1: the water/petrol/dirt is poured in the scale, 2: Lara holds the torch to the petrol, 3: the petrol is burning.
B, C, D: none

(PICKABLE OBJECTS)
A, B, C: none
D: 1: the item has just activated a PICKUP trigger, 0: in any other cases.

PUZZLE_HOLEs
A: 1: if Lara is just placing the puzzle item here (including the 'taking it out of the backpack' part), 0: in any other cases.
B, C, D: none

TURN_SWITCH
A: 0: the switch hasn't been used yet, 1: just moving anti-clockwise (and after that), 2: just moving clockwise (and after that).
B: 0: the switch hasn't been used yet or is just being turned, 2: the turning of the switch has just stopped (and after that).
C, D: none

CROWBAR_SWITCH
A: 0: the switch is useable, 1: the switch can't be used any more because a BABOON_NORMAL has been triggered in the same room where the switch is.
B, C, D: none

PULLEY
A: none
B: (see the obelisk-puzzle from 'The Great Hypostyle Hall'): 1: the pulley is forbidden ('Invisible'), 0: the pulley is useable
C: 0: the pulley hasn't been used, 1: the pulley has been used at least once.
D: 1 - standard value, i.e. the number you must type into the OCB window of the pulley.

DOOR_TYPEs (only with COG_SWITCH)
A: it is 0 if Lara isn't moving the switch. Or if she is then a frame counter starts here from 40 that ends at 0 exactly when Lara finishes the switch-using move. (Each switch-using is a 40-0 sequence.) I mean, if the door has ascended too high so that can't ascend all along when Lara is using the switch, then (though Lara's still using the switch) the frame counter will be interrupted and turns into 0.
B, C, D: none

SEQUENCE_DOOR1
A: 0: the door hasn't been opened yet, 1: the door has been opened (and maybe is closed now).
B, C, D: none

SEQUENCE_SWITCH1/2/3
A: 0: the switch isn't pushed in, 1: the switch is pushed in.
B, C, D: none

GOD_HEAD
A: 0: the head hasn't been activated, or has but hasn't been expanded to its maximal size yet, 1: the head is at its maximal size or is being/has been drawn back after that.
B: activating the head, a counter starts here from 0 (to control how long the head has been expanded), in Value 128/frame rate. If the head is totally expanded, then the counter will stop at 4096. The value remains that, but while the head is being drawn back, the counter will run back to 0 (in the same rate).
C: the default value is 0. When the head reaches its maximal size, then a frame counter starts from 210. Reaching 0, the head starts drawing back.
D: none

STATUE_PLINTH (with OCB=0)
A: 0: the PUZZLE_ITEM5 isn't placed on this pedestal, 1: that item is placed here.
B: 1: the inventory has been opened automatically at PUZZLE_ITEM5 (and is still open) when you hit CTRL at this pedestal, 0: in any other cases.
C, D: none

GRENADE (yes, it can be placed! See more about it in the tutorial Pyrotechnics and Flame Emitter Special Effects)
A, C, D: none
B: the default value is 0. A short frame counter runs here from 16 to 0 when the grenade is exploding (excluding the 'splitting flames' part after the exploding itself).

STEAM_EMITTER
A: as a horizontally blown steam: a non-0 number will show up in this field if the emitter starts stopping blowing the steam. This number depends on what you typed in the OCB window of the emitter. (For example if you want 2 seconds pause between the blows, then this number is 60, because 2x30=60 and 1 second is 30 frames.) A frame counter starts from that value at once. While that is running, the emitter stops blowing. When the counter reaches 0 the emitter will start blowing again.
As a (non-continuous) bubble-emitter under water: the default value is 0 but sometimes a number (randomly between 4 and 7) will show up in the field, indicating now a bunch of bubbles will be emitted that contains that 4-7 amount of bubbles. When the bubbles are being emitted one by one then the value decreases to 0 one by one.
As a (continuous) bubble-emitter under water: the default value is 20. A frame counter will start from this value when the emitter has been triggered. Reaching 0, nothing special will happen. (Newer activation won't start the counter again.)
B: as a horizontally blown steam: a random number (somewhere below 100) shows up in this field when the emitter starts blowing the steam, starting a frame counter at once from that value. When it reaches 0 the emitter will start stopping blowing.
As a (continuous) bubble-emitter under water: the default value is 1. One or two moments after the emitter has been triggered (so when the first bubbles comes out of the emitter) it turns into 0, and remains that 'forever'. (I think that 'one or two moments' is the frame counter that runs in Custom_A field now.)
C: as a horizontally blown steam: when the emitter starts blowing, then it counts from 0 to 4096. When the emitter starts stopping blowing, then it counts down from 4096 to 0. - It's the actual length of the flown steam. 4096 is about 1 (1,5, instead) square long.
D: none

EARTHQUAKE
A: numbers show up here randomly above 0. (109 seems the biggest number.) - This is the actual intensity of the earthquake.
B: the actual intensity of the earthquake, but not as precise as in Custom_A. I mean, there are only two values now: 20: low earthquake, 100: high earthquake. (Deactivating the earthquake, the value is always 100 instead of 0.)
C: it's a frame counter. It starts from a value, and, reaching 0, it will start again from a different value. (The starting numbers are two or three digits numbers below 200.) I think every phase from the start point to 0 means an intensity range. (So when the counter counts down the next phase from the start to 0 then the earthquake will have another intensity range, with bigger or smaller quakes as in the previous phase.) - The default value is 0 but antitriggering means a pause in the counter.
D: none

WATERFALLMIST (only if you customized it by OCB)
A: with standard, low or fast emitting: 0: deactive waterfallmist, -1: active waterfallmist.
With random emitting: two random frame counters run here one after the other (from the default Value 0 when the emitter has been activated): the starting values are one or two digits long positive numbers, and the end point is 0. The first sequence counts the time when the mist is being emitted, the second sequence counts the time when there is in a pause in the emitting. Then newer and newer first and second sequences are coming, of course.
B: 0: the mist isn't active or there's just a pause in the emitting, 1: the emitting just happens.
C: only with random emitting: random numbers show up here, probably from a 1-14 interval. A newer number will always show up at a start of a newer sequence. (So eg. at a start of the first 'activity' sequence Value 11 will show up in the field instead of the 0 there. Then, at a start of the first 'pause' sequence Value 8 will show up in the field instead of the 11 there.) I don't know what the exact meaning of these random numbers is, but be careful, because two sequences after each other may have the same random value.
D: none

SPRINKLER
A: a frame counter starts here from 0 when the sprinkler has been activated. When the last drip has come out of it, the counter will stop at 1200 (and remains that). (The 'shower part' stops at about 600.)
(Note: the usage of several objects is limited because of this kind of frame counters 'tying' them. - But you can use some tricks against that:
I mean, for example, this sprinkler cannot be antitriggered and cannot be re-triggered. But it doesn't mean you can't use the sprinkler more than one times: just force Value 0 into this field after the dripping has stopped, and the counter with the sprinkler will be active again. - Yes, we didn't antitrigger the sprinkler that's why the counter continues running at once, from 0 to 1200 again, if we turn the value into 0.
Or an example for another trick: force 1000 into the field when the counter reaches 200, so this sprinkler will stop after only a short dripping, because it has been 'showering' before that only for a short time.)
B, C, D: none

AMBER_LIGHT
A: if this light is active then the value runs continuously from -32768 to 32767, again and again. (So each value means the actual degree of the pulsing intensity.) - It changes Value 2048 after each frame. So each cycle is 32 frames long. (The default value is 0 but antitriggering means a pause in the counter.)
If you want other Value instead of 2048, then see the 'Time' field of the CUST_LIGHT_OBJECT type Customize Script command. You can find Value 2048 here as '-2048'. Type another negative value here, for slower (closer to 0) or faster (farther from 0) changes.
(Note: activating the light at the very first time, the counter always starts counting from 0, with the difference value: 0, -2048, -4096 etc., or 0, -16, -32 etc. Reaching minus thirty-thousand-whatever, it will turn into a thirty-thousand-whatever positive number, and start counting down to 0.)
B, C, D: none

WHITE_LIGHT
A: a frame counter starts here from 0 when the object has been activated. When this 'neon light that starts lighting in a blinking mode' lights continuously at last, then that means the counter stops at 160, and remains that. (Antitriggering turns the value back to 0.)
If you want other Value instead of 160, then see the 'Time' field of the CUST_LIGHT_OBJECT type Customize Script command. Type another value here, if you want. The smallest possible value is 96. The largest value that doesn't seem to cause a malfunction is about 200. ('Malfunction': some parts of the counter will be repeated, eg. 160-230, 160-230, so the counter is stuck there - but maybe for a while.)
B, C, D: none

(AI OBJECTS), LARA_START_POS
A, B, C, D: some of the fields have a constant 0, some of them have another constant number. Whatever they all are, I don't know.

PLANET_EFFECT
A: the starting value is 50+OCB number-1. (So eg. if Value 4 is typed in the OCB window, then the field value is 50+4-1=53.) If the effect has been activated, the value turns into -1 ('forever').
B: none
C, D: I don't know the exact meaning of the constant (positive) value here, but I know only OCB=1 effect has that value (the one that will directly be linked to ANIMATING4 - see the globe-puzzle of 'The Lost Library), the other effects have Value 0 here.

LASER_HEAD
A: 0: the head hasn't been activated yet or it has, but the head is still ascending i.e. isn't in a position to attack/search for Lara, 1: the head is in attacking position (but isn't attacking) or searching for Lara, 2: the head is attacking: getting energy or shooting that, 3: the eyes are all shot (and after that, 'forever').
B: (some negative number with four digits - let's call it Value A): the head hasn't been activated yet or it has, but the head is still ascending, Value A minus 5: after the head has ascended ('forever', so even if the head has been exploded).
C: the default value is 0. Activating the head, a counter starts from that (each value/2 or 3 frames). Reaching 8, it stops (keeping the value). Some moments after that (so when the head has ascended) the counter jumps to 2640 and starts a fast counting (Value 546/frame): 2640, 3186, 3732 etc. Reaching 32 thousand-whatever it turns into -32 thousand-whatever and continues running, counting down. Reaching 0, it turns into positive numbers again, and starts the counting up again etc.
Just when the two eyes has been shot, the Value X in Value X/frame starts increasing fast, soon it reaches the twenty-whatever-thousand value. When the head has just been exploded, the last value remains in the counter, forever.
D: the default value is 90. It starts a frame counter when the head reaches the starting position. Only when the counter reaches 0, the head will start searching for Lara.
After that, two types of frame counters will show up in the field again and again:
One of them is if the head is searching for Lara but can't find her. Now the starting value is between somewhere 20(?) and 100(?). The head will perform sudden head-movements always when the counter reaches 0. (If the head notices Lara, then the counter will be interrupted, keeping its last value, till the next type counter starts.)
The other counter type works when the head notices Lara and tries to hunt her down. It counts from 0 to 91. (This is the part when the head is getting energy.) When he's shooting, the counter is 91 constantly. Each newer attacking operation means one newer 0-91 interval.
When the eyes are all shot the counters will be interrupted and some other (even huger) numbers will show up here one after the other. When the head has just been exploded, the last value remains in the counter, forever.

HYDRA
A, B, C: none
D: when the hydra starts shattering ('dying') then a counter starts here from 0. (I think each value/2 or 3 frames.) When the shattering has been finished the counter stops at 12 and remains that.

ENEMY_SUB_MARINE
A: Positive (maximum 1984) numbers here mean how much the submarine is just tilted right. Negative (maximum -1984) numbers here mean how much the submarine is just tilted left. 0: the submarine isn't just tilted at all.
B, C, D: none

FISH_EMITTER
A: the default value here is the amount of fish that will be emitted. When the emitter has been triggered, the emitter will emit the fishes one by one, decreasing the amount here one by one. When the last fish has come out, the value is naturally becomes 0.
B: the default value is 0. When the emitter has been triggered, the emitter will emit the fishes one by one. If a fish is just emitted, a random number will show up here, between 16 (?) and 1. A frame counter starts at once from that value. Reaching 0, the next fish will be emitted. (When the last fish has been emitted, his random number will 'freeze' in the field, not starting a counter.)
C: -1: the emitter hasn't been triggered, 0: the emitter has been triggered.
D: when more types of fish will be emitted then the actual emitted amount of that fish type is counted here. For example, this is the sequence here, if you have 3 fishes in 3 fish types: 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3. (The last '3' value will remain in the field.)

Notes:

1. The Moveable object slots not mentioned above don't have values either Custom_A or Custom_B or Custom_C or Custom_D field:

MOTORBIKE, JEEP, SKELETON, MUMMY, HORSE, SCORPION, TROOPS, JEAN-YVES, KNIGHTS_TEMPLAR, WILD_BOAR, DEMIGOD1/2/3, BIG_BEETLE, BAT, DOG, HAMMERHEAD, SAS, SAS_DRAG_BLOKE, LARA_DOUBLE, SMALL_SCORPION, LOCUST_EMITTER, GAME_PIECE1/2/3, ENEMY_PIECE, DART_EMITTER, FALLING_CEILING, SMASHABLE_BIKE_WALL/FLOOR, COG, FLAME, ROPE, POLEROPE, SQUISHY_BLOCK1, MAPPER, KEY_HOLEs, SWITCH_TYPEs, UNDERWATER_SWITCH1/2, COG/LEVER/JUMP_SWITCH, PUSHPULL/KICK/UNDERWATER_DOOR, DOUBLE_DOORS, BRIDGEs, SARCOPHAGUS, SMOKE_EMITTER_WHITE/BLACK, RED/GREEN/BLUE/BLINKING_LIGHT, LENS_FLARE, TRIGGER_TRIGGERER, SMASH_OBJECTs, DEATH_SLIDE, CAMERA_TARGET, WATERFALLs, ANIMATINGs, MOTOR/RUBBER_BOAT, PARALLEL_BARS, PANELs, TIGHT_ROPE, LASER_HEAD_BASE/TENTACLE, FROG_MAN, KAYAK

2. I don't know if I examined all the possible situations about a given object slot to know the values in these fields. So maybe you'll encounter some cases when a field contains non-0 values, though I wrote it's 'none'. Or maybe you'll encounter some cases when a field also contains other values not only I mentioned above.
(Moreover, I can't examine some situations because I don't understand them. For example I don't know how the setup of the GUIDE works in the 'Valley of the Kings'.)

3. Each Moveable object slots that haven't been mentioned so far, that haven't been studied (because of they are no placeable - see eg. LARA_SKIN, FLARE etc - or its setup is too complicated or unknown - see eg. VON_CROY, SPIKEY_FLOOR, SARCOPHAGUS_CUT, HORUS_STATUE etc. - or aren't useable - see eg. MINE_DETECTOR or SECRET_MAP etc.).

4. Be careful! Some fields of some object slot may have strange values in strange situations. Or is it a bug? - See an example to understand what I'm talking about:
As I said above, the value of PUSHABLE_OBJECTs in Custom_D field is a constant 0. But in my 'dummy' level (i.e. the level where I do the testing for the tutorials) once I countered a case when that value became 1 ('forever') when Lara started pushing/pulling that object at the very first time. However, I can't duplicate that case in another level. Moreover, when I deleted all the objects from my test level, rebuilt the WAD and loaded the objects again, and placed a newer pushable object then the Custom_D field of that pushable was a constant 0.
So that 0/1 situation was a special situation that caused by a special setup I couldn't duplicate - or that was just a bug.
Probably (or perhaps?) we can't rule out that you will experience similar situations with the values I mentioned above in this addendum.
5. Please note some trap values in the tutorial seem random are probably really random (sort of...). - See eg. 1920 at the description of CHAIN.
I don't want to really check them because they are pretty unuseful values, probably nobody will ever use them.
So please check them if, however, you will use them. (It is not as hard as it sounds. I mean, eg. at that CHAIN parameter the value is 0 or 1920. So, you can treat 1920 as "not 0", i.e. your two values is not "0/1920" but "0/not 0".)

Made using TRNG 1.2.2.6