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

Closed Thread
Thread Tools
Old 07-08-14, 06:51   #1
Join Date: Dec 2011
Location: Hungary
Posts: 3,714
Default TRNG Collision

1. Object collision

Some methods you could use before TRNG to remove/add/edit object collision boxes:

- Editing the animation in WADMerger Animation Editor.
- Editing the Moveable object collision box size in Fexanim.
- The collision box of some Moveable (ANIMATING) objects is never valid: 12_MIP, 13, 13_MIP, 14, 14_MIP, 15, 15_MIP, 16, 16_MIP.
- Editing the Static object collision box size in StrPix.
- Enable/disable collision boxes in WADMerger.

If you use TRNG then you can use triggers as well to enable/disable collision boxes:

- A61 will remove the collision box of the Moveable object.
- A62 will restore the removed collision box of the Moveable object.
- F161 (or typing 4 in the OCB window) will remove the collision box of the Static object.
- F162 will restore the removed collision box of the Static object.

Special things about object collisions:

- Type 512 in the OCB window of the Static object if the object is too big so the collision box won’t work properly.

- I don’t know how many procedures will remove the collision box automatically. The invisible status (made by Invisible button, or A13 trigger in “hide” mode, or some FLIPEFFECT triggers for Static objects) and the transparency of the dead enemies are some of them.

- The objects textured totally magenta look totally invisible in the game.
In the WAD’s of classic TR games you can find several invisible Static objects like that, used only to simulate collision boxes. – See eg. the door-post collision objects in city.prj original TRLE project, in Room200: the door-post can’t have a cubic collision box all around itself, or else Lara can’t go through the door. But, without collision box, Lara may be able to go more or less through the two narrow side door-posts, in the two sides of the door. That’s why the game uses two invisible objects, placed where the side door-posts are, to create collision there.
The invisible PANEL Moveable objects in Paolone’s Collision demo project are special objects, their only purpose to create collisions like that. – Or you can texture them with “real textures”, if you want, to use them eg. as diagonal walls.


- Motorbike or jeep can collide with any objects, not only with creatures, which is new since TRNG But you can also customize the collision of motorbikes with creatures, using a Customize= CUST_BIKE_VS_ENEMIES Script command.

- Moveable object single meshes use the so-called sphere collisions, that you can check and edit eg. in sapper’s new StrPix.
Sphere collisions could be important eg. in C82 or C83 condition triggers.

- You can’t pull/push pushblocks over squares having eg. pickable items (medipacks etc.) or fire nullmeshes. It was possible before TR4, but it is a bug since then. But you can fix it now: see FFS_PUSHABLE_CAN_OVERSTEP_IT Script constant.

2. Room collision

New room collision effects, in TRNG:

1. A CUST_TR5_UNDERWATER_COLLISIONS constant will make Lara collide underwater with the walls as in TR5. (When she collides in TR4 she will continue the swimming movements towards the wall, but naturally won’t move further. In TR5 she will be diverted when colliding.)

2. Maybe you have an ANIMATING moving in a room, going into slopes, and you’d like to fix that bug in an easy way, so the ANIMATING will go up/down slopes when moving.
In that case you can use a trick, that is originally made for demo type cutscenes, but you can use it any time, i.e. even out of cutscenes.
I mean, you need to move that ANIMATING as an actor:

First you need to activate the ANIMATING in a special way, instead of the usual one, using an A86 trigger (in “Activate enemy and force him as Actor” mode).
Then use A88 (in “add” mode). (Perhaps you also need an A15 if you want to move the ANIMATING not with Animation0 but another animation.)

To restore the original features of the ANIMATING, first stop its activation with another A86 (in “remove living Actor and restore his AI slot skills” mode), instead of the usual deactivating method, then use another A88 (in “remove” mode).

So the new features are:

- the ANIMATING will go up/down slopes,
- it will fall into pits from ledges,
- it will be stopped by walls. (And it will start performing that status that would have performed if you had activated the object as an actor).


- The setup has some savegame-stability problems, that is why I recommend using it in this way:

