NGLE Manual

 

The NGLE Manual

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(=12×512) 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, 480×1+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 1024×-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 1024×-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 1024×1,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. – See about that, for example, in this tutorial, its demo project and its readme:Talking to Zip)
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 6×20=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: