Collision Sound Alerts

[Fidcal]

OK, I got 10 screenshots. I can work with this.

[Fidcal]

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.

[Fidcal]

I think there's more. Not all moveables are in moveable def files.

[Fidcal]

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.

[Ishtvan]

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.

[Fidcal]

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.

[Ishtvan]

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

[Fidcal]

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.

[Ishtvan]

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.

[Fidcal]

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.

[Ishtvan]

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.

[Springheel]

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.

[Fidcal]

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.

[Ishtvan]

Okay, it's tracked. I'm not sure what could have caused this, unless maybe the global soundshader in propagated_sounds was decreased in volume for something else and it also affected this?

[Ishtvan]

For some reason the moveable candle in Demagogue's FM had a really loud sound to the AI. Maybe it just needs to be updated, but wanted to bring it up in case it's a bug.

[Fidcal]

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?

[Tels]

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

[Fidcal]

I think we are agreeing but I'm not sure.

[Ishtvan]

I think it actually started out lit. I remember pinching it out.

[Fidcal]

[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?

[greebo]

The collision sound itself will cause the alert, so yes, it's handled the same. Maybe pushing things will trigger many sounds in a row.

[Fidcal]

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.

[Springheel]

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

[Fidcal]

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.

[Springheel]

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.