= activate an A60 as well, so the moving ANIMATING actual position will be saved in savegames. And
= you should put the three triggers again (A86 for the activation, A15 for the moving animation, A88 for the new collision features) in a TriggerGroup. The TriggerGroup must be activated by a GT_LOADED_SAVEGAME GlobalTrigger. The GlobalTrigger must be disabled by default (FGT_DISABLED). You should activate the GlobalTrigger with an F109 – I recommend doing it when the ANIMATING starts moving when activated.
On the same place where you use A86 to stop the ANIMATING, you should also use another F109 to disable the GlobalTrigger again.

- Be careful, the properties of the other copies of that ANIMATING will also be affected while you are using the new features.

- There are more types of actors. The leading actor is the strongest, first A86 will create a leading actor. If you have a leading actor, then your next actor will be an extra actor for A86. If you have an extra actor, then your all further actors will be bonus actors for A86.
And you can also use A87 to add/remove actor types.
Actor types, out of cutscenes, are useful for your ANIMATING only if you want some special feature. For example, only leading actors are able to use DIR_DIRECTION_LARA_LEADING_ACTOR in Parameters= PARAM_MOVE_ITEM, or only leading/extra actors are able to use cutscene camera triggers (see eg. F381 or F382), etc.
If you don’t want special features like that, then you don’t need to care about if the ANIMATING is a leading, extra or a bonus actor, all you need is control it with A86, as I said above.

- The A88 feature won’t work for ceiling. But you can use C90 or C91 to compare the position of the leading actor to the ceiling. So if the actor is too far/too close from/to the ceiling, then you can force something on the actor to do.
(And if you don’t want to use A88 at all, then you can use C88 or C89 to compare the position of the leading actor to the floor.)

- You don’t need A88 or C88-C91 everyway to solve the bad collision problem: you can use a sequence of Parameters= PARAM_MOVE_ITEM commands or similar ACTION triggers. The object will activate them for itself in a HEAVY way.
For example, when the ANIMATING, going forwards horizontally to the bottom of a slope, reaches that bottom, then it activates a HEAVY to move itself up with a given speed, for a given height. The elevation (reaching the given height, defined in the trigger) will stop, just when the object reaches the height of the top of the slope, so the object continues going forward horizontally.
So, while the object is moving forward by its own animation, it is also being raised up by a trigger, so the vector of the movement indicates both forwards and upwards, while the object is at the slope. – If the speed of the elevation is proper then it will seem as if the object goes up the slope nicely. (See some examples in “Populating your Streets” tutorial on TRF.)

2.1. Room collision, performed by objects

“Room collisions, performed by objects” means:

- Lara will walk/run on the top of the objects as if they were floor squares, and
- Lara will bump to the object sides as if they were room walls.

The types of these collisions are:

- If you want to simulate room collisions on the object sides then see the description of CUST_SET_STILL_COLLISION customization in NG Center.
(This feature is useful eg. for this trick: the object is some kind of wall, and you don’t want the player to realize Lara bumped to an object side, instead of bumping to a room wall.)
- See floor/ceiling square simulations below.
- See platform collisions below.
- Lara can’t get on the top of PUSHABLE_OBJECTs.
See the description of the OCB values of PUSHABLE_OBJECTs, to solve the problem.
- Closed trapdoors must be exactly in a portal between an upper and a lower room, and that will make the collision.
The trapdoor object must be placed in the lower room.


- If a trigger is placed on a floor square exactly below the closed trapdoor, then you may think the trapdoor is in the zone of that trigger, so that trigger should work as well if the activator (Lara or else) is on/over the trapdoor. But it is not true: closed trapdoors now work as solid squares, as upper borders for the “from floor to ceiling” trigger zones for the triggers below the trapdoor. – So the top of the closed trapdoor can work like a floor square for another “from floor to ceiling” trigger zone.
That is why, if you want an activator to activate a trigger when he/she/it is on/over the closed trapdoor, then, first of all, select the square exactly over the trapdoor, in the upper room. (You can’t select a floor square there, because the floor is a part of the portal now, so you can select the square only in Plan View Grid or on the ceiling in Editor Window.) – After that, set the trigger on the selected square.
For example, if that trigger is a PAD for that trapdoor, then the trapdoor will open exactly when Lara steps on it.
When the trapdoor is open, then the trigger zone of the PAD is invalid, and the zone of the trigger below the trapdoor is valid even over the trapdoor.
- As for colliding of a non-Lara object with another object having room collision:

= Creatures can’t use these kinds of collisions. (Use grey Box squares so creatures will not reach those objects.)
= Some other objects are able to use these kinds of collisions.
For example, Lara is able to push/pull a pushblock on a TWOBLOCK_PLATFORM, and the pushblock will be raised if the platform is ascending.
= Since motorbike and jeep has a developed collision in TRNG (as I said above), they will be able to perform some actions you usually don’t count on.
For example, there is an open water tunnel you need to cross with the bike. But there is no ramp for that. That's why Lara needs to find the motorboat and drive it to the proper position, next to the bank. Now she'll get on the bike and use the surface of the boat as a ramp to make the bike jump to the other bank of the tunnel. – I.e. the top of other objects will work automatically as a floor square for bike/jeep. (You need some slope that raises the bike/jeep to the level of the boat surface. And be careful with the room geometry, because the collision box of the boat next to the bank sometimes "impales" the floor of that slope, in which the bike/jeep will be stuck.)

2.1.1. Simulating floor/ceiling squares and their side walls

What if eg. you have a 2 clicks high table and you’d like Lara to walk on it, as if the surface of the table were a floor square. – Well, the classic TRLE method is this:

1. First of all, click on here: Room Editor Drop Down Menu Bar/Objects/Edit Object.
2. Now the “Select Object” panel pops up.
3. Select that table here and then click on OK.
4. Now the “Edit Object” panel pops up.
5. Click on – or + buttons any times, so a number will decrease/increase on the grid above the button. If the number is negative that means “lower the floor square”, if that is positive, that means “raise the floor square”. – Let’s suppose you adjust Value 2 on the grid.
6. Now click on OK to close the panel.

This is what happens now, with each table of that object slot which is placed in the map: you can see the floor square in the game exactly below the table, where that table sits. But the game will detect that floor square in a higher level, as if you had raised that floor square by 2 clicks. – So it is a “virtual” raise of the square.

So the object now is “wrapped” into an invisible block: there is a virtual floor square raised above the object, and the virtual side walls of that virtual square are around the object.

- Each “Edit Object” value will be deleted when you refresh the WAD in TRNG Room Editor.
- The method will work possibly only on the square of the object. (So you shouldn’t use it if the object is wider horizontally than 11 square.)
- The method is useful with any solid square below the object (so even with a Toggle Opacity square), but don’t use it with a non-solid (Toggle Opacity2) square or a portal below it.
- Usually objects, light bulbs etc. will be raised/lowered together with their square if that is being raised/lowered. But that doesn’t happen now, only the square moves “virtually”.

The new method is more flexible, using “Collision” FLIPEFFECTs. - See more about it in the Collision demo project of Paolone.
But I can sum it up, with my remarks, and compared it to the classic method:

a, You can simulate even ceiling squares now.
b, This method won’t edit objects or object slots so the new method won’t be affected by the refresh of the WAD.
c, Place these FLIPEFFECTs anywhere you want. It will lower/raise the floor/ceiling square there “virtually” (even if there is no object on that square), including Toggle Opacity solid squares.
(So the new method won’t be affected by the size of the object on that square, because objects are not parameters in this method.)
d, “Edit Object” will always use the slanted/broken status of the “original” square, but the new method can change it.
e, You can have maximum two “Collision” triggers on the same trigger zone: one for the floor and one for the ceiling.
f, “Collision” triggers are “fake” triggers which means they create the collision in the Room Editor so they don’t need to (and they won’t) be put into TOM files when outputting the WAD. - I.e. technically these triggers won’t be activated by anyone in the game.
That’s why it’s absolutely unimportant if it is a TRIGGER, PAD, HEAVY, SWITCH etc. trigger (except: it couldn’t be a CONDITION).
(And that is why any “trigger-related” thing - eg. One Shot - is useless with this trigger.)
g, Don’t even try to export these triggers into Script/WADMerger.
h, Always place them in the rooms where the collision effect will happen. – So:
- The trigger for the ceiling collision always must be in the room of the ceiling. (Unlike eg. Monkey attribute, where you need to mark the squares below the monkey ceiling, on the floor, even if the floor and the ceiling are in different rooms.)
- If your room has a flipped version and you want that collision both in the versions, then you need to place that trigger both in the original and the flipped room.

