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

Collision Sound Alerts

Recommended Posts

Thanks greebo. I'm not certain but I think it will be something like this: In moveables.def I define say,

 

"sprS_bounce_min_hard_on_tile" "bounce_default:-5" // ring, coin, key, small book

"sprS_bounce_min_hard_on_metal" "bounce_default:-5" // ring, coin, key, small book

etc. for all the surfaces. Then repeat that for all the 6 'hard' groups. (By 'hard' I mean the 6 groups I defined as alerting similarly on all hard surfaces not hard themselves necessarily.)

 

There are already 5 defs for soft surfaces that I think angua did, eg,

 

"sprS_bounce_carpet" "bounce_default:-5"

 

So they need replacing with eg,

 

"sprS_bounce_mid_hard_on_carpet" "bounce_default:-5"

Again, repeat for all soft surfaces then repeat those for the 3 'soft' groups.

 

Later, every moveable entity will need two complete sets of spawnargs, one from each group. So for example, a key is in the 'min_hard' hard group and the 'min' soft group so needs:

 

"sprS_bounce_min_hard_on_tile" plus same for metal, wood, etc.

"sprS_bounce_min_on_carpet" plus same for snow, etc.

 

If the above looks correct I will set up only stone & carpet and test it works in the test map with the test objects before proceeding further.

Share this post


Link to post
Share on other sites

Erm, I'm afraid I don't get the part about the "min_on_something". The code wouldn't work with that, it should be something like this:

 

"sprS_bounce_carpet" "bounce_min_hard_on_carpet:-5"

 

plus the corresponding entityDef "sprGS_bounce_min_hard_on_carpet".

 

edit: Sorry if I don't get everything what you write, I didn't follow your progress on this very closely.

Share this post


Link to post
Share on other sites

What exactly is wrong with "sprS_bounce_min_on_carpet"? It means a group called 'min' which is small moveables whether hard or soft. The group could equally be called 'smallmoveables' so it would be "sprS_bounce_smallmoveables_ on_carpet". Then there would be ones called "sprS_bounce_mediumsizedmoveables_ on_carpet" and "sprS_bounce_largemoveables_ on_carpet". Repeat for all soft surfaces.

Share this post


Link to post
Share on other sites

Well, yes, I understood so far, but it won't work, the code will simply ignore these right now. :mellow:

Share this post


Link to post
Share on other sites

Are you saying that all the groups we've been discussing and testing cannot actually be implemented?

Share this post


Link to post
Share on other sites

They can be implemented somehow, but it requires coding.

 

Hm.

 

Let's do this the other way around: please let me know which materials are grouped together to which category. I'll try to come up with a coding solution.

Share this post


Link to post
Share on other sites

Thanks greebo. You see the problem I hope? And to make sure we're on the same page: If we don't have groups then we have to set bounce_default and bounce_carpet etc on each entity type individually. But while say, all keys can inherit the same value; a coin or a ring (which is the same size and hardness as a key) are separate in loot. So we can't set all loot to inherit the same value. Furthermore, only about 3 of us are testing here so we can bet in three or four months someone will say 'I dropped the key on a wooden floor and the guard alerted - it's too high'. With grouping I can say 'no problem' I know a key is in hard surface group min_hard so I go to one place in moveables_def and change sprS_bounce_min_hard_on_hard and then I've corrected it for keys, and coins, and rings, and every similar moveable no matter how far spread and for every type of hard surface. If we absolutely have to include the material then we have to change it on say, 20 or 30 values in moveables.def. But if we can't have any groups at all then we need to keep a list of every moveable of similar size and hardness and change them all separately.

 

So for the purposes of surfaces we only need consider two types: hard and soft. A goblet dropped on wood or stone or metal ought to be similar enough in how it alerts to not be worth the effort of testing and implementing every variation. In the same way, a crate dropped on carpet or snow or mud can all be regarded as on 'soft'. The main differences are in the size and hardness of the object and whether the surface is hard or soft. In fact for soft surfaces then the surface itself is so dominant that there is not a lot of difference between dropping a soft sack or a hard crate on snow - the mass of the object and the softness of snow is dominant. So I made different groupings for both surfaces:

 

For the purposes of impacting on hard surfaces:

 

small hard = min_hard = ring, coin, key, small book

small soft = min_soft = quill, sheet paper, scroll

medium hard = mid_hard = goblet, trophy, big book

