View Issue Details

IDProjectCategoryView StatusLast Update
0004609The Dark ModAIpublic11.12.2017 20:07
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0004609: Beleaguered Fence AI alerted again at map start
DescriptionIssue 3768 was about alerting nearby AI at map start when the player dropped to the street outside the Watch station.

Also, guards in the jail cells were alerted slightly by the sound of ragdoll prisoners falling on their cots.

I fixed all this by not allowing propagated sounds during the first 60 frames.

With all the SVN changes post-2.05, the AI near the player at mission start don't hear him dropping, but the jailers hear the ragdolls dropping. This happens with both uncapped FPS and FPS capped at 60 (by allowing vsync).

Figure out what's going on. The hard-coded "no propagated sounds in first 60 frames" might have to be changed to account for new system settings.

TagsNo tags attached.

Relationships

related to 0003768 resolvedgrayman 2.02 sound difficulty breaks few maps at start player drop 
related to 0004616 resolvedduzenko With fully uncapped physics, Beleaguered Fence crashes at mission start 

Activities

nbohr1more

nbohr1more

07.09.2017 01:32

developer   ~0009151

I didn't see alerted AI when I launched this mission.

Fixed by 4613?
grayman

grayman

07.09.2017 01:46

administrator   ~0009152

The jail guards are alerted by the falling inmate bodies.

I fixed this a long time ago, and SVN has resurrected it.
stgatilov

stgatilov

07.09.2017 14:43

administrator   ~0009166

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
grayman

grayman

07.09.2017 14:59

administrator   ~0009167

Last edited: 07.09.2017 15:01

View 3 revisions

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.

stgatilov

stgatilov

07.09.2017 15:06

administrator  

stgatilov

stgatilov

07.09.2017 15:06

administrator  

Issue_4609_changestart.patch (463 bytes)   
Index: game/Player.cpp
===================================================================
--- game/Player.cpp	(revision 7118)
+++ game/Player.cpp	(working copy)
@@ -2732,6 +2732,9 @@
 	origin = spot->GetPhysics()->GetOrigin();
 	origin[2] += 4.0f + CM_BOX_EPSILON;		// move up to make sure the player is at least an epsilon above the floor
 	angles = spot->GetPhysics()->GetAxis().ToAngles();
