 |
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. |
 |
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. |
|
|
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 |
- Anonymous
