Ghostdog AI tutorial

Lithtech 2.1 Cobalt
Post Reply
User avatar
Spawn
Admin
Admin
Posts: 1124
Joined: Sun Jul 25, 2004 12:50 am
Location: Norway
Contact:

Ghostdog AI tutorial

Post by Spawn » Tue Jan 15, 2019 10:52 pm

Image

AIRegion

AIRegions are used to define the behavoir of AIs triggered into 'Search' state.

If an AI is triggered into 'Search' state, it can always use the SearchNodes in the AIVolume it is currently in. If you want him to use SeachNodes in other AIVolumes too, you have to connect these AIVolumes through an AIRegion.
The AI will then first use the SearchNodes in it's current AIVolume, then it will continue with the SearchNodes in the AIVolumes that are in it's current AIRegion.

To connect AIVolumes with an AIRegion you just need to put in the names of these AIVolumes in the Volumes fields of the AIRegion.

Image

In the situation shown above are several AIVolumes, some of them connected to an AIRegion (indicated by the yellow arrows if the AIRegion is currently selected in the NodeTree).

The AI - if triggered to 'Search' state by any event - will first search on SearchNode1 (because it's in the AIVolumeit is currently in) and then continue to SearchNode2 (because it's in an AIVolume that's connected to the AIRegion it's currently in). The AI will not use SeachNode3.

If the AI is in the AIVolume that SearchNode3 is in while triggered to 'Search' state, it will only use SearchNode3.

If two or more AIs are searching in an AIRegion, every SearchNode will only be used one time, means if one of the AIs has been there, the others will not consider using this Node again (until they are triggered to 'Search' state the next time).
The properties of the AIRegion are:

Pos: The absolute position of the AIRegion object (has no effect).
Rotation: The rotation of the AIRegion object (has no effect).
Volumes: As already said, here you have to put in the names of the AIVolumes connected to this AIRegion.
Search: You can use the PostSearchMsgxx fields to send messages. The first message will be sent if the first of the searching AIs has no more SearchNodes left, the second message will be sent if the second of the AIs has no more SearchNodes left etc...

AIVolume

AIVolumes define the space which AI can travel.

An AI can not really see the brushes that make up the world, in the way of "There's a wall, I cannot go this way". They navigate through the world by using the AIVolumes. The AIVolumes tell the AI where it can go and where not, while the physics of the game hold his feet onto the next ground.

This leads to the following notes:

Note: You should avoid having any objects inside and AIVolume, besides from stairs/steps which you want the AI to be able to go up and down or small objects that the AI can step over.
If you put bigger objects - for example a 128px high wall - into an AIVolume, the AI will walk up to it (because the AIVolume tells the AI it can go there) and suddenly be on top of the wall (because the physics of the game request this). To make it even worse: The AI may just walk right into the wall.

Note: To make sure an AI can get from one AIVolume to another, they should touch each other a minimum of 64px wide (it may work with less, but it can cause problems).

Image

You can create an AIVolume by setting up a brush floating 16px above the floor, 16px high (These values are not absolutely necessary ones, but generally good ones. Remember: the phyics hold the AI on ground level, the AIVolumes tell him where it can go).

Now place the marker somewhere on the top surface of the brush, select it and bind it to an AIVolume Object.

That's basically all, the brush will be invisible in-game and the AI will be able to move through the space it takes.

Note: There's an extra texture for AIVolume-brushes in the main TEX folder. This helps keeping the overview.

Now on to stairs/steps. You actually don't need to make an extra AIVolume for every step. As said before, if the steps are not to high you can cover them completely by one AIVolume. If you do it like shown in the picture, it should work correctly.

Image

The vector shown in the picture can be put in the StairsDir field, which will cause dead AIs to fall down the stairs. The vector is parallel to the floor, means the y-value is always zero (-1 0 0 or 0 0 1 ...)

Image

At last the LedgeDir field can be used if you have an AIVolume along a ledge like shown in the picture.
If you set a LedgeDir vector here, dead AIs will fall down the ledge.
This vector is also parallel to the floor.

The properties of the AIVolume are:

Pos: The absolute position of the AIVolume object.
Rotation: The rotation of the AIRegion object.
StairsDir: Can be used to make dead AIs falling down stairs (as described above).
LedgeDir: Can be used to make dead AIs falling down ledges (as described above).
Vertical: This is for underwater scenarios. You can connect two AIVolumes on different heights by a third one which has it's vertical flag set to 'True'. The AI can then move up and down between the different heights.
ViewNode(s): These fields are for putting in the names of AINodes that work as ViewNodes to this AIVolume. Read more about ViewNodes.


