Checkpoints
by
AkyV
Download a project file illustrating this tutorial
You'll be able to use checkpoint type game savings if you follow the
description in this tutorial. 'Checkpoint type' means all of this now:
- 'Saving crystal' objects mark the places of the checkpoints.
-
An automatic game saving will happen (in an unseen way) when Lara
reaches a checkpoint.
- You have a manual method and (if Lara dies)
an automatic method to load Lara (loading an automatic game saving) to
the latest checkpoint she reached so far.
- You can use the usual
(F5/F6) type game saving-loading system, but not in the usual way:
a, The first method I'll show works this way: you can save only at
checkpoints. So, if you load a saved position then you'll always get
back to a checkpoint.
b, The second method I'll show works this way:
you can save at any point of the level. But if you load then the game
won't load Lara to the exact point where this saving happened but load
her to the checkpoint she reached last before this saving.
Notes:
1. Loading to a checkpoint by
F6 makes that checkpoint become the latest checkpoint.
2. The
second F5/F6 method is obviously cooler than the first one. But the
second method has some unpreventable bugs. (Not game-killing bugs but
'only' annoying bugs - that's why I decided I'd show you the second
method.) - Sorry, I tried many things, but I couldn't prevent those
bugs.
3. This tutorial is made by TRNG 1.2.2.6
1. Take a life
energy crystal from any TR3 WAD and copy it into the WAD of your level,
into any ANIMATING slot. (For example, ANIMATING1.)
2. Try this in
the game: if the bounding box of this object is enabled (i.e if Lara
can't get through the object) then disable it, clicking on Disable
Collesion button of WADMerger (when this object is marked in the left
window).
3. Place one ANIMATING1 on each square of your plan where
you want to see a checkpoint.
4. Trigger the crystals to animate
them.
5. Place one FLIPEFFECT trigger on each of those squares:
'Backup. Save in silent way the current game in <&> backup file'. &=
Game Backup 1. - When Lara activates this trigger then a game saving
will happen: not in one of the usual savegame slots but in this 'Game
Backup 1' slot.
Notes:
1. Maybe the
crystal is too close to the floor so you'd better raise it up a bit.
2. Stop the animation of the crystals that are just out of the
player's POV to save some memory.
Then start their animations again
if the player can see them again.
3. Maybe it looks nice if
there's some light effect of every crystal. You can adjust that if you
use an AddEffect script command.
4. So, as you can see, you
always have to use this Game Backup 1 slot at every checkpoint in the
game.
5. When the trigger saves the position at the checkpoint
then Lara can be anywhere on that square from the floor to the ceiling.
If you don't want that then you can use some condition on that square:
For example, you don't want the checkpoint to save the position when
Lara is moving over the square with using monkey bars. In this case you
can use for example Vertical trigger CONDITION or 'Lara. (Status) Lara
is performing <#>action is (E)' CONDITION trigger to prevent game
saving.
6. You can place some additional triggers on the square
of the checkpoint:
a, Use a Text FLIPEFFECT to write text
'CHECKPOINT' on the screen for some seconds when Lara's on the square of
a checkpoint.
b, Use a Sound FLIPEFFECT to play a (very short) audio
or sound file, marking this is a checkpoint. (Just as a typical audio
file marks the secrets.) - You'd better use a sound. Because when you
use an audio, it will interrupt another audio that is just playing, when
Lara reaches a checkpoint.
(When you choose that sound then be
careful with the details: for example, the chance of the playing - i.e.
the value of CH - should be 0, i.e. 100 %. If it's not 0 then this sound
won't always play when Lara reaches a checkpoint.
By the way I chose
EXPLOSION1 - ID: 105 - sound for this tutorial. But it's only an
example, of course.)
If you use (one of) these triggers at a
checkpoint, then you need use that/those trigger(s) at all of the
checkpoints, definitely.
7. If you use this crystal in your WAD as a life
energy crystal then you won't have problems if you use that crystal in
another ANIMATING slot, too, as a saving crystal. (The different look is
recommended, though. - I.e. you need to retexture the life energy
crystals or the saving ones. - But only because of logical reasons: the
player won't confuse the two crystal types with each other this way. And
this is also more aesthetical, of course.)
1.2. LOADING TO THE LATEST
CHECKPOINT
1.2.1. In a manual way
Use
these rows in Script - not only in all [Level] blocks but also in
[Title] block:
GlobalTrigger= 1, IGNORE, GT_KEYBOARD_CODE, 46,
IGNORE, 1, IGNORE
TriggerGroup= 1, $2000, 98, $1
GT_KEYBOARD_CODE constant says the condition is true when the player
hits a key on the keyboard.
In NG Center\Reference\Keyboard Scancodes
list you'll find a list about the codes of the keys that you can use in
script commands. As you see, the code 46 is the key C.
So this
GlobalTrigger says: 'if the player hits C (C as Checkpoint) in any level
or title then the TriggerGroup#1 will happen, i.e. the game will load
Lara to the latest checkpoint she reached so far'.
; Exporting: TRIGGER(1:0) for FLIPEFFECT(98)
; <#> : Backup.
Restore (load) the <&>backup file in (E)way
; <&> : Game Backup
1
; (E) : Standard way (progress bar + load
camera screen)
; Values to add in
script command: $2000, 98, $1
Notes:
1. Until the very first saving at the very first checkpoint this
Game Backup type loading will load to title. (Place a checkpoint on the
square where LARA object is placed in the very first level of the game
to prevent this bug.)
2. You have to be careful with placing
checkpoints. - Two examples will explain it why:
- Lara's just
burning when her position will be saved at a checkpoint. She dies
(there's no water anywhere to extinguish her) and the game loads her
automatically to title. If the player loads this checkpoint (the latest
checkpoint) with hitting C then finds Lara here burning. So Lara dies
here again and the games loads again automatically.
- Lara's
jumping over a checkpoint and arrives into a pit. The pit is too deep
and there's no ladder or other tool that can help her to get out of the
pit. The player thinks: 'that doesn't matter. I'll load that checkpoint,
and the game will put Lara on that point'. But, if the player loads the
game, Lara shows up jumping, and then falls into the pit again.
3. You should inform the player about the new features just like this
key C. You have these possibilities for that:
- You'll make a
Readme file for your game.
- You'll use a FLIPEFFECT to place a text
(or an image with a text on it - see Image script command) on the
screen. In the present case something like this: 'Hit key C to load to
the latest checkpoint'.
- You'll use a Diary script command to edit
an in-game manual for your game.
1.2.2. In an automatic way
Use this row
in Script - only in all [Level] blocks:
GlobalTrigger= 2, IGNORE,
GT_LARA_HP_LESS_THAN, 1, IGNORE, 1, IGNORE
This GlobalTrigger
says: 'if Lara has (almost) died then the TriggerGroup#1 (see above)
will happen, i.e. the game will load Lara to the latest checkpoint she
reached so far'.
'Almost' means this method is wrong a bit,
because the load starts when Lara starts dying. So you won't see the
whole dying animation, it will be interrupted and the load will be
started.
If this interruption bothers you then you must avoid the
automatic loading: don't use that row in Script.
In this case you
will get back to title if Lara dies (as usually in NGLE).
1.3. USING FIRST USUAL
SAVING-LOADING METHOD
1.3.1. Using Save Game function
You
have to place this trigger in every level on the square where LARA
object is placed:
;
Exporting: TRIGGER(18:0) for FLIPEFFECT(51)
; <#> : Keyboard.
Disable <&>keyboard command for (E) time
; <&> : Save the
game (special)
; (E) : Forever (use
other action/effect to disable it)
; Values to add in
script command: $2000, 51, $12
So you're not allowed to save by the usual system in the whole
level. Except at the checkpoints.
An exception like that is marked
with one trigger that is placed on the square of each checkpoint:
; Exporting: TRIGGER(18:0) for
FLIPEFFECT(53)
; <#> : Keyboard.
Simulate receivement of <&>keyboard comand in (E) way
; <&> : Save the
game (special)
; (E) : Single
sending
; Values to add in script command: $2000, 53,
$12
So when Lara
reaches that checkpoint then the savegame panel pops up (by this
trigger) and you can save if you want. (The disabled state of saving by
the usual system won't prevent the savegame panel to pop up or you to
save on this panel now.) Or you can hit ESC to close the panel without
saving if you don't want.
Note:
Using this
saving-loading method it doesn't matter whether if you use the 'classic'
savegame panel or (see SavegamePanel script command) the new one.
1.3.2. Using Load Game function
The loading
by F6 will work properly if you use these rows in Script, only in all
[Level] blocks:
GlobalTrigger= 5, IGNORE, GT_LOADED_SAVEGAME,
IGNORE, IGNORE, 10, IGNORE
TriggerGroup= 10, $2000, 97, $1, $2000,
70, $1F69
$2000, 70, $1F69 is the trigger (see above) to play
sound 105. If you use another trigger to play another sound/audio file
at your checkpoints then use that trigger here and not $2000, 70, $1F69.
If you don't use any sound/audio at your checkpoints then just clear
$2000, 70, $1F69 here.
If you want to know more about this then
see advanced settings.
1.4. USING SECOND USUAL
SAVING-LOADING METHOD
This method is an advanced setting.
PART 2
ADVANCED SETTINGS
2.1. LOADING TO THE LATEST CHECKPOINT
2.1.1. In a manual way
Some advanced notes to the theme:
1. If you don't understand why we call Game Backup 1 position 'the
latest checkpoint she reached so far' then have a look at the picture of
this example:
arrow: Lara's route
C8: this is the 8th checkpoint of the level: checkpoint#8 (saves
position in Game Backup 1 slot any time when Lara reaches this point)
C9: this is the 9th checkpoint of the level: checkpoint#9 (saves
position in Game Backup 1 slot any time when Lara reaches this point)
P8: this is a point anywhere in the level. If the player hits C here
then the game will load Lara to the position of Game Backup 1 that is
saved at the latest checkpoint she reached so far: checkpoint#8. If the
player doesn't then Lara will go on to C9.
P9: this is a point
anywhere in the level. If the player hits C here then the game will load
Lara to the position of Game Backup 1 that is saved at the latest
checkpoint she reached so far: checkpoint#9. If the player doesn't then
Lara will go on.
2. I mentioned this problem above: the game
loads the checkpoint, but Lara shows up jumping, and then falls into the
pit again.
Well, I tried to prevent these kinds of problems, forcing
Lara to have a fixed and standard - for example, standing - animation
always after the game has loaded her to a checkpoint, but it doesn't
work properly, because the game won't abort an animation - for example,
that jumping - right after loading. - By the way, knowing that problem,
I think it's not even worth caring about other fixed settings - position
on the square, facing - that Lara could have when the game has loaded
her to a checkpoint.
3. I mentioned above how useful the Readme
file, the text on screen or a diary to inform the player - also about
any preventable bugs (if you have some, not only in this theme), telling
the player what to do to prevent.
2.1.2. In an automatic way
If the interruption mentioned above (see
Chapter 1.2.2.) bothers you but you don't want to avoid the automatic
loading then you have to know that you can't use Lara's exactly dead
status as a condition (see: $8000, 0, $1D) for that GlobalTrigger
because every trigger will be ignored after Lara's death. Including the
loading trigger, of course.
;
Exporting: CONDITION(29:62) for PARAMETER(0)
; <#> : Vitality= 0
; <&> : Lara.
(Health) Lara vitality is (E)Condition than <#>vitality
; (E) : Equal than
...
; Values to add in script command: $8000, 0,
$1D
So you have only
this choice to use the automatic loading without that interruption:
You don't use that GlobalTrigger in Script, but you export that
$2000, 98, $1 loading trigger as an AnimCommand. Then add that
AnimCommand to all (!) the dying animations of Lara in WADMerger.
(Actually it means not one but more AnimCommands if you add this trigger
to frames that have diverse numbers. I.e., for example, if you add the
trigger to frame60 at one animation and frame70 at another animation.)
Always add this AnimCommand to the latest frame just before the loop end
of the animation:
For example, see Animation149: 'impaling by teeth
spikes' dying animation that has 86 frames. It has these values: Next
Animation= 149 and Next Frame= 86. It means the animation will be looped
at the end (just as every dying animation), i.e. the animation will
'freeze' at the end. - So you have to place the AnimCommand just before
this 'looping frame', at frame85.
Anyway, this is still not a
perfect method. Because the loading will start just when the dying
animation is completed. So in this case the game will skip the short
pause between the end of the dying animation and the start of the
loading that we got used to.
If you miss this pause then you'll
export $2000, 148, $64 trigger, as another AnimCommand:
; Exporting: TRIGGER(100:0) for
FLIPEFFECT(148)
; <#> : Text. Print
ExtraNG <&>string on screen, freeze game and wait Escape
; <&> : 100:
; (E) :
; Values to add in
script command: $2000, 148, $64
Place
this trigger to the frame just before the frame of the loading: this
frame is frame84 now.
This trigger will print a text on the screen,
and freeze the game until the player hit key ESC. This time you use
ExtraNG string#100 to print, but you can see: this string is empty now.
So, the game will freeze (without any text printing on the screen), and
when the player hits ESC then the game will step to the next frame of
the animation, i.e. start loading.
If one of these two
AnimCommands doesn't work (properly) at an animation then use bigger
space between them at that animation. (For example, two frames space
instead of one frame.)
And/or use these AnimCommands only at the
frames that you can see on the frame bar under the Animation Editor
window. (For example, if FrameRate=2 and you see frames 68, 70, 72 etc.
there then don't use frames 69, 71 etc.)
Use this
AnimCommand-type method only if those AnimCommands work properly at all
the dying animations!
Notes:
1. As some further correction, you can think something like this:
'This animation ends at frame86, but the freezing breaks it at frame84.
I'll add more frames to the animation: frame87 with that freezing
trigger, frame88 with that loading trigger and frame89 as the new
looping frame. So I'll see the whole original animation until frame86
without any bothering AnimCommands, because I'll delete them from
frame84 and 85. And I won't miss anything with breaking at those new
frames because Lara is still - i.e. dead - at frame86 and the new frames
are the copies of frame86 so Lara will be still from frame86 to
frame89'.
2. Be careful: if you have the same animations in two
or more WADs then these animations don't always have the same FrameRate
value.
2.2. USING FIRST USUAL
SAVING-LOADING METHOD
Maybe you
think you'll reform this method (see Chapter 1.3.): you won't use that
popping-up trigger but you will form a 'frame' around the checkpoint:
this 'frame' is the eight squares just around the square of the
checkpoint. The 'frame' is composed of those disabling triggers. And
this time you also have an enabling FLIPEFFECT ('Keyboard. Enable newly
<&>keyboard command', &=Save the game (special)) on the square of the
checkpoint.
This way this is what will happen: when Lara reaches the
checkpoint then you can save there if you want, hitting F5. But if Lara
leaves the checkpoint then you can't save again.
But this would
be a problematic reform, because of these two reasons:
- When
opposed (on/off) triggers respecting the same thing (i.e. saving by F5
this time) are really close to each other (i.e. in adjacent squares)
then this setup doesn't always work properly if Lara moves straight from
one trigger to the other trigger. (I think it's - mostly? - a FLIPEFFECT
malfunction.)
- Just think about an event that is about a fast
riding with a motorbike (because you have to do something during some
short time). You don't have any time to stop at the checkpoint you're
just driving through and save there. But if you're just driving through
there fast, hitting F5, then maybe you hit F5 too soon or too late, but
not exactly at that checkpoint, so you'll miss the opportunity to save
with F5 at that checkpoint.
2.2.1. Switching on and off the
savings
Be careful with placing checkpoints. See this example: Lara's chasing an
enemy but a checkpoint gets in her way and the savegame panel pops up,
distracting the player.
If you don't want the popping-up to bother you
in some part of the game then you can switch off the popping-up
temporarily if you hit F2 (losing the chance to save at the checkpoints
by the usual system) and switch that on again if you hit F1. - But only
after you did these three things:
1. Place only (!) these triggers on the
square of each checkpoint (so clear every other trigger there):
- Condition trigger(s) that is/are customized
for that checkpoint. (See, for example, that Vertical trigger CONDITION
above.)
- A
trigger that activates TriggerGroup#9:
; Exporting: TRIGGER(265:0) for
FLIPEFFECT(118)
; <#> : TriggerGroup. Perform
<&>TriggerGroup from script.dat in (E)way
; <&> : TriggerGroup= 9
; (E) : Single performing
(to use when in TriggerGroup there are only commands)
; Values to add in script
command: $2000, 118, $109
Note:
Because of some strange reason, we have to use
�single performing' value in E window of the trigger, in spite of that,
as you'll see below, there's a condition in the trigger, so - according
to the general rules - we should use �multiple performing' value there.
(But the trigger wouldn't work properly with �multiple' value now.)
2. Use these entries in
Script, only in all [Level] blocks:
GlobalTrigger= 2, IGNORE, GT_KEYBOARD_CODE, 59, IGNORE, 10, IGNORE
GlobalTrigger= 3, IGNORE, GT_KEYBOARD_CODE,
60, IGNORE, 3, IGNORE
GlobalTrigger= 4, FGT_SINGLE_SHOT_RESUMED,
GT_CONDITION_GROUP, IGNORE, 4, 5, IGNORE
GlobalTrigger= 13, FGT_SINGLE_SHOT_RESUMED,
GT_CONDITION_GROUP, IGNORE, 7, 6, IGNORE
TriggerGroup= 10, $2000, 234, $48
TriggerGroup= 3, $2000, 235, $48
TriggerGroup= 4, $8000, 72, $2C
TriggerGroup= 7,$8000, 72, $2D
TriggerGroup= 5, $2000, 204, $15, $2000, 66,
$202, $2000, 64, $14
TriggerGroup= 6, $2000, 204, $14, $2000, 66,
$202, $2000, 64, $15
TriggerGroup= 9, $2000, 97, $1, $2000, 66,
$102, $2000, 64, $210, >
$2000, 70, $1F69, $8000, 72, $2C, $2000, 53,
$12
The GlobalTrigger#2 says if the keyboard code is 59
(key F1) then TriggerGroup#2 will be activated - i.e. Local Byte Delta1
variable gets bit 0 (I mean the variable gets value 1):
; Exporting: TRIGGER(72:0) for
FLIPEFFECT(234)
; <#> : Variables. Numeric. Set in
<&>Variable the (E)bit
; <&> : Local Byte Delta1
; (E) : Bit 0 ($00000001 ;
1)
; Values to add in script
command: $2000, 234, $48
The GlobalTrigger#3 says if the keyboard code
is 60 (key F2) then TriggerGroup#3 will be activated - i.e. Local Byte
Delta1 variable loses bit 0 (I mean the variable gets value 0):
; Exporting: TRIGGER(72:0) for
FLIPEFFECT(235)
; <#> : Variables. Numeric.
Clear in <&>Variable the (E)bit
; <&> : Local Byte Delta1
; (E) : Bit 0 ($00000001 ;
1)
; Values to add in script
command: $2000, 235, $48
The GlobalTrigger#4 says if the condition is
true in TriggerGroup#4 then TriggerGroup#5 will happen:
; Exporting: CONDITION(44:62) for
PARAMETER(72)
; <#> : Local Byte Delta1
; <&> : Variables. The
<#>Numeric Variable has the (E)Bit set
; (E) : Bit 0 ($00000001 ;
1)
; Values to add in script
command: $8000, 72, $2C
This condition examines if Local Byte Delta1
has bit 0 (value 1).
The GlobalTrigger#13 says if the
condition is true in TriggerGroup#7 then TriggerGroup#6 will happen:
; Set Trigger Type - CONDITION 45
; Exporting:
CONDITION(45:62) for PARAMETER(72)
; <#> : Local Byte Delta1
; <&> : Variables. The
<#>Numeric Variable has the (E)Bit clear
; (E) : Bit 0 ($00000001 ;
1)
; Values to add in script
command: $8000, 72, $2D
This condition examines if Local Byte Delta1
has not bit 0 (value 1).
The TriggerGroup#5 and #6 are the opposite of
each other:
TriggerGroup#5 clears 'savegames off' text (the content of ExtraNG
string#21) off the screen and prints 'savegames on' text (the content of
ExtraNG string#20) on it:
; Exporting: TRIGGER(21:0) for
FLIPEFFECT(204)
; <#> : Text. Print. Remove
(&)Extra NG String from screen
; <&> : 21: savegames off
; (E) :
; Values to add in script command: $2000,
204, $15
; Exporting: TRIGGER(20:0) for
FLIPEFFECT(64)
; <#> : Text. Print ExtraNG
<&>string on screen for (E) seconds
; <&> : 20: savegames on
; (E) : Forever (use other
action/effect to disable it)
; Values to add in script
command: $2000, 64, $14
TriggerGroup#6 clears 'savegames on' text off
the screen and prints 'savegames off' text on it:
; Exporting: TRIGGER(20:0) for
FLIPEFFECT(204)
; <#> : Text. Print. Remove
(&)Extra NG String from screen
; <&> : 20: savegames on
; (E) :
; Values to add in script command: $2000,
204, $14
; Exporting: TRIGGER(21:0) for
FLIPEFFECT(64)
; <#> : Text. Print ExtraNG <&>string on
screen for (E) seconds
; <&> : 21: savegames off
; (E) : Forever (use other
action/effect to disable it)
; Values to add in script
command: $2000, 64, $15
So the GlobalTrigger#4 says if Local Byte
Delta1 is 1 then the game will clear 'savegames off' text and prints
'savegames on' text.
And the GlobalTrigger#13 says if Local Byte
Delta1 is not 1 then the game will clear 'savegames on' text and prints
'savegames off' text.
So if you hit F1 then you can see
'savegames on' or when you hit F2 then you can see 'savegames off'.
; Exporting: TRIGGER(514:0) for
FLIPEFFECT(66)
; <#> : Text. Set <&>color
and (E)position for next Print String flipeffect
; <&> : White
; (E) : Top line, central
alignment
; Values to add in script
command: $2000, 66, $202
This trigger - using the default white color -
puts 'savegames on' and 'savegames off' texts on the top of the screen.
(If we left them on the default position then these texts would be
overlapped with 'CHECKPOINT' text.)
(Maybe you think you don't need
FGT_SINGLE_SHOT_RESUMED flag and you can merge GlobalTrigger#4 and #13
in this:
GlobalTrigger= 4, IGNORE,
GT_CONDITION_GROUP, IGNORE, 4, 5, 6
No, believe me, it won't work. Because of
technical reasons. I'd rather skip the explanation now.)
The 'savegames on' means you can save with usual
saving system at the checkpoints because the savegame panel will pop up
there.
The 'savegames off' means you can't save with
usual saving system at the checkpoints because the savegame panel won't
pop up there.
But why do these texts mean that?
Well, now the TriggerGroup#9 is what contains
that trigger for popping-up (see $2000, 53, $12 above) and also contains
a condition trigger ($8000, 72, $2C) for the popping-up trigger. If the
condition in $8000, 72, $2C trigger is true (i.e. being after hitting
F1, when Local Byte Delta1 is 1) then the savegame panel will pop up if
Lara reaches that checkpoint, or, if the condition's not true (i.e.
being after hitting F2, when Local Byte Delta is not 1), it won't pop
up.
So these things happen (in this order) when Lara activates
TriggerGroup#9, reaching a checkpoint:
1. This trigger saves the
game in Game Backup 1 slot:
; Exporting: TRIGGER(1:0) for
FLIPEFFECT(97)
; <#> : Backup. Save in silent way the
current game in <&> backup file
; <&> : Game Backup 1
; (E) :
; Values to add in script command: $2000,
97, $1
2. This trigger confirms that the position and color
of text 'CHECKPOINT' have the default values of the game.
; Exporting: TRIGGER(258:0) for
FLIPEFFECT(66)
; <#> : Text. Set <&>color and
(E)position for next Print String flipeffect
; <&> : White
; (E) : Bottom line,
central alignment
; Values to add in script
command: $2000, 66, $102
You need the trigger,
because this text has not the default position value: a $2000, 66, $202
trigger - see above - has been activated before this $2000, 66, $102
trigger, and a text-forming trigger - like each of these two triggers -
is always valid until a newer text-forming command.
3. This (optional) trigger prints
the content of ExtraNG string#16 (i.e. text 'CHECKPOINT') on the screen
for 2 seconds:
; Exporting: TRIGGER(528:0) for
FLIPEFFECT(64)
; <#> : Text. Print ExtraNG <&>string on
screen for (E) seconds
; <&> : 16: CHECKPOINT
; (E) : 2 seconds
; Values to add in script
command: $2000, 64, $210
4. This (optional) trigger plays sound file
105, marking: this is a checkpoint:
; Exporting: TRIGGER(8041:0) for
FLIPEFFECT(70)
; <#> : Sound. Play
<&>Sound sample of first group (0-255) for (E) time
; <&> : EXPLOSION1 105 Ok
explos1
; (E) : Perform one single
time
; Values to add in script
command: $2000, 70, $1F69
5. If $8000, 72, $2C condition is true, too, then the
$2000, 53, $12 trigger will happen, i.e. the savegame panel will pop up
- or, if it's not then it won't.
Technical notes:
- The 'savegames on' and 'savegames off'
states and texts will always be saved when a game saving happens and
will always be restored by loading these savings.
Let's see an example: the value is 'savegames
on', and you saved on the savegame panel at a checkpoint. Then you
switch this feature off. After that if you load in the usual system or
hitting C to this checkpoint then the game will also load the saved
value 'savegames on'.
- It's always a good idea to
decrease the number of the placed and overlapped triggers with placing
them in a triggergroup. (That's what we did now: as you see, this time
we placed the backup-saving, CHECKPOINT-printing and sound-playing
triggers in a triggergroup.)
And this way you may also prevent some
malfunction that exists when you use overlapped triggers instead of
having them in a triggergroup. (For example, because, you can adjust the
order of activation of the triggers in a triggergroup, putting the
triggers here in the proper order. - You can't - always? - do that at
overlapped situations.)
- When you choose a variable for
any purpose of the game (because you don't have to use exactly the same
variables everyway I present in this tutorial) then don't forget these
things:
a, After all, you can choose any
variable if that variable is good for your purpose. (For example,
variables named Alfa, Beta, Delta are good for general numeric tasks.)
b, You can use variables named
Local only in the actual level. But the values of variables named Global
and any other variables can be valid globally, i.e. for the whole game.
Be very careful, if you use ResetHUB, because
it (always?) resets the value of the global type variables when leaving
the level.
c, If you don't know what kind of
byte, short or long variable to choose then see the tutorial of
Variables demo project: Chapter 'The size of the Variables'.
d, Be careful: you can use the same
variable for more purposes in the level, but you can use this variable
only for one purpose at the same time.
e, Current Value is a global type
variable that you should use only for special tasks. (For example, this
is the variable that you can take a value from variable A to variable B
with.) So if it's possible, don't engage Current Value for small tasks.
f, Be very careful with variables:
for example, if you use task A (that has variable V1) in the level X
then it works perfectly, and if you use task B (that has variable V2) in
the level Y then it also works perfectly. But if you use task A and B in
the level Z then the task A and/or B will work with problems maybe,
because of variable V1 and V2 may disturb the working of each other in
that situation.
See more about variables in their
above-mentioned tutorial.
3. Place this trigger on the square where
LARA object is placed:
; Exporting: TRIGGER(72:1) for FLIPEFFECT(234)
; <#> : Variables. Numeric. Set in <&>Variable
the (E)bit
; <&>
: Local Byte Delta1
; (E) : Bit 0 ($00000001 ; 1)
; Values to add in script command: $2000, 234,
$48
This trigger adjusts 'savegames on'
state as the default state of the level.
The 1 in (72:1) means 'one shot': it's
important or else you'll switch this feature on unintentionally if you
take Lara on this square later in the level.
Note:
Be careful: if you have a checkpoint where
there's a LARA object then you can't have this trigger placed there to
prevent some malfunction.
2.2.2. Using Load Game function
When the player loads a savegame slot then
the game will load Lara in a position of a checkpoint - not the latest
checkpoint under any circumstances but the one where the saving in this
savegame slot happened:
L1: the player
saved Lara's position at this checkpoint in savegame1 slot in the
savegame panel. (Or any other savegame slot. It doesn't matter ever,
actually.)
P: this is a point anywhere in the level. If the player
hits C here then the game will load Lara to the position of Game Backup
1 that is saved at the latest checkpoint: checkpoint#5. If the player
loads savegame1 slot here from the savegame panel then the game will
load Lara to the checkpoint that is saved in savegame1 slot:
checkpoint#4.
(P can also mean title when you got back there after
Lara left C5. Or another level that Lara reached after she left C5.)
It's logical the checkpoint#4 will become the latest checkpoint
after loading to that point with the usual system.
But it's
problematic a bit: when Lara reaches checkpoint#4 then she will activate
the 'Backup. Save in silent way the current game in <&> backup file'
trigger and just after that the player will save on the savegame panel
popped up. So when the player loads Lara to this on-panel saving point
with Load Game function then the game will find that Backup trigger
there in an activated - i.e. a non-activable - state. That's why after
this loading, this checkpoint won't be the latest checkpoint instead of
checkpoint#5 automatically: because that Backup-saving trigger won't be
activated again.
Of course, if Lara steps off the square of that
checkpoint and steps on that again at once then she will activate that
trigger again, correcting the problem. But it's lame. It means we have
to find a nice method to define that checkpoint as the latest
checkpoint.
That's why I told you (see Chapter 1.3.2.) to use
these rows in Script, only in all [Level] blocks:
GlobalTrigger=
5, IGNORE, GT_LOADED_SAVEGAME, IGNORE, IGNORE, 10, IGNORE
TriggerGroup= 10, $2000, 97, $1, $2000, 70, $1F69
So this
GlobalTrigger says: 'if the loading of the game has just happened then
the TriggerGroup#10 will happen, i.e. the game will save the game in
Game Backup 1 slot'. That's why the checkpoint - whereto the loading has
just happened - has just become the latest checkpoint.
; Exporting: TRIGGER(1:0) for
FLIPEFFECT(97)
; <#> : Backup. Save
in silent way the current game in <&> backup file
; <&> : Game Backup
1
; (E) :
; Values to add in
script command: $2000, 97, $1
Notes:
1. The usability of Load Game function is not affected by whether
the game has 'savegames on' state when you use this function or
'savegames off' state.
2. The purpose of the $2000, 70, $1F69
trigger is to play sound 105.
But why do we want to play that sound
when a savegame has been loaded?
Well, the order of the triggers in a
triggergroup sometimes matters - just as now: in TriggerGroup#9 the
sound-playing trigger has to be before the popping-up trigger.
If you
load with the usual system to a checkpoint then the game will load Lara
to the popping-up point. And this point is after the playing trigger, so
the game won't start the sound after it has loaded Lara to this point.
So that's why the game plays sound 105 with TriggerGroup#10 when a
savegame has been loaded.
3. We have no problem that's similar to
problem of the sound files with text 'CHECKPOINT' that's just on the
screen when a savegame has been loaded.
4. In the example above,
loading savegame1 will load to checkpoint#4. So if you want to go back
to checkpoint#5 after this savegame1 loading - without journeying the
route again from checkpoint#4 to checkpoint#5 - then you have to save
the game in savegame2 (or any other) slot at checkpoint#5, before this
savegame1 loading.
2.3. USING SECOND USUAL SAVING-LOADING
METHOD
Technical note:
The
unpreventable bugs of the method mostly exist because of two reasons:
- Game Backup type saving and loading always have the same rules
just as the usual saving and loading system. - For example, if you use
CUST_CD_SINGLE_PLAYBACK constant to adjust audio files for the usual
system then this adjustment will also be valid for Game Backup type
method.
So one of the major problems now is hard to tell the game in
the triggers or in the script that if I'm just talking about a
savegame-type saving-loading or a backup-type saving-loading.
-
The another major problem is the things always have their saved values.
For example: you have a position (let's call it 'A'), and you save it.
After that, Lara reaches another position (let's call it 'B') and does
something there. You try to remind the game of Lara doing something in
position B so you take Variable X there and give that variable the value
1 (saying 'value 1 means something happened here, but if nothing
happened here then Variable X doesn't get value 1'). After that, you
load position A, thinking 'I use Variable X as a condition. So if that
thing happened, i.e. if Variable X=1 then I get the game to do Y thing
at position A, but if that thing didn't happen, i.e. if Variable X not =
1 then I don't get the game to do Y thing at position A'. - But you gave
Variable X value 1 after you
saved position A. And the game will load that non-1 (for example, 0)
value if you load position A, so it's sure that you won't find Variable
X=1 value at position A.
(No,
GT_AFTER_RELOADING_VARIABLES, GT_BEFORE_SAVING_VARIABLES or any similar
thing doesn't work in these cases.)
You may think: 'of course they
have their saved values', but we would need the positions not to have
some values to prevent some bugs of this method.
2.3.1. The way the things work
These things happen when you hit F5 to save:
1. The original
task of F5 is forbidden, so when you hit F5 then the saving procedure
starts - but not in the usual way.
2. The game saves Lara's position
in a Backup slot. (Not in the Backup 1 slot, but, for example, Backup 2
slot.)
3. The game loads Lara to the checkpoint she reached last
before this saving, i.e. to the position saved in Backup 1 slot. - The
load camera picture of this level will cover the screen (automatically)
all the time when this saving procedure are happening so the player will
think Lara didn't lose her position during the procedure.
4. The game
makes the savegame panel pop up.
Unpreventable bug#1:
When Lara reached that checkpoint, then maybe some audio and/or sound
was playing. You'll hear that audio/sound when you are loaded here now.
That's why you'll know that you're not at the position of Backup 2, i.e.
Lara lost her position.
I mean I wanted to make the game become dumb
while Backup 1 is loaded during the saving procedure but it didn't work
properly.
Alternative endings of
the method:
Ending#1:
5. Hit ENTER.
6. The game saves.
7. The game loads Lara back to the position of Backup 2.
Ending#2:
5. Hit CTRL.
6. The game saves.
7. The game
leaves Lara at the position of Backup 1.
Ending#3:
5. Hit
ESC.
6. The game leaves Lara at the position of Backup 1.
So,
as a player, you'll think these things happened:
- Hitting ENTER:
'I saved the game'.
- Hitting CTRL: 'I saved the game and then the
game loaded me to the checkpoint Lara reached last before this
procedure'.
- Hitting ESC: 'I aborted the saving procedure and then
the game loaded me to the checkpoint Lara reached last before this
procedure'.
(The original task of hitting CTRL - saving the game
- and hitting ESC - aborting the saving procedure - were changed
automatically because of the circumstances of the setup of the second
method. I couldn't prevent those automatic modifications without making
bugs - but, hey, you can use ENTER and CTRL for not the same purposes
now in the savegame panel.
The original task of hitting ENTER -
saving the game - would also been changed if I hadn't done some things
in script - see below.)
Unpreventable bug#2:
As you can see, the 'aborting the saving procedure' task is missing now.
So, if you start the saving procedure then you'll have to save in a
savegame slot everyway, with hitting ENTER - even if you don't want to
use that saved position later at all - or else Lara will lose her
position at the end of the procedure.
2.3.2. Using Save Game function
You
have to place this trigger in every level on the square where LARA
object is placed:
;
Exporting: TRIGGER(18:0) for FLIPEFFECT(51)
; <#> : Keyboard.
Disable <&>keyboard command for (E) time
; <&> : Save the
game (special)
; (E) : Forever (use
other action/effect to disable it)
; Values to add in
script command: $2000, 51, $12
You think this trigger means you're not allowed to save by the usual
system in the whole level. But we use script (see below) to give F5
another method to save (see above), so this trigger means these two
things now:
- when you hit F5 then the savegame panel won't pop
up at once, but another saving procedure will happen, and
- you're
not allowed to save by choosing Save Game in inventory. (Anyway, if you
use that disabling trigger then you don't have Save Game in inventory.)
You have to use these rows in script, only in all [Level] blocks:
GlobalTrigger= 6, FGT_REMOVE_INPUT, GT_KEYBOARD_CODE, 63, IGNORE,
11, IGNORE
GlobalTrigger= 7, IGNORE, GT_SAVED_SAVEGAME, IGNORE, 14,
15, IGNORE
GlobalTrigger= 8, IGNORE, GT_LOADED_SAVEGAME, IGNORE,
IGNORE, 16, IGNORE
GlobalTrigger= 9, IGNORE, GT_CONDITION_GROUP,
IGNORE, 17, 18, IGNORE
Organizer= 2, FO_TICK_TIME, IGNORE, 0, 12, 2,
13
TriggerGroup= 11, $2000, 235, $48, $2000, 127, $2
TriggerGroup=
12, $2000, 97, $2
TriggerGroup= 13, $2000, 98, $1, $2000, 53, $12
TriggerGroup= 14, $8000, 28, $30C
TriggerGroup= 15, $2000, 98, $2
TriggerGroup= 16, $2000, 234, $48, $2000, 70, $1F69
TriggerGroup= 17,
$8000, 72, $2C
TriggerGroup= 18, $2000, 128, $2
STARTING THE SAVING PROCEDURE
The GlobalTrigger#6 uses key F5 (see: keyboard code 63) as a
condition. But thanks to FGT_REMOVE_INPUT constant, the disabled task of
key F5 won't be enabled by that condition. So when you hit F5 then the
savegame panel won't pop up but only the TriggerGroup#11 will happen.
; Exporting: TRIGGER(2:0) for
FLIPEFFECT(127)
; <#> : Organizer.
Enable <&>Organizer
; <&> : Organizer= 2
; (E) :
; Values to add in
script command: $2000, 127, $2
This trigger starts Organizer#2.
We need some time gap
between saving Backup 2 and then loading Backup 1 to prevent some
malfunction. That's why we use an organizer. We use FO_TICK_TIME
constant, so the gap is small really, because this constant means that
the unit of the organizer is not second but frame. (One second is thirty
frames.)
One frame is too small for the proper working, so we use two
frames as a gap in Organizer#2.
; Exporting: TRIGGER(2:0) for FLIPEFFECT(97)
; <#> : Backup. Save
in silent way the current game in <&> backup file
; <&> : Game Backup
2
; (E) :
; Values to add in
script command: $2000, 97, $2
This trigger saves Lara's position in Game Backup 2 slot.
As
we know, $2000, 98, $1 trigger loads Lara to the latest checkpoint, i.e.
the actual position of Game Backup 1 slot.
And, as we know, $2000,
53, $12 trigger makes the savegame panel pop up.
(As I said
before, the positions keep their saved values. Then how can we make the
savegame panel pop up after loading Backup 1 slot? After all,
Organizer#2 is started after saving in Backup 1, so when we loaded
Backup 1 then Organizer#2 should be aborted without that popping-up,
because Organizer#2 doesn't exist at Backup 1. - I don't know. I think
this is a 'huge luck'. Maybe there are some triggers that are
exceptions.)
FINISHING THE
SAVING PROCEDURE
The
GlobalTrigger#7 says if you've just saved the game and the condition in
TriggerGroup#14 is also true then TriggerGroup#15 will happen.
; Exporting: TRIGGER(2:0) for
FLIPEFFECT(98)
; <#> : Backup.
Restore (load) the <&>backup file in (E)way
; <&> : Game Backup
2
; (E) : Standard way (progress bar + load
camera screen)
; Values to add in
script command: $2000, 98, $2
This trigger loads Lara back to the position of Game Backup 2 slot
after saving the game.
But you want to load Lara there only if we
saved with Save Game function and not with an automatic saving in a
Backup slot. You have only one mode to 'explain to the game' that you're
talking about only Save Game function now: you'll mention the key ENTER
as a condition. Because you use ENTER at Save Game function, but don't
use at Backup savings.
;
Exporting: CONDITION(12:56) for PARAMETER(28)
; <#> : ENTER
; <&> : Keyboard.
<#>keyboard scancode is currently (E)
; (E) : ACTIVE
(Multi shot for positive condition)
; Values to add in
script command: $8000, 28, $30C
This trigger says the condition is true if the player uses key ENTER
in multi shot mode.
No, multi shot doesn't mean two or more hits. -
I'll explain it:
1. The savegame panel is on the screen.
2.
The player hits ENTER to save (Shot#1).
3. The panel closes.
4.
The ENTER is still pushed for a short moment (Shot#2) before the player
releases that.
The first shot is in the 'dead time' of the game
(i.e. when it's frozen under the savegame panel), so the condition
couldn't sense that (properly).
(So key ENTER could keep its
original saving task because we defined that multi shot condition.)
THE PROBLEM OF THE ENDLESS
ORGANIZER
The Organizer#2
is working now when the game saves Backup 2. So, when the game loads
back Lara to Backup 2 at the end of the saving procedure, then
Organizer#2 exists, that's why goes on: the game loads to Backup 1
again, and the savegame panel pops up again etc.
So you have to abort
the Organizer#2 at the end of the procedure. So you'll take a variable
and adjust its value 1 when the game has been loaded - i.e. at the end
of the procedure, when the game loads back to Backup 2.
And you'll
adjust the value 0 of this variable when the organizer starts. So, if
you start organizer then the variable is 0, i.e. it's also 0 when it
reaches the Backup 2-saving point after that. But, after the game has
loaded back to this saving point at the end of the procedure then the
variable takes value 1. - So we need a condition: if variable=1 then let
the game abort the organizer.
This variable is
Local Byte Delta1 now.
The GlobalTrigger#8 says if you've just
loaded the game then TriggerGroup#16 will happen.
; Exporting: TRIGGER(72:0) for FLIPEFFECT(234)
; <#> : Variables.
Numeric. Set in <&>Variable the (E)bit
; <&> : Local Byte
Delta1
; (E) : Bit 0 ($00000001 ; 1)
; Values to add in
script command: $2000, 234, $48
This trigger gives Local Byte Delta1 variable the bit 0 (value 1).
; Exporting: TRIGGER(72:0) for
FLIPEFFECT(235)
; <#> : Variables.
Numeric. Clear in <&>Variable the (E)bit
; <&> : Local Byte
Delta1
; (E) : Bit 0 ($00000001 ; 1)
; Values to add in
script command: $2000, 235, $48
And this trigger (in TriggerGroup#11, when the game starts
Organizer#2) clears that value 1, giving the variable the value 0.
The GlobalTrigger#9 says if the condition in TriggerGroup#17 is true
then TriggerGroup#18 will happen.
; Exporting: CONDITION(44:62) for
PARAMETER(72)
; <#> : Local Byte
Delta1
; <&> : Variables. The <#>Numeric Variable
has the (E)Bit set
; (E) : Bit 0
($00000001 ; 1)
; Values to add in
script command: $8000, 72, $2C
This trigger examines if Local Byte Delta1 is 1.
; Exporting: TRIGGER(2:0) for FLIPEFFECT(128)
; <#> : Organizer.
Stop <&>Organizer
; <&> : Organizer= 2
; (E) :
; Values to add in
script command: $2000, 128, $2
This trigger aborts that endless organizer.
Notes:
1. The game gives this variable the value 1 after every type loading
(so also at the points where we don't want to), but it doesn't disturb
the working of the organizer, because the start of the organizer always
gives value 0 to the variable.
Look at that strange point again
where the savegame panel pops up: when the game has loaded Backup 1 then
the game - ignoring the condition (maybe because there's 'dead time'
there) - won't give value 1 to the variable.
It's another 'huge luck'
there, because value 1 would break organizer at that point - and we
don't want that breaking, of course.
2. Unpreventable bug#3:
You have a similar problem with sound 105 just as at the first method:
you can hear that sound when Lara reaches a checkpoint, but you can't if
she gets back to a checkpoint with some loading.
I think you have
only two (not really proper) solutions for that problem:
- You
don't care about the problem, so you won't hear sound 105 when Lara has
been loaded back to a checkpoint.
- You use that sound 105-playing
trigger ($2000, 70, $1F69 - see above in TriggerGroup#16) also with that
loading condition. But it means you'll hear that sound after every
loading - i.e. also when the game loads Lara back to the position of
Backup 2 (that is not at a checkpoint) at the end of the saving
procedure.
(Of course, it's also a solution if you don't use
Sound triggers to the checkpoints at all. In this case you'll prevent
this annoying bug - but skip the sound feature.)
2.3.3. Using Load Game function
When the player loads a savegame slot then
the game will load Lara in a position of a checkpoint - not the latest
checkpoint under any circumstances but the one where the saving in this
savegame slot happened:
L1: this is a
point anywhere in the level. The player starts saving procedure here.
During the procedure the game loads Lara to the latest checkpoint
(checkpoint#4) and saves her position there in savegame1 slot in the
savegame panel. (Or any other savegame slot. It doesn't matter ever,
actually.)
P: this is a point anywhere in the level. If the player
hits C here then the game will load Lara to the position of Game Backup
1 that is saved at the latest checkpoint: checkpoint#5. If the player
loads savegame1 slot here from the savegame panel then the game will
load Lara to the checkpoint that is saved in savegame1 slot:
checkpoint#4.
(P can also mean title when you got back there after
Lara left C5. Or another level that Lara reached after she left C5.)
But you have the same problem just as at the first method: when you
load a savegame slot and it's not the latest checkpoint then - it's
logical, though - it doesn't become the latest checkpoint automatically.
You need these rows in all [Level] blocks to prevent that problem:
GlobalTrigger= 10, IGNORE, GT_KEYBOARD_CODE, 64, IGNORE, 19, IGNORE
GlobalTrigger= 11, IGNORE, GT_KEYBOARD_CODE, 28, 20, 21, IGNORE
GlobalTrigger= 12, IGNORE, GT_KEYBOARD_CODE, 1, IGNORE, 22, IGNORE
TriggerGroup= 19, $2000, 234, $8
TriggerGroup= 20, $8000, 8, $2C
TriggerGroup= 21, $2000, 97, $1
TriggerGroup= 22, $2000, 235, $8
You'll mention key ENTER again to explain to the game that you're
just using Load Game type loading (when you use ENTER) and not some
other type loading (when you don't use ENTER). (If you don't do that
then the position of Backup 2 would also become the latest checkpoint
when the game loads that at the end of the saving procedure. - No, it
doesn't matter now you hit ENTER to save just before that loading.)
But how will the game know that you use ENTER at Load Game and not at
another function? - To solve that problem, you'll use a variable. It
will get value 1 if you hit F6 to load a savegame. And you'll use a
condition: the game will care about that 'ENTER-mention' only if the
variable=1. (GT_LOADED_SAVEGAME condition with multi shot ENTER wouldn't
work now.)
The GlobalTrigger#10 says if the player hits key F6
(see: keyboard code 64) then TriggerGroup#19 will happen.
; Exporting: TRIGGER(8:0) for
FLIPEFFECT(234)
; <#> : Variables.
Numeric. Set in <&>Variable the (E)bit
; <&> : Global Byte
Delta1
; (E) : Bit 0 ($00000001 ; 1)
; Values to add in
script command: $2000, 234, $8
This trigger gives Global Byte Delta1 variable the bit 0 (value 1).
The GlobalTrigger#11 says if the player hits key ENTER (see:
keyboard code 28) and the condition in TriggerGroup#20 is also true then
TriggerGroup#21 will happen.
; Exporting: CONDITION(44:62) for PARAMETER(8)
; <#> : Global Byte
Delta1
; <&> : Variables. The <#>Numeric Variable
has the (E)Bit set
; (E) : Bit 0
($00000001 ; 1)
; Values to add in
script command: $8000, 8, $2C
This trigger examines if Global Byte Delta1 is 1.
And $2000,
97, $1 trigger saves the game in Game Backup 1 slot, saying: 'if you hit
ENTER after you hit F6, then the checkpoint that has just been loaded
will be the latest checkpoint'.
Notes:
1. You have to clear value 1 from that variable after this loading
procedure or else it will be problematic (i.e. the game will always save
the actual position in Backup 1 slot), if you hit ENTER later at any
function of the game:
- The value got 1 only when you hit F6, so
the value is 0 at the position that you will load now. So, if you load
that position then the game will clear value 1 automatically.
-
If you don't hit ENTER, i.e. if you abort the procedure with hitting ESC
then the game will clear value 1 by GlobalTrigger#12:
The
GlobalTrigger#12 says if the player hits key ESC (see: keyboard code 1)
then TriggerGroup#22 will happen.
; Exporting: TRIGGER(8:0) for FLIPEFFECT(235)
; <#> : Variables.
Numeric. Clear in <&>Variable the (E)bit
; <&> : Global Byte
Delta1
; (E) : Bit 0 ($00000001 ; 1)
; Values to add in
script command: $2000, 235, $8
This trigger clears value 1 of Global Byte Delta1.
(This
clearing works at every ESC-hitting. But it doesn't matter because
Global Byte Delta1 has nothing to do with other game procedures that
need ESC.)
2. Maybe you are in Level A when you load a savegame
that was saved in Level B.
That's why I chose a 'global' type
variable: you'll define that value 1 in Level A, but the game will take
the value 1 of the variable from A to B, to define that saved position
in Level B as the latest checkpoint.
Though, it's strange: when you
hit ENTER this is the ENTER of GlobalTrigger#10 of Level A (because
we're not talking about multi shot now), but when $2000, 97, $1 trigger
saves the game then that $2000, 97, $1 is the $2000, 97, $1 of
Globaltrigger#11 of Level B. - So one half of the procedure happens in
Level A, and the other half happens in Level B. (Or just I think that's
what happens. - Whatever: the setup seems to work and that's the point.)
3.
Unpreventable bug#4:
This problem-preventing won't work, if you load
a savegame from title. - So, if you choose a savegame slot in the Load
Game menu of title, then the game will load that position but it won't
become the latest checkpoint after it's loaded if it's not the latest
checkpoint.
Of course, this is not a big problem: after all, as I
said, if Lara steps off the square of that checkpoint after it's loaded
and steps on that again at once then she will activate that placed
Backup 1-saving trigger again, correcting the problem. But it's lame.
(Anyway, naturally you can also define a new latest checkpoint if you
load a savegame from this/another level or if you make Lara
walk/run/swim etc. to another checkpoint.)
But be careful: this
bug will get the things pretty messy if the player forgets about the
recovering. (For example, don't forget: saving with F5 always loads Lara
back to the latest checkpoint - even if it's just the wrong checkpoint.)
4. Using this saving-loading method use only the 'classic' savegame
panel. If you use (see SavegamePanel script command) the new one that
may generate a bug. (I.e. the new panel breaks the effects of
GlobalTrigger#10-12.)
5. In the example above, loading savegame1
will load to checkpoint#4. So if you want to go back to checkpoint#5
after this savegame1 loading - without journeying the route again from
checkpoint#4 to checkpoint#5 - then you have to save the game in
savegame2 (or any other) slot after Lara reached checkpoint#5, before
this savegame1 loading.