2.1.2. Platform collisions

Some platforms don’t have collisions, Lara will fall through them when she wants to walk/run on them (see eg. TWOBLOCK_PLATFORM or BRIDGE_FLAT objects). To make that platform solid under Lara, place a DUMMY trigger under that object, on the closest solid floor square (i.e. on the square where the object is supposedly placed).


- If the size of the object is bigger than 11 square then you need to place that DUMMY on EACH closest solid floor square under that object.
- If you have collision problems with the TWOBLOCK_PLATFORM that you use for an elevator, then see Paolone’s Elevator demo project.

Platform collisions with activation/deactivation:

You can use any other triggers (TRIGGER, ANTITRIGGER, PAD, ANTIPAD, HEAVY, HEAVYANTITRIGGER, COMBAT) instead of DUMMY, if you want.
The difference: the non-DUMMY triggers will also perform their “usual” effects – so this is their “aggregated” purpose:

- TRIGGER: the platform is solid and activated if Lara gets in the trigger zone,
- ANTITRIGGER: the platform is solid and deactivated if Lara gets in the trigger zone,
- PAD: the platform is solid and activated if Lara touches the floor square OR the platform surface,
- ANTIPAD: the platform is solid and deactivated if Lara touches the floor square OR the platform surface,
- HEAVY: the platform is solid and activated if the non-Lara activator gets in the trigger zone,
- HEAVYANTITRIGGER: the platform is solid and deactivated if the non-Lara activator gets in the trigger zone,
- COMBAT: the platform is solid and activated if Lara gets in the trigger zone, having weapons in the hand.


- Some kinds of platforms don’t do anything if activated (see eg. BRIDGE_FLAT’s), so in their cases it doesn’t matter if you use DUMMY or other triggers for the collision, under them.
- A TWOBLOCK_PLATFORM (having some number in its OCB window) will rise a bit if activated.
So, in its case, it matters if you want a DUMMY or other trigger below the platform: DUMMY will only make it solid, other triggers will even activate it.


- The activation/deactivation of the platform and its collision can be separated from each other. I mean, eg. you use a DUMMY under the platform for the collision, but you use a TRIGGER, anywhere else in the map, to activate the platform. – A nice example for that:
In settomb.prj original TRLE project, TWOBLOCK_PLATFORM objects are “sand surfaces” in Room58. Now they are exactly on the floor so they don’t really need the DUMMY triggers below them. But if Lara uses the switch to activate the platforms in Room3, then they will be raised a bit (thanks to the TRIGGER OBJECT triggers for the platforms overlapped with the SWITCH trigger), performing the illusion of “Room58 will be filled with sand”. After that, the “sand surfaces” will be in a higher level in Room58 so DUMMY triggers below the platforms are needful to prevent Lara from falling through them.

- The trigger zone goes from floor to ceiling, as usually, so eg. a TRIGGER will be activated now

= either Lara is over the platform,
= or if she is between the platform and the floor (with the trigger) under the platform.

Sometimes it is disturbing. For example, if a platform doesn’t have textures from below (see eg. that sand surface), so Lara mustn’t get under the platform. In those cases eg. you cannot let Lara get under the platform (eg. with clever room geometry etc.).

- If the “usual” effect of the trigger cannot work that doesn’t mean the collision doesn’t work:
For example, if Lara steps on a platform, having a HEAVY for its collision under it, then Lara naturally cannot activate that HEAVY to activate the platform – but the platform is in the trigger zone of the HEAVY so the collision will work.

- If you use timer, One Shot, released STT number buttons for the trigger, then those features will be used only by the activation/deactivation, not by the collision.
So it is useless to adjust those features at DUMMY triggers.

