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

Collision Sound Alerts

Recommended Posts

This thread is about assigning alert values to collision sounds.

 

I'm working out how to proceed and this is what I have so far:

 

  • Go through all entity defs for moveables
  • Any with no spr$_bounce see if there is a suitable global one in existence
  • If yes, apply it to that entity def
  • If no,
    • estimate volume
    • estimate duration (not implemented)
    • create a global def
    • then apply it to the entity def.

    [*]Repeat

Share this post


Link to post
Share on other sites
Duration is not implemented and probaby won't be, so don't worry about that. If you think the sound would be more suspicious because of a longer duration, just add some to the volume. Not 100% accurate, because it will make the sound travel farther, but it works well enough.

 

Using some general global defs is a good idea, like "small soft object hitting soft surface", or in general "<size> <hardness> object hitting <hardness> surface". Then apply them, like a ceramic mug or a statuette falling on a tile floor could use "small_hard_object_on_hard_surface", wood crate falling on carpet could be medium moderately hard object hitting soft surface, and so on.

 

Within the local entity def, you can also make small tweaks to the volume of the global sound used. For example if a falling statuette should be a little louder than a mug, you can have the mug use "small_hard_object_hitting_medium_su

rface" with no modificiation, then to make the statuette slightly louder, have it use "small_hard_object_hitting_medium_su

rface:5", which means use all the other settings of the global sound but +5 dB louder than the stored volume for that sound.

[EDIT: Weird, the forum is messing up my formatting there, but it should be:

"<sound name>:<volume offset>" in the spawnarg]

 

It could be a pain to fill ou these sounds for all possible surfaces when some of them might have the same loudness to AI (stuff falling in snow vs. on sand, for example). We might want to modify the code to make sub-groupings of surfaces that absorb sound about the same, like very soft, soft, moderate, hard, very hard, or something.

Thanks Ishtvan, I'll check this out. I'll probably need a test map too.

Share this post


Link to post
Share on other sites

Some basic propagated sounds are defined in moveable_base (in moveable.def) already:

	"sprS_bounce"					"bounce_default"
"sprS_bounce_cloth"				"bounce_default:-5"
...

The corresponding propagated sound is in tdm_propagated_sounds.def:

entityDef sprGS_bounce_default
{
"inherit" "atdm:entity_base"
"vol" "40"
"dur" "100"
"alert_factor"	"0.35"

"editor_displayFolder"	"Sound/Propagated sounds"
"editor_usage"	"Propagated sound of moveable colliding."
}

The alert increase will be dependent on the volume heard by the AI and is scaled by alert_factor, so that noises at the same volume can be differently suspicious.

Share this post


Link to post
Share on other sites

Is it possible for anyone to quickly produce an inheritance tree for moveables for me to refer to: I want to see if there is any common points I can insert where all (or most) of those below will inherit rather than insert on every entity. I started working this out manually but it occurred to me that perhaps one of you coders can dump out such a list with ease?...

 

entityDef moveable_base (moveable.def)
  L entityDef atdm:moveable_base (tdm_moveable.def)

Share this post


Link to post
Share on other sites

You can use the "Entity Class Tree" in DarkRadiant, it's in the Entity menu.

 

To quickly focus on the moveable, just create one in the map and select it. Then (with the entity selected) open the class tree, it will focus on the selected entityDef.

Share this post


Link to post
Share on other sites

We should probably strip out all references to duration since it won't be implemented, and just use alert_factor for that purpose.

Share this post


Link to post
Share on other sites

I'm trying to grasp an overall summary of the moveable tree structure so made up this image. Hope you can zoom it. It only includes a sample of entities. The cyan area seems to all come under the umbrella of atdm:moveable_small_base and is 90% of everything so I thought a medium def covering those and then adjust the individual heavyweights like cannonballs or lightweights like rings separately. But I see these are already covered by "sprS_bounce" "bounce_default" in moveable_base. So I'm wondering why all objects don't already cause some alerts but just need refining? I thought we were saying virtually none were alarming the guards?

post-400-1238840019_thumb.jpg

Share this post


Link to post
Share on other sites

Are we certain that these offsets are being included? I have tried different values with no effect. If I change the original values in sprGS_bounce_default and reloadDecls then it works. But if I set say "sprS_bounce" "bounce_default:25" or "sprS_bounce_carpet" "bounce_default:25" it has no effect.

Share this post


Link to post
Share on other sites

All objects already do cause alerts, although the standard values are probably far too low at the moment. (The AI only goes to ObservantState for a very brief moment when you drop a crate right behind them. On the other hand, one of the guards got alerted by me dropping the readable in Broken Fence... :huh: )

 

I also tried setting

"sprS_bounce" "bounce_default:25"

on a moveable crate, and it definitly had an effect. The AI immediately turned around and started searching.

 

