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 02-09-15, 10:55   #1
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default TRNG - Bridge collisions

by Paolone


Download demo project

The basics: Bridges and dummy triggers


In the Level Editor you can create a hanging footbridge using the specific object BRIDGE_FLAT triggered with a DUMMY trigger.



However, many time ago, it has been discovered that it's not necessary that we use a DUMMY trigger, we could get same result using a common TRIGGER activation.

Triggering the Bridge with a condition trigger

But what happen when we place also a CONDITION trigger in same sector where we placed the TRIGGER for the bridge? In previous versions, nothing of interesting: the bridge was always enabled ignoring the response of the condition, but from the 1.2.2.4 dll version, the engine will check the condition trigger and, therefore, the other common trigger for the bridge will be performed or less in according with the response of the condition trigger.

Thank to this new feature we can create footbridges with irregular shape, where for "irregular" we mean not always the usual game square.

For example if we place in same game sector a condition trigger like this:

; Set Trigger Type - CONDITION 6
; Exporting: CONDITION(6:62) for PARAMETER(5)
; <#> : Square fragment (1,1)
; <&> : Fragmented trigger. Check in (E) way if lara is in <#>fragment of 2x2 sector grid
; (E) : DEFAULT. Lara is over current #fragment




The condition will be true only when lara is over the square that is a 1/4 of the original game sector, in the specific way when she is in the top-left little square of the game sector.

Well, if we place also the BRIDGE object and the trigger for this item, what will it happen when lara is in the top-left little square?

Answer: She will remain over the bridge object.

But when she is outside of that little top-left square, what will it happen?



Simply the bridge will be not enabled and so lara will fall down because it was like if the bridge was not present in that sector.

Thanks to this method we can create more detailed floor (and ceiling) collisions with very interesting possibilities.

Last edited by AkyV; 02-09-15 at 11:24.
AkyV is offline  
Old 02-09-15, 10:58   #2
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

The Conditions: Fragmented triggers

To better support this new bridge collision feature, it has been added a big quantity of new fragmented triggers.

In this chapter you can see the old and the new fragmented triggers you can use.






AkyV is offline  
Old 02-09-15, 11:04   #3
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

Limits and chances of the condition triggers

The new code used to verify the condition triggers cann't be overloaded. It's able to manage only two triggers for sector: the condition trigger and the common trigger for the bridge object.

You cann't use DUMMY triggers with the CONDITION triggers, of course, because they are both special triggers and you can not mix them.

You cann't use condition triggers different than fragmented triggers, or at least, if you do that you could get unpredictable results.

You cann't either place two or more condition triggers in same sector, anyway, you can use a single condition trigger like this:

; Set Trigger Type - CONDITION 15
; Exporting: CONDITION(15:0) for PARAMETER(1)
; <#> : TriggerGroup= 1
; <&> : Multiple condition of <#>TriggerGroup script command

In this way it will be the response of conditions exported in TriggerGroup command of script.dat to set if the condition is true or false and pratically in this way, you can use many condition triggers, going around the previous limit.

Mixing Conditions to get new Shapes

The triggergroup condition trick is very useful to get composite zones, mixing in direct or inverse mode the standard shapes supplied from the single fragmented triggers, upto getting new unlimited shapes.

For example if we wish create a smooth diagonal strip where lara will be able to walk we'll have to perform some computes.



We wish get a triggered zone with the shape of green zone of Pic1 (see above image).

Unfortunately there is no condition to have immediatly that diagonal, in fact the grid trigger to have a diagonal (Pic2) it's not the same we wish, since lara will be not able to walk over that strip because it made with a serie of little squares.

So we have to get our target in another way, using different conditions and mixing them in some way.

Looking our target (Pic1) we see there are two sort of white triangles (signed with "A" and "B")

Since we can trigger triangles pherpas it's this the right way.
So we could use the condition for the the two triangles: Alfa triangle (Pic3) has same shape of A Triangle (Pic1), while the Beta triangle (Pic4) has same shape of B Triangle (Pic1).

Anyway there is yet a problem: while the triangles in Pic1 are white (the excluded zone from triggering), those got with our triangle conditions (Pic3 and Pic4) are green, i.e. the triggered zone. We could solve this problem using these trigger in Inverse mode. In this way the triggered zone will be that is outside of given triangle. In this way we get the inverse zone of Alfa Triangle (in yellow in Pic5) and the inverse zone of Beta Triangle (in yellow in Pic6).