AINode

AINode are special points the AI can use for special purposes.

Image

ai node 01

As I already said, AIs do not really see the brushes the world consists of, so they will not be able to think something like "There's a crate, let's duck behind it". If you want them to do such things, you have to tell them where.
If you do not use AINodes, the only thing they can do is 'rush' after you.
You must place AINodes in AIVolumes, so that they are reachable to the AI. Place the marker on the top surface of an AIVolume, and add an AINode object to the world.
Note: Don't put AINodes to close to walls (or other brushes), so that the AI will not clip into them. 16px should be the minimum.
You can use the Rotation tab to set the direction the AI will look if using this AINode.
Until now the AINode has no purpose, so it's not more like a point the AI can run to and look in the specified direction. Actually I don't know if it will use it at all.
You can now set the purpose of this AINode by setting one of the flags under one of the tabs (CoverInfo,PanicInfo,...) to 'True'.
Note: Avoid using one AINode for more that one purpose, this may cause problems.
We will talk about the different purposes of the AINode in seperate chapters.

The properties of the AINode are:

Pos: The absolute position of the AINode object.
Rotation: The rotation of the AINode object sets the view direction of an AI using this AINode.
• CoverInfo
• PanicInfo
• VantageInfo
• SearchInfo
• MiscInfo
• ViewNode at last isn't a property, but one of the things you can use an AINode for.



AIGroup

AIGroups allow AIs to share there senses, means all AIs in a group can react on an event that happens to one of them.
There's not much more to say to this. Just put in the names of the member AIs in the Member fields. This activates the GroupReactions tabs of the AIs belonging to this AIGroup.
Note: Although I didn't try I guess it's no good idea to have an AI in more than one AIGroup.
The properties of the AIGroup are:

Pos: The absolute position of the AIGroup object (doesn't affect anything).
Rotation: The rotation of the AIGroup object (no effects again).
Memberx: The names of the AIs belonging to this AIGroup.


CAI

These are the different kind of computer controlled characters you can use.

There are three groups of AIs: good, neutral and bad. While 'good' AIs attack 'bad' ones and the other way round, 'neutral' ones seem to attack everyone who threatens them with a weapon - if they have a weapon themselves that is.
Every AI will switch to 'Panic' mode if they don't have a weapon, the difference is that 'good' or 'bad' ones will switch directly when they see an AI of the opposite site, while 'neutral' ones only switch when they are threatened, i.e. when somebody with a weapon gets to close to them for too long.
Note: The player is per default a 'good' character.

If you place an AI in your level, just make sure that it's bounding box (which is displayed) doesn't clip into any objects. If you place the AI hovering over the ground, the game will take care that it's placed on the next ground underneeth when the level starts.
The AIs have many different attributes which set their behaviour. You can find them all in 'aibutes.txt' in the 'attributes' folder. Because every attribute has a short description, it's very useful to have a look at this file.
- First there are different kinds of 'brains', which set the 'dynamical' behaviour of an AI, things like 'how often to check for cover', 'how often to consider throwing a grenade' or 'how often to play a partol sound'. Most of these values have and additional random amount to make reactions less determinated.
- Next are the global values which affect every AI. Things like 'rate at which senses are increased when alerted' or 'how far carries an ally death noise'.
- At last the templates for every CAI which set the 'static' attributes of this CAI, here you will find things like 'WalkSpeed', 'Hitpoints' or 'Accuracy'. These are the ones that can be overridden by the AttributeOverride tab.
Most important are the IndividualReactions and GroupReactions tabs:
If you have a single AI (not in an AIGroup), it will react to an event according to the setting in it's IndividualReactions tab.
If you have a several AIs in an AIGroup, the one that the event happens to will react according to it's IndividualReactions tab while all other AIs in the group will react according to their settings in the GroupReactions tab.
The prefixes of the event names:
ISE... - Individual Sees Enemy...
IHE... - Individual Hears Enemy...
ISA... - Individual Sees Ally...
IHA... - Individual Hears Ally...
GSE... - Group Sees Enemy...
GHE... - Group Hears Enemy...
GSA... - Group Sees Ally...
GHA... - Group Hears Ally...

Now to the suffixes:
...1st is the first time the event occurs. Let's say the ISE1st event occurs. Now - according to the actual state of the AI (normal,aware,alerted etc.) - there's a reaction time until it checks for this event the next time. There are two possibilities what happens then. If the event still happens (the AI stills sees the enemy) that would be the ISE event and the according reaction would be performed. The other possible event is the ...False1st one (in this case ISEFalse1st) and again the specified reaction takes place. That leaves the ISEFalse event left. This is the event that happens if the AI looses sight after the ISE already happened.
So the 'event chain' for the ISE (Individual Sees Enemy) event looks like this:

Image

The properties of the CAI are:

Pos: The absolute position of the CAI.
Rotation: The rotation of the CAI (sets it's initial view direction).
DamageProperties: These values are most self-explanatory. Because they are present for many WorldObjects, I may cover them in an extra chapter.
MoveToFloor: Not quite sure. I guess it tells the game to 'put' this CAI on ground-level when the level starts.
ShowDeadBody: Don't know what the possible values are. I guess it's just a time value, where '-1' means forever.
HeadExtension: ?
CinematicExtension: ??
BodySkinExtension: ???
ModelStyle: The style of this model.
Brain: Defines which 'brain' this CAI uses, means the according values in the 'aibutes.txt'.
Attachments: You can attach objects to the CAI here. Weapons and stuff.
IndividualReactions: Defines the reactions to events that happen to this CAI.
GroupReactions: Defines the reactions to events that happen to another CAI in the same AIGroup as this one.
Commands: The 'initial' field is for commands the AI should perform right at start of the level (patroling etc.), the other ones I'm not sure about.



CoverNode

A CoverNode tells the AI where it can take cover.

Place the AINode in a place that can be used for cover. Then activate one of the flags under the CoverInfo tab. This AINode is now a CoverNode.

The Rotation (i.e. the view direction) should be set to the direction from which the enemy will approach. If the enemy comes from a different direction, not crossing the FOV (Field of View) assigned to this AINode, it will not be used.

Image

I will loose a few extra words about the 1WayStep property here, the rest of them are quite self-explanatory or can be explained in a few words down in the properties section.

For the 1WayStep- sidestepping out of a cover - you will have to set the stepout-direction by setting the Roll property (in the rotation tab) to 0 or 180, where 0 means right (according to view direction) and 180 means left. It is also indicated by a little red line in the Node object.
Place the Node as shown in the picture (16px away from the corner in each direction), and set view direction direct to the wall.

The properties of the CoverNode are:

Pos: The absolute position of the CoverNode.
Rotation: The rotation of the CoverNode sets the view direction of an AI using this Node, and (together with the CoverFov) the area in which the player has to be to make the AI consider using this Node.
Vantage: The AI will duck here.
Blindfire: The AI will duck, hold his gun over his head and shoot blindly over the object before him.
1WayRoll: I could not see what this is good for, since they do this rolling thing without AINodes too. Maybe a leftover from a previous version?
2WayRoll: Same as for 1WayRoll.
1WayStep: The AI steps out of the cover (described above).
2WayStep: For thin cover objects. The AI can step out of the cover in both directions.
IgnoreCoverDir: If set to 'True', The AI can use this point to cover in all directions, ignoring the direction settings (i.e. a 360° FOV).
CoverFov: Field (angle) Of View.
CoverRadius: The area in which the AI has to be to consider using this Node.
CoverThreatRadius: If the player gets into this radius, the AI will perform the CoverThreadReadiusReaction.
CoverThreadReadiusReaction: See above. Default command is 'attack': the AI leaves cover and attacks.
CoverObject: A 'trigger' command will be sent to this Object when the AI reaches the point. Good for flipping over tables and such things.
CoverTimeout: After this period of time, the AI will execute the CoverTimeoutCmd.
CoverTimeoutCmd: See above. Default command is 'reevaluate', means the AI 'overthinks' the actual situation.
CoverDamageCmd: This command is executed if the AI takes damage while using the cover. Don't know how much damage is has to get...
CoverHitPointsBoost: If the AI takes the cover, it will get this times as much as it's actual hitpoints? Not quite sure about this. Anyone?

ViewNode

The ViewNode tells the AI where to look for the player if it has not traversible path to the AIVolume the player is currently in.

You can make a Node to a ViewNode by not activating any of it's purposes (cover, vantage etc.) and giving the name of this AINode to the AIVolume(s) that should be seen from this ViewNode.
Note: For this to work the AI must know in which AIVolume the player is currently in. The ViewNode has no search function.
As I mentioned before the AI can not see and consider the brushes that make up the world, so if AI looses sight of the player it basically does nothing else but to try reaching the AIVolume the player got to by moving through the AIVolumes it can reach. So if there's not path to the player (an AI on top of the roofs while the player is on the streets below), he will often not be able to get the player back in sight - without (carefully) placed ViewNodes.
A few examples:

Image

In this case the player goes up the stairs to start shooting at the two AIs in the room.
Without the ViewNode the AIs will stay inside an shoot at you as long as they can see you. They will not leave their current AIVolume, because there is no traversal path to the upper AIVolume for them, so they just can not imagine whereelse to go to shoot at you.
With the ViewNode however the AI has a clue about an alternative viewing point to the AIVolume you're currently in. This leads to the situation that one AI stays in the room, while the other one goes out to the ViewNode. Crossfire!

Image

Now a slightly different situation. I must say I'm still not quite sure about this, I tested it many times with small variations and I can only say: I THINK it's like this.
After you showed up at the upper AIVolume you step back to the small AIVolume on the stairs. The enemy now still knows where you are for a certain amount of time, although he cannot see you. But he has no ViewNode to this AIVolume, so he stays inside.
Now if you jump down to the AIVolume to which he has a ViewNode, BEFORE this certain amount of time is over, he will use the ViewNode.
If you jump down AFTER this certain amount of time, he will have 'lost knowledge' about your position and stays inside.

...which leads - IF RIGHT - to the following:

Note: If the AI looses sight of you, it will know for a certain amount of time in which AIVolume you currently are, no matter
- if this AIVolume is connected to the one the AI is currently in.
- if you crossed an area which is not covered by any AIVolume to get there.
If the AI don't manage to get you back in sight in this time, it will loose knowledge about you position.
As a last example I shamelessly copy-pasted in what John Mulkey said about the ViewNodes in the forum:
"View nodes are used when an AI can fight the player but does not have a traversible path to the player. (makes them appear to be jockeying for the best firing angle and anticipating the players moves). An example would be a bridge over a crevass. If the bridge has AIs on it and the player is at the bottom of the crevass, there will be a point where the player can cross under the bridge and emerge on the other side. The effect you would want would be that the AIs cross to the opposite side of the bridge to catch the player coming out from under the other side."
"That's where the view nodes come into play. First you would put an AI volume on each side of the bridge down in the crevass where the player will be. Now in each of the AIVolume objects refence AINodes that you have placed on the corresponding sides of the bridge. This way, when the AI loses sight of you, they will ask "What volume is the player in?" and then "Is there a view node associated with that AI Volume?" They will then go to that AINode and try to blow you away."

Well, that does it, I think :)

The properties of the ViewNode are:

Pos: The absolute position of the ViewNode.
Rotation: The rotation of the AINode sets the view direction of an AI using this AINode.

VantageNode

VantageNodes give the AI clues about good firing positions.

If you already read about AINodes and CoverNodes, there's really nothing to add here. So I will only list the properties.
The properties of the CoverNode are:

Pos: The absolute position of the VantageNode.
Rotation: The rotation of the VantageNode sets the view direction of an AI using this AINode, and (together with the CoverFov) the area in which the player has to be to make the AI consider using this Node.
Vantage: Makes this AINode a VantageNode.
IgnoreVantageDir: If set to 'True', The AI can use this point to vantage in all directions, ignoring the direction settings (i.e. a 360° FOV).
VantageFov: Field (angle) Of View.
VantageRadius: The area in which the AI has to be to consider using this Node.
VantageThreatRadius: If the player gets into this radius, the AI will perform the VantageThreadReadiusReaction.
VantageThreadReadiusReaction: See above. Default command is 'attack': the AI leaves the Node and attacks.
CoverDamageCmd: This command is executed if the AI takes damage while using the Node. Don't know how much damage is has to get...

ViewNode

The ViewNode tells the AI where to look for the player if it has not traversible path to the AIVolume the player is currently in.
You can make a Node to a ViewNode by not activating any of it's purposes (cover, vantage etc.) and giving the name of this AINode to the AIVolume(s) that should be seen from this ViewNode.

Note: For this to work the AI must know in which AIVolume the player is currently in. The ViewNode has no search function.

As I mentioned before the AI can not see and consider the brushes that make up the world, so if AI looses sight of the player it basically does nothing else but to try reaching the AIVolume the player got to by moving through the AIVolumes it can reach. So if there's not path to the player (an AI on top of the roofs while the player is on the streets below), he will often not be able to get the player back in sight - without (carefully) placed ViewNodes.
A few examples:

Image

In this case the player goes up the stairs to start shooting at the two AIs in the room.

Without the ViewNode the AIs will stay inside an shoot at you as long as they can see you. They will not leave their current AIVolume, because there is no traversal path to the upper AIVolume for them, so they just can not imagine whereelse to go to shoot at you.

With the ViewNode however the AI has a clue about an alternative viewing point to the AIVolume you're currently in. This leads to the situation that one AI stays in the room, while the other one goes out to the ViewNode. Crossfire!

Image

Now a slightly different situation. I must say I'm still not quite sure about this, I tested it many times with small variations and I can only say: I THINK it's like this.

After you showed up at the upper AIVolume you step back to the small AIVolume on the stairs. The enemy now still knows where you are for a certain amount of time, although he cannot see you. But he has no ViewNode to this AIVolume, so he stays inside.

Now if you jump down to the AIVolume to which he has a ViewNode, BEFORE this certain amount of time is over, he will use the ViewNode.
If you jump down AFTER this certain amount of time, he will have 'lost knowledge' about your position and stays inside.
...which leads - IF RIGHT - to the following:

Note: If the AI looses sight of you, it will know for a certain amount of time in which AIVolume you currently are, no matter
• if this AIVolume is connected to the one the AI is currently in.
• if you crossed an area which is not covered by any AIVolume to get there.
If the AI don't manage to get you back in sight in this time, it will loose knowledge about you position.
As a last example I shamelessly copy-pasted in what John Mulkey said about the ViewNodes in the forum:

"View nodes are used when an AI can fight the player but does not have a traversible path to the player. (makes them appear to be jockeying for the best firing angle and anticipating the players moves). An example would be a bridge over a crevass. If the bridge has AIs on it and the player is at the bottom of the crevass, there will be a point where the player can cross under the bridge and emerge on the other side. The effect you would want would be that the AIs cross to the opposite side of the bridge to catch the player coming out from under the other side."

"That's where the view nodes come into play. First you would put an AI volume on each side of the bridge down in the crevass where the player will be. Now in each of the AIVolume objects refence AINodes that you have placed on the corresponding sides of the bridge. This way, when the AI loses sight of you, they will ask "What volume is the player in?" and then "Is there a view node associated with that AI Volume?" They will then go to that AINode and try to blow you away."

Well, that does it, I think :)
The properties of the ViewNode are:

Pos: The absolute position of the ViewNode.
Rotation: The rotation of the AINode sets the view direction of an AI using this AINode.

SearchNode

SearchNodes tell the AI where to look for the enemy if triggered to 'Search' state.
Most thing concerning SearchNodes are already described in the AIRegion section. You just have to set the view direction of the AINode an then activate at least one of the flags in the SearchInfo tab.

All of the flags you can set here are animations the AI can perform at this SearchNode.
The properties of the CoverNode are:

Pos: The absolute position of the SearchNode.
Rotation: The rotation of the SearchNode sets the view direction of an AI using this AINode.
ShineFlashlight: The AI uses a flashlight.
LookUnder: The AI seems to look under an object.
LookOver: The AI looks up.
LookLeft: The AI looks left.
LookRight: You'll never find out.
Alert1: A generic animation.
Alert2: A generic animation.
Alert3: A generic animation. These ones are mainly if you want to make a SearchNode, but don't want to use one of the more 'special' animations above. Flashlights are stupid in daylight levels and the other 4 affect the FOV.

PanicNodes are used by AIs triggered into 'Panic' state.
AIs are (per default) triggered into 'Panic' state if they have no weapon and someone threatens them. Main use for the PanicNode is for creating scenarios with civilians.
The properties of the CoverNode are:

Pos: The absolute position of the PanicNode.
Rotation: The rotation of the PanicNode sets the view direction of an AI using this AINode.
Stand: The AI will stand here.
Crouch: The AI will crouch here.
PanicRadius: The area in which the AI has to be to consider using this Node.
PanicObject: A 'trigger' command will be sent to this Object when the AI reaches the point. Good for flipping over tables and such things.

PanicNode

PanicNodes are used by AIs triggered into 'Panic' state.

AIs are (per default) triggered into 'Panic' state if they have no weapon and someone threatens them. Main use for the PanicNode is for creating scenarios with civilians.

The properties of the CoverNode are:

Pos: The absolute position of the PanicNode.
Rotation: The rotation of the PanicNode sets the view direction of an AI using this AINode.
Stand: The AI will stand here.
Crouch: The AI will crouch here.
PanicRadius: The area in which the AI has to be to consider using this Node.
PanicObject: A 'trigger' command will be sent to this Object when the AI reaches the point. Good for flipping over tables and such things.

MiscNode

MiscNodes allow AIs to interact with WorldObjects like buttons, switches etc.

This is most useful for having AIs press buttons. If you want them to do that you have to set 'Sound alarm' or 'Hit switch' as a reaction in the IndividualReactions or GroupReactions tab of the AI.
Then place the Node and an 'Alarm' Prop or a 'Switch' next to it. Give the name of the Prop or Switch to the UseObject field of the Node.
Now if the event happens and you have - for example - set 'Sound alarm' as a reaction to this, the AI will look if it's in the UseObjectRadius of a MiscNode that is assigned to an 'Alarm' Prop, then run there and use it, which causes the 'Alarm' Prop to fire it's message.
Note: The button does not have to be in reachable distance to the AI, it will perform it's animation and the Prop/Switch will fire, nomatter where it is.
At last I need to say that I didn't figure out what kind of Objects the AI can use at the MiscNode. 'Alarm' and 'Switch' are clear because you can set them in their Reactions tab, but for every other (if possible) there must be messages you can send to them, which I just don't know.
The properties of the MiscNode are:

Pos: The absolute position of the MiscNode.
Rotation: The rotation of the MiscNode sets the view direction of an AI using this AINode.
UseObject: The AI will use this Object when it reaches the Node.
UseObjectRadius: The area in which the AI has to be to consider using this Node (i.e. use the Object).
PickupObject: The AI will pick up this Object when it reaches the Node. Don't know under which circumstances, or which message to send.
PickupRadius: The area in which the AI has to be to consider using this Node (i.e. pickup the Object).
BackupCmd: The AI will go to this Node (when a 'Get backup' reaction is set) and perform this command.
BackupRadius: The area in which the AI has to be to consider using this Node (i.e. 'getting backup').
TrainingFailureCmd: If anybody can tell me what TrainingFailure means... thank you.
Poodle: hmmmmm...

CinematicTrigger

This is an example on how to use the CinematicTrigger to create an opening cinematic for your level.
You may want to add a few Cinematic sequences to your level, especially at it's beginning. You will need the following things for this:

Cate (AI_Neutral_Hero),
• a TeleportPoint,
• a CinematicTrigger and
• a few Keys.

For this example I will assume that the player (i.e. Cate) should be seen in the movie and that the movie starts right at the beginnig of the level. Keep that in mind while reading.

To do an opening cinematic, place the GameStartPoint somewhere in the level where it can not be seen by the cinematic camera and by AIs (this last thing isn't a MUST, but if you don't, you first have to trigger nearby AIs to 'senses 0', because otherwise they will probably see and kill you while you're enjoying the movie. You can also remove any Bad AI for movie time by setting the according flag in the Cinematic Trigger, but that's half the fun in most cases).
Note that the Cate you will see in the movie is not the actual player, because with the AI replacement you can do more things (like using animations and so on).

Place your Cate (AI_Neutral_Hero) in your desired place, and put the TeleportPoint a the place the player should be after the movie (the same place as your Cate, if she doesn't move during the movie).

Now place the CinematicTrigger at the first camera position and set the following properties:

StartOn: 'true' (You can use a seperate Trigger to start a cinematic while already playing the level, but then you will have to teleport player away an create placeholder AI before starting the cinematic). I will try to make an example for this too.

CleanUpTriggerTarget is some non-existing target - Read more about this here. The messages are send when the end of the cinema is reached.

CleanUpTriggerMessage is 'msg Cate remove;msg player (teleport tp)' , where Cate is the name you've given your AI_Neutral_Hero and tp the name of your TeleportPoint.
You can also add 'msg player (fadein x)' so the cut to players view is not too hard (x is a time value).

Under Camera set CreateCamera to true. The KeyFrames will move this camera.

Under KeyFramer set CreateKeyFramer to 'true' and enter a name in the BaseKeyName field. For this example I will use the name 'Camera'.

On to the actual camera movement: Just make your Cinematic Tigger as ActiveNode in the NodeTree, and then start placing the Keys in your world. The first one is named 'Camera0', the following 'Camera0x' where x counts up. Give every Key it's desired position, viewing angle and the time the camera will need to get there from the Key before.

Note that every Key can send messages when the camera reaches it. With this some very cool things can be done!

(Reposted here for preservation)

Image
Image

Post Reply