Jump to content
The Dark Mod Forums

Collision Sound Alerts


Recommended Posts

  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

In the end I worked from the files and it went much better than expected. There may be some compromises here and there.

 

All now committed and I'll do some testing later.

Link to post
Share on other sites

Hopefully now finished. Have updated test/propagation3.map with more varied range of objects. These no longer have special test values added in the map but use the new values.

Link to post
Share on other sites

Sweet, haven't got a chance to test yet but it sounds promising.

 

We might still want to have the capability to be totally silent. We used to be able to do that by just not setting sprS_bounce_*, but now that the code is automatically looking up the global suspicious sound shader, I'm not sure if there is a way to make it AI-silent anymore?

 

Something else also occurred to me. We can no longer do quick volume offsets in the individual defs, can we, because we can't do "sprS_bounce" "<global shader name>:+15". Or can we? Don't know if that's a big deal or not. It means people couldn't make a slightly larger rock, inherit the standard one and then change the volume quickly in the local entityDef. They would have to make a new global sound def. Maybe it's okay though because they are supposed to follow categories anyway.

Link to post
Share on other sites

I doubt it because there is no volume or alert value applied directly to the actual entities - only a size and hardness category. Could be useful if easy to implement but otherwise I think we have a reasonable compromise that is easy to follow.

Link to post
Share on other sites
I doubt it because there is no volume or alert value applied directly to the actual entities - only a size and hardness category. Could be useful if easy to implement but otherwise I think we have a reasonable compromise that is easy to follow.

Well, when the code is generating the string for the global suspicious sound shader to play, it could also add the ":<offset>" after it. I guess since we're using spawnargs now, we would need to read it from a volume offset spawnarg. Seems do-able. That would allow FM authors to say "this chunk of lead is like a small hard rock, but a tad louder."

Link to post
Share on other sites
  • 2 weeks later...

Reviewed this again and now I've slightly increased med & large hard objects on hard surfaces. Effectively these values must be fairly close so I'm closing this on the tracker. Some may be a little low compared to real life but the values have been compromised for good gameplay. Anyone is still free to recommend changes to values of course but this is best if it arises out of real game play imo.

Link to post
Share on other sites

Yeah that seems about right.

 

On a separate note, it seems like the alert from arrows breaking/impacting nearby and the player whacking a stone wall with the sword went down a lot? That used to get an alert from pretty far away (and I think it still should), but now they barely notice.

Link to post
Share on other sites

Are they affected by this system? If I allocated arrows to the small hard group and the sword to medium-sized hard group. Assuming I did then I would have been thinking of a junk arrow or sword. Presumably there are separate entities for actual weapon types and moveables. If so I'll have to have a look at what I did.

Link to post
Share on other sites

I didn't think they were affected by these changes. Those sounds should be separate things defined on the projectile like snd_break and defined on the melee weapon like snd_hit_stone. They are not bounce sounds. Maybe it's the AI response that changed and the volume of those sounds needs to be pumped up accordingly. I don't know at what time arrows breaking stopped being loud.

Link to post
Share on other sites
I don't know at what time arrows breaking stopped being loud.

 

I remember commenting on that same issue back when we were playtesting St. Lucia, so it's been a while.

Link to post
Share on other sites
I didn't think they were affected by these changes. Those sounds should be separate things defined on the projectile like snd_break and defined on the melee weapon like snd_hit_stone. They are not bounce sounds. Maybe it's the AI response that changed and the volume of those sounds needs to be pumped up accordingly. I don't know at what time arrows breaking stopped being loud.
OK, not my problem as far as this thread covers ;) I recommend you add it to tracker.
Link to post
Share on other sites

I checked the def and it looked like I missed it. There is candle base followed by lit candle base which inherits from it. I may have read it as one def and only added to the lit. I've now changed it. Can you confirm it was when the candle was NOT lit Ishtvan?

Link to post
Share on other sites
I checked the def and it looked like I missed it. There is candle base followed by lit candle base which inherits from it. I may have read it as one def and only added to the lit. I've now changed it. Can you confirm it was when the candle was NOT lit Ishtvan?

 

The "unlit" candle base is only used for candles that are "unlit at map start", but then it is always used. E.g:

 

* unlit at map start => inherit from unlit base

* lit at map start => inherit from lit base

 

The state of the candle after map start doesn't have to do anything with 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 post
Share on other sites
  • 4 weeks later...

[from pandora thread]

-Collision sound on the book moveable used here is very loud to AI (slight bumps to it alert them a lot).

-Chairs and candles were also too loud to AI. Slightly bump the chair walking past, or rock it a bit by bumping a candle into it? That's a highest level alert.

 

Bumping things - are these alerts handled the same way as dropping?

Link to post
Share on other sites

OK, looking at the map there are two moveable readables...

 

"classname" "atdm:moveable_book_red1_small"

"classname" "atdm:moveable_bookt1"

 

Neither of these has the spr_object spawnargs. Either I missed them or they are new since I did this work. I see others like the scroll in that def file where I had already added the spr_object. Anyway, I'm just relieved it doesn't mean the method we used isn't robust! Well, this doesn't mean it's not robust anyway but you know what I mean. I'll fix these. It did occur to me when I first did this, it relies on people when they make new moveables to include these spawnargs. Many of them have to go on the actual entity def and can't inherit whereas others do so anyone might not necessarily see or know about these. Maybe that's true about all spawnargs though.

 

I'll fix these ... OK done, untested though.

Link to post
Share on other sites

Yes, it's quite possible I've made movables and not done this, as I haven't really followed the whole discussion (those two books are not new, however, they're some of the oldest entities).

Link to post
Share on other sites

They were certainly at the top of the page but I don't know how I could have missed them. I faintly remember judging what group to put a book in - yet they are the only two moveable books. - No there's not. I just looked and I missed two others. Now I'm thinking, are these moveable in the sense that they go in the inventory to read as against static books? Maybe that's what I thought at the time. I dismissed them as readables, ie, mobile in the inventory, but not actually manoeuvrable. But it only seems that way because normally you frob a book and if it goes in the inventory you usually keep it and read it. But I think there are books that are not readable but just moveable.

 

I see we have moveable readables and readables mobile. I'd better check them all. :rolleyes:

Link to post
Share on other sites
Now I'm thinking, are these moveable in the sense that they go in the inventory to read as against static books?

 

Even if it's something that you frob to go in inventory, the player could still drop it again, or knock it over.

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.


×
×
  • Create New...