Jump to content
The Dark Mod Forums
Sign in to follow this  
RPGista

Visportals that can decrease sound

Recommended Posts

My suggestion for the glass door thingy would be to use a new entity, that completely behaves like a door, with the only difference that it does not cause a visportal to be closed if the door is closed itself. The mapper would still have to place the visportal "inside" the door, what is, as grayman noted, much more failsafe.

 

Using this idea, I've added a "transparent" spawnarg to doors.

 

When this is set to "1", a transparent door or window with a visportal touching it will:

 

1 - not close the portal when the door closes

2 - feed the portal the correct sound loss value as the door or window opens, closes, or moves. The sound code reads the current loss and plays the volume at the correct level.

 

So this was a good idea, Obsttorte. Thanks for it.

 

I'm testing this with two windows that open onto a gravelled walkway. Two guards patrol on the gravel, and I can shut the windows and incur sound loss, so the crunching sound is loud when they pass by an open window, and somewhat muted when they pass by a closed window.

  • Like 2

Share this post


Link to post
Share on other sites

Good work. :smile:


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites
Two guards patrol on the gravel, and I can shut the windows and incur sound loss, so the crunching sound is loud when they pass by an open window, and somewhat muted when they pass by a closed window.

How does it currently work for normally closed doors/windows atm..?

 

Good work on this btw guys :-)

Share this post


Link to post
Share on other sites

Only doors occlude sound when closed. Windows (glass, so you can see trough them) do not occlude sound, as it is not possible to place a visportal in them.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

Since I'm working on ramping sound up and down when doors open and close, I want to know how open an open door is. There's an existing routine that gives me this, but it's incorrect for doors that open clockwise ("rotate 0,-90,0"), providing weird values. I corrected the code, but the same routine is used for something called "fine control frobbing" on doors. Here's a comment from Ishtvan:

 

// Ishtvan: Allow for fine control when frob is held
virtual void FrobAction(bool frobMaster, bool isFrobPeerAction = false);
virtual void FrobHeld(bool frobMaster, bool isFrobPeerAction = false, int holdTime = 0);
virtual void FrobReleased(bool frobMaster, bool isFrobPeerAction = false, int holdTime = 0);

 

FrobHeld() is the routine that calls the buggy "what percent open" routine.

 

Is this the infamous "hold frob on door and you can ease it open" function that either was never implemented or doesn't work?

 

Maybe the bug I found is a step toward making it work.

Share this post


Link to post
Share on other sites
Is this the infamous "hold frob on door and you can ease it open" function that either was never implemented or doesn't work?

 

Yes, that's what it sounds like.

Share this post


Link to post
Share on other sites

There's an existing routine that gives me this, but it's incorrect for doors that open clockwise ("rotate 0,-90,0"), providing weird values.

What exactly do you mean with weird? Can you post some examples (of both correct and incorrect values).

 