You can switch on tdm_showsprop and tdm_showsprop_radius to see how large the volume heard by the AI is and how much alert it causes.

Share this post


Link to post
Share on other sites

What is the range for "vol" and "alert_factor"? Which does the offset affect? I can still make no change no matter what values I put in as default offsets. So I suspect it is just affecting "alert_factor" which has no affect if the "vol" is not high enough.

 

@angua: Can you check my understanding of this please?

 

I have a test map with atdm_moveable_crate03. This (should) inherit from movable_base but it does not show "sprS_bounce_carpet" if I list its inherited spawnargs in entity inspector.

 

If I drop the crate on carpet then by default the AI do not respond 4 paces away.

 

In tdm_propagated_sounds.def is entityDef sprGS_bounce_default and if I increase "vol" then reloadDecls then drop the crate on carpet then the AI respond immediately so this is obviously working.

 

I restore the default values and this time in moveable_base I change "sprS_bounce_carpet" "bounce_default:-5" to "sprS_bounce_carpet" "bounce_default:125". The AI does not respond.

 

So I increase the vol moderately to 60 in the sprGS_bounce_default, set the alert_factor to default then set "sprS_bounce_carpet" "bounce_default:-99" - The AI responds. So the offset seems to have no affect that I can detect whether high or low.

 

Maybe the crate is just not inheriting sprS_bounce_carpet" but why?

 

Sorry - I have several sessions with this so far and still can make no sense of it let alone actually start any actual work.

Share this post


Link to post
Share on other sites

The offset definitely affects the volume, not alert factor.

 

I think the problem is that reloadDecls doesn't always work with inherited things. It's happened to me numerous times where I change something on ai_base, reloaddecls and nothing is changed on the AI I'm testing with that inherits from ai_base.

 

Nowadays I just set temporary args on the def file if I'm actually testing ingame, then move it up to the base class def file when done. Otherwise I have to exit and restart the game to make sure changes on the base class make it down to whatever I'm working with. It's a pain I know.

Share this post


Link to post
Share on other sites

Well, I thought of that originally and tested and verified that reloadDecls worked if I altered the original values. I wanted to be absolutely sure. So what may be happening is it works if I just alter what is a set value like defining a constant but not actually in the class tree because the crate is already spawned. Damn.

 

I'm hoping I can just split moveables into 4 x 2 types for this operation: tiny (fork) small (goblet) medium (crate) leaving big for large pushables like big crates and barrels. I don't know yet if pushables cause an alert when pushed but I think they do. I think snd_bounce works if just pushed. Then subdivide the 4 into hard & soft. If I can then decide that say 75% are in the group small_hard I want to set that on the moveable_base so then I only have to consider the 25%. Actually, maybe just 3 groups will do if pushing a barrel can be treated the same as dropping a crate. It might really be more like dropping a goblet. Yes, a barrel is big but pushing it is not so loud as dropping a small crate - crash. So I might group those with small. In which case name them small, medium, large x 2 hard, soft. That still leaves the door open for specials if any.

Share this post


Link to post
Share on other sites

That sounds like a good plan.

 

When we decide on the noise, we should probably look at the weight of these as well. Are these heavy things representing full barrels/crates, or fairly light things representing empty barrels and crates? Everything else held constant, increasing mass will make more noise because they have more kinetic energy to convert to sound energy. I would think a barrel would make more noise than a goblet.

 

I don't think we should think about rolling a barrel vs. dropping a crate. Assume they are both be dropped for the purposes of this sound. We can write the physics test to check velocity relative to the collision surface, so a rolling barrel will already have a lower collision velocity than one that is dropped straight down.

Share this post


Link to post
Share on other sites
I would think a barrel would make more noise than a goblet.
This needs more thought. A metal goblet dropped on stone would wake the dead. A barrel pushed along is nowhere so loud as a dropped crate. Plus we don't want players being penalised for slightly nudging a barrel the same as dropping a crate. Goblet & Barrel are quite different sounds but I'm hoping we can evaluate them to the same alert group. There is a case for saying dropping a goblet ought to risk an alert but nudging a barrel ought not. Problem is, barrels can be pushed off ledges and I think the impact sound is the same as for just nudging it. How do we handle that?

Share this post


Link to post
Share on other sites

The code already checks for the collision speed of the object. If the object hits with very low velocity, the volume will be lower as well (both of the audible and the propagated sound).

The maximum volume is defined in the def as the bounce sound (or the propagated sound, respectively), the maximum decrease is set on tdm_moveable_base as min_velocity_volume_decrease, currently set to 20 db.

Share this post


Link to post
Share on other sites

Ah good. So I could set a barrel to a high value but just nudging it will only cause a minor alert if any but push it down the stairs and big commotion. In that case I think I will set big crates and barrels in the same group as grabbable crates and chairs. I see a small crate thrown downstairs causing a similar commotion to a big crate pushed down stairs. For the sake of simplicity and keeping this to just three alert group types: small, medium, large, I would allow a little licence. Of course, someone might produce a pushable grand piano.... :laugh:

 

