Jump to content
The Dark Mod Forums

Visportals that can decrease sound


RPGista

Recommended Posts

Why would the mapper want to adjust the sound loss for player and AI separately? It is easier if there is only one 'slider.' But we don't know what the AI really hears. Can it be somehow tested?

 

Today I start looking at:

 

1 - How far the same sound travels for both AI and the player, w/o doors or "loss" spawnargs in the way.

 

2 - How the existing loss spawnargs affect the AI distance.

 

3 - Whether the existing loss spawnargs can be used as is to keep the player distance the same as the AI distance.

 

Where I go after that depends on what I find out.

Link to comment
Share on other sites

Regarding func_portals: I didn't tested it yet if portals closed by func_portal entities really block all sounds, but I guess it is so as Springheel tested it.

 

See this post.

 

  • tweak the func_portals so sound can propagate through visportals closed by them

 

This bit is done and tested.

 

Clarification: portals closed by func_portals didn't stop the sound, but occluded it. The code change is to stop the occlusion.

Link to comment
Share on other sites

OK :smile:

 

Regarding the door thingy: there are spawnargs for doors ("loss_open", "loss_closed") that seem to handle this behaviour. I don't know if they only apply to AI though.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I've committed maps/test/funcportals.map.

 

I'll take a look and see what's up.

 

As far as the rest goes, I don't see a whole lot of point in having separate values for player and AI sound...seems to me like it will lead to confusion and inconsistency far more often than it will be useful.

 

In terms of how I would like to see this work, as a mapper I would be quite happy with an entity like a func_portal, that you create and intersect with the visportal in question, and on that entity a spawnarg "sound_loss" or whatever, that controls how much sound is lost going through that portal. If the portal instersects a door, then the door can carry that spawnarg instead.

 

Only visportals that intersect doors should need separate values for loss_open and loss_closed.

 

I don't think this has the potential to break any existing maps.

Link to comment
Share on other sites

Slow day today, but I did gather up some math.

 

I set up a single room with me and an AI with his back turned toward me. By firing broadheads around, I determined that the AI can't hear any arrow strikes more than 254 doom units away. No doors or visportals between him and the arrow.

 

For me, I could hear the arrow hit up to 388 doom units.

 

So, for the same event, the player's hearing is ~1.5 times better than an AI's. (Actually, any AI's because they all have the same minimum auditory threshhold of 20.2dB.)

 

That seem right? The AI's acuity was 100, and he wasn't alert.

 

Edit: I bring this up because there was talk about "if I can hear him, I expect him to hear me". I.e. some sort of balance. But it's not really balanced.

Link to comment
Share on other sites

Balancing this would not make much sense in this respect. When I was mentioning this I referred this to the "use two different spawnargs for player and ai" thesis by Tels.

 

Regarding question #2 in post #51 (above). Wasn't it just supposed to reduce the noise that comes to the ai by a certain amount?

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

As far as I can see it from the code the sound loss is additive

 

 

idVec3 portalCoord = pSndAreas->portals[i2].center;
	tempDist = (origin - portalCoord).LengthFast() * s_DOOM_TO_METERS;

	// calculate and set initial portal losses
	tempAtt = m_AreaPropsG[ initArea ].LossMult * tempDist;

	// add the door loss
	tempAtt += m_PortData[ pSndAreas->portals[i2].handle - 1 ].loss;

	// get the current loss
	tempLoss = m_SndGlobals.Falloff_Ind * s_invLog10*idMath::Log16(tempDist) + tempAtt + 8;

 

 

For example. You have a room with two entries. Let's suggest the sound comes trough the first visportal at 40dB and when it reaches the second visportal it is at 30dB due to the distance. Let's assume furhtermore the sound_loss on the first vp would be set to 10. Then the sound would propagate with 30dB into the room (instead of 40) and would have a value of 20 dB when it reaches the second vp. If the value would have been set on the second vp instead, the sound would enter at 40dB, would reach 30DB on the second vp, but once it has passed the second one and is in the next room would be at 20dB.

 

EDIT: It's the line with the door loss. (It's not clear on first sight but further below it is commented with "// add any specific loss on the portal"). So I guess the portal gives back the loss that is fitting in the situation.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Well, player/ai hearing an arrow is another can of worms I suppose.

First would probably need to test several noises to make sure it is consistant (throw rock/teapot, fire arrows, etc...). Assuming it is:

 

