www.tombraiderforums.com

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Tomb Raider Level Editor Tutorials

Closed Thread
 
Thread Tools
Old 10-06-14, 18:02   #1
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,493
Default TRNG Activation and deactivation of cameras

1. Classic static camera triggers and their development in TRNG

If a static camera (Camera or Fixed Camera) is active, then the camera target is usually Lara, who you will see from the POV of that camera.
The difference between Camera and Fixed Camera is the activation/deactivation method:

The methods to activate a Camera/Fixed Camera with a trigger:

- The classic, TRLE method: CAMERA trigger.
- The new, TRNG method: an F118 trigger to activate a TriggerGroup in single mode. (The camera effect would be more or less buggy if you use multiple or continuous mode.) The TriggerGroup must contain an A41 trigger.

So A41 will be useful only exported in Script!

If the activator is Lara and she’s holding weapons in the hands then you can activate only a Fixed Camera.
It also means these cases work only with Fixed Camera:

- COMBAT camera trigger or
- C35 condition trigger (in “Lara is holding a weapon” mode) is used for the camera trigger, or
- HEAVY camera trigger+SHATTER object shot by Lara.

Notes:

- If you remove a Camera/Fixed Camera from the map then the classic TRLE triggers to activate/deactivate it will be deleted as well automatically.
But, if a TRNG ACTION trigger activates/deactivates a Camera/Fixed Camera then don’t forget to delete that trigger after you deleted that Camera/Fixed Camera, because this time the triggers won’t be deleted automatically.
- If the camera is still active by an A41, when the trigger conditions become true again (which mostly means if Lara gets back to the trigger zone), then the camera view will possibly shiver for a moment. It can be prevented, using One Shot in that F118.
- If you want to use an A41 as an AnimCommand, then you must export an F118 into WADMerger that contains that A41.

Always be careful with activating static cameras with HEAVY triggers. I highly recommend testing the situation carefully in a test project, before you try it in your “real” project.
I mean, maybe you encounter some bugs with these setups, that you are able to fix only heavily. (For example: you want a pushblock to activate a camera if Lara pushes/pulls it on a HEAVY. Sometimes the activation happens automatically, though perhaps only for a moment, before she moves it on that HEAVY. – And perhaps you can’t really get rid of that bug even if eg. you remove the pushblock off the map.)


The methods to deactivate a Camera/Fixed Camera:

a, Only if a CAMERA trigger switched on the camera:

- If the activator was Lara:

= Lara leaves the trigger zone of CAMERA trigger, or
= Lara is still in the trigger zone of CAMERA trigger, but:

< the player hits the Look key (useful only with Camera), or
< Lara draws a weapon (useful only with Camera), or
< the timer of the CAMERA trigger expires, or
< an F120 trigger has been activated somewhere else, somehow, or
< a flyby sequence starts.

That “being in trigger zone” thing is important if Lara activated the trigger in PAD mode: so the camera won’t switch off if she jumps up from the floor of PAD. (Because trigger zones go from floor to ceiling.)

- If the activator was not Lara (i.e. in HEAVY case):

= the player hits the Look key,* or
= Lara draws a weapon (useful only with Camera),*
= the timer of the CAMERA trigger expires, or
= an F120 trigger has been activated somewhere, somehow, or
= a flyby sequence starts.*

*: Sometimes these are buggy. I.e. eg. the camera will switch back on if the player releases the Look key or if Lara holsters the weapon. (Moreover, sometimes it won’t even switch off if she draws the weapon.) Possibly you have more chance for the success, if the activator has left the trigger zone.
That is why I recommend using timer or F120 in these cases everyway to switch off the camera, so that you can surely switch it off when you want.

b, Only if an A41 trigger switched on the camera, if the activator was either Lara or not:

- the player hits the Look key (useful only with Camera), or
- Lara draws a weapon (useful only with Camera), or
- the timer of the A41 trigger expires, or
- an F120 trigger has been activated somewhere, somehow, or
- another static camera is activated, or
- a demo type cutscene or a camera for a demo type cutscene is activated.

Notes:

- A41 cameras and their timers are only suspended, not interrupted by flyby camera sequences.
- If the Look key is disabled/useless for a general looking around, then you can’t use it to deactivate cameras either.
- It is hard to say that triggers for static cameras use which working method. – For example:

