View Issue Details

IDProjectCategoryView StatusLast Update
0005018The Dark ModTexturespublic03.07.2021 09:01
ReporterSpooks Assigned To 
Status newResolutionopen 
OSWindowsOS Version7 
Product VersionTDM 2.07 
Summary0005018: FM-overridden material definitions do not automatically load in-game
DescriptionIn previous versions of TDM, materials defined in the FM folder that have the same name as core mod ones will take priority and load over the defaults in an FM. Currently, this only happens if the user types the console command to reload declarations, at which point whatever (modified) default materials are used in the map will update to match their FM definitions.

This is too much to ask for average players and may already be messing with the look of some released FMs.
Steps To ReproduceTake a random material e.g. textures/darkmod/stone/cobblestones/blocks_mixed_multicolour

Copy it over to your own .mtr file but change something significant, e.g. replace the diffusemap with _white.

Fully restart the game if you have it open.

You will notice the cobblestone will look as usual, but upon typing reloadDecls it will update to your custom definition.
TagsNo tags attached.




24.03.2019 11:37

reporter   ~0011692

Slight correction, on a further test I see reloadDecls might not work, but reloadImages does.


02.01.2020 05:58

administrator   ~0012009

I failed to reproduce it, both on unpacked SVN and on packed 2.07-hotfix.

What I did is:
  1) Copy materials/ into closemouthed_shadows.pk4::materials/
  2) In the copied file inside pk4, find declaration textures/darkmod/stone/brick/old_worn_blocks_002 and replace: diffusemap to _white, bumpmap to _black.
  3) Start TDM, choose Closemouthed Shadows FM and start new game.
The walls look white for me, without doing anything special.

Is this problem happening to someone else?
Does it happen to you now?
Are you using packed 2.07-hotfix?
Note that declarations are loaded when TDM starts, not when you start the FM.

Some ways to see what is happening:
  1) condump has search paths you are using (can be printed separately by command "path")
  2) You can enable cvar "logFile 1", then start TDM as "TheDarkModx64.exe +set fs_debug 1", then search for the name of your .mtr file in qconsole.log.
  3) Probably procmon can help to see where TDM goes, but most likely it won't explain anything anyway.


27.01.2020 18:43

reporter   ~0012157

I now don't remember precisely the incident because of which I submitted this bug but it may well be a wrongful submission. IIRC the kernel of what this bug actually is (and I've ran into it recently again) has nothing to do with materials but rather with texture formats. The problem is that upon overwriting a core mod .dds texture file with an FM .tga equivalent, the texture wouldn't update in-game unless "reloadImages" was invoked. If however the FM texture is changed to .dds (and I don't know if it's the format per se really, it may just be up to texture format parity) and put in the appropriate folder, the texture ingame gets overwritten properly.

Given that it's my error in over-generalizing the report here, I ask that it's either suspended, closed or renamed, though I don't rightly know if the bug as I've reframed it now is even that much of a bug. I still thank you for looking more into it, stgatilov.


28.01.2020 05:32

administrator   ~0012159

There is some nontrivial logic of loading DDS / TGA. I.e. engine loads DDS, and if that it not found, then tries to load TGA.
If DDS was originally missing and you add it, I'm not sure which of the files will get loaded on reloadImages.
And the same applies to timestamps. If you have both TGA and DDS but update TGA, then I would imagine it will never be reloaded, because DDS is always preferred.
Maybe that's not the exact behavior, but something close certainly happens.


03.07.2021 09:01

administrator   ~0014141

The main misconception here is "materials defined in the FM folder that have the same name as core mod ones will take priority and load over the defaults in an FM".
As far as I know this is wrong in TDM, and most likely was wrong always, including in the original Doom 3.

In the reality:
1) If you make file with same name, then it overrides the file from core. The engine never looks at the core file in this case.
2) If you make decl with same name (e.g. material), then the core one takes precedence and you get a warning about redefinition.
Note that these two cases are governed by completely different systems.

I wrote about it in dev forums:
Pasting below:

When same file is present both in TDM core and in FM, then the file from FM takes precedence.
When same decl is present in two different files, one in TDM code and another one in FM, then the version from TDM core takes precedence.

Thus, I cannot agree that having same decl in core and in FM is a valid situation... unless they are perfectly equal.
But to be honest, it sounds like a problem to me anyway, because existing TDM assets sometimes change, which silently changes FMs too.

Here is more precise explanation of rules.
There is established order of search path for files: FM files always come first, TDM core files come later.
If several files with same relative path exist, filesystem iterates over search paths and opens the first file it can find. That's why FM files override TDM core files.
DeclManager iterates over search paths, and parses all files with appropriate extensions there. When it detects that some decl was already defined before, it prints warning and skips the new definition. That's why decls from TDM core files override the ones from FM.

Issue History

Date Modified Username Field Change
22.03.2019 22:48 Spooks New Issue
24.03.2019 11:37 Spooks Note Added: 0011692
02.01.2020 05:58 stgatilov Note Added: 0012009
27.01.2020 18:43 Spooks Note Added: 0012157
28.01.2020 05:32 stgatilov Note Added: 0012159
03.07.2021 09:01 stgatilov Note Added: 0014141