[Mod] Sound Polish

[Taffingtaffer]

The mod's name is gonna see a change, since the scope has shifted a bit more since the last post.

Besides including the overrides I attached before, AI alert 3 & 4 is gonna get a dramatic duration and fuzzyness decrease from core values and barks are going to be more frequent: meaning, guards are going to chill out before you get the temptation of quickloading, and they're going to mutter and snore way more frequently to prove they are alive. 

DaftMugi also shared with me another override for pickpocketting frob distance values, to make them closed to Thief's. Ironically, it also brings consistency to the general frob distance; TDM has longer distances for any other object, except items carried by AI.
I can already see the argument that the shorter distance makes pickpocketting more "tense". The way I see it is that bump detection isn't a fun mechanic during this action, and the distance is annoying even when the AI has been knocked-out.
If you are already in a hurry to get away with the loot because you are illuminated and the guard could turn around, you don't want to also worry about bumping your head against their back because you forward-leaned.
Alerting them while crouched in a poorly chosen hiding spot actually makes the bump mechanic interesting; gives you a chance of getting away if the area is dark enough, or punishes you for being overconfident if not.

I'll be checking all AI footstep declarations to be throughout and the monster walking volumes, then then release version 1.0 in Codeberg for easy versioning and issue tracking.
I'm a bit unsure about the license; TDM LICENSE.txt says everything is licensed under CC BY-NC-SA 3.0 "unless explicitly stated otherwise".
TDM Modpack is Public Domain, on the other hand.

Edited November 30, 2025 by Taffingtaffer

[Wellingtoncrab]

21 hours ago, Taffingtaffer said:

DaftMugi also shared with me another override for pickpocketting frob distance values, to make them closed to Thief's

This is interesting - is there a global way to do this other than overriding the frob distance for each individual def?

[Taffingtaffer]

1 hour ago, Wellingtoncrab said:

This is interesting - is there a global way to do this other than overriding the frob distance for each individual def?

Doesn't look like it. It indeed involves overriding the several distances in tdm_prop_items.def, tdm_prop_items_keys.def and tdm_prop_wearable_items.def.

I was having a similar doubt with AI definitions. Looking at the EntityDef Tree, the base for humanoid footsteps is tdm_ai_humanoid.def.
To make SqueakBoard available for all humanoids I'd have to add it there; then each female would need overrides for their specific shaders. Not sure if this will even be used in the future, but it feels good to understand the hierarchy.

Edited December 1, 2025 by Taffingtaffer

[Taffingtaffer]

OP updated with an overview of the changes and the links to the repository and the release. 

[datiswous]

I would not call it Polish, because then people think it's sound in the Polish language.

[snatcher]

On 11/30/2025 at 6:37 PM, Taffingtaffer said:

DaftMugi also shared with me another override for pickpocketting frob distance values, to make them closed to Thief's. Ironically, it also brings consistency to the general frob distance; TDM has longer distances for any other object, except items carried by AI.
I can already see the argument that the shorter distance makes pickpocketting more "tense". The way I see it is that bump detection isn't a fun mechanic during this action, and the distance is annoying even when the AI has been knocked-out.
If you are already in a hurry to get away with the loot because you are illuminated and the guard could turn around, you don't want to also worry about bumping your head against their back because you forward-leaned.
Alerting them while crouched in a poorly chosen hiding spot actually makes the bump mechanic interesting; gives you a chance of getting away if the area is dark enough, or punishes you for being overconfident if not.

Pickpocketing somebody who is awake and not distracted sounds like a difficult thing to pull off. When it comes to execution (gameplay / mechanic) I don't recall ever blaming the game for the failures (I normally always rush up and hardly ever retreat) so I support extreme short frob-distances in this case.

I would agree though that it should be easier to pickpocket death/unconscious bodies but that's a different topic altogether because there are many things at play:

• Auto search bodies on/off
• Frob helper on/off
• Frob-fighting between the item and the body

[snatcher]

On 11/30/2025 at 6:37 PM, Taffingtaffer said:

Besides including the overrides I attached before, AI alert 3 & 4 is gonna get a dramatic duration and fuzzyness decrease from core values and barks are going to be more frequent: meaning, guards are going to chill out before you get the temptation of quickloading, and they're going to mutter and snore way more frequently to prove they are alive. 

These are tough topics.

Should AI cool down sooner or should the player (almost) always have a chance to carry on?

By having AI cooling down sooner players can (and probably will) quickload or simply wait. "Snowed Inn" is a good example of taking short cool down periods to the extreme. Borderline ridiculous.

By having AI taking its time to cool down you know that if you manage to escape AI will be stuck there for some time giving you some advantage but, can you actually escape with the tools you have and at what cost?

Should AI announce their presence via footsteps, barks, both, and how often? Let's not underestimate the feeling of "not knowing" what's behind the corner.

Edited December 3, 2025 by snatcher

[Taffingtaffer]

On 12/3/2025 at 8:18 PM, snatcher said:

Pickpocketing somebody who is awake and not distracted sounds like a difficult thing to pull off. When it comes to execution (gameplay / mechanic) I don't recall ever blaming the game for the failures (I normally always rush up and hardly ever retreat) so I support extreme short frob-distances in this case.

I would agree though that it should be easier to pickpocket death/unconscious bodies but that's a different topic altogether because there are many things at play:

• Auto search bodies on/off
• Frob helper on/off
• Frob-fighting between the item and the body

Even if it makes sense for it to be difficult, it doesn't feel very good in practice, in my opinion. I use forward-leaning constantly and the default distance reduces its usefulness; try shortening the gap while standing up and you'll bump against the AI back easily. It can also happen while crouching if the AI plays crouching animations.