+
+	origin.Set(-706, -2185, -40);
+	angles.pitch = 30;
 }
 
 /*
stgatilov

stgatilov

07.09.2017 15:08

administrator   ~0009168

Last edited: 07.09.2017 15:10

View 2 revisions

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?

grayman

grayman

07.09.2017 15:50

administrator   ~0009169

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

grayman

07.09.2017 15:54

administrator   ~0009170

In 2.05, he throws one arm off the bed, which alerts the nearby guards.
grayman

grayman

08.09.2017 02:31

administrator   ~0009178

In 2.04, he moves a bit more than in 2.03, which alerts the nearby prisoners, but not the guards.
stgatilov

stgatilov

08.09.2017 03:56

administrator   ~0009179

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

grayman

08.09.2017 05:17

administrator   ~0009180

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

grayman

08.09.2017 19:16

administrator   ~0009185

Remind me again how to uncap FPS. This time I'll write it down.
nbohr1more

nbohr1more

08.09.2017 19:59

developer   ~0009186

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).
grayman

grayman

09.09.2017 01:21

administrator   ~0009187

Fully uncapped, Beleaguered Fence crashes at mission start.
grayman

grayman

09.09.2017 01:23

administrator   ~0009188

Uncapped FPS with most physics capped doesn't crash.
grayman

grayman

09.09.2017 01:28

administrator   ~0009189

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

grayman

09.09.2017 01:37

administrator   ~0009190

Fixed in rev 7124.
stgatilov

stgatilov

09.09.2017 04:36

administrator   ~0009192

Last edited: 09.09.2017 04:51

View 2 revisions

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.

grayman

grayman

09.09.2017 12:14

administrator   ~0009196

Last edited: 09.09.2017 12:16

View 2 revisions

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?

stgatilov

stgatilov

09.09.2017 15:19

administrator   ~0009200

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

grayman

09.09.2017 15:26

administrator   ~0009201

Last edited: 09.09.2017 15:27

View 2 revisions

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.

stgatilov

stgatilov

10.09.2017 10:08

administrator   ~0009204

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).
grayman

grayman

10.09.2017 13:32

administrator   ~0009205

Done.
stgatilov

stgatilov

09.12.2017 12:52

administrator   ~0009751

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

grayman

09.12.2017 15:40

administrator   ~0009752

Heh. PMing Sotha, adding you.
grayman

grayman

11.12.2017 15:08

administrator   ~0009759

Last edited: 11.12.2017 20:07

View 2 revisions

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

Issue History

Date Modified Username Field Change
19.08.2017 20:46 grayman New Issue
19.08.2017 20:47 grayman Relationship added related to 0003768
07.09.2017 01:32 nbohr1more Assigned To => stgatilov
07.09.2017 01:32 nbohr1more Status new => feedback
07.09.2017 01:32 nbohr1more Fixed in Version => TDM 2.06
07.09.2017 01:32 nbohr1more Note Added: 0009151
07.09.2017 01:46 grayman Note Added: 0009152
07.09.2017 01:46 grayman Status feedback => assigned
07.09.2017 14:43 stgatilov Note Added: 0009166
07.09.2017 14:59 grayman Note Added: 0009167
07.09.2017 15:00 grayman Note Edited: 0009167 View Revisions
07.09.2017 15:01 grayman Note Edited: 0009167 View Revisions
07.09.2017 15:06 stgatilov File Added: tdm_4609_longfall.mp4
07.09.2017 15:06 stgatilov File Added: Issue_4609_changestart.patch
07.09.2017 15:08 stgatilov Note Added: 0009168
07.09.2017 15:10 stgatilov Note Edited: 0009168 View Revisions
07.09.2017 15:50 grayman Note Added: 0009169
07.09.2017 15:54 grayman Note Added: 0009170
08.09.2017 02:31 grayman Note Added: 0009178
08.09.2017 03:56 stgatilov Note Added: 0009179
08.09.2017 05:17 grayman Note Added: 0009180
08.09.2017 19:16 grayman Note Added: 0009185
08.09.2017 19:59 nbohr1more Note Added: 0009186
09.09.2017 01:21 grayman Note Added: 0009187
09.09.2017 01:23 grayman Note Added: 0009188
09.09.2017 01:28 grayman Note Added: 0009189
09.09.2017 01:37 grayman Note Added: 0009190
09.09.2017 01:37 grayman Status assigned => resolved
09.09.2017 01:37 grayman Resolution open => fixed
09.09.2017 04:36 stgatilov Note Added: 0009192
09.09.2017 04:51 stgatilov Note Edited: 0009192 View Revisions
09.09.2017 12:14 grayman Note Added: 0009196
09.09.2017 12:16 grayman Note Edited: 0009196 View Revisions
09.09.2017 15:08 stgatilov Relationship added related to 0004616
09.09.2017 15:19 stgatilov Note Added: 0009200
09.09.2017 15:26 grayman Note Added: 0009201
09.09.2017 15:27 grayman Note Edited: 0009201 View Revisions
10.09.2017 10:08 stgatilov Note Added: 0009204
10.09.2017 13:32 grayman Note Added: 0009205
09.12.2017 12:52 stgatilov Note Added: 0009751
09.12.2017 15:40 grayman Note Added: 0009752
09.12.2017 15:40 grayman Assigned To stgatilov => grayman
09.12.2017 15:40 grayman Status resolved => assigned
09.12.2017 15:40 grayman Resolution fixed => open
09.12.2017 15:40 grayman Fixed in Version TDM 2.06 =>
11.12.2017 15:08 grayman Note Added: 0009759
11.12.2017 17:04 grayman Status assigned => resolved
11.12.2017 17:04 grayman Resolution open => fixed
11.12.2017 17:04 grayman Fixed in Version => TDM 2.06
11.12.2017 20:07 grayman Note Edited: 0009759 View Revisions