medium soft = mid_soft = apple, loaf, small bag

large hard = max_hard = crate, chair, cauldron, barrel

large soft = max_soft = sack, package, boars head

 

 

For the purposes of impacting on soft surfaces:

 

small = min = quill, paper, ring, small book

medium = mid = loaf, goblet, trophy, big book

large = max = package, crate, cauldron, barrel

 

OK, to answer your question,

 

the hard (for alert purposes) materials imo are:

 

metal, stone, wood, ceramic, glass, brokeglass, tile, gravel, rock, twigs, squeakboard, slate, armor_chain, armor_plate, liquid, puddle

 

the soft materials are:

flesh, carpet, dirt, grass, foliage, sand, mud, snow, moss, cloth, straw, armor_leath

Share this post


Link to post
Share on other sites

Hm, yeah that's a problem.

 

One solution that wouldn't require coding would be to put the grouping into the propagated sound def:

 

So the moveables would still have to define each surface type (which can be partially inherited):

	"sprS_bounce_cloth"			"bounce_min_hard_on_soft"
"sprS_bounce_carpet"			"bounce_min_hard_on_soft"
...

and there would be a propagated sound def for each group:

 

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

...

 

That would at least solve the problem with having to change the propagated sound volumes on many moveables later, but would still be a lot of work defining the propagated sounds on the moveables for all surface types.

 

Maybe we can also find a simple solution for grouping the surfaces themselves into soft and hard in the code.

Share this post


Link to post
Share on other sites

Can't say I understand this.....

	"sprS_bounce_cloth"			"bounce_min_hard_on_soft"

What exactly does that do? It seems to assign the value "bounce_min_hard_on_soft" to "sprS_bounce_cloth". So if you then apply "sprS_bounce_cloth" to say a key entity then it will use the values for "bounce_min_hard_on_soft" if it impacts on a cloth surface. But where would those values be defined and more importantly, what happens for say a max_hard object like a large barrel on cloth? If you also set up:

 

	"sprS_bounce_cloth"			"bounce_max_hard_on_soft"

 

Then is that not assigning two values to the same thing?

Share this post


Link to post
Share on other sites
Can't say I understand this.....

	"sprS_bounce_cloth"			"bounce_min_hard_on_soft"

What exactly does that do? It seems to assign the value "bounce_min_hard_on_soft" to "sprS_bounce_cloth". So if you then apply "sprS_bounce_cloth" to say a key entity then it will use the values for "bounce_min_hard_on_soft" if it impacts on a cloth surface. But where would those values be defined and more importantly, what happens for say a max_hard object like a large barrel on cloth? If you also set up:

 

	"sprS_bounce_cloth"			"bounce_max_hard_on_soft"

 

Then is that not assigning two values to the same thing?

 

sprS_bounce_cloth is the "local" name of the sound on the entity. It says "this is the sound you play when this particular entity lands on cloth." So you can't really "apply" "sprS_bounce_cloth" to more than one entity. It is a "key" on the entity and the second part of that line, "bounce_max..." is the value of that key. The key being named that way says look up my value when I land on cloth. The value of the key ("bounce_min_hard_on_soft") is the suspcious sound shader to play when this entity lands on cloth, and this can be shared across multiple entities that are similar, or different on entities with different size/hardness.

 

It's just like how you can set "snd_explode" or whatever on a projectile, and then in the value of that key, you set actual sound shader to play when it explodes. Multiple projectiles share the key part "snd_explode", but the part after that can be different to have different explosion sounds for different projectiles. An even simpler example is "name" "<entity's name>". Many entity's can use the "name" field in their spawnArgs, but they all have something different for the value of name.

Share this post


Link to post
Share on other sites

I think I've done everything I can. I'll leave this until someone can come up with a solution for me to work with. :)

Share this post


Link to post
Share on other sites

Ok, I have something for you in SVN:

 

The latest code in PK4 groups all known material names together by their surface hardness ("soft" and "hard"). Moveables carry two properties:

 

"spr_object_size"  "small|medium|large"
"spr_object_hardness"  "soft|hard"

 

On moveable collision, the code assembles the name of the propagation def automatically into something like this, when a small, hard moveable is colliding with a carpet, for instance:

 

"bounce_small_hard_on_soft"

 

So, all that's left to do is to define the entityDefs sprGS_bounce_small_hard_on_soft, and all the variants.

 

Does this make sense to you? I left you a note in tdm_propagated_sounds.def (at the bottom).

 

