Visportals that can decrease sound

[Baddcog]

Wrong thread?

 

Nope, Spring mentioned ai trying to throw rocks through windows...a few posts up.

[Springheel]

Hmm, I've been noticing a few oddities in maps lately. It seems like sounds are traveling to areas further away than they used to in at least two maps I've been playtesting. I've tracked it here: http://bugs.thedarkm...iew.php?id=3340

 

Anyone using the SVN build, please keep your ears open for this.

[grayman]

I checked in a change to bring the sound volume through closed doors more in line with what we're used to hearing. It adds 10dB to the "loss_closed" value on doors. This only affects player sound.

 

A new windows DLL is available in SVN rev 13352. Make sure you delete darkmod/gamex86.dll before testing.

 

Making this change exposed an engine bug in my original sound changes, so there's a new engine as well.

 

Remember to put "loss_closed" back to "10" in the door definition.

[grayman]

I noticed that with the recent door sound loss change, it's not easy to hear AI footsteps through doors.

 

Please do some testing and see if we need to adjust the extra 10dB loss on doors for player sound to something less. If we do, the machine noise coming through the kitchen door in Chalice will get louder, though. Perhaps we can find a happy middle.

[Obsttorte]

Is the door loss different if you lean against the door (standing beside it and leaning sidewards)? In this case it may be good, because it gives the listening at doors feature much more sense.

[grayman]

Leaning into a door still works as it always has: no sound loss.

 

So perhaps this would encourage more door-leaning-into-ness.

[Springheel]

Agreed.

[Tels]

Leaning into a door still works as it always has: no sound loss.

 

So perhaps this would encourage more door-leaning-into-ness.

 

Sidetracking this: Shouldn't there still be a door-loss, depending on door-type, albeit less than when the door is closed? E.g. 0.1 x the door_loss when closed, or so? Otherwise, a heavy iron door and a paper-thin wood-door would sound the same when you lean in. I could see mappers trying to have different doors for some reasons, and the "no sound" loss would counter this completely.

 

Encouraging leaning into doors is of course a good idea.

[Obsttorte]

This sounds reasonable, although I'm not sure if it is a good idea to give the mappers the possibility to change such values. Maybe just my lack of fantasy.

[Tels]

This sounds reasonable, although I'm not sure if it is a good idea to give the mappers the possibility to change such values. Maybe just my lack of fantasy.

 

I didn't mean the mapper should be able to change this factor directly, but indirectly by choosing a different type of door (heavy steal vs. thin wood). So if the sound_loss_lean_in is simple sound_loss_closed * 0.1, that would account for different doors, but not give mappers any value to change.

 

Also, this brings me to the question: How are grates handled in sound_loss? I guess a portcullis/grate should not have a sound_loss? How is that defined/changed on a door now?

[Obsttorte]

I didn't mean the mapper should be able to change this factor directly, but indirectly by choosing a different type of door (heavy steal vs. thin wood). So if the sound_loss_lean_in is simple sound_loss_closed * 0.1, that would account for different doors, but not give mappers any value to change.

OK. Then we're on the same page.

Also, this brings me to the question: How are grates handled in sound_loss? I guess a portcullis/grate should not have a sound_loss? How is that defined/changed on a door now?

Doesn't the sound loss only apply to doors that are touching a visportal. As grates doesn't do that, they should not affect sound at all.

[Tels]

OK. Then we're on the same page.

 

I'm not sure about you, but I'm generally not on pages

 

Doesn't the sound loss only apply to doors that are touching a visportal. As grates doesn't do that, they should not affect sound at all.

 

Right, that was a thinko on my part

[grayman]

After my changes, grates, jail cell doors, portcullises, etc. can touch a visportal as long as the door has the "transparent/1" spawnarg.

 

It's up to the mapper to change the default "loss_closed" setting for doors made of different materials. All we provide is a default setting of 10.

 

As for leaning into a door and applying a factor to loss_closed so the volume isn't full strength, that can be done and would be more realistic. Or, if there's concern that mappers might not want players to hear anything through a particular door, we could provide a "no_lean_in_sound" spawnarg and default it to 0. The mapper could set it to 1 to cut off all sound from leaning in.

[Tels]

