[http://sourceforge.net/p/ufoai/bugs/2136 Item 2136] imported from sourceforge.net tracker on 2013-01-28 19:22:20

Using R24909.
Wilderness map -tracefile reveals a (set of) filled cell(s) around position x=138, y=146z=3 and 4. (right in front of the soldier in the screeny). As a consequence, the soldier can't further walk down the catwalk.

Actually, the prob extends through the whole xy-column from z=0 through 7.

I bet this prob is not restricted to the wilderness map and can cause many different pathfinding issues, so we should find and fix this bug before all others. Thus prio 8.
===== Comments Ported from Sourceforge =====

====== aduke1 (2009-06-29 20:11:17) ======

catwalk
====== aduke1 (2009-07-12 22:43:23) ======

Some debugging showed what happens:
(doing CheckCell for (138,146,7), z=5 will work as well)

- we find a floor at some 220 mapunits
- check for legroom is ok
- check for torsospace *fails*
- so we go down, but torsospace will continue to fail there too
- reaching the bottom of the map, we'll set all cells below the starting cell to 'filled'.

The figures look ok to me, no clue yet :(

====== aduke1 (2009-07-16 23:29:58) ======

Important intermediate result:
I changed MIN_STEPUP to *3* and could happily stroll the catwalk all the way down.

I currently suspect some DIST_EPSILON prob, but have no clue yet. The ingame visuals do not allow to judge what it really is.
So I could spend a lot of time either
- learn how to use radiant (and get the exact figures)
- debug tracing to get the figures
- or....

wilminator, I suppose it was you who implemented the debug_map cmd (with those red and green blocks).
If so, what about creating some 'debug_map 4' that visualizes the *traces* routing will execute ?
I can imagine something like the std battlescape cursor with a 4x4 extension for the legroom and maybe some different colours to distiguish crouching and upright walking height.

What do you think ?

====== aduke1 (2009-07-17 22:56:14) ======

More intermediate results:

Here's what happens:
We have 5 stairs, each 3 QUANTs high, spread over 4 moves in Y-dir.
Legroom test will find a stair and consider it a potential floor.
Due to the spread, on some of the 5 stairs, the torso test will protrude into the stair *above* that floor (see screenshot) and fail accordingly.
As a consequence, the floor will be considered 'not usable'.

This is not a bug in the code, it's a design problem. Marking the cell 'filled' seems inappropriate for a stairway, but I can easily think of similar situations where we need it to be 'filled' (eg. the socket of some machinery).
So what can we do ?
- setting MIN_STEPUP to 3 will solve *this* problem. But we'll most likely find places where we need 4,5,6...
- aligning all maps to the needs of the pathfinding algo sounds like a terribly wrong concept. But then again, maybe that's the price for having a grid in a 3D-environment...
- any better idea ?

Up for discussion.

btw the steep stairways on farm map may have the same prob, not sure though.

====== aduke1 (2009-07-17 22:57:46) ======

torsoTest protrudes into stair
====== wilminator (2009-07-18 18:29:55) ======

Thinking about it, maybe increasing WALL_SIZE may be more beneficial...
WALL_SIZE is the unchecked space from the edge of a cell into the center that is not checked for obstructions. Increasing this value decreases the width of the torso bounding box that is causing steps to become unusable. This is appropriate if there are no actors wider than 22 model units. Currently, the WALL_SIZE value is set to allow actors that are 24 model units wide (UNIT_SIZE - 2 * WALL_SIZE = 24), and may be too generous. We could also increase the legroom height, which may make sense also, right now, the current leg height (PATHFINDING_MIN_STEPUP) assumes that an actors legs, as well as the most an actor can climb in a single step, is 2 QUANT or 8 model units. This could be split out so there is a separate constant for the actual leg height, and a different constant for the most an actor can rise in a step.
====== aduke1 (2009-07-18 21:08:44) ======

Increasing WALL_SIZE would only gradually solve some problems, eg. it wouldn't make the catwalk walkable. btw WALL_SIZE *is* already set to 5.

Using a separate constant for legroom height sounds like a good idea to me :)
I'd suggest a value of 4. That should solve the catwalk and more and still sounds reasonable (some 70cm).

====== aduke1 (2009-07-21 21:14:27) ======

As you didn't oppose vehemently, I implemented a PATHFINDING_LEGROOMHEIGHT of 4 and applied it to routing (R25314). Works like a charme :)

But there is a second prob with this situation: imagine a very similar situation where we *want* the torsoCheck to fail. Setting *all* cells in the column to filled (as the current code does) would be inapropriate for fliers ! Well, but that bug has a much lower prio...

I still would like to know what you think about my suggestion 'debug_map 4' below...

====== wilminator (2009-07-22 03:31:05) ======

Darn, you beat me to it ;) No, seriously- I hadn't posted my version because I was trying to think about why we needed PATHFINDING_MIN_STEPUP. When I was done changing the name, I didn't have any instances of MIN_STEPUP anywhere, except as a define. I like your version better, so I'm reverting to it.

As far as the cells above being filled, I see your point. We will have to look at this later.

For the debug_map 4 option, how do we want to do this? We have many sets of traces, and two flavors: floor and wall. We can't show ALL the traces at one time- sensory overload. We are looking at two things imho- a floor trace bit and a wall trace bit. The floor trace bit would cause the bounding box traces for the floor trace to be shown as if the scan started from the currently highlighted cell. Rendering this trace should be easy- we can adapt my boxes to have the sizes of the trace bounding boxes. My only concern is the shading- with our new shading algorithms, our boxes tend to fade to black, regardless of the color.

The wall trace would be more difficult: we need a starting cell and a direction. I'm open for suggestions on how to handle this. We also need to figure how we want to render this: one solid block for the available passage, or multiple boxes for each trace actually ran? Again, beware sensory overload.
====== aduke1 (2009-07-22 21:08:29) ======

*smiles*

As for debug_map 4, imho an 'extended cursor' like I lined out below is a good start and will be enough for a long time.
Once we have such a cursor that marks the technical dimensions of an actor, it's easy to turn the map view into a position where you can see if that shape would fit through the opening that you look at.
Yes, we have too many different methods to trace for walls to visualize them all at the same time.
We *could* plan for some debug_map 8 with two addional params. One for the dir, one for the tracing method to visualize. But atm I don't think we need that.

I have noticed the decreased visability of the cursor box too. Good to hear that it's not my new monitor :) Maybe Mattn can do something about it ?

====== aduke1 (2012-09-30 23:59:01.275000) ======

- **milestone**: 2.3 --> 2.3.x