Do we need to adjust sounds made by objects? Is this in code (ie: dB)?

 

I hadn't really considered this to be an issue before but I think it's legitimate.

 

Still it seems separate (to a degree at least) from portal sounds. I was more concerned about voices/footsteps before. Seeing as how you can hear an ai walking through glass, you assume he can hear you (but he can't??? that depends on if mission author used locations, and since the player doesn't know that, and the player can hear the guards well in ALL cases, they assume they can be heard in all cases).

 

I still the the location settings being even for player/ai is most important.

 

--------

Though having player and ai hear noises all the same regardless of portals would be an improvement too. If I shoot an arrow from nearby a guard to distract him, I can hear it but it doesn't distract him then something is wrong.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Do we need to adjust sounds made by objects? Is this in code (ie: dB)?

The sound is propagated trough the areas until it reaches the AI. The code only handles the falloff, thus meaning the amount by which the volume of the sound is reduced over distance. If a noise of an object seems to loud or to silent, the object sound volumes have to be changed, but not the sound propagation code.

 

The difference to the sound propagation for the player is that it uses a distance based approach. The algorithm calculates the distance the sound has to travel to the player, and than calculates how much this dimishes the volume of the sound. The code for the AI works with the sound volumes directly. Anyways, the sound loss goes hand in hand with the distance travelled, so as said it can just be added to the travel length of the sound. (similar like it's been done with sound propagation to AI, just that this uses the volume instead)

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

^I think you took that out of context. I'm not asking if the sounds are too loud or soft (i know those are adjusted in text). I'm asking what we would need to do to make it accurate between player and ai. As your example, a player can hear the arrow further way than the guard can, but the player would assume the guard would hear it the same.

 

We don't want to make the sound louder so the guard can hear it, because then the player will just hear it further away. Same issue exists, just at a different distance.

 

We need to make the player and the guard both aware of the same sound at the same distance.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I guess that both AI and player are "hearing" actually the same. The main difference is that for AI all sounds that have a volume below 20dB get cut off, so the AI don't hear them. Changing this value downwards would increase difficulty a lot.

 

But I don't think that any changes are neccessary here. The players already got used to how noise sensitive the AI is, so why change it. Another point is that mappers can actually adjust the AI to sound behaviour (or make it difficulty dependent). Anyways, the system is good as it is. The player also sees more then the AI. ;)

 

The only think that really needs a tweak here is the visportal problem.

  • Like 1

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I'll take a look and see what's up.

 

I give up. Now I not only can't repeat my earlier results with func_portals, I can't get them to occlude sounds AT ALL.

Link to comment
Share on other sites

When talking about what AI and the player can hear, keep in mind that there are actually two sounds. One is the sound the player hears, and one is the sound propagated to the AI, which doesn't have a sound file (*.ogg, *.wav) associated with it, but does have a volume.

 

If we wanted to make player hearing appear equivalent to AI hearing, then we'd have to either increase the volume of the propagated sound or decrease the volume of what the player hears.

 

Neither case seems acceptable. In the first case, we'd be increasing the chance that an AI will hear a suspicious sound, and in the second case we'd be making sounds softer for the player. Both changes would affect the player's experience in existing missions. We'd need to decide if this constitutes breaking missions.

 

So unless we think this is a problem that really needs to be fixed, and that doing so will provide better gameplay in existing and future missions, we probably shouldn't tinker with real and propagated sound volumes.

 

My interest in finding out if "what the player hears" is the same as "what an AI hears" is to assess how we would use the loss spawnargs that are applied to AI sound but not to player sound. Whether we use the same spawnargs for both methods or come up with new ones for player sound, the results shouldn't alter the balance (or imbalance, as we learned today) between what the AI hears and what the player hears.

 

(Also, the player's ability to more easily hear a broadhead hit might not be the case for other sounds. I'd be surprised if, in checking all other sound "pairs", we find the same relationship across them all. If we end up tinkering with these volume settings, we'll need to take a representative sampling of the very large number of pairs and decide that their average will apply to all pairs.)

Link to comment
Share on other sites

I give up. Now I not only can't repeat my earlier results with func_portals, I can't get them to occlude sounds AT ALL.

 

When you say "repeat my earlier results" are you talking about going back to the mission basement and redoing the experiment and not getting the same results? Or are you talking about my test map?

 

Occlusion applied to player sounds affects the perceived distance between the player and the speaker, not the volume of the sound. In my test map, the min speaker radius is very large, and close to the max speaker radius. If the min distance is 1000, and you're 500 from the speaker, with a closed portal between the two of you, the perceived distance is 500+450 = 950, which is less than 1000, so in 1.08 you'd still hear the sound at full volume. It isn't until you get two closed portals between you and the speaker that the perceived distance goes beyond the max radius, killing the sound. (This will be fixed in 1.09: portals closed by func_portals won't occlude sound.)

Link to comment
Share on other sites

I guess that both AI and player are "hearing" actually the same. The main difference is that for AI all sounds that have a volume below 20dB get cut off, so the AI don't hear them.

 

The main difference is actually the volume settings that were placed on these sounds initially. The 20.2dB cutoff is supposed to represent the lowest level of human hearing in real life, so it should apply to both AI and the player. Unfortunately, the player sound doesn't use dB, but simulates sound cutoff by manipulating the perceived distance between a speaker and the player. In the case of the arrow hit sound pair, the results are off by a factor of 1.5 in the player's favor. If the player sound volume had been originally set so that "what the player hears" matched "what an AI hears", then balance would have been achieved, and the player would have more realistically used the 20.2dB cutoff. (Also, balance would have been better achieved if the player method didn't use the min/max speaker radii, which doesn't simulate reality.)

 

Btw, ALL AI use the 20.2dB cutoff. I was surprised that the werebeast and the lanternbot weren't given a lower cutoff. The code stops propagating a sound when its volume drops below 15dB, so that must have been considered the absolute softest hearable sound, with the expectation that some AI with better hearing than humans would be allowed to be set that low. But with everyone using 20.2dB, it really has no effect.

Link to comment
Share on other sites

When talking about what AI and the player can hear, keep in mind that there are actually two sounds. One is the sound the player hears, and one is the sound propagated to the AI, which doesn't have a sound file (*.ogg, *.wav) associated with it, but does have a volume.

 

If we wanted to make player hearing appear equivalent to AI hearing, then we'd have to either increase the volume of the propagated sound or decrease the volume of what the player hears.

 

Neither case seems acceptable. In the first case, we'd be increasing the chance that an AI will hear a suspicious sound, and in the second case we'd be making sounds softer for the player. Both changes would affect the player's experience in existing missions. We'd need to decide if this constitutes breaking missions.

 

 

how about we slightly increase what the ai hears and slightly decrease what the players hear. that should give us perfect balance :D

 

----

But like i said before, before we go and add 3 dB to all sounds we'd need to do thorough testing to see if it's just arrows or everything.

 

Lowering the cutoff might be a fix, but that seems like opening a can of worms.

 

Everything has been pretty well tuned to sounds that alert the ai and sounds that felt proper to the devs as we adjusted sounds. There obviously (at least with arrows) seems to be a gap between ai and player.

 

Lowering the ai dB threshhold would have serious changes to ALL sounds. Footfalls and whatnot have been tweaked pretty decently. If we lower the dB then ai could hear you easier correct? Then we'd have to tweak all the footstep sounds again.

The player registers these sounds more through what they are doing/how close the ai are, not the actual sounds themselves. You know you have to sneak up on a guard, you don't listen to your footsteps and think 'ok, he can hear me now'.

 

So I'd say that's just a no go.

-----

 

however tweaking some sounds like arrow impacts to make the ai/player threshold 'seem' even would be much better IF it comes to that. At least that way we are only changing impact sounds. And only if we feel the gap exists between player/ai. (it's possible the teacup sound level is more even than arrow level).

 

This would result in minor changes that I doubt any players would even realize happened. Does anyone now really realize that an ai can't hear an arrow quite as far away as the player? You mentioned it but you were testing sounds. I've never noticed it in game either, but if it's an easy tweak that can tighten up the game why not?

 

=====

Still, as stated before, this is of less concern than fixing the portal threshold because a guard can sound right on top of the player when he is not. That can create confusing gameplay.

 

=======================

about the werewolf and lantern bot...

 

imo it would be bad to have ai of different hearing levels. Yes, the lantern bot works on hearing, and the werewolf obviously would be more in tune.

 

But too much of the game depends on the players footstep sounds. If we lowered their hearing relatively then crouch walking would still alert them (and nobody else). So you are around a corner from one of them and don't know it. You are being careful and crouch walking and all of a sudden an alarm goes off or a werewolf pounces you.

All of a sudden you have to change your entire gameplay style to match the possibility you'll encounter a very rare ai.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

When talking about what AI and the player can hear, keep in mind that there are actually two sounds. One is the sound the player hears, and one is the sound propagated to the AI, which doesn't have a sound file (*.ogg, *.wav) associated with it, but does have a volume.

I know.

If we wanted to make player hearing appear equivalent to AI hearing, then we'd have to either increase the volume of the propagated sound or decrease the volume of what the player hears.

 

Neither case seems acceptable. In the first case, we'd be increasing the chance that an AI will hear a suspicious sound, and in the second case we'd be making sounds softer for the player. Both changes would affect the player's experience in existing missions. We'd need to decide if this constitutes breaking missions.

 

So unless we think this is a problem that really needs to be fixed, and that doing so will provide better gameplay in existing and future missions, we probably shouldn't tinker with real and propagated sound volumes.

That was what I was trying to say. Sorry if it was a bit unclear.

 

If and only if some sounds seem not to alert AI in cases where they should, like it was mentioned with the broadhead arrow, then I think the easiest way to fix that would be to increase the propagated volume for the AI a bit. But it has to be discussed for every single case if it really is a problem.

 

I thought about such cases earlier in for myself. For example if you shoot a torch with a water arrow where the guard is only two meters far away. I think the AI should hear the water arrow impact (maybe it does, unsure). But that's only my view. As said, such changes should be discussed.

 

Regarding sound propagation to the player: I didn't think about the dependency of the volume estimation on speaker radius. This is a little problem, because if mappers don't set a minimum sound distance in a proper way (so there is a noticeable falloff) this might cause some problems. Using the sound_loss spawnarg for players, too would than mean that we have to take the falloff into consideration when transforming the actual spawnarg value (for example 10dB) into a proper distance to achieve the right effect.

 

Regarding the code it just calculates the sound reduction depending on the distance. So an alternative would be to use a spawnarg "sound_loss_player" "X", where X is the amont of noise that should slip trough the visportal. So if one choose X=0.8 for example the sound volume would be reduced by 20%. I guess this is easier to handle then an actual volume based spawnarg, as the distance required for such an reduction would depend on the already achieved reduction on the on side and the falloff type (linear, quadratic) on the other side. Or we just choose a distance based spawnarg.

 

Regarding some AI to hear better: I guess this depends on how loud the players footsteps actually are. It could be already a big change if the cutoff for werebeasts is set to 19dB for example without having a negative impact to the gameplay. I guess this should be tested.

 

(If there is a chance that such things could be implemented without breaking the gameplay, I guess it would be fair to give the werebeast a disadvantage in return. Maybe it can see worse. But this is another story.)

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The 20.2dB cutoff is supposed to represent the lowest level of human hearing in real life

 

And yet crouch walking on stone can never get higher than that cut-off, which means AI can never hear it. I don't understand that.

 

 

When you say "repeat my earlier results" are you talking about going back to the mission basement and redoing the experiment and not getting the same results?

 

Yes. I basically set up two rooms with a speaker in one and a visportal in between. Forcing the visportal closed didn't seem to have any effect on the volume of the sound. I'm not sure what's going on...I'm getting bizarre results with the horse KO issue too.

 

So unless we think this is a problem that really needs to be fixed, and that doing so will provide better gameplay in existing and future missions, we probably shouldn't tinker with real and propagated sound volumes.

 

Agreed.

Link to comment
Share on other sites

I basically set up two rooms with a speaker in one and a visportal in between. Forcing the visportal closed didn't seem to have any effect on the volume of the sound. I'm not sure what's going on.

 

The closed visportal probably wasn't occluding enough distance off the sound to make a difference in what you were hearing.

 

If you could post the map, I'll look at the math instead of asking you a bunch of questions.

Link to comment
Share on other sites

If the sound has a mindistance of 1 and a reasonable maxdistance (I think it's 30 in this case), then shouldn't occlusion always make a difference?

Link to comment
Share on other sites

Your comment in another thread triggered a thought. After deleting the old .cm and .proc files and dmapping, it then worked. It does seem like it works the way you described; I don't know how I so firmly got it in my head that it cut sound off entirely.

Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...