As for the other bit, I only see frob-fighting as a relevant factor; Auto Search bypasses the problem, and Frob helper can only help so much when the short distance and frob-fighting clash against each other.
It's just that widening the frob distance improves the reliability of the frobbing for KOed AIs, even if the focus is still wonky.
Sounds like a good idea for a small mod, in any case, making specific frob distances for KOed/dead AIs (if that's even possible).

On 12/3/2025 at 8:44 PM, snatcher said:

These are tough topics.

Should AI cool down sooner or should the player (almost) always have a chance to carry on?

By having AI cooling down sooner players can (and probably will) quickload or simply wait. "Snowed Inn" is a good example of taking short cool down periods to the extreme. Borderline ridiculous.

By having AI taking its time to cool down you know that if you manage to escape AI will be stuck there for some time giving you some advantage but, can you actually escape with the tools you have and at what cost?

Should AI announce their presence via footsteps, barks, both, and how often? Let's not underestimate the feeling of "not knowing" what's behind the corner.

I was under the impression that the long cooldowns tempted Thief players to quickload in TDM (myself included).
I have checked "Snowed Inn" values; they are indeed very short. Volta III are even shorter. This proves that even mappers feel the cooldowns are too long, though. I think my values were kind of a fluke because I didn't experiment too much to find my middle ground.

I don't want AIs to be overly enthusiastic and go stomping loudly and yelling all the time, but getting surprised constantly doesn't add to the enjoyment. I'm also trying to play with a shorter tdm_ai_sightmax to balance out sight distance a bit, after @Wellingtoncrab told me about the variables. It's already in my autocommands as a commit.

[snatcher]

I totally get what you are saying @Taffingtaffer

It is time for you to start thinking about offering separated mods: independent standalone mods in their dedicated topics or a set of standalone mods under your signature (a modpack). I will gladly rebrand my modpack when other authors with different backgrounds, views and scopes start offering their work in the form of modpacks.

[snatcher]

On 8/25/2025 at 2:22 AM, stgatilov said:

Unfortunately, there are two systems which work here, and they don't know anything about each other.

First, there is a filesystem. It has a set of search directories (a directory can be pk4 archive too), which are sorted by some rules. You can see the sorted order near the beginning of the game console. If some file can be found in several search directories, then the file from the first directory wins. All the other instances are completely ignored, the game cannot see them at all and cannot know of their existence.

Second, there is decl system. Sound shaders is one type of decls. One file often contains many decls. The order of loading decls from the files have nothing to do with the order of search directories in the filesystem. Recently I ensured that the files from missions take precedence over the core files, but the core-core and mission-mission ordering is still the same as in Doom 3, i.e. not something to rely on.

As far as I see, the decl system enumerates all decl files, sorts them lexicographically, and parses one by one. Whenever it sees a decl with the name that is already occupied, it skips the new decl. So the decl from the lexicographically minimal filename wins (if both filenames are in core or both are in mission).

What do you think @stgatilov, should we try putting some order here?

I am thinking a testing cvar that we can activate locally and monitor the results throughout 2026.

• tdm_parse_order 0 = Current
• tdm_parse_order 1 = New (reverse lexicographical order everywhere)

[stgatilov]

1 hour ago, snatcher said:

I am thinking a testing cvar that we can activate locally and monitor the results throughout 2026.
tdm_parse_order 1 = New (reverse lexicographical order everywhere)

To be honest, it sounds quite dangerous.
Every second mission has some duplicate decls warnings, we'll be hunting those issues forever if we change the order.

If you are interested in mods, it would make more sense to solve the problem similar to how core/mission priority works now. We can add some convention for mods, and tag all the respective decls as MOD. And then we can either set CORE < MOD < MISSION or CORE < MISSION < MOD priority.

Something like mod_somearbitraryname.pk4 in the core directory would probably work, or maybe we can invent something similar to the current naming. What is the current convention for mod files?

This will make overriding decls by mods an officially supported strategy, instead of something that relies on engine order rules which are somewhat confusing and where never supposed to be relied on.

[snatcher]

3 hours ago, stgatilov said:

[...] What is the current convention for mod files?

None.

The "problem" is when there are duplicated decls in different pk4. I thought pk4 load order mattered but it doesn't and there is no intuitive way to guarantee a decl wins. Not only with mods but with missions as well: pretend I want to "patch a mission" and I create a companion pk4 as proof of concept. Changes may or may not apply depending on pk4 name and/or filenames inside the pk4. Each case is different. There's a logic yes, but it is not elegant.

z.pk4 and its contents should always win over a.pk4, at least for mods (for now).

You can of course think of new, long term strategies.

[stgatilov]

5 minutes ago, snatcher said:

The "problem" is when there are duplicated decls in different pk4.

There should be warning about it.

Quote

Not only with mods but with missions as well: pretend I want to "patch a mission" and I create a companion pk4 as proof of concept.

As a workaround, you can send zip file and ask to unpack it into where pk4 is.

Quote

z.pk4 and its contents should always win over a.pk4, at least for mods (for now).

But your suggestion was different from it. You suggested to use reverse lexicographical order of filepaths within pk4.
So I see that even if we change order, the confusion will still remain.

[snatcher]

43 minutes ago, stgatilov said:

There should be warning about it.

Download this mod (Sound Polish) and place all three pk4 in your root folder:

• x_sound_polish_mod.pk4
• x_sound_polish_mod_ThiefierSoundsByGin.pk4
• x_sound_polish_mod_VoltaFootstepMod.pk4

Pretend you don't know what the source code does. Try guessing what's going on.

(You can use the console, change pk4 names and listen to footsteps on wood, remove files...)

[wesp5]

Maybe if the sounds are really improved, it would be easier to include this into the core mod?

[stgatilov]

4 hours ago, snatcher said:

Download this mod (Sound Polish) and place all three pk4 in your root folder:

• x_sound_polish_mod.pk4
• x_sound_polish_mod_ThiefierSoundsByGin.pk4
• x_sound_polish_mod_VoltaFootstepMod.pk4

Pretend you don't know what the source code does. Try guessing what's going on.

Doesn't it sort of proves the point that it's better to mark some pk4 as "mod" ones based on naming or location convention?

[snatcher]

Sure. I just can't picture in my mind what you have in mind. There's a "mods" folder and every pk4 in there is treated as a mod? What about pk4 names? which one wins? What about files inside the pk4? Which one wins? what about dcls? Which one wins?

• mods/a_thing.pk4
• mods/my_addon.pk4
• mods/xperiment.pk4

[datiswous]

for (non map) scripts you have to declare them in a file. Maybe something like that for mods too?

[stgatilov]

6 hours ago, snatcher said:

Sure. I just can't picture in my mind what you have in mind. There's a "mods" folder and every pk4 in there is treated as a mod?

Yes.

Quote

What about pk4 names?

Does not matter I guess.

Quote

which one wins? What about files inside the pk4? Which one wins? what about dcls? Which one wins?

Just like now: following the obscure rules made by ID many years ago.
Normally, it is not something to rely on, no?

[snatcher]

8 minutes ago, stgatilov said:

Just like now: following the obscure rules made by ID many years ago.
Normally, it is not something to rely on, no?

That's correct. If two different modders mod, in example the lantern, and the user keeps both mods, it is impossible to tell intuitively which part of which mod is applying. pk4 A or B? Filename A or B?  Definition A or B? Texture A or B?

If in the proposed strategy parsing ordering / sorting remain the same then it doesn't fundamentally improves anything and we should rather not bother.

[wesp5]

Maybe the file date is relevant, e.g. the newest one wins?

[stgatilov]

22 hours ago, wesp5 said:

Maybe the file date is relevant, e.g. the newest one wins?

The rules are deterministic and can be found from looking at the source code.
Moreover, I think I have described them above (and maybe in some other places).

The problem is that they are too complicated to be intuitive.
And to be honest, I don't see a way to make them simple due to many details involved: pk4 name, core/mission, filename, decl name.

[Taffingtaffer]

v1.1 is released!

Might not seem like much from the changelog, but as usual with this mod it has involved a lot of sound shenanigans.
This time I've had to go hunting for new sounds to finally address the poor state of hit sounds on materials. Stims projected to AI by hits done with the blackjack and the sword will at last feel decent, at the very least.
 

[snatcher]

Thanks!

18 hours ago, Taffingtaffer said:

Stims projected to AI by hits done with the blackjack and the sword will at last feel decent, at the very least.

Decent, you say? You are taking us from no response whatsoever all the way up to high alerts in two hits!

Just like with everything that has to do with your mod I need time to adjust. Letting melee weapons swing by mistake can put you in a nasty situation now 

[Taffingtaffer]

v1.2 released

With this, all obvious oddities should be addressed. Beds, sacks and other cloth stuff no longer sound like flesh when hit (attacking them with the sword felt unpleasant, as if they were mimics), moss patches are finally moss and newspapers no longer act like metal slabs when hit.

I do have noticed a weird thing going with female models from much messing around in the test map: there's a very specific section of her head portion, either the collarbone or the nose bridge/eyes that plays metal sounds when hit with the blackjack. The newspaper thing was already rather obscure (although r_showSurfaceInfo 1 literally pointed me to the right definition when aiming at the newspaper) and in this case it's rather hard to reproduce, so I'll let it be; I've had my fair share of rabbit holes.
 

4 hours ago, snatcher said:

Thanks!

Decent, you say? You are taking us from no response whatsoever all the way up to high alerts in two hits!

Just like with everything that has to do with your mod I need time to adjust. Letting melee weapons swing by mistake can put you in a nasty situation now 

Now authors can play the good ol' trick of Bafford's metal lamp right above the cook in the kitchen.  I still haven't played many missions after releasing the mod, but hit propagation feels more generous here. Hitting metal in Thief is a sure way to make guards pinpoint you with their 6th sense unless you have a silent and dark path to go around them.
TDM AI has more granular alert reactions, so even if you hit metal, AI might just statically look in your general direction if you are far enough.

Congrats on the Healing Boost mod, by the way. Hoarding food will get to a different level with it.