After my changes, grates, jail cell doors, portcullises, etc. can touch a visportal as long as the door has the "transparent/1" spawnarg.

 

It's up to the mapper to change the default "loss_closed" setting for doors made of different materials. All we provide is a default setting of 10.

 

Great to hear that there is now a transparent spawnarg! This will come in handy.

 

However, I have two small requests here:

1. The default should be different for different doors. (metal/wood etc.)
   
2. The new spawnargs don't seem to be documented nor set in the def files. Could you please add these there with "editor_bool transparent" etc on the door base entity? If you have added other spawnargs, please add them, too.
   

 

"editor_bool transparent" "blah blah blah."

 

etc.

 

As for leaning into a door and applying a factor to loss_closed so the volume isn't full strength, that can be done and would be more realistic. Or, if there's concern that mappers might not want players to hear anything through a particular door, we could provide a "no_lean_in_sound" spawnarg and default it to 0. The mapper could set it to 1 to cut off all sound from leaning in.

 

If we provide a way for mappers to influence it, it should be a factor, not a boolean, because the code effort is the same, but it is more flexible.

[Springheel]

he default should be different for different doors. (metal/wood etc.)

 

Door entities don't record what type of material they are. The mapper just applies a skin.

[Tels]

Door entities don't record what type of material they are. The mapper just applies a skin.

 

Ah, shoot. But we do have pre-made entities that are the same "type"? E.g. "heavy door + skins", "light door + skin", "metal door + skin"? We can't cover every case, but the ones the mappers use most should be correct w/o the mapper having to do something.

[Springheel]

But we do have pre-made entities that are the same "type"?

 

No. We just have entities for different door sizes (they're all the same thickness).

[grayman]

The new spawnargs don't seem to be documented nor set in the def files. Could you please add these there with "editor_bool transparent" etc on the door base entity? If you have added other spawnargs, please add them, too

 

Done in the def files. I think this is the only one I missed.

 

I haven't written any documentation yet.

[Tels]

Done in the def files. I think this is the only one I missed.

 

Thanx!

 

I haven't written any documentation yet.

 

Fair enough Thank you for the work, it is already cool

[Obsttorte]

I'm not sure about you, but I'm generally not on pages

Alter, machs mir nicht so schwer. Ich dachte das ist ein englisches Sprichwort. Ich meinte nur das wir die selbe Ansicht teilen.

 

Addition: I agree with Tels that there should be default values for different "types" of doors dependend of the material they are made off, so that mappers (that may not be aware of the specific spawnargs) don't have to adjust this. I know this means extra effort, but .... I don't know how to complete this sentence

[plasticman]

Ich dachte das ist ein englisches Sprichwort.

It is:

 

[Springheel]

Addition: I agree with Tels that there should be default values for different "types" of doors dependend of the material they are made off,

 

How would you suggest doing that? Other than making separate door entities for every conceivable texture/size combination (and we have easily 30 different door textures and at least 4 different shapes and sizes), there's no way to know what skin a mapper has chosen for the door.

[grayman]

KISS.

 

Leave it up to the mapper.

[Baddcog]

Yeah, seems that door sound blocking would be minimal between door types (would a metal door really block that much more sound than a wood one?).

 

I can see a door with a small window (opening) in it blocking more sound than an open door. But a mapper can set that prop (atm they'd have to make the door too anyway)

[grayman]

As for leaning into a door and applying a factor to loss_closed so the volume isn't full strength, that can be done and would be more realistic. Or, if there's concern that mappers might not want players to hear anything through a particular door, we could provide a "no_lean_in_sound" spawnarg and default it to 0. The mapper could set it to 1 to cut off all sound from leaning in.

 

It appears this is impossible to do, given the current design (even after my changes).

 

The way eavesdropping works is that the player's "ear" is virtually moved to a point on the other side of the door. Since the door does not lie on the path eavesdropped sounds take as they travel from their origins to the player's "ear", any spawnargs on the door dealing with sound loss have no impact.

 

I changed the extra player-only sound loss to 9dB from 10dB, and this lets me hear faint footsteps and barking from patrolling lobby guards while standing in the Outpost sleeper's room.

 

In Chalice, the courtyard machine is slightly louder when standing in the kitchen, but it's still pretty close to what we hear with 1.08.