 |
Config/savegame? |
|
|
I looked at atdm_ai_thief02_3, who patrols the building and passes near 9326.95 613.45 -679.84 (where he sometimes dies according to logs). It seems that sometimes he tries to sit down, but gets "teleported" to weird places due to it. Hence added 0004940 as related. |
|
|
Here is the footage of miserable death due to programmers' bugs =) https://thedarkmod.blob.core.windows.net/various/forum_images/5156_pd3_accident.mp4 |
|
|
Two more cases: https://thedarkmod.blob.core.windows.net/various/forum_images/5156_pd3_accident2.mp4 https://thedarkmod.blob.core.windows.net/various/forum_images/5156_pd3_accident3.mp4 The exact effect is different, but all the time AI tries to sit down in a horribly wrong way. |
 |
I'm not able to repeat the events from the start log in the description at will. But two things that always happen are: 1. at spawn location, strife right until blocked by wall - always a huge translation for player console log 2. setviewpos 8800 2064 -583 and try walk forward - movement blocked by stairs with "huge translation" log Suspecting that physics fails to process small movements happening in high coords due to fp32 precision loss? |
|
|
Curious: the huge translation happens in 64bit release but not in 32bit debug build Apparently triggered by "Maximum Optimization (Favor Speed) (/O2)" |
|
|
Unless debugger plays tricks this line is suspicious (physics_player.cpp:402): idVec3 fullForward = downTrace.endpos + maxStepHeight * velocityNorm; + downTrace.endpos {x=8839.75000 y=2064.00000 z=-629.874695 } idVec3 maxStepHeight 16.0000000 float + velocityNorm {x=56.1372032 y=0.000000000 z=42.1064301 } idVec3 + fullForward {x=613956.500 y=2064.00000 z=5954735.00 } idVec3 |
|
|
Totally confused and clueless Adding the logging code makes the error go away idVec3 fullForward = downTrace.endpos + maxStepHeight * velocityNorm; gameLocal.clip.Translation( stepTrace, downTrace.endpos, fullForward, clipModel, clipModel->GetAxis(), clipMask, self ); if ( fullForward.z > 9999 ) { common->Warning( "%s\n", fullForward.ToString() ); common->Warning( "%s\n", ( downTrace.endpos + maxStepHeight * velocityNorm ).ToString() ); common->Warning( "%s\n", ( maxStepHeight * velocityNorm ).ToString() ); common->Warning( "%s\n", velocityNorm.ToString() ); } Commenting it out and the error comes back |
|
|
The attached save game always generates huge translation for crater entity when AI walks by https://drive.google.com/file/d/1we-VjDPsRhblXgJcYtc2qnQt9KvBZa5L/view?usp=sharing |
|
|
I start wondering if it's VS2019 optimizer bug. I test this with the notools project that uses 2019 build tools. |
|
|
Fixed by updating MSVC 2019 to 16.4.5 Thank you MS for wasting a day of my life |
|
|
I cannot reproduce anything you are saying. But AIs are dying, and it is an unrelated problem. |
|
|
Sorry, but I still see AIs on this map self-killing and teleporting to nowhere. Regardless of which MSVC I'm using. Basically, the Chair-Killer has returned! =) So I'll keep this task open. |
|
|
Speaking about atdm_ai_thief02_3, who happens to teleport to many various places when he tries to sit down. In one of the cases he teleports outdoors =) Looking at what caused the movement, I see that ai_darkmod_base::Legs_Sit_Down script is calling setOrigin here: vector vec2Ideal = getVectorToIdealOrigin(); // vector from where the AI stopped walking to the ideal location for sitting vector startLocation = getOrigin() + vec2Ideal; // base movement toward ideal location float vec2IdealLength = sys.vecLength(vec2Ideal); if (vec2IdealLength > 0) { float time2Slide = 0.5; // Slide to ideal position in 0.5s. float slideIncrements = 10; // Do it in 10 increments vector incSlide; // Incremental slide incSlide_x = vec2Ideal_x/slideIncrements; incSlide_y = vec2Ideal_y/slideIncrements; incSlide_z = 0; // assume AI is on the floor, so ignore any z component float incTime = time2Slide/slideIncrements; float i; for (i = 0 ; i < slideIncrements ; i++) { setOrigin(getOrigin() + incSlide); sys.wait(incTime); } } When inspecting the vec2Ideal value, I see that: (9288 80 -688) --- location of path_sit2 (9338 118 -703) --- approximate origin when AI starting sitting down (9248 712 -448) --- owner->GetMemory().startSitLocation --- i.e. the destination of the movement caused by script code So the "ideal" location is very far. In fact, it is exactly where path_corner_307 is located, which is several path-entities away. |
|
|
As far as I guess, the idea was to "snap" AI into the mapper-specified location at the moment of sitting. I don't understand why path_sit entity itself could not be used for it --- that would be quite logical. Supposedly because position of path_sit never influenced anything, so mappers put it into random places. That's why we try to get the last visited path_corner entity and snap AI into its location. This is logical if everything went normal, then the AI should have started sitting down from that location (since task changed to "sit" immediately after that). I looked where startSitLocation is updated. There are two places, and I guess this is the main one: // grayman 0003989 - Save the ideal sitting location, which is the path_corner origin. // This is useful when sitting down and lying down, to make sure I sit // or lay down in the correct place. owner->GetMemory().startSitLocation = path->GetPhysics()->GetOrigin(); So I started the game afresh and recorded which "path" entities happened here: Entity "path_corner_301": num=5979 def=77 Entity "path_corner_314": num=5993 def=77 Entity "path_corner_307": num=5985 def=77 Entity "path_corner_318": num=5998 def=77 Somewhere here the guy tried to sit down, and was pulled back apporoximately to where path_corner_318 is. Then he continued patrolling: Entity "path_corner_314": num=5993 def=77 After that he tried to sit down again, and was thrown into path_corner_314 location, and killed by the stairs obstacle. |
|
|
Ok, the reason was that there is another was out of PathCornerTask: else if (_usePathPrediction) { // Move not done yet. Try to perform a prediction whether we will hit the path corner // next round. This is valid, as no accuracy is set on the current path. I added the same assignment in this code path, and now the guy does not die. However, he sits straight on the stairs instead of the bench. The last location when is assigned to startSitLocation is "path_corner_316". I have no idea why "path_corner_300 is ignored: it is in-between "path_corner_316" and "path_sit_2" on the patrol path. |
 |
Working on the problem, with notes being attached to issue 3989. When the problem is fixed, I'll note that in the related issues. |
|
|
The missing line stgatilov pointed out in the path prediction code was the root cause of these huge translation problems. With the line added, the PD3 AI properly navigated his patrol w/o huge translations or damage. The problem of his sitting in the wrong places is a problem with the map: the monsterclip around the bench he's supposed to sit on is misapplied, making it impossible for him to get to the path_corner in front of the bench, at which he sits down. Since he can't get to the path_corner, he sits wherever he is at the moment. I've seen him sit both at the bottom of the stairs and in front of a nearby door. The path_corners in those locations are trying to get to the bench path_corner, but find that they're unable to. Fixed in rev. 8595: AI.cpp AI_events.cpp Memory.cpp Memory.h MovementSubsystem.cpp IdleState.cpp PathCornerTask.cpp |
|
|
Committed a corrected copy of erasing.map (PD3) if anyone wants to dmap it and observe the behavior of the afflicted AI. darkmod/maps/bug5156_corrected_PD3/erasing.zip |
- Anonymous
