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

revision 26009.
see attached screenshots.

00 - soldier walks one lever up when instructed to step on a chair;
01 - soldier partially walks through the door (although this might be "works as intended" because of center of the path not being obstructed)
===== Comments Ported from Sourceforge =====

====== richlv (2009-09-04 22:04:53) ======

00
====== richlv (2009-09-04 22:07:47) ======

01
====== aduke1 (2009-09-06 13:03:00) ======

01 - as of R26057 it has become even worse. I can walk through the glass of the open door (see screenshot) but NOT in the other direction. The same applies to the closed part of the door.
Is there anything special about the glass of that door (one-sided brush) ?
Is that a FUNC_DOOR ?

====== aduke1 (2009-09-06 13:03:57) ======

walking through glass door
====== richlv (2009-09-06 19:00:34) ======

i can confirm that walking through the door in one direction is now possible. door does not seem to be special in any way - glass is quite fine, handle is marked passable (although that should not affect anything).
while the glass has one contentflag applied that in radiant is uunamed, unmarking that checkbox segfaults, so i can't test whether it impacts anything. anyway, it should not affect pathfinding, unless radiant is to blame here.
====== aduke1 (2009-09-09 16:22:54) ======

Debugging showed that the RT_ObstructedTrace at MIN_OPENING height goes right through the glass.
At least I can't shoot through the glass.
I'm assigning this to wilminator because he wants to have look at tracing anyway.

Oh and as for the '00' prob: wilminator, do you know which part of the code decides where to display the cursor and in which color ?
====== wilminator (2009-09-12 05:02:20) ======

Which map? And yes aduke1, welcome to func_doors.... :P

I have tracked down what may be an error in line tracing, but it should not cause the kind of errors you are seeing here (box tracing, whole 'nother beast) and line of sight. The bug would most likely be related to weaponclips passing through walls.
====== wilminator (2009-09-12 05:03:46) ======

Correction- that would be bullets flying through weaponclips... weaponclips through walls should not be a problem...
====== aduke1 (2009-09-12 10:28:22) ======

It's the static village.map. Location is 121/119/0.

Repeat:
do you know which part of the
code decides where to display the cursor and in which color ?
====== wilminator (2009-09-15 03:57:43) ======

Look at CLAddTargetingBox in cl_actor.c.
====== aduke1 (2009-09-16 21:55:05) ======

Thx, wilminator, I'll take a closer look there :)

Now that radiant works again, I gained some more insight.
Man, this damn little door seems to open a can of worms for us :(

1. NO, it's not a func_door, it's worldspawn.

2. I removed the PASSABLE flag from both handles. Results:
- the pathfinding overlay shows the open part of the door as blocked, the closed part as 'can walk through'.
- running the map in UFO with a real actor, he'll walk around the open part (well, diagonally right through the frame)
- he will walk around the closed part orthogonally as he should on his way *into* the hospital, but walks right through the glass on his way out.

3. I removed both handles from the doors. Result:
Pretty much the same as above, except for the fact that the actor can now walk through the open part of the door in one direction (from entrance to parking lot).

4. I noticed that the glass in the doors has different blend values. I swapped them. Result:
No change.

I'm rather puzzled atm.

====== aduke1 (2009-10-07 22:00:02) ======

I copied both doors to some 'labratory map' to narrow it down. Then I noticed that the glass in the doors is func_breakable, read something in our wiki that you should not copy func_breakables because it might srcew up pathfinding. Suspicious.

Richlv,
Could you plz make the glass unbreakable again and tell me if the prob persists ?
You know the maps much better than me. Can you think of a similar situation with func_breakable on some other maps and tell me if they have the same prob ? (walk through glass or frame)
====== tlh2000 (2009-10-14 06:13:53) ======

this might be the same problem as we have for func_door, too - bmodels need their mins/maxs shifted for random map assemblies (though not origin based bmodels like func_doors) - maybe the shifting is not correct. activate the cvar - sv_send_edicts to see bounding boxes for the server side mins/maxs rendered for bmodels.
====== aduke1 (2009-10-17 21:24:15) ======

The situation has improved a lot with r26568: we can no longer walk through the glass; but we still can walk through the doorframe of the open part of the doors diagonally.
====== aduke1 (2009-10-19 23:32:59) ======

Richlv,
when you wrote "...because of center of the path not being obstructed" you were closer to the reason than all my comments below ;)

Wilminator,
here's what happens:
when tracing from 121/119 in dir 7, we take the 'shortcut' and trace from sky to earth.
We detect the upper part of the door at 15 quants fine.
As we have enough headroom, we use MicroTrace() to see if we can step up and down again those 15 quants.
MicroTrace fails to detect anything that is two or more mapunits away from the line (which is the case here) and will give us 14 quants back as the bonusheight.
Result: no obstruction at all.

So what can we do ?
1. Leave everything as is. It looks ugly, but it will not really break gameplay.
2. Adjust the maps. In this particular case, we could expand the door a bit until it is no more than 1 mapunit away from the very edge of the cell, so it can be detected by the MicroTrace. But this effect also applies to eg. the corner of a table or crate that is close, but not close enough to the edge of the cell.
3. Increasing microstep size from 4 to whatever doesn't help coz that would break the walkabilty of many stairs on our maps.
4. I also thought of an actor-sized trace starting at LEGROOM above the floors that MicroTrace finds and going up. But that would also break at least the steepest of the stairs we can currently climb (in theory).
5. In this example it's rather obvious: Walking from floor=1 up to 15 and back down to 1 is not possible. We could restrict that to 6 or 7. But that would restrict our ability to climb (might even make sense) but wouldn't solve it for tables & crates.

Anybody with better ideas ?

====== wilminator (2009-10-20 06:30:18) ======

routing.c patch
====== wilminator (2009-10-20 06:38:20) ======

Wow, I'm writing code again.... cool!
I've attached a patch that should fix the issue. I compiled the map with -debugtrace to see what was happening. The sky trace is tried, but fails because the galss is in the way. So it reverts to the brute force search, which finds the top of the door as the initial floor and sticks the value in opening->base. As mentioned before, RT_MicroTrace misses the door because it is too tiny.
But since we found the door with the original passage trace (as opening->base), I added a check so the middle base gets adjusted to the lowest height possible if opening->base is more than MIN_STEPUP above the found floor for that one trace. The effect is that it re-inserts the wall into the microtrace- giving the passage a stepup value of 13 == impassable. This should fix most issues like this.
Mike (wilminator)
====== aduke1 (2009-10-20 12:59:08) ======

Excellent :)
Just tested it, and it works nicely.
You should commit the patch asap.
====== wilminator (2009-10-21 04:14:18) ======

Committed fix, changing status to pending. Awaiting confirmation from bug reporter.
====== aduke1 (2009-10-27 23:02:21) ======

Richlv,
your #00 prob should also be fixed as of r26804 :)
====== richlv (2009-10-31 12:14:01) ======

hmm. i was sure i commented on this bug already - probably gprs ate my comment.
anyway, problem 01 is fixed, but 00 is not fixed in revision 26846
====== aduke1 (2009-10-31 20:07:37) ======

You're right, r26804 merely skipped the *display* of the cursor.

I guess r26858 really fixes it :)
====== richlv (2009-10-31 23:24:47) ======

hooray. confirming that both problems are fixed in trunk, rev 26859 :)