Jump to content
The Dark Mod Forums

Visportals that can decrease sound


RPGista

Recommended Posts

The current portal design is such that if you can't see through a portal (it's closed) then sound (to the player) is occluded (less volume) as it passes through that portal. If the portal is open, then there is no occlusion. It's probably this way to account for open and closed doors.

 

However, this design causes two problems:

 

1 - A closed window that has an open portal (you can see through it) doesn't occlude the sound.

 

2 - A portal closed by a func_portal occludes sound, even though there's no closed door.

 

Note that a portal closed by a func_portal doesn't just reduce the volume, it acts as a barrier. No sounds will pass through a portal closed by a func_portal (to the player).

 

3 - A non-door portal closed by the renderer for view culling may or may not occlude sound. I haven't found that code yet, so I'm not sure about this one.

 

I have to believe that if this were the case, we would regularly notice sounds being cut off suddenly as we turned corners.

 

 

5 - A window w/o a portal. Imagine a room with a glass divider. The mapper doesn't put a portal across the glass. A player should expect to hear some of a sound on the other side of the glass. This is the general case of "sound occlusion through walls", which could use material and thickness considerations to simulate expectations, but currently doesn't. I don't know if this is easily fixed. (This is different from the case where there are no visportals between the player and a sound source he can't see, and he experiences the sound "through the wall" when he shouldn't.)

 

I don't understand this one. Isn't the answer that the mapper should just put a portal inside the glass to occlude some sound?

 

6 - The code doesn't take visportal size into account. Small openings should allow less sound to pass than large openings. (Springheel's "tiny opening" problem comes to mind.) This should be easy to add, but the amount of occlusion will need to be determined experimentally.

 

(Hey, I thought only my doctor knew about that problem....)

 

Does the code need to do that, or can we just leave it to the mapper to set appropriate values? It's not always the size of the opening...a small hole in a thin wall would let through more sound than a small hole through six feet of stone, yet both might be the same size visportal.

Link to comment
Share on other sites

 

Does the code need to do that, or can we just leave it to the mapper to set appropriate values? It's not always the size of the opening...a small hole in a thin wall would let through more sound than a small hole through six feet of stone, yet both might be the same size visportal.

 

A default value would probably be a good idea, but then more experienced mappers can fine tune the results if they find it too much or too little.

Link to comment
Share on other sites

Note that a portal closed by a func_portal doesn't just reduce the volume, it acts as a barrier. No sounds will pass through a portal closed by a func_portal (to the player).

 

That hasn't been my experience. What are you basing this on? (Also, the code doesn't appear to support that.)

 

I don't understand this one. Isn't the answer that the mapper should just put a portal inside the glass to occlude some sound?

 

Sure, for glass. But it's a special case of the more general case of occlusion through walls, where mappers wouldn't normally put visportals.

 

For example, imagine you're standing in a hallway. Next to you is a wall, and on the other side of that wall, only a few feet away, an alarm is blaring. Our code only allows the sound to leave through the portals to the room. Perhaps they lead to hallways far from you, and if we follow the path of the sound along these hallways, back toward you, eventually the sound dissipates due to distance fading, and the result is you can't hear the sound.

 

But you're standing on the other side of the wall. Surely you'd expect to hear a loud alarm through the wall. Occluded, yes, but you'd still hear it. This is a case where the mapper won't be putting a portal between you and the sound.

 

Does the code need to do that, or can we just leave it to the mapper to set appropriate values? It's not always the size of the opening...a small hole in a thin wall would let through more sound than a small hole through six feet of stone, yet both might be the same size visportal.

 

We could leave it to the mapper, but it's one more thing the mapper needs to deal with. And, while "it's not always the size of the opening", the size of the opening does contribute to occlusion, and it's something we can deal with automatically, w/o involving the mapper.

Link to comment
Share on other sites

 

 

But you're standing on the other side of the wall. Surely you'd expect to hear a loud alarm through the wall. Occluded, yes, but you'd still hear it. This is a case where the mapper won't be putting a portal between you and the sound.

 

 

 