=We need a single TriggerGroup for A41.
= CAMERA timer or A41 timer starts when the trigger is activated, even if Lara is in the trigger zone. – It is a “single” behavior.
= As I said above, CAMERA won’t switch off while Lara is in the trigger zone. – It is “multiple” behavior.
= CAMERA or A41 will never switch off if the CONDITION trigger overlapped with them goes false. – It is a “continuous” behavior.
= If the player releases the Look key when Lara is in the zone of TRIGGER CAMERA, that won’t switch the camera back on, though the conditions all became true again. (“Lara is in the trigger zone”+”Look is not pressed”.) – It is a peculiar behavior.
= Etc.

- From TRNG 1.3.0.0 you can type even an F406 trigger in the TriggerGroup of A41, to make the camera infinite. Another F406 (not scripted everyway) will abort it. (The benefit of it: other cameras will never abort it till F406 abortion, only suspend it.)

See more about working methods here:
http://www.tombraiderforums.com/show...29#post7060929

So, as you see, the main difference between CAMERA and A41 triggers is A41 camera can continue shooting even if Lara (if she is the trigger activator) has left the trigger zone!

Other differences between CAMERA and A41:

a, There are differences between deactivation methods. (See just above.)

b, CAMERA triggers cannot be exported into the Script/WADMerger. ACTION triggers can.

c, The biggest timer for CAMERA triggers is 255 seconds.
The biggest timer for A41 triggers is 127 seconds. (But you can use Organizer with the ACTION for even a much bigger time. For example, a TriggerGroup of an Organizer command will activate a non-timed A41 at once, then, after a given time, the Organizer will activate an F120 in another TriggerGroup.)

d, In the overlaps One Shot value is the own of the CAMERA trigger.
I.e. CAMERA casual trigger won’t adopt One Shot value of the special trigger or the casual triggers of the overlap won’t adopt One Shot value of CAMERA special trigger. – It is not true for a casual F118 (with that A41), that will adopt One Shot of the special trigger. (Though, if you want a One Shot for A41 in a “One Shot-less” overlap then you can use TGROUP_SINGLE_SHOT flag in that F118, so that is the own of that F118.)

See more about special and casual triggers here:
http://www.tombraiderforums.com/showthread.php?t=205393

e. Setups with switches:

- CAMERA trigger timer will fail with a switch that works only once, according to its animations, if there is an OBJECT trigger overlapped as well with the switch - with a positive or a negative timer - to activate an object.
The solution: choose the new, TRNG version to activate the camera (A41) and/or the object (A43).
- If Lara moves the switch back when a negative object timer is counting/has expired then CAMERA triggers won’t be activated. A41 will.
- Some switches (see eg. LEVER_SWITCHes) won’t be disabled physically by One Shot in SWITCH triggers. These switches will act a bit differently in some situations, as opposed to other switches do:

= SWITCH trigger with One Shot, Lara moves the switch back to “off” position, or (again) to “on” position: these operations affect only CAMERA triggers (without One Shot) below the switch, activating them.
= I don’t recommend typing a positive or a negative timer, for this kind of switches, to time an object, due to more reasons. For example, because CAMERA trigger timer also here will fail now.

- The “timer bug” won’t affect CAMERA triggers. – See here about the timer bug:
http://www.tombraiderforums.com/showthread.php?t=205564

f, Follow cameras and special effects (see just below) work only with A41. (In fact, they could work even with CAMERA triggers, but in a buggy way.)

g, If you can’t see the image on the screen when a static camera shot is being shown then (recommended with A41 camera triggers) try IF_OVER_FIXED_CAMERA or IF_OVER_FLYBY constants in the Image command.

Notes:

- A possible bug with LEVER_SWITCHes that perhaps will happen with some other switches as well:
“Thanks to” the geometry/size of the switch, Lara is not (always) standing (exactly) in the TRIGGERs below the switch when starting using the switch. (Standing on the adjacent square perhaps.) Maybe it is important, if you activate a camera with this switch, because maybe the camera won’t switch on if the lever gets into on position.