Note: the code does this for idMoveables exclusively, everything else is working as usual.

Share this post


Link to post
Share on other sites

We'll have to wait for Fidcal's reply, but it makes sense to me. That sounds perfect. :)

 

As for doing it on idMoveable only. We stopped supporting idMoveableItem, so we don't have to worry about that. The only other class I can think to do it on might be idAFEntity, because a free-standing ragdoll object like a bucket or chain section or severed arm or something might get picked up and dropped.

Share this post


Link to post
Share on other sites

Thanks greebo - yes it looks good from your post. I'm updating - probably not have time to study it tonight but I'll check it out in the morning.

Share this post


Link to post
Share on other sites

In my local copy I've now set up the sprGS values in tdm_propagated_sounds.def and commented off the old sprS values in moveable.def.

 

I believe what we now need to do is create two new spawnargs: sprS_bounce_on_hard and sprS_bounce_on_soft. These would then be set up throughout the entity tree as eg,

 

Barrel:

"sprS_bounce_on_hard" "bounce_large_hard_on_hard"

"sprS_bounce_on_soft" "bounce_large_hard_on_soft"

 

Loaf:

"sprS_bounce_on_hard" "bounce_medium_soft_on_hard"

"sprS_bounce_on_soft" "bounce_medium_soft_on_soft"

 

Plus, I guess, defaults in moveable.def so if any are missed at least they have a default. But what? medium hard? Alternatively, we set up twelve sprS equivalents to the sprGS defs but that means every entity has to have its particular two from the twelve. Much neater and easier I think to have just two spawnargs?

 

Can you confirm the above greebo? And can I just add the above spawnarg names or do they need to be coded?

Share this post


Link to post
Share on other sites

If I understand greebo right, you don't have to enter in those sprS spawnargs anymore. The code will automatically play the suspicious sound shaders bounce_x_y_on_z based on the entity's spr_object_size and spr_object_hardness spawnargs.

Share this post


Link to post
Share on other sites

Yes, you're right, the spawnargs are already there as size and hardness. OK, I'll apply this to the test objects later to make sure it's working before proceeding.

Share this post


Link to post
Share on other sites

Yes, you don't need the sprS_* spawnargs, I skipped that step in the code for your convenience. Only the sprGS_* entityDefs are required.

 

Note that the "spr_object_size" defaults to "medium" and "spr_object_hardness" defaults to "hard".

Share this post


Link to post
Share on other sites

Just testing on test objects and quickload is crashing to desktop. Don't know if it is related to these changes.

Share this post


Link to post
Share on other sites

I'll upload a new PK4, there is a bug in the code which I fixed yesterday.

Share this post


Link to post
Share on other sites

OK. No problem.

 

All tested OK on the test objects. Later today I'll start adding these spawnargs to actual entities. Seems to me I should commit the tdm_propagated_sounds.def along with the first batch and disable 'bounce' in moveables.def too. So for a time this may break alerts in all maps. Not much idea yet whether this will take hours or days. Depends on how many of the same size and hardness inherit from the same source. Also need to consider could that change? Could someone make a giant key? Unlikely and they'd have to set the spawnargs individually. But I need to keep it in mind. Large crate, tiny crate, etc. Maybe all food can be small soft then set one or two individuals like loaf = medium soft.

Share this post


Link to post
Share on other sites

It's probably worth spending a few minutes drawing stuff out on paper or something to think of the best way to group everything into hard, soft, medium with minimal "tweak each object by hand" treatment.

Share this post


Link to post
Share on other sites

Yes, I was thinking the same. I'll look at DR's entity tree first to see if it helps here. I've not had time to even start this yet. It also occurred to me that perhaps these size/hardness groups might be used for something else in the future perhaps. Also, that giant key thing, I realized why it rang a bell. In a T2 mission someone made a crowbar as a key entity. So I think anyone creating a new moveable entity needs to consider these groups and not just inherit.

Share this post


Link to post
Share on other sites

I wish I could get a printout of the moveables tree. I may have to copy it screen by screen.

 

Small rocks are about the size of a loaf which is medium soft but I'll probably make these rocks large hard. I think I need to consider mass as well as hardness.

 

I see moss blobs in the moveables tree. They should be silent. I didn't allow for totally silent. If I make them small soft then they will make a tiny alert mutter on stone if immediately behind an AI. Maybe that's good.

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