Where is the routine (and what's its name) stored in the code?


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

The routine is CBinaryFrobMover::GetFractionalPosition(). It measure how "open" something is.

 

The problem is that the code normalizes angles to -360 -> 360 and it should be normalizing angles to -180 -> 180.

 

By "weird" I mean that it should provide results between 0.0 and 1.0, and when the angles are normalized wrong, the routine can provide results outside this range.

 

I won't post examples, because I'd have to take the time to create them, and put the code back to its original bad state.

Share this post


Link to post
Share on other sites

At mission start, when sitting at the "Hit Attack ..." screen, you might have noticed some nearby sound that cuts off when you hit the attack key.

 

This problem is fixed by not running sounds until the Attack key is pressed. The problem was caused by doors not closing their portals until 16ms after the Attack key is pressed (the game clock doesn't start running until then, and the initial portal close runs off the clock).

 

The only objection I can see is that any sounds in the room where the player starts (don't need to go through door portals to get to him) will be silent until the player is ready to start.

 

I don't think this is a problem, but if anyone objects, let me know. The player can't see anything, so not hearing anything should also be fine.

Share this post


Link to post
Share on other sites

Great fix in my opinion, I suffer from this problem in my own map too, would be good to get rid of those broken sounds.

Share this post


Link to post
Share on other sites

I just looked at the doom3 gpl and beneath the normalize360() function there is also a normalize180() version, so you could try this one.

 

The difference is that the 360 version should return a value between 0 and 360 degrees, while the second one returns one between -180 and 180 (what may be more suitable here).

 

https://dev.visucore...ygen/index.html

 

https://dev.visucore.com/doom3/doxygen/classid_angles.html


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

The sound_loss value on location separators is now added to any loss values on a door when they touch the same portal. It now works as advertised.

 

All loss spawnargs now apply to both AI and the player.

  • Like 2

Share this post


Link to post
Share on other sites

This is great news for an old problem. Thanks for your work grayman!

 

Patently Dangerous

 

Separators on two windows provide additional losses of 20, so when the window is closed, the total sound loss would now be 30 instead of 10. No change to the sound loss when the window is open, because the separator won't contribute. Edit - based on what Springheel said below, the "sound_loss" would be expected to contribute even when the window was open, so the loss with the window open would now be 21 instead of 1.

 

Sorry I'm just replying to this. I added those because the footsteps from the upstairs guard was leaking onto the street below (on the easy difficulty where the windows were left open) and I didn't like that, so its contribution when the window was open was actually the original intention and a good thing. I don't see it really affecting the gameplay anyway.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

Grayman, since you've been looking into sounds, do you understand what this value is doing?

 

 

"editor_float maxrange" "Range in meters above which sound propagation is not calculated for the calibrated sound volume. NOTE: Values of maxrange 2.2 and cal 30 means a whisper of 30dB SWL gets cutoff after travelling 2.2 [m] (~7ft). maxrange has no bearing on how AI are alerted, it's just for optimization, although if it's set too low then sounds will be cutoff when the AI should have heard them."

 

It's from soundprop.def. I'm trying to track down why some AI ignore friendly AI yells for help even when they're in the same room.

Share this post


Link to post
Share on other sites

Grayman, since you've been looking into sounds, do you understand what this value is doing?

 

Not without running some experiments and seeing what the effect is. I could do that after I'm done with the work I'm doing now.

 

Here is some documentation:

 


/**
* NOTE: MaxRange is the maximum distance (in meters) that a sound with
* volume equal to MaxRangeCalVol will be propagated.
* At the default values, these settings are calibrated so that the cutoff
* for a whisper (30dB SWL) is 2 meters (~6 ft)
*
* Formula for cutoff range:
* For a given volume vol0,
* Max Range is calculate with the following "empirical" formula,loosely based on
* the fact that sounds sound twice as loud when they differ by 10 dB
*
* range = pow(2, ((vol0 - MaxRangeCalVol) / 7) ) * MaxRange
*
* The penalty for overestimated the cutoff range is more AI included in the computation
* The penalty for underestimating is AI not hearing a sound that they should have heard.
* Ideally, you want the maxrange to be just a few meters past where the sound falls
* below the AI's threshold volume.
**/

/**
* ADDITIONAL NOTES:
* The formula for calculating how much an AI is alerted from a sound is:
*
* psychLoud [in "alert" units] = 1 + (propParms->loudness - threshold)
*
* An alert unit of 1 is a barely heard sound (whisper) heard for ~100mS
* An alert unit of 10 corresponds to hearing twice as loud a sound.
**/

Share this post


Link to post
Share on other sites

Sorry I'm just replying to this. I added those because the footsteps from the upstairs guard was leaking onto the street below (on the easy difficulty where the windows were left open) and I didn't like that, so its contribution when the window was open was actually the original intention and a good thing. I don't see it really affecting the gameplay anyway.

 

If your intent was that the player would hear muffled footsteps in easy mode when the windows were missing, then that didn't work up to and including 1.08.

 

In 1.09, it'll work, w/o any changes to the map.

Share this post


Link to post
Share on other sites
Here is some documentation:

 

Thanks for that. It makes me a little more puzzled, however, because it seems to suggest that sounds should have their own MaxRange value, when there is, in actuality, just one global value (3).

Share this post


Link to post
Share on other sites

Brittle fractures now work properly for player sound.

 

In 1.08, when looking through a breakable window, sound comes through with no loss. Break the window and there's no change in volume.

 

In 1.09, the window will muffle the sound. Break the glass and the sound jumps to full volume. (Volume levels depend on what's been set on the brittle fracture for broken and unbroken sound losses.)

  • Like 1

Share this post


Link to post
Share on other sites
If your intent was that the player would hear muffled footsteps in easy mode when the windows were missing, then that didn't work up to and including 1.08. In 1.09, it'll work, w/o any changes to the map.

 

Yes, I realized the sound_loss spawnarg was broken way back then (this was pre-release) and left those spawnargs in precisely because I predicted it might get fixed eventually and it'd be a free update. And now it has and is. :)


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

The new portal settings entity (info_portalSettings) is now working. In DR, it's blue, to differentiate it from a location separator. It has sound and light loss spawnargs like a location separator, but it doesn't create a location boundary. (Light loss isn't implemented in either entity.)

 

The sound loss spawnargs on doors, location separators, and the portal settings entities are all in dB, and affect both AI- and player-heard sounds.

 

This lets existing maps take advantage of the 1.09 sound changes (except for the portal settings entity).

 

---------------------------------------------

 

I'm wondering if I should put these flags on the portal settings entity and the location separator:

 

"AI" "0/1"

"player" "0/1"

 

If "AI" is set to "1" the sound_loss value is applied to what an AI hears.

 

If "player" is set to "1" the sound_loss value is applied to what the player hears.

 

The default setting is "1" for both.

 

This would let mappers create different occlusion values on portals. For example, if they want to make it easier for the player to hear through a portal than an AI. Or vice versa.

 

Please comment.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...