- Trigger number buttons are useful, if you want more than one trigger to activate one object. But those buttons are useless, if you want more than one trigger to activate a camera or a FLIPEFFECT etc.
But you can simulate that feature for any (!) executable trigger, if you use variables. – Let’s see this example:
Lara uses a switch to activate a camera. Nothing will happen, because she needs to use another switch as well for that camera.
Now the setup looks eg. this way:

= a switch (that works only once, according to its animations) on a SWITCH trigger and on an F231 (F231 will add value 1 to a variable),
= and another switch (that works only once, according to its animations) on another SWITCH trigger and on another F231 (F231 will add value 1 to the same variable).

And we need a GT_CONDITION_GROUP type GlobalTrigger, with this condition TriggerGroup: “if the value of that variable is 2”, and with this executable TriggerGroup (IdPerformTriggerGroup): “activate a given camera for X seconds”.
If Lara uses the first (any) switch then nothing will happen, because the variable value will be 1 now. But if she uses the other switch as well, then the variable value will be 2, so the camera will be activated now.

Remarks:

= The variable value must be surely 0 before activating those triggers.
= The triggers cannot be activated more than once, or else each usage of the switch will add value 1 to the variable again, so the camera will be activated not always when you want it. That’s why I said “switch that works only once” now – but, in a switch-free setup, you need to use eg. One Shot instead.
= The GlobalTrigger must have an FGT_SINGLE_SHOT flag or else the camera won’t be deactivated when the timer expires (because the variable value is still 2 when the timer expires, activating the camera again).
= Eg. if you have a door to open only if you use more switches, having camera triggers for the same camera (showing the door) under the switches, then each usage of each switch will activate that camera. But if you places F231 there instead of the camera triggers then you will be able to create a setup in which the camera will be activated only when all the switches have been used, showing the door only when that is just opening.
= This simple setup is not the best setup (see eg. because without One Shot you need a switch that works only once). I’m sure if you understand TRNG well then you will able to create better setups.
But this tutorial is not about how to create complex TRNG setups.

Non-Lara targets for static cameras:

You can define another target (instead of Lara) for the static camera (either with a CAMERA or with an A41 trigger), if you want.
No, it is not only a CAMERA_TARGET nullmesh, it could be any (!) Moveable object. – For example, if it is a creature, then the camera will turn towards it continuously, while the creature is moving, changing the camera angle automatically.

The triggers to activate a non-Lara target for a camera:

- The classic, TRLE method: TARGET trigger, naming the target in the trigger.
- The new, TRNG method: ACTION trigger (A42), naming the target in the trigger.

You need to combine the triggers for targets with the camera triggers in one of these ways:

- TARGET+CAMERA: the zones of the triggers are the same.
- TARGET+F118 (A41): it seems a buggy construction. I don’t recommend it.
- A42+CAMERA: A42 must be exported into a single TriggerGroup. The zones of the triggers (F118+CAMERA) are the same.
- A42+F118 (A41): A42 must be exported in the TriggerGroup of A41. (The order is important: A42 must always be the first trigger in the camera TriggerGroups.)

If you don’t know which version to choose, then here are the main differences:

a, “Do I choose TARGET or A42 for the CAMERA?”
TARGET is better, because A42 seems buggy with HEAVY.
Choose A42 if you want to export other triggers in the TriggerGroup of A42 as well.

b, “Do I choose CAMERA or A41 for the target?”
As you know, there are differences between CAMERA and A41 (see above).

Note:
If you use Drop Down Menu Bar\Objects\Change Object to change a placed object, and that object is the object of an ACTION or a TARGET trigger then the changed placed object will be the new object of the trigger, automatically.

2. Standalone camera targets

If you place a TARGET trigger, but without overlapping it with a trigger for a camera, then the game will force Lara, the only valid activator now (while she is in the trigger zone), to look at the point where the object in that TARGET trigger just is in the game.

Note:
Each standalone TARGET trigger can be used automatically once, before the next load of the game. But they can be activated (only once) again after you load a savegame. And once again after the next load etc.
(It works like a One Shot OBJECT trigger, i.e. any TARGET triggers are unable to draw Lara’s look to that target, before the next load of the game, if Lara activated one of these triggers.)
Force Value 32 in “Flags of Item (Long)” Item Memory Zone field with F255, after you naming the target object with an A54, so the TARGET trigger will be able to be activated once again, even before that save/load. (So this is the way to fix that “unintentional One Shot” bug.)