Mixing with AND operator

Now we have simply to export both our triangle triggers in a TriggerGroup:

====== TO GET YELLOW ZONE OF PIC5 ==========
; Set Trigger Type - CONDITION 70
; Exporting: CONDITION(70:58) for PARAMETER(768)
; <#> : Cathetus Size= 768
; <&> : Fragmented trigger. Check in (E) way if lara is in the North-West corner triangle with <#>Size
; (E) : INVERSE. Lara is outside of current Triangle

====== TO GET YELLOW ZONE OF PIC6 ==========
; Set Trigger Type - CONDITION 71
; Exporting: CONDITION(71:58) for PARAMETER(768)
; <#> : Cathetus Size= 768
; <&> : Fragmented trigger. Check in (E) way if lara is in the South-East corner triangle with <#>Size
; (E) : INVERSE. Lara is outside of current Triangle

Now, since the default logical operator is AND, to link the two triggers, the whole triggergroup condition will be true when both conditions are true: i.e. when lara is over the zone of first trigger and she is over the zone of second trigger, too.

This situation will happen only when Lara will be in the overlapped zone of the two triggers, i.e. in the zone that the two conditions have in common: the blue zone you see in Pic7.
And that zone is exactly what we wished get.

Note: we can get same result using the NOT operator on the direct triangle triggers, i.e. saying: it's true when lara is not over first (alfa) triangle and neither over the (beta) second. This second method is pratically the same just used, of course, we simply used the NOT operator instead of the INVERSE mode in the trigger.

Mixing with OR operator

Remember that you can always paste two or more fragmented zones simply typing both trigger in a triggergroup command and linking them using the OR operator.



For example in above image, if we wish get the Pic1 sensitive zone (our target) just simply we type the condition trigger to get the column (2th vertical of 3x3 grid) with the condition to get the circle (Pic3)

Using the OR operator the result will be our target

Mixing composite: all operators, AND, OR and NOT

When you wish get a shape really complex you could have to use all operators AND, OR and NOT.



Using the correct sorting of operators

In above image to get the shape showed in Pic1, you have to create a TriggerGroup with:

NOT The condition trigger for Pic3 image: Circle Radius 150
AND The condition trigger for Pic2 image: Circle Radius 400
OR The condition for pic4 image: 3th horizontal strip of 3x3 grid

Remark: it's not so easy to explain but when you mix AND OR and NOT the order you use to type the condition is very important.

For example while the above sequence will work fine, the following sequence:

The condition trigger for Pic2 image: Circle Radius 400
NOT The condition trigger for Pic3 image: Circle Radius 150
OR The condition for pic4 image: 3th horizontal strip of 3x3 grid

It will fail when Lara is in any red point showed in Pic1 of belove image:



Because it should be true, since lara is on green zone, but the result will be false.

The parsing of the triggers will work in this way:

Analyse first trigger (Circle Radius 400) and the condition is False
check for next operator and find a NOT, but missing other operators the NOT values like an "AND NOT"

Since it finds a first false condition linked with a following AND the parsing will be completed immediatly with the response: the condition is false.

By other hand, if we change above sequence using an OR togheter with the NOT:

The condition trigger for Pic2 image: Circle Radius 400
OR NOT The condition trigger for Pic3 image: Circle Radius 150
OR The condition for pic4 image: 3th horizontal strip of 3x3 grid.

The triggerGroup will fail newly everytime lara is in the position showed in red in Pic2 of above picture.

The reason is that the parsing in this case will work in this way:

Analyse first trigger (Circle Radius 400) and the condition is False
Check for next operator and find an OR, so it continues to verify if next condition is true:
Analyse (NOT Circle Radius 150) and it is true.

Check next operator and find it is an OR, so the parsing skip next condition because when in a sequence of conditions, A OR B OR C, one of these (A, B, C) it's true it's not necessary that other of them were true.

But, skipping the next (and last) condition (3th horizontal strip of 3x3 grid) it will consider true also when lara is simply outside of the "Circle Radius 150" like showed in Pic2 of above image, where the conditon it will be true in spite lara is in a white zone.

The Operators Priority in TRNG

A way to understand these ambiguities it's to place, in the formula, the ideal round parenthesis, remembering that the priority used in TRNG has following sorting: NOT, OR, and at end the AND.

Some examples to clear the priority and how place the parenthesis:

First example:

a AND b AND NOT c OR d

It will become:

a AND b AND ((NOT c) OR d)