- “Anti” triggers under the platforms are useful instead of DUMMY only if the platform is already active, when the activators gets into the trigger zones of those “anti” triggers. – Examples:

= A TRIGGER somewhere else in the map will activate the TWOBLOCK_PLATFORM, which will start rising. Now Lara steps on the platform, so the ANTIPAD under the platform will stop the platform before that reaches the uppermost point of the raise.
= In catacomb.prj original TRLE project there is a TWOBLOCK_PLATFORM “stone plate” placed in Room84. It has been activated automatically, without triggers (i.e. having all the number buttons pushed in the OCB panel), but it won’t still move, because this time there is 0 in the OCB window, which means the active platform won’t move by itself, but it will lower a bit if Lara stands on it, and rise back to the original position if Lara gets off the platform.
But that automatic activation is not enough for the collision (because the platform has been activated NOT by a trigger below it), that’s why there is a HEAVYANTITRIGGER under the platform, on the closest solid floor squares, in Room126.
There is a pushable column in Room126 so if Lara pushes/pulls it on that HEAVYANTITRIGGER, that will deactivate the platform, so that won’t descend the next time if Lara steps on it. If the column is on the HEAVYANTITRIGGER, then the column will be exactly between the floor and the platform, so it is a nice illusion for this situation: “the plate always descends under Lara. But if she pushes/pulls the column in the lower room tightly between the plate and the floor, then the column will hold the plate, so the plate won’t descend any more if Lara steps there”.

Platform collisions with trigger overlaps:

You can use trigger overlaps with platforms, as usual. So eg. if a PAD under the platform to activate the platform/make it solid and a TRIGGER to activate a door are overlapped with each other, that will cause the platform and the door both will be activated and the platform will be solid if Lara is standing on the platform.
But you must be careful if you want to use condition (SWITCH, KEY, PICKUP, CONDITION) triggers in the overlap:

- SWITCH, KEY or PICKUP triggers are useable.
For example, place a pickable object on a floor square under the platform, then raise it to the platform level as if it were placed on the platform. There is a TRIGGER OBJECT for the platform and a PICKUP for the pickable object under the platform. So the platform will be activated by a PICKUP trigger if Lara picks up that object from the platform surface.
- CONDITION triggers usually don’t seem useful – because they will control not only that TRIGGER that activates the platform, but they also control the collision. (So, if the condition is not true, then Lara will fall through the platform.)

SWITCH, KEY or PICKUP triggers are usually 11 square sized, on the square where that switch, key hole, pickup object is placed. But this time, if that TRIGGER under the platform is more than 11 square sized (because the platform is bigger than 11 square) then the condition trigger must be big enough to be overlapped with the whole TRIGGER.

Multiplied platforms:

You may ask: is a DUMMY trigger also useful in an overlap? – Yes, but all the other triggers in the overlap are TRIGGER’s and each TRIGGER will work as DUMMY triggers, according to the overlapping rules:


So if you place a TRIGGER overlapped with a DUMMY, then in the Window Object of the TRIGGER must be a platform, and the platform must be on the same square(s) where the platform of that DUMMY is, under or over the platform of the DUMMY.
So everything what each TRIGGER does now is makes collision for its own platform.

However, naturally you can have more platforms over the same square even if it is not a DUMMY+TRIGGER overlap. For example: it is a HEAVY+TRIGGER overlap, so if Lara pushes a pushblock on one of the platforms, then all those platforms will be activated.

But you must be careful, because you will have problems with the collisions of those platforms. – Because a square can’t really support more than one platform collision trigger. (For example, the lower platform will have the collision either from below or from above, but the upper platform will have the collision only from below.)

Fragmented platform collisions:

“Fragmented” conditions are the only CONDITION triggers which could be useful in a trigger overlap below a platform. – That is what a “Fragmented” condition is able to do in that CONDITION+TRIGGER overlap:

a, Eg. if the platform is a circle shaped BRIDGE_FLAT, then the “Fragmented” condition will define the circle shape for the collision, so Lara will fall down if she leaves that circle, getting over the other parts of the square shaped TRIGGER OBJECT trigger that creates the collision of the platform. - See more about it in “Miscellaneous2” demo project of Paolone:


b, That TRIGGER can activate the platform (if that is active-able) only if Lara is over that circle shaped part of the trigger square.


- If you use a “Fragmented” condition for a platform, then always choose Default or Inverse in Window Extra of the CONDITION trigger. Because Pad or Pad-Inverse in that condition will work only if Lara touches the floor square, below the platform. (It doesn’t mean Pad/Pad-Inverse are useless, because you can use “Fragmented” conditions even without a platform, in other setups.)

- If you want a complex fragmented area with more than one “Fragmented” condition triggers then export those triggers into a TriggerGroup – which will have only those “Fragmented” condition triggers – and then place a C15 trigger of that TriggerGroup overlapped with the TRIGGER.

- The “Fragmented” conditions are intended to make a shape for 11 sized squares. But it doesn’t mean the condition doesn’t work with bigger platforms, eg. even with a 22 sized TWOBLOCK_PLATFORM object, having a 22 sized “Fragmented” condition below it.
However, the collision eg. for this TWOBLOCK_PLATFORM will work as if you placed four 11 sized copies of that “Fragmented” condition trigger there.

- As I said above, there could be problems if you have more than one platform above each other. It is also true with the CONDITION trigger in the trigger overlap: that “Fragmented” condition will work properly only on one of the platforms.
It depends on the trigger order. The proper TRIGGER must be selected AFTER the CONDITION trigger everyway, on the square where the triggers were placed, if you click on them.

And one more thing about that: the CONDITION will also fail due to the wrong trigger order of a square if you use other triggers as well. For example you have these triggers on a square:

= “Fragmented” condition for a rhombus shape, and
= TRIGGER to create a (rhombus shaped) collision for the BRIDGE_FLAT object over the trigger, and
= TRIGGER to open a door, overlapped with the bridge executable trigger.

Now this thing should happen: the TRIGGER for the bridge will create the collision. The “Fragmented” condition says this collision must be a rhombus, to fit the rhombus shaped bridge. The “Fragmented” condition also affects the other TRIGGER in the overlap, so the door will open only if Lara is on/over the rhombus bridge, not opening it if she is on/over the other parts of the square shaped trigger.
But the condition will fail, if – clicking on Plan View Grid – the other executable trigger will be selected sooner and the bridge trigger will be selected later. (It seems “Collision” FLIPEFFECT triggers are exceptions, they can be selected even sooner.)

- Your object can have a pretty nice room collision if you combine the method of the floor square simulation with the fragmented platform collision. – See eg. Chapter “Bridges in depth: simulating the collisions of the Statics” in “Miscellaneous2” demo project of Paolone:
You can see a picture of a broken, Static column there. The collision box of the column has been removed with StrPix (because the usual collision box, that “wraps” the whole object, wouldn’t be proper now) - so Paolone used other tricks for the proper collision:

= The square below the object is raised a bit “virtually” by a “Collision” FLIPEFFECT trigger, so Lara is able to walk on the plinth of the column.
= There is a BRIDGE object raised to the top of the column. The bridge is used only as the simulation of the treadable column-top so the bridge is invisible, having the Invisible button pressed.
= You can use OCB numbers to adjust the proper depth for the bridge. (See NG Center about bridge OCB values.) That’s why that bridge – though it seems only 1 click thick – “virtually” exactly as tall as the column.
= The “Fragmented” condition trigger will create a circle shaped collision for the circle shaped column-top – in fact, for the bridge on the column-top. And, because the bridge is (virtually) as tall as the column, that’s why the condition will narrow the bridge collision for the whole height of the column, from a square to a circle.
So “Fragmented” collisions affect not only the surface of the platform but its height as well. – Which is logical because we chose Default, not Pad, so the trigger will affect the whole platform virtual height, which is in the “from floor to ceiling” trigger zone.
That’s why the “Fragmented” conditions will adjust the proper collision for the cylinder shaped column body as well.

Made using TRNG

Last edited by AkyV; 02-06-16 at 18:30.
AkyV is online now  
Closed Thread


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 23:28.

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