3. New camera effects with static cameras

Follow cameras:


The so-called “follow” cameras are Cameras or Fixed Cameras that will keep a constant distance to the target (usually Lara), while shooting at the target.

I.e. follow cameras are recommended if you want to link a camera to the target when that is moving.
Maybe you say the basic (chase, combat, look) cameras will do the same for Lara. But it is not really true – mostly, because, a follow camera will always keep at least one of its x, y, z coordinates in the game, i.e. a follow camera won’t follow Lara in every direction.

You must always start the effect with a “single” F118 (with an A41 in it), as if it were a “normal” (Fixed) Camera.
The F119 trigger (which defines the effect type) must be in the same TriggerGroup, or overlapped with that F118.

If the activator (Lara or else) activates those triggers then the (Fixed) Camera will switch on to shoot at the target. – But the camera switches on not exactly where it is placed, i.e. it depends on the effect type.
While the camera is on, it will follow the target – the way as it is defined by the effect type.

The camera can usually be switched off with the usual “switching (Fixed) Cameras off of A41” methods - but you must also adjust these values in F119 to switch off the camera in the required way:

- “forever”: A41 timer doesn’t work now,
- “same time…”: A41 timer works now, too,
- “current room”:

= if the target leaves the room where it was when the trigger was being activated, that switches the camera off, too, and
= A41 timer doesn’t work now.

When you switch it off, the camera will stop moving, and remain in its actual position.

If you want other target for the camera than Lara, then define the target with an A42 (in the TriggerGroup of the A41 camera trigger, as I said above).

See some effect type examples (with Lara targets this time) to understand the effect:

- East-West (in ngle) fixed other North-South and Up-Down coords:
The camera moves in east/west direction (according to Room Editor facing), keeping north/south and vertical position.

In this case, the camera always keeps its own north/south and vertical position as it is placed in the Room Editor. So if Lara is moving in north/south or vertical direction, then the camera will turn towards her when shooting at her, but not follow her. On the other hand, if she is moving in east/west direction, then the camera will follow her when shooting at her.
The following position is always in Lara’s actual north/south axis. So, when the camera switches on then the camera will jump from its actual position, in east/west direction, to a position in which the camera will be in the same north/south axis where Lara just is – and the camera will remain in the same north/south axis when she’s moving in east/west direction.

- East-West (in ngle) preserving North-South distance and fixed Up-Down coords:
The camera moves in east/west and north/south direction, keeping vertical position, preserving north/south distance.

In this case, the camera always keeps its own vertical position as it is placed in the Room Editor. So if Lara is moving in vertical direction, then the camera will turn towards her when shooting at her, but not follow her. On the other hand, if she is moving in east/west or north/south direction, then the camera will follow her when shooting at her.
The following position is always in Lara’s actual north/south axis. So, when the camera switches on then the camera will jump from its actual position, in east/west direction to a position in which the camera will be in the same north/south axis where Lara just is – and:

= the camera will remain in the same north/south axis when she’s moving in east/west direction, and
= the camera will preserve the north/south distance to Lara, while she’s moving in north/south direction.

- Horizontal axes fixed the Up-Down coordinate:
The camera moves in east/west and north/south direction, keeping vertical position.

In this case, the camera always keeps its own vertical position as it is placed in the Room Editor. So if Lara is moving in vertical direction, then the camera will turn towards her when shooting at her, but not follow her. On the other hand, if she is moving in east/west or north/south direction, then the camera will follow her when shooting at her.
The following position is always in Lara’s actual north/south and east/west axes. So, when the camera switches on then the camera will jump from its actual position, in east/west and north/south direction to a position in which the camera will be in the same north/south and east/west axes where Lara just is – so the camera will be exactly on/above/below her. (If it is “on”, “above” or “below” that naturally depends on the kept vertical position of the camera.)
The camera will naturally remain exactly on/above/below her when she’s moving in east/west or north/south direction.

So, as you see:

- A direction without an attribute (eg. “east-west” without “fixed” or preserving”) - including directions not mentioned (see eg. the missing “east-west” and “north-south” in “Horizontal axes fixed the Up-Down coordinate”) - means the camera is jerked in that direction, to be positioned in the other horizontal axis of Lara. (Eg. if the direction without attribute is “east-west”, then the other axis is “north-south”.) Then the camera will follow Lara in that “attribute-less” direction, remaining in that axis.
(Or, if it is “up-down”: the camera will be jerked upwards or downwards, to be in the same vertical position where Lara is. Then the camera will follow Lara upwards/downwards.)
- A direction with “fixed” attribute (eg. “fixed up-down”) means the camera won’t follow Lara in that direction, keeping the original, Room Editor position of that coordinate.
- A direction with “preserving” attribute (eg. “preserving north-south”) means the camera (just positioned by the “direction without attribute”) will follow Lara in that “preserved” direction, keeping the distance between the camera and Lara in that direction.

Notes:

- The camera is not allowed to bump against a wall, while Lara is moving in the “preserved” direction. (Eg. Lara moves southwards. The preserved distance is north/south, so sooner or later, the camera bumps against a south wall. Lara keeps going southwards, but the camera can’t go southwards more, that is why the distance will change between them unintentionally.)
- The effect could be a bit buggy if some key command is linked to that. For example, if you use a shatterable vase with a HEAVY to switch on the effect with a Fixed Camera, then, in the “East-West (in ngle) fixed other North-South and Up-Down cords” case, the camera will switch on but (sometimes?) be jerked to Lara’s axis only when the player releases Action (CTRL) that (s)he used for shooting.

Special effects:

F123 trigger will perform a special effect with Cameras/Fixed Cameras, usually on Lara. You can select the effects in the trigger:

- Enemy effect: it works for Lara like a customized chase camera.
- Matrix effect: the camera will rotate around the vertical axis of Lara. (First the camera starts in front of her. If you start the effect more than once, then the camera will remember the angle in which it stopped the rotation last.)
- Portrait effect: you can achieve the same effect on Lara as if you customized the chase camera to show her front-wise.

Other definitions in the trigger:

- Same up/down: the camera will be in the same vertical position where Lara’s pivot is.
- Upper than: the camera will be higher than Lara’s pivot is.
- Preserve up/down: it is a similar “preserving” case as with F119 trigger. (I.e. first the camera is on the same vertical position where Lara’s pivot is, but, after that, at the next switching-on, it restores the actual vertical position of the camera. - I’m not sure it works for each effect where it is mentioned.)

As you see, usually it doesn’t really matter where you place the Camera/Fixed Camera, because F123 will define the camera position for the effect. – Except:

- The trigger will define the radius (horizontal position) for the Matrix effect, but the camera vertical position is the Camera/Fixed Camera position in Room Editor.
- The trigger will define the distance (horizontal position) in the “preserve up/down” case, but the camera original vertical position (before the very first activation) is the (Fixed) Camera vertical position in Room Editor.

You must always start the effect with a “single” F118 (with an A41 in it), as if it were a “normal” (Fixed) Camera.
The F123 trigger must be in the same TriggerGroup, or overlapped with that F118.

If the activator (Lara or else) activates those triggers then the (Fixed) Camera will switch on to start the effect on Lara.

The camera will always switch off with the usual “switching (Fixed) Cameras off of A41” methods. – Except:

- I don’t recommend trying to stop the effects with activating another camera trigger.
- If you don’t time the matrix effect, then only one turn will be performed, and then the camera will switch off automatically.

When you switch it off, the camera will stop moving, and remain in its actual position.

If you want other target for the camera than Lara, then define the target with an A42 (in the TriggerGroup of the A41 camera trigger, as I said above).

Cameras for demo type cutscenes:


I don’t want to talk about demo cutscenes now.
But I mention demo cutscene cameras now, because you can use them even out of cutscenes.

You can have several Cameras and Fixed Cameras placed in the map for several camera tasks. If a demo cutscene camera trigger is active then it will “borrow” one of the Fixed Cameras, “carrying” it whereto it will use it.
If the camera shot time expires, then the camera will be “carried back” to its own position. (The “own position” is not the “Room Editor position” everyway. I mean, see eg. the follow camera above: it can be activated in different positions. Always the actual position is the “own position” in that case.)

These are the triggers to activate demo cutscene cameras:

- F381: the camera is looking at the leading actor,
- F382: the camera is looking at the extra actor,
- F383: the camera is looking at Lara,
- F395: the leading or the extra actor is looking at Lara in “first person” mode,
- F396: Lara is looking at the leading or the extra actor in “first person” mode.

