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 12-06-16, 11:17   #1
AkyV
Moderator
 
Join Date: Dec 2011
Location: Hungary
Posts: 2,314
Default Overlaps and boxes – aka enemy AI malfunction

Note:
I am not a programmer. So what I wrote in this tutorial are mostly “trial and error” conclusions and experiments. So maybe I am wrong sometimes.


If your enemies start acting in a strange way, as if their AI had broken, then the reason probably is you have exceeded the maximum limit of the so-called “overlaps” and “boxes”. – No, this box is not that grey spot you can set down in the map with the grey Box button, it is something else.

If you are a TRNG user, then you can check in the infobox the actual and the maximum values of overlaps and boxes:



The “Overlaps” and “Boxes” values in the infobox will be refreshed at the next “output WAD” operation.

The “overlaps” and “boxes” values will be increased if you execute an operation like this:

- creating a new room,
- connecting a room*,
- lifting up a floor square to create a block,
- create a wall made by the green Wall button,
- setting down a grey Box spot.

Why? Because those operations put obstacles in the walking enemies’ way.
Obstacles which seem to be calculated:

- green room walls
- solid floor surfaces
- floor square sidewalls (The height of the sidewall doesn’t matter, it could be even tiny, it will be counted. On the other hand, fake floor collisions made by flipeffects are not counted now.)
- hole (portal) on the floor
- grey Box spots

*: portals are tricky for the overlap/box counter. Sometimes the counter won’t change or decrease if you create a portal. See more about it in “Explanation” chapter below.

So, if you want to decrease “overlaps” and “boxes” values, then the most basic way is to remove the obstacles:

- delete a room,
- remove the solid floor squares between the rooms,
- delete a door (portal, not an object),
- sink down a floor square so it will reach the level of the surrounding floor squares,
- remove walls made by the Wall buton,
- remove grey Box spots.

Or do the opposite, create more obstacles.
I mean, for example, let’s suppose you have a floor made to be zigzaggy with Wall button-made green columns on it. There can be several tiny boxes and overlaps between those obstacle columns. If you fully stuff the gaps between the columns, with other green columns, so it will be a big green block, then it will be only ONE big obstacle, removing the boxes and overlaps from the gaps which don’t exist any more.
(This method is not true for grey Boxes. See in the notes why.)





So, we can say: the more boxy your level is, the lower “overlaps” and “boxes” values are.

Which means your level will have presumably high overlap and box values if you have too many and/or too large open/complex areas.

If you don’t want to hurt the room geometry to decrease overlaps/boxes then split the level into two parts. (Thanks Titak for these last two conclusions.)

Notes:

- The ceiling (including the ceiling square side walls) doesn’t seem important now. If there is no solid room floor above the room of the box, then I may say that the upper limit of the box is “in the infinite somewhere above the box”. – Just remember the crawlspaces which are not forbidden for baddies because they don’t have grey boxes, so the baddy will walk into the crawlspace, not detecting the low ceiling.
- Slopes or broken surfaces are a bit special. A low slope or broken surface, without lifting its block, won’t be calculated as an obstacle. Without a lifted block, slopes need to be at least 2 clicks’ high to be obstacles, broken surfaces at least need to be 4 clicks’ high.
These slopes/broken surfaces are act (as obstacles) as if you raised a floor square there.
And an interesting thing: slopes, even on raised blocks, will act like green columns (as obstacles), if the slope of that square is too many clicks’ high. (It is not true for broken surfaces.)
- Yes, the grey flat Box spots are also invisible 3D obstacles in the editor. Each grey square is something similar obstacle as if you raised a floor square there. But not clearly. I mean, I don’t know which 3D form exactly is what the editor can see for grey Box spots, but it can be something complicated, because a lot of grey squares will highly increase the amount of overlaps and boxes, even if they compose one big spot, so theoretically it should be only one big obstacle!

Explanation

Boxes are invisible 3D sectors in the map.
Boxes always go from the nearest obstacle in one direction to the nearest obstacle in the other direction.
If you create a new room with the default 18×18 size, then that room has only one box:



The box goes to:

- from floor to “the infinite somewhere above”, and
- from the west room wall to the east room wall, and
- from the north room wall to the south room wall.

If you create a column in the room with the Wall button, then that single box will be split into four boxes:



