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:
