 |
I didn't see alerted AI when I launched this mission. Fixed by 4613? |
 |
The jail guards are alerted by the falling inmate bodies. I fixed this a long time ago, and SVN has resurrected it. |
 |
Well, the body falls in 75-th frame according to logs: [game\Entity.cpp (4694):DEB (SOUND) FR: 75] PropSoundS: Propagating global sound bounce_large_soft_on_soft without checking local sound [game\SndProp.cpp (1159):DEB (SOUND) FR: 75] Processing AI long_distance_guard in initial area 33 [game\SndProp.cpp (1160):DEB (SOUND) FR: 75] Dist to AI: 9.077142 [m], 357.367798 [D3], Propagated volume 21.294584 [dB] [game\ai\AI.cpp (9635):DEB (SOUND) FR: 75] CheckHearing to AI long_distance_guard, loudness 21.294584, threshold 18.799999 [game\ai\AI.cpp (9655):DEB (SOUND) FR: 75] CheckHearing to AI long_distance_guard, loudness 21.294584, threshold 18.799999 |
|
|
The intent is that suspicious sounds don't propagate in the first second of the game. The "first second" used to be measured at 60FPS, so the sound won't propagate before frame 60. This was fixed in 2.03, 3 years ago. I'll collect the data from a 2.03 run and see how it compares with data from an SVN run. |
|
|
I have attached a patch which changes initial location/orientation, so that player spawns in front of the offending "ragdoll 5". Also I have attached a video showing how this ragdoll falls. I must admit it takes him a long time to get still =( BTW, was ragdoll physics always so bad? Or it is yet another thing which happened when switching to MSVC2013 + SSE? |
|
|
atdm_env_ragdoll_beggar_5 is indeed the offender. In 2.03, he fell straight to the cot and turned slightly. Stable in < 1s. In SVN, he hits the cot and vibrates himself off the edge, onto the floor. Stable in > 1s. I'll check what he does in 2.04 and 2.05, but for the moment, it look like he doesn't like some physics change done between 2.03 and today. |
|
|
In 2.05, he throws one arm off the bed, which alerts the nearby guards. |
|
|
In 2.04, he moves a bit more than in 2.03, which alerts the nearby prisoners, but not the guards. |
|
|
It sounds like physics was never stable enough, so it would unlikely be stable soon. Then we can never be absolutely sure that fixed number of seconds would be enough for a ragdoll to get still. As for simple fix, we can extend this period to two seconds (but not 120 frames I suppose). Or we can try to change ragdoll position in the mission, which is less desirable, I suppose. To be honest, I cannot think of more proper solution. Trying to detect whether some sound is initial or player-induced is not going to work correctly. Theoretically, we can set larger period of mute if we spawn player after it too. Otherwise there is always risk that quick action of player would go unnoticed by nearby guards. |
|
|
Yes, I was thinking 2s myself, as well as altering the check from frames to time. I assume gameLocal.time starts counting at the end of frame 0. We shouldn't have to worry about losing suspicious sounds from the player that early. Nearly all maps provide a safe landing spot for the player at map start. AFAICR, only The Alchemist drops the player in front of several guards. They're going to see the player before they hear him, so loss of the initial sounds shouldn't be a problem. |
|
|
Remind me again how to uncap FPS. This time I'll write it down. |
|
|
Capped FPS with physics capped (legacy behavior): com_smp 0 com_fixedTic 0 Capped FPS with uncapped physics (2.05 behavior): com_smp 0 com_fixedTic 1 r_swapInterval 1 Uncapped FPS with most physics capped: com_smp 1 com_fixedTic 0 Fully uncapped (best performance): com_smp 1 com_fixedTic 1 Note: r_swapInterval 1 caps any of the above scenarios but does not affect physics tics. The uncapped physics modes are mostly correct but it would be ideal if they were fully fixed and we could drop all modes that use com_fixedTic 0 as that mode often produces lag or stutter when changing views (etc). |
|
|
Fully uncapped, Beleaguered Fence crashes at mission start. |
|
|
Uncapped FPS with most physics capped doesn't crash. |
|
|
gameLocal.time and gameLocal.framenum are identical regardless of capped/uncapped fps. Capped shows last sound from the falling ragdoll at frame 103. Uncapped shows last sound from the falling ragdoll at frame 104. So it appears safe to take the simplest solution, which is to double the frame number below which no suspicious sounds are propagated. I'm going to go ahead and check in that solution. |
|
|
Fixed in rev 7124. |
|
|
Not sure that this is a good fix. As far as I understand, both times show the number of frames rendered. Then with uncapped FPS one second may take from 30 to 200 frames, depending on player's hardware. I have about 100 FPS at the mission start. With uncapped FPS, the body drops differently each time I restart the mission. Sometimes I see something like: [game\SndProp.cpp (1159):DEB (SOUND) FR: 133] Processing AI long_distance_guard in initial area 33 [game\SndProp.cpp (1160):DEB (SOUND) FR: 133] Dist to AI: 8.599510 [m], 338.563385 [D3], Propagated volume 21.160810 [dB] [game\ai\AI.cpp (9635):DEB (SOUND) FR: 133] CheckHearing to AI long_distance_guard, loudness 21.160810, threshold 18.799999 [game\ai\AI.cpp (9655):DEB (SOUND) FR: 133] CheckHearing to AI long_distance_guard, loudness 21.160810, threshold 18.799999 So the better approach would be to use GamePlayTimer. Duzenko added millisecond-resolution timer there, although he did not fully exposed it. We need member _msecPassed, which has no getter currently. EDIT: asked about why there is no getter in discussion of 0004409. |
|
|
Are you saying that gameLocal.framenum now increases at a different rate (frames/second) than it did in 2.05? And that it increases at a different rate when FPS is 60 vs., say, 500? Isn't that a huge problem? |
|
|
I'm not 100% sure here. But isn't 0004493 entirely about this "huge problem"? I suppose anything looking like integer frame number cannot represent physical time if FPS is uncapped. BTW, it just occured to me that GamePlayTimer._msecPassed might be a bad way to measure physical time, in case if physics is slowed down when FPS < 60... I guess we need to ask some expert in these matters (e.g. Duzenko) to write a small wiki article, which would explain all the different timers: frame number / physical time / astronomical time; absolute / of gameplay only. |
|
|
Could you ask him? There are more than 1500 uses of gameLocal.framenum. Granted, many are print statements, but we can't be changing the underlying timing of events in the game; too much will break. |
|
|
Ok, Duzenko agreed that "gameLocal.time" reflects physical time (in milliseconds). Judging by code, it is physical time elapsed since game started (savegame-persistent). So it would be better to check (gameLocal.time < 2000) instead of (gameLocal.framenum < 120). |
|
|
Done. |
|
|
The issue still happens for me on the latest 2.06 beta sometimes. The first time I tried guards even went to alert level 4. I think we should NOT try to hack the game rules to make a single map with a stupid error work well. Instead, we should fix the map issue. Remove that goddamn body! Or at least place it better so that it does not fall so randomly. |
|
|
Heh. PMing Sotha, adding you. |
|
|
The solution of moving or removing the ragdolls in BF so they don't take so long to fall into place isn't satisfactory. More ragdolls end up with their arms sticking through walls (BF in 2.05 had a couple), and it doesn't look good. Instead, I looked at how long it took each of the ragdolls in BF to come to rest. A few of them don't do so until long after the current 2s mark for propagating suspicious sounds. They haven't bothered the other AI in the prison up to now simply due to distances the sounds must travel. Since allowing ragdolls to fall into place at the start of a mission should NEVER alert nearby AI, I've decided to not let ragdolls make a suspicious sound until they've initially come to rest. Once they've done that, they can make all the sound they want (i.e. the player picks one up and dumps it near a guard). This keeps the ragdolls that take way more than 2s to come to rest from alerting nearby AI. I've kept the 2s boundary, though, for all suspicious sounds, to cover the case where the player might be dropping into place at the start of a mission. This also upset the beginning of BF, because a patrolling guard is right in front of the player when the player lands. Rev. 7343: Physics_AF.cpp AFEntity.cpp AFEntity.h |
- Anonymous