Well, it depends on the type of wall for one.

 

But we can't account for every possible instance can we?

 

Even if on the other side of the wall the sound needs to travel through air... and mappers need to portal for good performance. I'd say don't worry about it, nobody has ever complained of this type of instance have they?

 

The major complaint is not hearing the same drop in volume as the AI hear. An author can always leave out a portal if they think it would make the sound more realistic. Hell they can drill a hole in a wall and fill it with func_static (and vis_portal it for that matter) so it looks like a solid wall but has somewhere close for sound to travel through. That's like 3 seconds of mapping for a very specific event. I wouldn't code around something that odd or rare.

---

I also wouldn't recommend hard coding values for sizes of holes. If a mapper feels it's important to have a certain hole allow less sound they can put a location there. It's really not that hard.

 

Again the main issue is that an ai might barely hear the player, but to the player it sounds like the ai is right on top of them.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

That hasn't been my experience. What are you basing this on? (Also, the code doesn't appear to support that.)

 

I tested it quite a bit when I first had the issue with the basement guard. My experience was that forcing a visportal closed with a func_portal blocked out ALL sound from the room beyond.

 

 

For example, imagine you're standing in a hallway. Next to you is a wall, and on the other side of that wall, only a few feet away, an alarm is blaring. Our code only allows the sound to leave through the portals to the room. Perhaps they lead to hallways far from you, and if we follow the path of the sound along these hallways, back toward you, eventually the sound dissipates due to distance fading, and the result is you can't hear the sound.

 

Ok, I understand the issue now. But wouldn't addressing that require an entire redesign of how sound works? Sound doesn't take worldspawn into account when travelling, only portals, as I understand it. Changing that seems like a pretty huge kettle of fish.

Link to comment
Share on other sites

I tested it quite a bit when I first had the issue with the basement guard. My experience was that forcing a visportal closed with a func_portal blocked out ALL sound from the room beyond.

 

Cutoff depends on the sounds involved, and the distance they have to travel.

 

I've committed maps/test/funcportals.map. In DR, you see a long hall split by visportals, each with a func_portal with portal_dist set to 256 (very short). As you walk down that hall, only the visportals closest to you will be open. Across from the door, you'll find a speaker with large min/max distances that nearly reach to the end of the hall.

 

Build that, start it up, go through the door and walk backwards down the hall to your left. As you walk, the speaker will spout some AI sounds. When the first visportal between you and the speaker closes, you can still hear the voice. Keep backing up and you'll hear the voice until the next portal shuts. Each portal is reducing the effective radius of the speaker by 450 doom units when it closes. By the time the second portal closes, TDM has reduced the radius by 900, bringing you outside the reduced max radius of the speaker, so you can't hear it any more.

 

This shows that func_portals don't cut off all sound. They only reduce a sound's volume, depending on the min/max distances.

 

I've tested a change that keeps the portals from reducing the sound volume as you walk down the hall. Now, with 4 closed portals between you and the speaker, you can still hear it.

Link to comment
Share on other sites

But wouldn't addressing that require an entire redesign of how sound works? Sound doesn't take worldspawn into account when travelling, only portals, as I understand it. Changing that seems like a pretty huge kettle of fish.

 

Probably not. We'd only be interested in what lies on a straight line between the player and the speaker. Ray tracing would allow us to build up a picture of wall materials and thickness, which could determine how much sound leaks through.

 

While there might not be a hue and cry for this, I might fiddle with it after I get the rest of the changes in, just to hear what it sounds like.

Link to comment
Share on other sites

Well, you can run a map without portals and see how bad it sounds. Some early maps had pretty bad visportalling and it basically sucked.

 

But like I said, if an author wants a sound 'leak' that's easy enough to do with a fake wall.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

If you can set up a system easily enough to check for real world factors like a wall between the source & player, or even directing sound around obstacles to get to the player (sound pathfinding?), I say it's definitely worth at least looking into to see what's possible. I have noticed sound quirks like that all the time; people don't complain about them because they either aren't looking for them & don't notice or just take it as a quirk of the game, but it happens. If it turns out to be a giant task, then we know & can let it lie, but maybe some advances are more feasible & worth doing.

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

