 |
Slight correction, on a further test I see reloadDecls might not work, but reloadImages does. |
 |
I failed to reproduce it, both on unpacked SVN and on packed 2.07-hotfix. What I did is: 1) Copy materials/tdm_stone_brick.mtr into closemouthed_shadows.pk4::materials/tdm_stone_brick.mtr. 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. |
|
|
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. |
|
|
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. |
|
|
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: https://forums.thedarkmod.com/index.php?/topic/20499-console-warnings/&do=findComment&comment=460395 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. |
 |
The rules of decl processing have changed to set the FM to take precedence over core in 2.11 ( 0005766 ) |
- Anonymous