So not only the amount of overlaps and boxes will be recalculated when a new obstacle emerges, but even their positions!

(Naturally those colored lines should exactly over each other but I let a tiny distance between them, so you can distinguish them easily from each other.)

If you don’t understand why that happened then let’s see for example the northern part of the room where we find this box:



The box goes to:

- from floor to “the infinite somewhere above”, and
- from the west room wall to the east room wall, and
- from the north room wall to the north column wall.

Overlaps are the 3D areas where two boxes are overlapped with each other:



Overlaps are white zones in the image above.
As you see:

- the red box has an overlap with the blue box (nortwest) and the brown box (northeast)
- the blue box has an overlap with the red box (nortwest) and the magenta box (southwest)
- the brown box has an overlap with the red box (northeast) and the magenta box (southeast)
- the magenta box has an overlap with the blue box (southwest) and the brown box (southeast).

And, yes, I didn’t duplicate them. I mean, for example when I said:

“the red box has an overlap with the blue box (nortwest)”
“the blue box has an overlap with the red box (nortwest)”

I mean, each overlap is calculated twice in the overlap counter. I suppose it is because it matters if the enemy in that overlap moves from Box A into Box B or from Box B into Box A.

Enemies in the boxes:

What if eg. if Lara is in the room, and an enemy is also there in the room? – Let’s suppose (see the image above), Lara is in the magenta box and the enemy is in the red box.
How will the enemy find Lara?
Well, the game tells to the enemy in which box Lara is. So the enemy need to figure out how to go from the red box into the magenta box. For doing that the enemy checks a data base called "Overlaps". The enemy ask the overlaps: "which boxes are accesible from the red box? " The Overlaps data base will give a list with the blue box and brown box which means, from the red box, you can only go to the blue or the brown box. Then the enemy chooses to move to a box of that list and then ask the Overlaps again the accesible boxes for the box he is at now. This way he reaches the magenta box.
In others words the enemy try to found the "link" in the Overlaps from his box position to Lara's box position, to know how to go there.
(Based on the description by Turbo Pascal.)

An example from a vertical view:



As I said above, the ceiling is not an upper limit now. So what you can see above the boxes is not the ceiling but the floor of the next room just right above this room.

Boxes and overlaps between the rooms:

1. If you connect two rooms horizontally or vertically, then their boxes perhaps will merge with each other, if the rooms, as you see in the image (horizontal 2D view), fit properly to each other:



As you see, connecting rooms could be a good idea to decrease the box amount. But naturally it happens only if there are no obstacles, like a floor block “threshold”, between those boxes.
So, in this special case, if you delete this portal or raise a threshold, then the box counter won’t be decreasing, but increasing, splitting this box again!

Or, another example (horizontal 2D view):



2. But mostly, when you do a horizontal connection, then new overlaps will emerge. This time it seems the overlap between the boxes only a line, because the boxes touch each other in the portal (horizontal 2D view):



It is very strange, but overlap counter won’t be increased, if you open a horizontal portal between two rooms, but none of the original boxes in the rooms are wide enough to fit that portal – so that line overlap above seems to work only for boxes which are wide enough for the portal (horizontal 2D view):



So there is no overlap now, which doesn’t mean enemies can’t go from one room into the other! (Perhaps are overlaps not so important now, because the route of the enemies between the rooms are controlled by the portals?)

For example, if you make a green colum wall now in a proper place then that will recalculate the boxes, so the line overaps will emerge in that portal:



3. Vertical portals work in a different way. When you create a vertical portal, then the overlaps and boxes positions will also be recalculated, and a new box will emerge which fits the portal, going through it (vertical 2D view):



And that “line overlap” again... I mean, as I said above, portals (holes) on the floor are obstacles, so there will be boxes around that vertical portal in the upper room which are line-overlapped with the box going through the portal only where they touch it.
In this image you have eight line overlaps:



This is not really clear for me. I mean, walking enemies won’t jump into this hole. Perhaps are this kind of overlaps only for flying enemies?

4. And one more thing:
“Line overlaps” will emerge and increase the counter even if the boxes touch each other “at their corners”. (It is naturally a very strange overlap, possibly useless?)
It happens for example, if your ledge is not a “balcony” but only “a walkway on the blocks”:

No line:





Line:





Made using TRNG 1.2.2.7+
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 16:53.


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