Jump to content
System downtime for updates - Sunday 13 July 2025 ×
The Dark Mod Forums

Recommended Posts

  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Posted

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.

Posted

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.

Posted

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.

Posted

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.

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

  • 2 weeks later...
Posted

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.

Posted

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.

Posted

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.

Posted

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.

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

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

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?

Posted

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.

Posted

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?

Posted
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

  • 4 weeks later...
Posted

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

Posted

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.

Posted

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.

Posted

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

Posted

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:

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

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

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...