View Issue Details

IDProjectCategoryView StatusLast Update
0004912The Dark ModAIpublic24.01.2019 02:57
Reporternbohr1more Assigned Tograyman  
Status resolvedResolutionwon't fix 
Product VersionSVN 
Target VersionTDM 2.07Fixed in VersionTDM 2.07 
Summary0004912: AI ignoring 40 degree slope limit. Walking up walls and getting stuck.
DescriptionI thought this was a map bug with Return to the City v3 but Business as Usual is facing the same issue.

AI are trying to walk up angled walls that are far steeper than 40 degrees.

Savegame from "Business as Usual" attached.
Additional InformationMaybe something to do with this snippet in Monster_Physics.cpp

// greebo: We have collided with a steep slope in front of us
    if (projection < minFloorCosine && projection > 0.06f)
        // greebo: Set the endposition a bit more upwards than necessary to prevent gravity from pulling us down immediately again
        stepPos = tr.endpos - gravityNormal * stepUpIncrease;
        // No slope, just use the step position
        stepPos = tr.endpos;

    // if the move is further without stepping up, or the slope is too steep, don't step up
    nostepdist = ( noStepPos - start ).LengthSqr();
    stepdist = ( stepPos - start ).LengthSqr();
    // Use the position that brought us the largest forward movement
    if (nostepdist >= stepdist)
        start = noStepPos;
        velocity = noStepVel;
        return MM_SLIDING;
TagsNo tags attached.




12.12.2018 04:27

developer (2,015,987 bytes)


13.12.2018 12:50

administrator   ~0010903

Correction: Physics_Monster.cpp

I made a change a few lines below the ones you cited, but they only take effect if the AI is falling asleep or getting up.


13.12.2018 16:44

administrator   ~0010905

Could you please provide coordinates where the problem happen?
You can get them by using getviewpos consoel command.


14.12.2018 01:20

developer   ~0010908

Business as Usual v3:

-120.83 396.92 55.08 : 1.44 -4.29 0

Return to the City v3:

-91.64 164.56 448.93 : -11.88 5.83 0


14.12.2018 04:54

administrator   ~0010910

Ok, I noticed how guards sometimes jump into 80-degree steep wall =)

The code you cite does not prevent it from happening. Instead, it lifts guard up if he tries to go along the steep wall, so that he does not get into the wall.

I don't know if preventing guards from going up was intended. If we do it the hard way, it might break something.
Also note that sometimes guard needs to step over a small obstacle. This obstacle might by 89-degrees steep but have a height of half a meter. So measuring steepness only by slope is definitely a bad idea.

Another approach would be tweak AI to avoid going up so steeply. Maybe it can be done by reducing AAS size, maybe not. When guard cannot go through easily, he starts running around, possible bumping into walls. And this moment he can go up accidentally.


14.12.2018 04:58




14.12.2018 05:22

administrator   ~0010911

Last edited: 14.12.2018 05:40

View 2 revisions

Side comment: It would be nicer if the getviewpos command spammed the console every second or so, rather than having to be typed in all the time. The way it is now, it's extremely frustrating trying to find a location.

Ah, nevermind. Looking at the code shows me there's a setviewpos command, which solves my problem.



14.12.2018 05:23

administrator   ~0010912

Last edited: 14.12.2018 05:24

View 2 revisions

I don't see a sloping wall in BAU at -120.83 396.92 55.08. ??

Nevermind, I see the slope on the support column.



14.12.2018 05:27

administrator   ~0010913

"reducing AAS size" = nonononono


14.12.2018 05:34

administrator   ~0010915

Last edited: 14.12.2018 05:36

View 2 revisions

The root cause is that the map isn't properly monster_clipped on those func_static support columns. The AI thinks he can climb the column, regardless of the slope. This has to be supported because mappers sometimes use thin slivers to help the AI go up and down in tight spaces.

I suspect the other problem location(s) have the same "problem".

I would say that trying to solve this w/o map improvements has a good chance of creating problems elsewhere.



14.12.2018 13:14

administrator   ~0010918

RttC has the same problem: some monster_clip could have been applied around the sloped building corner to prevent the climbing.

I'll look at the situation, but if older versions of TDM show the same behavior, I'm not inclined to make changes for 2.07, because maps have been played for years using the older versions, and we haven't been deluged with complaints.

On the other hand, if 2.06/2.07 broke something, I'll try to fix it.


14.12.2018 19:41

administrator   ~0010919

After looking at the math, the only good solution is to use proper monster_clipping in the map, to keep the AI away from these sloped walls.

The math is designed to maneuver up and down slopes, and changing any of it endangers the situations where it looks fine.

If I were to try to accommodate the steep slopes by trying to move the AI away from the slope, so he doesn't move so far up, it's not going to look good as he slides sideways.

It's best that the AI not get anywhere near these situations, and that's what monster_clipping is for. Let's make the mappers use it.


23.01.2019 16:33

developer   ~0011481

Regarding Monsterclip in RTTC...

It seems that the affected building has decal overlays on the walls which might
be overriding the normal collision\clip behavior.

I added override materials to the mission with monsterclip in the global header for the decals and repacked the mission.


24.01.2019 02:14

developer   ~0011487

I tried adding monsterclip args to the materials on the affected wall in
"Business as Usual" but the behavior persisted after a dmap.

When I viewed the area in g_showCollisionWorld, I saw a giant slab in front of the wall. I can only guess it's caulk?


24.01.2019 02:57

developer   ~0011488

Setting func_static_279 to "noclipmodel" "1" cured the issue in Business v3

Issue History

Date Modified Username Field Change
12.12.2018 04:27 nbohr1more New Issue
12.12.2018 04:27 nbohr1more Status new => assigned
12.12.2018 04:27 nbohr1more Assigned To => stgatilov
12.12.2018 04:27 nbohr1more File Added:
13.12.2018 12:50 grayman Note Added: 0010903
13.12.2018 16:44 stgatilov Note Added: 0010905
14.12.2018 01:20 nbohr1more Note Added: 0010908
14.12.2018 04:54 stgatilov Note Added: 0010910
14.12.2018 04:58 stgatilov File Added: business3_guard_in_air.jpg
14.12.2018 05:22 grayman Note Added: 0010911
14.12.2018 05:23 grayman Note Added: 0010912
14.12.2018 05:24 grayman Note Edited: 0010912 View Revisions
14.12.2018 05:27 grayman Note Added: 0010913
14.12.2018 05:34 grayman Note Added: 0010915
14.12.2018 05:36 grayman Note Edited: 0010915 View Revisions
14.12.2018 05:40 grayman Note Edited: 0010911 View Revisions
14.12.2018 05:42 stgatilov Assigned To stgatilov => grayman
14.12.2018 13:14 grayman Note Added: 0010918
14.12.2018 19:41 grayman Note Added: 0010919
14.12.2018 19:42 grayman Status assigned => resolved
14.12.2018 19:42 grayman Resolution open => won't fix
14.12.2018 19:42 grayman Fixed in Version => TDM 2.07
23.01.2019 16:33 nbohr1more Note Added: 0011481
24.01.2019 02:14 nbohr1more Note Added: 0011487
24.01.2019 02:57 nbohr1more Note Added: 0011488