Link to comment
Share on other sites

I haven't had timeto read the forum the last days, so please don't take my silence for approval :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

The current portal design is such that if you can't see through a portal (it's closed) then sound (to the player) is occluded (less volume) as it passes through that portal. If the portal is open, then there is no occlusion. It's probably this way to account for open and closed doors.

 

However, this design causes two problems:

 

1 - A closed window that has an open portal (you can see through it) doesn't occlude the sound.

 

2 - A portal closed by a func_portal occludes sound, even though there's no closed door.

 

3 - A non-door portal closed by the renderer for view culling may or may not occlude sound. I haven't found that code yet, so I'm not sure about this one.

 

I'm testing a fix now that separates view blocking and sound blocking. This should solve these problems.

 

Other problems:

 

4 - Upthread talks about the "sound_loss" on location separators. This loss is only used for sounds propagated to AI. Sound to the player ignores this value. Based on the discussion, I assume folks are expecting "sound_loss" to also apply to what the player hears. Is that correct? If so, then this needs to be fixed.

 

But not by making sound_loss apply to the player sound, but by having:

 

* sound_prop_loss (the former sound loss, renamed for clarity, applies only to AI and if not set, defaults to sound_loss)

* sound_loss (applies only to what the player hears)

 

 

5 - A window w/o a portal. Imagine a room with a glass divider. The mapper doesn't put a portal across the glass. A player should expect to hear some of a sound on the other side of the glass. This is the general case of "sound occlusion through walls", which could use material and thickness considerations to simulate expectations, but currently doesn't. I don't know if this is easily fixed. (This is different from the case where there are no visportals between the player and a sound source he can't see, and he experiences the sound "through the wall" when he shouldn't.)

 

I don't think it is feasible. This would need a complete simulation of the entire world (in a blocky way) to account for physical correct sound wave propagation. There are some libs for it, and some games implement it (there are you tube videos). But if you have want to make to correct (instead of a hacky way that only accounts for a few special cases), you also need to account for reflections, doppler shift, travel times differing between wave lengths etc. It is not enough to just muffle the sound.

 

Right now correct sound propagation needs visportals and I don't see how this can easily be changed without having a full "sound renderer". So not having a visportal there is a mapper error and can unfortunately only fixed by him.

 

6 - The code doesn't take visportal size into account. Small openings should allow less sound to pass than large openings. (Springheel's "tiny opening" problem comes to mind.) This should be easy to add, but the amount of occlusion will need to be determined experimentally.

 

Probably;:

 

* "area size" < X => use sound_loss * 0.1 value

* "area_size" > X => use sound_loss value

 

and interpolate between.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Probably not. We'd only be interested in what lies on a straight line between the player and the speaker. Ray tracing would allow us to build up a picture of wall materials and thickness, which could determine how much sound leaks through.

 

While there might not be a hue and cry for this, I might fiddle with it after I get the rest of the changes in, just to hear what it sounds like.

 

That will break old maps and make things quite different. Currently as someone said, sound never travels through worldspawn and changing this would create a lot of unnec. changes.

 

It would also be incomplete, because the mapper has no way to stop the sound through a thin wall that is there because it has to be thing due to mapping contstriains. My advice is don't do that. Suddenly hearing AI through walls would be an unwelcomed effect in most cases.

 

If the two rooms are situated next to each other, there is a likely chance they have a door or window or other openings already, so sound will already pass along.

 

(Which reminds me, do closed door shut out sound 100%? They should only let sound through to some percentage that is based on the door, e.g. wood vs. steel door. If not, that needs to be corrected and would also already cater for your alarm blaring situation).

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

(Which reminds me, do closed door shut out sound 100%? They should only let sound through to some percentage that is based on the door, e.g. wood vs. steel door. If not, that needs to be corrected and would also already cater for your alarm blaring situation).

As far as I recognized it closed doors only muffles the sound, so there should not be any problem here.

 