But why do we need demo cutscene cameras out of cutscenes? – Well, it could be useful eg. if you want different camera shots at a given point of the level – without using complex condition+executable trigger sequences.
For example, in Position A of the level an F381 camera will show the actual leading actor. (Which actor is not a real actor of a demo cutscene this time, because we are out of cutscenes now.) Lara is able to reach that point from X direction or from Y direction. When she comes from X direction then she crosses an A87 to make a puzzle item the leading actor. When she comes from Y direction then she crosses another A87 to make a lever switch the leading actor. – When she reaches Position A with F381:

= if she came from X direction, then the camera will show the puzzle item, saying: “if you find the puzzle item then you can open Door B with it, to go further, Door C is useless now” (because the switch is unavailable if you came from this direction),
= if she came from Y direction, then the camera will show the lever switch, saying: “if you find the lever switch then you can open Door C with it, to go further, Door B is useless now” (because the puzzle item is unavailable if you came from this direction).

Or: this camera always has a given position to its target, so it will follow its target when that is moving. – It is useful if you think follow camera or special effect setups (see above) are too complicated for you.

Notes:
- Cameras for demo type cutscenes and their timers are only suspended, not interrupted by flyby camera sequences.
- If the target is moving, then the camera will move with it so the camera will keep the angle and distances. – Except:
The camera will start keeping its actual position if you activate an F391 trigger. After the given frames (defined in F391), the camera will stop keeping the position and jump into another position (i.e. restarting keeping that angle and distances again) to continue following. – But:

= I don’t recommend more than 255 frames in F391, because the effect seems buggy.
= If the frame is 0 in F391, then the camera will keep the position “forever”. Activate an F392 to abort the keep.

Using modes of the cameras:

- Usually you control a demo cutscene this way:
F379 will start the demo, which will start the FO_DEMO_ORGANIZER Organizer at once. The first TriggerGroup of the Organizer will adjust some basic tasks (transporting creatures with A40 to demo start positions, activating actors, defining the text parameters for them etc.) at once, then one or more TriggerGroups after each other will use A91 triggers to start the given Parameters= PARAM_ACTOR_SPEECH sequences for the given objects. While those PARAM_ACTOR_SPEECH sequences are working by themselves, the Organizer will continue activating other TriggerGroups (eg. to activate cameras etc.).
So you need to export the camera triggers into the Script.

The demo cutscene camera will stop shooting if you activate another demo cutscene camera or if you activate an F384 or an F394. – Don’t forget to stop these cameras at the latest when the demo cutscene ends.

- Using cameras out of cutscenes:
The camera triggers must be exported in a TriggerGroup. The F118 of that TriggerGroup (always in “multiple” mode) must be placed in the map.
It works as the good old CAMERA triggers. It mostly means the camera is active only when Lara is in the trigger zone.

Features available only in demo cutscenes:

The camera angle and the horizontal distance of the camera to the target object are defined in the camera trigger itself. The vertical position of the camera is always at the same vertical position where the pivot of the target object is. – If you want to change those parameters (only with F381, F382, F383 cameras!) then these are your possibilities:

- F385: the camera moves in the required clicks upwards (while the given frames elapse).
- F386: the camera moves in the required clicks downwards (while the given frames elapse).
- F387: the camera comes closer to the target, horizontally, in the required clicks (while the given frames elapse).
- F388: the camera goes farther from the target, horizontally, in the required clicks (while the given frames elapse).
- F389: the camera turns right (from the target’s POV), in the given angle (while the given frames elapse).
- F390: the camera turns left (from the target’s POV), in the given angle (while the given frames elapse).

Always export the possible F385-F390 triggers into the TriggerGroup of its camera trigger, always typing them after the camera trigger.

Note for F387:
If the required clicks are more than the actual distance then the camera will get on the other side of the target. Eg. the actual distance is 5 clicks, looking at the face of the target. If the movement is 8 clicks then 5-8= -3, so the camera will look at the back of the target, in 3 clicks distance.

Actors:

Actors are Moveable objects (mostly creatures) that can be controlled in a different way, as opposed to you can control them in the “real” game.
Usually you can have maximum three actors in a demo cutscene:

- Lara herself (because we can’t control her in the demo playing),
- the so-called leading actor (optional),
- the so-called extra actor (optional).

Any Moveable object can be either a leading or an extra actor. - The differences between being a leading and an extra actor:

- Leading actors are able to activate HEAVY/HEAVYANTITRIGGER triggers, extra actors are not.
- C88-C91 conditions are useless with extra actors. (Though you can try a similar ENV constant for any object.)
- See PARAM_MOVE_ITEM Script constant: some DIR constants (to adjust the direction for the movement) work only for the leading actor.

The common properties of the leading/extra actors are they lose their artificial intelligence, so they are “brainless dummies” (quoted from Paolone), so they will do anything only if we force them to do something.

Usually you need an A86 trigger to start/stop actors. If you activate an actor with A86, then you need to know this:

- If there is no leading or extra actor, then A86 will activate the given object as the leading actor.
- If there is the leading actor but there is no extra actor, then A86 will activate the given object as the extra actor.
- If there are both the leading and the extra actors then A86 will activate the given object as a “bonus” actor.
“Bonus” actors are less useful in cutscenes than the other actors. They are “brainless” just like the leading/extra actors, but some features that work only with leading/extra actors don’t work with bonus actors. (For example cutscene camera triggers are useless for bonus actors.)

If you want another leading/extra actor, then you can turn any object into a leading/extra actor any time, with A87.
For example, you have a leading and extra actor already when you turn an inactive (“invisible”) creature with A87 into a new leading actor. Now the extra actor will remain the same, the previous leading actor will turn into a bonus actor. – After that, you use A86 to activate that inactive object, i.e. to activate your new (leading) actor.

Notes:

- If an object is just a brainless actor then all the objects of its slot are brainless, too.
So you mustn’t use an enemy as a real enemy if another enemy of that slot is just working as an actor.
- If you save the game and then load that then the actors will turn back into “real” objects, losing “actor” status, having their AI again. (Use eg. a GT_ALWAYS or a GT_LOADED_SAVEGAME GlobalTrigger to execute A86 or A87 to restore the actor status. Disable the GlobalTrigger if you don’t want to restore it any more.)

4. Flyby cameras

More flyby cameras compose a flyby camera sequence.

The methods to activate a flyby camera sequence with a trigger:

- The classic, TRLE method: OBJECT trigger (naming the first camera of the sequence).
- The new, TRNG method: ACTION trigger (A45) (naming the first camera of the sequence), in “activate” mode.

The methods to deactivate a flyby camera sequence:

- the sequence ends by itself (it is possible only if the sequence is not a loop), or
- you can abort the sequence:

= hitting the Look key – except if you press Button9 at that first camera in OCB panel, to disable Look, or
= hitting any key (see CUST_ESCAPE_FLY_CAMERA constant in a Customize Script command), or
= a demo type cutscene is activated, or
= activating an A45 trigger (naming the first camera of the sequence), in “untrigger” mode.

Usually you can choose any methods to activate a flyby sequence but there are differences between the classic and the new methods:


- OBJECT is multiple, ACTION is single. (It could be important eg. if Lara is still in the proper position to activate the flyby sequence, when the sequence ends. For example, if Lara is in the trigger zone of a TRIGGER OBJECT to activate a flyby sequence when the sequence ends, then the multiple effect will re-activate the sequence – except, if you used One Shot for the trigger.)

See more about here what single or multiple is:
http://www.tombraiderforums.com/show...29#post7060929

- OBJECT triggers cannot be exported into the Script/WADMerger. ACTION triggers can.

- In the overlaps One Shot value is the own of this flyby OBJECT trigger.
I.e. OBJECT casual camera trigger won’t adopt One Shot value of the special trigger or the casual triggers of the overlap won’t adopt One Shot value of OBJECT camera special trigger. – It is not true for a casual A45, that will adopt One Shot of the special trigger. (Though, if you want a One Shot for A45 in a “One Shot-less” overlap then you can use TGROUP_SINGLE_SHOT flag in a F118 with an A45 in it, so that is the own of that F118.)

See more about special and casual triggers here:
http://www.tombraiderforums.com/showthread.php?t=205393