Second example:

a OR b AND c OR NOT d

it will become:

(a OR b) AND (c OR (NOT d))

Too slim collisions

You can create very detailed shapes anyway the engine, when Lara is in some state-id, could not detect the too slim collisions.



In above images we have this problem. If we create a conditional trigger to enable the collision in that slim rectangle, when lara runs she could pass across the collision.

The reason is that the engine checks in front of lara (in the running direction) using an increment of about 200 units. If the width of the collision is less than that value, the engine will discover that there is no obstacle in front but in the reality this happen because the engine skipped the zone of the collision, checking directly in the opposide side of the obstacle.
AkyV is offline  
Old 02-09-15, 11:08   #4
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

The Bridge Objects



In the old Level Editor there were only three bridges: BRIDGE_FLAT, BRIDGE_TILT1 and BRIDGE_TILT2
The "tilt" should be the gap in the sloped opposite sides about the height. Tilt 1 means one click gap, while tilt2 is two clicks gap.

All default bridge objects allow to lara to walk over them avoiding the sliding.

New Bridge Objects



Differently the new bridge objects, BRIDGE_TILT3, BRIDGE_TILT4 and BRIDGE_CUSTOM, have slopes where lara is not able to walk, she will slide over them.

It could seem weird having bridges where lara cann't walk but there are two exceptions to do: both new bridges are customizable whereby OCB, and you could make them walkable. Pratically we could see Lara walk over a tilt4 slope for the first time.

The other exception is when you mean use the bridge to create a detailed collision on some static, like a huge statue. In this situation you need of walkable bridges (flat, tilt1, tilt2) but you could require also some sloped surface where lara will slide, like with bridges tilt3, tilt4 or tilt_custom.

This method is important when you wish avoid to move up invisible collision from floor upto the statue. A method that will work but with the problem that lara will be not able to walk belove the statue, for example under the huge arms of the statue.

The custom Bridge

The BRIDGE_CUSTOM has a bizarre shape but it doesn't show the real floor collision. I used that shape only to remember that is a bridge with variable sloping grade.

In fact, you can set the tilt factor setting a value in his OCB field.

In this way you can use the BRIDGE_CUSTOM to have any tilt slopes.

Customizing the new Bridge Objects: the OCB values

All new Bridge objects can be customized with their OCB field.
The formula used to create an OCB value for these objects is this:

TiltFactor + NoSlidingFlag + EnableHangFlag + Depth*256

Where:

TiltFactor is the Tilt value, for example with TiltFactor = 0 you create a BRIDGE_FLAT, and with TiltFactor = 2 you create a BRIDGE_TILT2 slope.

The max allowed value is tilt 63.

NoSlidingFlag is the value 128. If you add this value in the OCB lara will be able to walk over this Bridge avoding the sliding.

EnableHangFlag is the value 64. If you add this value Lara will be able to hang of edges of current bridge. By default the hanging feature it has been been removed because it caused many problems on all new edges, i.e. those not matching with the standard game squares.

I suggest to let disabled the hanging feature with the only exception when you are using a bridge with a common squared shape (no fragmented triggers for it).

Depth is the height of the bridge object set in 1/4 of click. This means that, to have a bridge with height of one sector, you should use 16 as Depth.

The depth is important because a Bridge has also a function of ceiling when lara is belove of it.

The old bridges had all the depth of one click.

Remarks:

* The TiltFactor will be used only from the BRIDGE_CUSTOM object, while for other bridges the tilt is implicte in their name: BRIDGE_TILT2, BRIDGE_TILT4 ect.

* Above ocb description could be less updated than that you read in OCB section of the Reference panel of NG_Center program. So you should consulte that reference for the OCB values to use.
AkyV is offline  
Old 02-09-15, 11:10   #5
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

The planning with the framework bridges



Give newly a look to the bridge objects in the misc2.wav (above image).

The used "framework" shape could seem weird but there is a reason to have a design so light for the bridges.

Since we mean use these bridges togheter with conditional triggers to change their collision shape, it should be impossible use the same bridge, with same shape, to cover different shapes in the level.

For this reason we'll planning the footbridges of our level in this way:



We'll use the real BRIDGE object to have the feature of new collisions but all these objects will have selected the Invisible button.

In this way the effective bridge will be invisible and we should (and could) use other footbridges, like different statics, to show in game the walkable footbridges.

Above method it's necessary if we use many different (collision) bridges in many different zone of our level.