Regarding sound trough walls: I must agree Tels and Baddcog. Such a change would definetely break existing maps. Not all rooms that are only seperated by a thin wall are meant to be part of the same building or whatever. So hearing sound through the wall is not intented in most cases. And, as Baddcog said, if the mapper actually wants this effect, there is an easy way to accomplish it (as described by him).

 

Regarding seperate sound loss values for AI and player: I'm not really a fan of this idea. Why should sound propagate in a different way to AI as it does to the player. Giving the mappers such possibilities will lead to two problems IMHO:

  1. The mappers may overlook that there are two values two set, and will only set one. This will effect in what we have now or in the situation that the sound gets muffled to the player but not to the AI. I guess especially the latter is a problem as the mapper would need to invest a lot of time testing just to find out that he forgot to set a spawnarg.
  2. Such things would break gameplay. I guess that most players use the loudness at which they can hear the AI as an indicator for how good they can be heard by them. Tweaking with two different values only gives us inconsistencies and confusion.

So I would say that we use the "sound_loss" spawnarg that is already there, and apply it to what the player hears. I suggested a relatively easy possibility to fix that by adding a distance to the path the sound travels trough visportals to accomplish the muffling. My idea was the following:

  • read the sound_loss spawnarg from the info_locationseperator, if such an entity doesn't exist in the visportal choose a value depending on visportal size (this is something to think about it)
  • calculate the distance that is equivalent to the sound loss (shall mean the distance the sound normally would have to travel to decrease by this value)
  • apply the length to the length of the path the sound has to travel

IMHO this would only require a few new lines in the code and we don't break the existing system. As said any bigger changes will most certainly only cause negative side effects.

 

Regarding visportal size to sound muffle: As said by Springheel this approach is not optimal. Tels also noted that it is not the best idea to force the mapper to have info_locationseperators in every visportal that shall muffle sound, as this would lead to a high amount of zones. He also had the idea of using a new entity instead. So it would be placed in a visportal that has no seperator in it and apply the values, without breaking the map up into seperate zones at this specific portal.

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

Cutoff depends on the sounds involved, and the distance they have to travel.

 

I've committed maps/test/funcportals.map. In DR, you see a long hall split by visportals, each with a func_portal with portal_dist set to 256 (very short). As you walk down that hall, only the visportals closest to you will be open. Across from the door, you'll find a speaker with large min/max distances that nearly reach to the end of the hall.

 

Build that, start it up, go through the door and walk backwards down the hall to your left. As you walk, the speaker will spout some AI sounds. When the first visportal between you and the speaker closes, you can still hear the voice. Keep backing up and you'll hear the voice until the next portal shuts. Each portal is reducing the effective radius of the speaker by 450 doom units when it closes. By the time the second portal closes, TDM has reduced the radius by 900, bringing you outside the reduced max radius of the speaker, so you can't hear it any more.

 

This shows that func_portals don't cut off all sound. They only reduce a sound's volume, depending on the min/max distances.

 

I've tested a change that keeps the portals from reducing the sound volume as you walk down the hall. Now, with 4 closed portals between you and the speaker, you can still hear it.

 

I believe Spring meant that forcing the portal closed stopped all sound from reaching the player, probably not the AI though....yet your tests show otherwise. I'll be looking forward to testing your new changes as they come in. :)

Link to comment
Share on other sites

As far as I recognized it closed doors only muffles the sound, so there should not be any problem here.

 

Regarding sound trough walls: I must agree Tels and Baddcog. Such a change would definetely break existing maps. Not all rooms that are only seperated by a thin wall are meant to be part of the same building or whatever. So hearing sound through the wall is not intented in most cases. And, as Baddcog said, if the mapper actually wants this effect, there is an easy way to accomplish it (as described by him).

 

Regarding seperate sound loss values for AI and player: I'm not really a fan of this idea. Why should sound propagate in a different way to AI as it does to the player. Giving the mappers such possibilities will lead to two problems IMHO:

 

 

