Jump to content
The Dark Mod Forums

Collision Sound Alerts


Fidcal

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.

Link to comment
Share on other sites

  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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