But I can make 4 groups if the general view is that it is necessary.

 

[EDIT] I would add that I think there is a kind of upper cap to distance no matter what the noise. Setting off a bomb in a city it should bring AI from the entire city to the scene but we accept only from just around the corner is OK. Am I wrong to think this?

Share this post


Link to post
Share on other sites

I'm trying to get this clear before I proceed. I don't want to change hundreds of entities then find I have to change them again.

 

If I create something like:

 

"sprS_bounce_small_soft" "bounce_default:-5"

"sprS_bounce_small_hard" "bounce_default:-3"

"sprS_bounce_medium_soft" "bounce_default:-2"

"sprS_bounce_medium_hard" "bounce_default"

"sprS_bounce_large_soft" "bounce_default"

"sprS_bounce_large_hard" "bounce_default:+5"

"sprS_bounce_vlarge_soft" "bounce_default:+7"

"sprS_bounce_vlarge_hard" "bounce_default:+10"

 

Then apply that as far as possible to inherit to the max number then add to individuals, if people don't like it we need only change the defaults plus a few individual entities if people think I put them in the wrong group.

Share this post


Link to post
Share on other sites

Just to chime in: we should probably always lean toward the side of being overly generous to the player. It'd be far more frustrating to have AI go ballistic because you grabbed a mug and had it slam against another object when you picked it up (something a normal person would never do, but it happened to me frequently in the contest maps; basically I became afraid of picking things up), than to have the AI not notice it and go about their business.

 

Either that generosity has to be there, or manipulation (pick up, set down) needs to be perfect, and let's face it, it probably cannot be.

Share this post


Link to post
Share on other sites

Chime away - I'd rather get input before I start than have to redo it.

 

I'll try if possible to make it that placing down or nudging a goblet onto a bottle or similar might cause a mutter from an AI but only if he is within a couple of paces and not if he is across the room. But if I drop it on a stone floor then he should alert. That will be the aim anyway. :rolleyes:

Share this post


Link to post
Share on other sites
It'd be far more frustrating to have AI go ballistic because you grabbed a mug and had it slam against another object when you picked it up (something a normal person would never do, but it happened to me frequently in the contest maps; basically I became afraid of picking things up), than to have the AI not notice it and go about their business.

 

Either that generosity has to be there, or manipulation (pick up, set down) needs to be perfect, and let's face it, it probably cannot be.

Problem is, grabbing always tries to drag it to the center of your view and also we're using a discrete distance grid, so this initial move from the object's current position to this desired position is what bangs things together when you grab them.

 

In the past, I've suggested an initial phase of grabbing, where it starts from the current object position, checks ahead of it to see if moving to the center of your view would hit something, and if so, doesn't move that way yet until you manuever it around whatever it would hit. This could have unintended consequences though, like when you want to pick up a plate and something on top of it, but it won't let you because it detects the collision with the thing already on the plate and refuses to move upwards.

Share this post


Link to post
Share on other sites

@Fidcal:

 

Like angua is saying, the code checks for the velocity, so we shouldn't be comparing nudging a barrel and dropping a goblet, we should be comparing dropping the barrel and the goblet from the same height. A full barrel is really heavy, so a heavy, medium hardness barrel might make the same noise as a light, hard goblet.

 

@angua:

At what velocity does it use the un-modified volume set in the def file? This might help a bit to visualize the situation when we set volume in the def file, if we know what collision velocity this volume represents. Is it falling to the ground at 1 meter/second, 5, 10, etc? Or we could solve for the height it falls from, if that is easier to think about. I guess we can also just listen to the un-modified audible soundshader volume and set the un-modified AI volume according to that, but we can't do that when setting both of them from scratch.

 

IMO we should also only take velocity in the collision normal direction, so if you push a barrel sideways, there's not as much downward velocity as dropping it straight down. I can't remember if the code currently does this or not. Later on we could try differentiating between smacking into, sliding across or rolling, but that's probably a post-1.0 feature.

Share this post


Link to post
Share on other sites

I'm aiming for only 2 hardnesses - hard and soft - to keep it simple. This is both for the object and the surface dropped on. As I understand it, there are already in place single values for everything if dropped on soft surfaces like snow, carpet, dirt. This is not perfect. A barrel would cause no more alert than a spoon in snow. But the alert will be very low and I think we can accept this compromise or it will get too complex.

Share this post


Link to post
Share on other sites

Yeah, the code can handle a different value for every type of surface (snow vs. carpet), but I agree the tweaking and maintaining would get pretty complex. Although if we have SFX for dropping stuff in snow and we put in different audible sounds, we might as well put in different propagated sounds too. But AFAIK we don't have SFX for that.

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