Since we'll have to place in level map, the real BRIDGE object, to enable the collisions, and the static footbridge to show the mesh in game, it should be confused overlap in the map, in same zones, two objects: the bridge and the static, and it's own for this reason that I gave to the BRIDGE this framework layout. In this way in the map you'll be able to see both the objects, and select, rotate, move them in easy way, in spite they were in same sector.
AkyV is offline  
Old 02-09-15, 11:17   #6
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

Bridges in depth: simulating the collisions of the Statics

The bridges are not simply the hanged surfaces where lara is able to walk.

With opportune OCB you can transform a bridge in a real 3d solid, with an high depth, like several clicks or sectors.
This feature, added to the framented trigger, it allows to use the bridge collision to create very fine collision for static or moveable (animating) like it had never been possible.

For example in following image:



We have a column, with a squared plinth and a sloped circular surface at top.

Well, using a mix of bridge collision and collision trigger we can cover all these shapes as effective collisions.

Lara is able to walk over the plinth (A Picture), or to walk over the circular surface, and the collision will be own a circle with the correct slope (B Picture).

To adapt the collision around to an object we have to apply some little tricks.

Align the surface with some ideal bridge position

We should very often modify a bit the original position of the mesh (using metasquoia) to align the main surface with the position where we can place a floor collision.

In this speech you should remember that you can place a bridge with gaps of 128 units, i.e. 1/2 click, and that the height (depth) of the collision works in 1/4 of click, so it should be a multiple of 64 units.

For example in our example of the column with the plinth, we changed the slope surface to be aligned with the surface of a BRIDGE_TILT2 object.



A good way to perform this operation is to load in Metasequoia both the objects: first the column, and then, with the Insert command, also one of the Bridges we think to use. (See A Picture in above image)

Then we select only the bridge and using the [Move] command, move it up of multiply by 128, until to reach a position of its surface very alike than that of the column.

Now we can move up/down a bit the vertices of the column surface to have them perfectly aligned with the slope surface of the bridge.

If we made all above procedures correctly in the NGLE (and in game) we'll be able to cover perfectly the column surface with the bridge surface (B Picture)

The overloading of the bridge triggers

In some circustances it will be necessary use some collision trigger to complete the collision shape of our static.

The collision triggers are (fake) flipeffect triggers that change the collision before creating the .tom file in output wad ngle command.

You can move up/down the collision from floor or ceiling, setting further triangle slope.

In the chapter Limits and chances of the condition triggers (see above) I said it's better don't overload the floor data triggers, i.e. I suggested to let only the couple: Condition + Trigger for Bridge in a game sector.

As general rule that was a good suggestion, anyway in some circustances we could place other triggers in that game sector, just understanding when this operation is dangerous and when it isn't.

In the case of Collision triggers the operation is fully safe since these are not real triggers operating in game time but only fake triggers working as placefolders in projecting time to remember where modifing the collision before outputing the wad.

This means that, when the game will begin the collisional triggers will be no more present in tr4 file, so there is no overloading in this case.

However, since we are in topic, we could describe those seldom situations where we could really overload the condition/bridge triggers and why.

The floor data triggers

The triggers for bridges and their further conditions work in a different way in according with the game phase.

In one phase the game engine checks for triggers for bridges parsing the floor data only to discover the collisions. When it finds a trigger for a bridge, check the position of the bridge and set the collision to a different height in according with the position of the bridge.

In a second phase the game engine check for all triggers to manage the objects, flipmap, soundeffect and other game stuff. In this second phase the triggers for the bridges will be ignored.

It's important understand how the triggers will work in the two above phases because the results are very different.

Parsing the triggers to compute the collisions

In this phase, we named phase one, the only considerated triggers are the further conditional triggers and the triggers for the bridges.

The engine performs this compute:
  • If it finds a condition, check if it's true and if it is, the following trigger (only the next) will be performed.
  • If the condition was true or if there was no condition, the trigger for bridge will be managed to compute the new floor collision.
  • If there are further triggers for bridges, there will be all managed for the collision compute, indifferently if the condition was true or false.
Reading above description we can find a possible usage in overloading when we have, in same sector but at different heights, two or more bridge objects.

If we place in our game sector the following triggers:

Condition trigger
Trigger for Bridge 77
Trigger for Bridge 81

where the bridge 77 (index =77) and the bridge 81 are in same vertical of that sector, of course, the engine will work in following way:

It performs the condition triggers. When the condition is true, there will be created the collision for the Bridge 77, when it is false, the bridge 77 will be ignored.

While for the Bridge 81 its collision will be ALWAYS created with no regard about the response of the condition trigger.

In game playing terms, this means we could place two or more overlapped bridges where only one (that is the first trigger after the condition) could be affected with some fragmented shape, while all other bridges should have the common full square shape.

In this speech there is a boring question.

Since there are different behaviors in according if a trigger for bridge is the first, after the condition, or one of the following, we have to force the correct position for our wished trigger.

For example if the Bridge77 has slim shape, while the Bridge81 has the full square size, we have to be sure that the Trigger for Bridge77 was always the first, after the condition.

You can perform a click in 2d panel view to see the sorting of trigger but when the position is wrong, i.e., in our example, when our trigger for Bridge 77 is the second, what could we do to solve the problem?

The solution is easy. Just, when the our trigger (bridge 77) is selected, hit the Del key to remove it. Now select newly the square and click on the pink button to add a trigger. In this way we changed the position for our Trigger for Bridge77 and it should be at first place.

When there are many triggers the question could be a bit more boring but the result we have to reach is clear: the trigger affected from the condition has to be the first after the condition.

Remark: After some checking results that the bridge with condition has to be always the lower in the 3d space, while the other on same tile but upper will be all with full size (no affected by conditions.

Parsing the triggers for the game planning

In the phase we named two, when the engine looks for flipeffects, actions and other triggers for game stuff, the parsing of the triggers in a given sector is more easy:
  • If there is a condition check if it is true or false.
  • If the condition was true perform all following triggers.
  • If the condition was false the engine will ignore all trigger on this sector.
This means that in a situation like this:

Condition Trigger
Trigger for Bridge 77
Trigger for Bridge 81
Trigger to play sound 34
Trigger to enable baddy1 143

The triggers will be performed only if the condition is true, while in a false case all triggers will be ignored.

Since we suppose our condition is a fragmented trigger to support the shape of Bridge77, this means that the triggers will be performed only when lara is over the shape set for Bridge77, but ignoring if lara is over the Bridge77, above or belove of it.

Last edited by AkyV; 02-09-15 at 11:23.
AkyV is offline  
Old 02-09-15, 11:22   #7
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,377
Default

About the Miscellanous II demo project



The Depth factor


Looking the OCB value used for three types of footbridges you find following values:

Slim footbridge with L shape: 512
The ring: 0
Staircase: 384



While for the column (above image) it was: 4608

Decoding the Bridge OCBs


Since the depth factor is stored as 1/16 of sector, and the depth value has to be multiplied by 256 in OCB, the settings about the depth for above bridges should be:

Slim footbridge: 512 = 2 * 256 (depth = 2)

The ring: 0 but by default when there is zero, the depth is one click, i.e. 4 of sixteenths of sector.

StairCase: 384: removing the ocb flag for Disable sliding (128): 384 - 128 = 256. So it was 1 * 256, the depth factor was 1.
The column: 4608 / 256 = 18

About the real game units, since one sixteenth of sector is 64 (1024 / 16 ) the depth (or height) of above objects were:

Slim footbridge = 128
The ring = 256
Staircase = 64
The column = 1152

A bug or a chance?


As usual you can use also the downside of the bridge as a monkey ceiling, just placing the monkey attributes on the sectors where is the bridge.

Anyway, when this attribute is on the slim footbridge, it happens something of weird:



Lara is able to hang on the ceiling of the bridge, starting from the floor of the bridge.

Looking above images it seems a bug, in particular way the frame 4 is very suspect, therefore we can say it is a bug.

However that bug is not avoidable because it is an effect of my fixing of other bug that happened when lara tried to fall down and hang the edge of fragmented borders. So to fix that bug I had to remove the collisions from the Lara's arms while she is doing a back down jump.

You see in frame 4 that the arms of Lara pass across the footbridge and it's for this reason that the engine, when lara is more down (frame 5) enables the ceiling hanging: Lara in that moment is in correct position for the monkey.

In spite in above sequence it seems a bug you could change the shape of the bridge to get plausible that skill: just the bridge had in inner side (because this happen only in this side) a framework shape, like it was builded using metal pipes.

In above way, since the movement is very fast, the trick could look plausible.

Anyway if you don't wish this situation you should avoid to place the monkey attributes belove the bridges that are using fragmented triggers.
AkyV is offline  
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 04:19.


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