View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004912||The Dark Mod||AI||public||12.12.2018 04:27||24.01.2019 02:57|
|Target Version||TDM 2.07||Fixed in Version||TDM 2.07|
|Summary||0004912: AI ignoring 40 degree slope limit. Walking up walls and getting stuck.|
|Description||I 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 Information||Maybe 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;
|Tags||No tags attached.|
Quicksave_0.save (2,015,987 bytes)
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.
Could you please provide coordinates where the problem happen?
You can get them by using getviewpos consoel command.
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
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.
business3_guard_in_air.jpg (274,797 bytes)
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.
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.
|"reducing AAS size" = nonononono|
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.
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.
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.
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.
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?
|Setting func_static_279 to "noclipmodel" "1" cured the issue in Business v3|
|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: Quicksave_0.save|
|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|