- “Anti” triggers only with A45 will work to activate flyby camera triggers. - See adopting rule “f” exception here to understand what it means:
http://www.tombraiderforums.com/showthread.php?t=205393

Notes:

- You can have maximum eight flyby camera sequences in a level, from ID 0 to ID 7.
- If a switch activates a flyby sequence, then that will activate it, either Lara switches on the switch or if she switches it off. But nothing will happen if she uses the switch when the sequence is just being performed.
- If you remove a Flyby Camera from the map then the classic TRLE triggers to activate/deactivate it will be deleted as well automatically.
But, if a TRNG ACTION trigger activates/deactivates a Flyby Camera then don’t forget to delete that trigger after you deleted that Flyby Camera, because this time the triggers won’t be deleted automatically.
- Other customization for flyby cameras: CUST_PAUSE_FLY_CAMERA, CUST_TEXT_ON_FLY_SCREEN.
- F369 will simulate the black stripes of the flyby cameras (without performing any flyby camera shots), for a given time.
- Never use FLYBY trigger for flyby cameras in a level. FLYBY triggers are used for the title, to link the flyby sequences to each other.
- Linking camera sequences to each other in a level, but without cutcams, is possible in TRNG:

Put these two ACTION (A45) triggers in a TriggerGroup, in this order:

a, abort the first sequence
b,start the second sequence

Where the camera with OCB14 is placed (i.e. wherefrom you want to jump), use a HEAVY F118 to start the TriggerGroup.

Important note!
The setup won't work if you want to jump between two separated parts of a sequence.
So use it only if you want to jump from a sequence to another sequence.

- See more about flyby cameras eg. in TRLE manual or some TRF tutorials

5. Chase, combat and look cameras

You couldn’t do anything with the basic (chase, combat, look) cameras in TRLE – but with TRNG, you will be able to change their values:

a, You can customize the basic (chase, combat, look) cameras, with a Customize= CUST_CAMERA Script command.
PARAM_SET_CAMERA constant (in a Parameters Script command) will do the same, except: the customization will be valid only for a given time, activated by F214. (If you activated the customization “forever”, then disable that by F215.)

b, F121 will disable the combat or the look camera. F122 will restore that.

c, The standby camera effect is a special effect that will be accomplished by the chase camera. (Mostly it is something similar – eg. Matrix effect – what an F123 can do on Lara target, see above.)
Use a StandBy Script command to define that effect. The effect of a given StandBy command will be started by F346, for a given time.

Notes:

- The StandBy that has ID 1 is a special one, because it will be started automatically, if the player won’t hit a key for a given time.
- You can create maximum 49 StandBy commands for each level, choosing ID’s for them from a 1, 2, 3,…498, 499 interval. However, the biggest StandBy ID in that F346 trigger is 255.
For the time being, StandBy with ID256-ID499 can’t be used for any purposes.
- I don’t recommend mixing the usage of a standby effect with another camera. (Eg. if a Fixed Camera is just shooting when you activate a standby.) All of those things seem buggy for me.

d, Use F279 to force a value in “Camera Mode Next (0='follow me', 1='fixed', 2='look'; 3 ='combat') (Long)” Code Memory Zone field:

Force 2:

- the look camera will work when you should see the chase camera, and
- if you use the look keys+arrows to look around, then the camera will keep the last position when releasing the keys, and
- if a standalone TARGET draws Lara’s look then this camera position will be kept after leaving the trigger for the TARGET, and
- you can’t activate triggers for Cameras (but you can for Fixed Cameras*)

Force 3:

- the combat camera will work when you should see the chase camera, and
- you can’t activate triggers for Cameras (but you can for Fixed Cameras*)

Export F279 in a TriggerGroup and force it continuously (with a GlobalTrigger, or activating the TriggerGroup with an F118/F373). If you stop the forcing (disabling the GlobalTrigger, or making the GlobalTrigger condition false, or with an F192 for the F118/F373 triggers), then the effect will stop.

Notes:

- *: Don’t activate a Fixed Camera in a new, TRNG way (i.e. by an ACTION trigger exported into a TriggerGroup) if you force this value.
- Don’t use F279 now if a flyby camera sequence is just working.

Made using TRNG 1.2.2.7.

Last edited by AkyV; 22-04-17 at 10:50.
AkyV is online now  
Closed Thread

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 17:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.