It should not propagate different, but the scales that are used for both systems are different (remember, the AI doesn't "hear" it only computes the loudness of a sound if should perceive) - hence we need two values that are by default setup so that both systems have the same "volume", but there is a way to adjust it if nec.

 

(Edit: Just imagine AI standing in one room, player in the other, a small opening, and the mapper wants the AI alerted if the player drops a book too hard on the table. There are various ways to achive it, but all are cumbersome compared to just reducing the "sound_prop_loss" value on the portal connecting the two rooms by 20%.)

 

If grayman works in this area, he might as well do it right, instead of us having to have the same discussion in a year and yet another touch of the portal system just to add yet-another-variable (and maybe then we don't have anyone who can do this change for various reasons).

 

(Edit: This is one of the fundamental software design principles: hard-coded values are bad. We alread have to add yet-another-scripting event every now and then just because someone needs to adjust something. Likewise for spawnargs etc. If we hard-code something into the SDK code, then it means that: mappers cannot override if nec, and even if we change it later, it means extra work (digging into the code again just to find where and how) and also with our 1-year release cycles everyone has to wait a year before they can use the feature. So better make it configurable from the start. Reading one more spawnarg at map start won't hurt, but it saves the day later.)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

(Which reminds me, do closed door shut out sound 100%? They should only let sound through to some percentage that is based on the door, e.g. wood vs. steel door. If not, that needs to be corrected and would also already cater for your alarm blaring situation).

 

The "loss*" spawnargs on doors are only applied to sound propagated to AI.

 

For player sound, a default occlusion distance of 450 is applied to closed doors, regardless of material. When I determine how the "loss*" spawnargs can be applied to player sound, this will change.

 

Ditto for location separators and their "sound_loss" spawnargs.

 

If you're concerned about sound changes breaking maps (i.e. the "occlusion through walls" change), then I assume you're also concerned about these other sound changes, because the player might be hearing things he didn't hear before, and in some cases, things the mapper might not have wanted him to hear.

 

If that's the case, then I'll have to ignore the existing "loss" spawnargs on entities and we move to a different method going forward. One that provides more realism, but which leaves existing maps with the sound environment they've always provided.

 

Other folks should comment on this aspect so I get a sense of what I should be doing.

Link to comment
Share on other sites

The "loss*" spawnargs on doors are only applied to sound propagated to AI.

 

For player sound, a default occlusion distance of 450 is applied to closed doors, regardless of material. When I determine how the "loss*" spawnargs can be applied to player sound, this will change.

 

Ditto for location separators and their "sound_loss" spawanargs.

 

If you're concerned about sound changes breaking maps (i.e. the "occlusion through walls" change), then I assume you're also concerned about these other sound changes, because the player might be hearing things he didn't hear before, and in some cases, things the mapper might not have wanted him to hear.

 

If that's the case, then I'll have to ignore the existing "loss" spawnargs on entities and we move to a different method going forward. One that provides more realism, but which leaves existing maps with the sound environment they've always provided.

 

Other folks should comment on this aspect so I get a sense of what I should be doing.

 

No, I might have been unclear, I don't think changing how the player hears the sound is a problem - actually, it is NOW the problem and we want to change that (see Springsheels example "AI is on top of me despite being a level lower").

 

I'm more concered that if you re-use "sound_loss" to modify how the player hears things, you'll also (at the same time) change how the AI perceives things, and THAT will break maps more easily. (Player hearing things 10% louder or less loud makes almost no difference, but for the AI it can be the difference between "able to sneak by" and "not able to sneak by".)

 

And that's why I'm repeating myself in saying that there should be two variables so that these two systems can be tweaked indepentently from each other - so that how the player hears things doesn't screw up the AI and tweaking the AI (if that is nec.) doesn't suddenly change the player side again.

 

As for the other changes on doors, that looks like an improvement to me, so I'm ok with it. (After all, a paper-thin wooden door and a heavy metal door should definitely change how both AI and player hear through it).

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

But not by making sound_loss apply to the player sound, but by having:

 

* sound_prop_loss (the former sound loss, renamed for clarity, applies only to AI and if not set, defaults to sound_loss)

* sound_loss (applies only to what the player hears)

 

Wha?

 

I can't do that, since it'll break existing maps, where sound_loss was applied to AI sound. Can't have it suddenly not apply to AI sound.

Link to comment
Share on other sites

If grayman works in this area, he might as well do it right, instead of us having to have the same discussion in a year and yet another touch of the portal system just to add yet-another-variable (and maybe then we don't have anyone who can do this change for various reasons).

 

Ah, well, there's the rub.

 

1 - Right = Perfect real-world experience, including doppler effect, occlusion based on opening size, leading sound, trailing reverbrations, occlusion through walls, etc.

 

2 - Right = Current AI working fine, just need to tweak the player side of things to be closer to what the AI "hears". AI and player use different algorithms.

 

3 - Right = AI sound needs tweaking, and tweak the player side of things to be closer to what the AI "hears".

 

4 - Right = AI and player should use the same algorithms, though they might be implemented differently.

 

5 - Right = Use the same spawnargs to apply to both AI and the player.

 

6 - Right = Use different spawnargs for AI and the player.

 

7 - Right = Don't break existing maps. The AI should behave the same, and the player should experience the same sounds. (i.e. change no code)

 

8 - Right = The AI should behave the same, and the player should have a better sound experience, even if this "breaks" existing maps.

 

9 - Right = Identify and fix bugs w/o redesigning either the player or AI algorithms.

 

10- Right = ?

 

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

 

Pick one, or some combination, and let me know.

Link to comment
Share on other sites

Other folks should comment on this aspect so I get a sense of what I should be doing.

 

Um... No democracy for the ignorant: I understand the system so poorly that I shouldn't really get a vote. Anyways: thoughts.

 

Please no map breakage!

 

Why must the audio be different for AI and player? It feels intuitively right to have the AI hear the same stuff the player hears. The player would get a feeling of the noise he makes to what the AI hears better if the system was unified.

 

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?

 

Sound passing through walls sounds like a bad default in a sneaking game.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Sound passing through walls sounds like a bad default in a sneaking game.

I second that. Beneath the possibility of map breakage no one was complaining about that so far, so I guess it is not worth the effort (which would be extreme high, I guess).

 

Regarding the spawnargs: I guess the main point of Tels position is that the player has no cut off like the AI has. If the volume of a sound the AI "hears" is lower than a specific value (I think 20dB or so), the AI does not react to it as if it wouldn't hear it. The player, on the other side, can hear such noises or not depending on the enviromental volume (machine sounds, wind, ...), something the AI algorithm didn't even take into consideration.

 

So I guess having two spawnargs makes sense. Obviously the naming convention suggested by Tels does not work due to what Grayman said. I suggest leaving "sound_loss" for the AI and have another spawnarg called "sound_loss_player" for example.

 

Regarding doors: It makes sense that thick metal doors have another impact on sound propagation than thin wooden doors have, so this could be tweaked if possible. Taking the enviromental noise into consideration as described above would also be a plus, but as the current code ignores everything that comes not from an enemy, the amount of work needed to reach this behaviour may be not worth the result gained.

 

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. Well, this is definetily not senseful and should be tweaked, too. The portal should use the "muffling" spawnargs if set and if not should not muffle sounds at all. A visportal in a hallway should not propagate sound different dependent on whether it is closed or not for example.

 

So IMHO the points to work at are:

  • make it possible to muffle sounds via spawnargs on info_locationseperator entities and/or a new entity that does not split the map on that visportal into zones (use different spawnargs for the player then for the AI)
  • tweak the func_portals so sound can propagate through visportals closed by them
  • change the way door affects sound propagation depending on the material they are made off
  • optional: make the cut off volume depending on enviromental noise, so that AI hear less in a loud enviroment like the player do (may be difficult in implementation and have a high impact on performance)

I would NOT mess around with sounds passing through worldspawn, as it was not asked for and will definetily break all existing maps.

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

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

      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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...