Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
trs:npc_behaviour [2017/01/25 13:39] stohrendorf old revision restored (2017/01/08 19:47) |
trs:npc_behaviour [2017/11/17 12:19] (current) stohrendorf |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | {{indexmenu_n>6}} | ||
| + | |||
| ====== Non-Player Character Behaviour ====== | ====== Non-Player Character Behaviour ====== | ||
| Line 19: | Line 21: | ||
| Despite the existence of //script files//, here is no any scripting for entity behaviour, like in most contemporary games. This hardcoding makes it difficult to port the earlier Tomb Raider scenarios to the engines of the later games, which could be desirable with their improved hardware support. While textures, models, and animations can be ported, behaviour cannot be. | Despite the existence of //script files//, here is no any scripting for entity behaviour, like in most contemporary games. This hardcoding makes it difficult to port the earlier Tomb Raider scenarios to the engines of the later games, which could be desirable with their improved hardware support. While textures, models, and animations can be ported, behaviour cannot be. | ||
| - | However, there is a small change in TR4 and TR5 which indicates that specific entity behaviour can be altered — it’s called //OCB//. It was briefly described in [[meshes_models#object-code-bit|this section]]. OCB is a special value defined for each entity instance, based on which entity can switch the way it acts (most prominent examples are flame emitters, which change their size and emit direction based on OCB, and teeth spikes, which change their orientation in space). | + | However, there is a small change in TR4 and TR5 which indicates that specific entity behaviour can be altered — it’s called //OCB//. It was briefly described in [[trs:meshes_models#object-code-bit|this section]]. OCB is a special value defined for each entity instance, based on which entity can switch the way it acts (most prominent examples are flame emitters, which change their size and emit direction based on OCB, and teeth spikes, which change their orientation in space). |
| Sometimes OCB is interpreted as a “packed” field with several values incorporated — like teeth spike OCB contain information about their horizontal and vertical orientation, and also about their “physical” behaviour (stick out constantly, pop-retract in looped manner, or pop-retract just once). | Sometimes OCB is interpreted as a “packed” field with several values incorporated — like teeth spike OCB contain information about their horizontal and vertical orientation, and also about their “physical” behaviour (stick out constantly, pop-retract in looped manner, or pop-retract just once). | ||
| Line 53: | Line 55: | ||
| This is presumably the way //TRLE// creates boxes for each level: | This is presumably the way //TRLE// creates boxes for each level: | ||
| - | * For each sector, extend one axis until a height difference is reached. | + | * For each sector, extend one axis until a height difference is reached. |
| - | * Then extend this row (or column) perpendicular until another height difference is reached. This is a rectangle with the same height and it //defines a box//. | + | * Then extend this row (or column) perpendicular until another height difference is reached. This is a rectangle with the same height and it //defines a box//. |
| - | * Do the same with the other axis first, and you get another box. | + | * Do the same with the other axis first, and you get another box. |
| - | * Repeat this process for every sector, maybe extending into neighbor rooms through the portals. | + | * Repeat this process for every sector, maybe extending into neighbor rooms through the portals. |
| - | * Make sure that there are no any duplicate boxes. | + | * Make sure that there are no any duplicate boxes. |
| There are two variations of box structure — one for TR1 and another for TR2 and any other game version. | There are two variations of box structure — one for TR1 and another for TR2 and any other game version. | ||
| Line 85: | Line 87: | ||
| }; | }; | ||
| </code> | </code> | ||
| - | In ''%%OverlapIndex%%'', the high bit is sometimes set; this occurs in front of swinging doors and the like. That basically means they are unpassable by large enemies, like the T-Rex. | + | The ''%%OverlapIndex%%'' contains a block mask for path finding by enemies in two highest bits: Bit 15 (blockable) and bit 14 (blocked). The first one marks it as unpassable by large enemies, like the [[:items:details:tr1:trex|T-Rex (ID 18)]], the [[:items:details:tr1:mutant|Mutant (ID 20)]] or the [[:items:details:tr1:centaur|Centaur (ID 23)]] and is always set behind doors. The second one marks it unpassable for other enemies and is set for movable blocks (if blockable bit is set), for closed doors and for some flip maps (set at start). |
| === Overlaps === | === Overlaps === | ||
| Line 190: | Line 192: | ||
| ==== AI Data Block in TR4-5 ==== | ==== AI Data Block in TR4-5 ==== | ||
| - | Beginning with TR4, AI objects are //not kept along with other entities//. Instead, they have their own structure, which is basically simplified [[meshes_models#tr4_entity|[tr4_entity]]] structure, and moved to separate data block. This seems reasonable, as the only purpose of AI objects is to serve as “waypoints”, and they have neither //collisional// nor //control// code attached to them. | + | Beginning with TR4, AI objects are //not kept along with other entities//. Instead, they have their own structure, which is basically simplified [[trs:meshes_models#tr4_entity|[tr4_entity]]] structure, and moved to separate data block. This seems reasonable, as the only purpose of AI objects is to serve as “waypoints”, and they have neither //collisional// nor //control// code attached to them. |
| The format of AI object structure as follows: | The format of AI object structure as follows: | ||
