nbohr1more

Yes, it's a core shader. Converted from ARB to GLSL from Greebo's original design I believe.

The water shader used in this mission does not access the depth buffer. It needs to be rewritten but it includes a blur effect so it's harder to implement the change.

I have a theory... Several candle entities start out lit and mappers add "extinguished" as an arg to start them unlit. This arg tells the script to blow out the candle at map start ( seems like we could design that to work better somehow....) If the extinguish action is interrupted during map start, the particle, light or both may be active on these candles. I added a waitFrame() to init block in the light holder script and thus far have not been able to reproduce the issue. Please create a script folder in your darkmod directory ( or fm directory ) and place the attached replacement script there then test whether the issue persists. tdm_light_holders.script Edit: I should mention that randomly I am seeing candles smoke in The Outpost for the first time with this change. Before they would either be lit or have a flame particle or be fully unlit. Now I either see unlit candles (expected) or candles that have just been extinguished and are releasing smoke. ( A significant improvement )

I think it's a good idea to offer this feature. On a related note, I tried to configure parry for an alternate key since clicking middle mouse is too close to mouse scrolling and can lead to accidentally holstering the weapon during combat. The GUI selection only allowed me to "add" parry but not remove the mouse button. Not the worst issue but certainly annoying.

Replicated on Dev Build 10071 going back to a previous build Cannot replicate on 9881, SLL beta map is also cured there 9944 replicated ( sorta ) no unlit candle in the room with a flame particle... It took quite a few tries to replicate this and again there were no unlit candles with flame particles. Only the candle bundle on the shelf was lighting unexpectedly. I was unable to replicate in the SSL test map. Gonna move forward to see if there is a build where the problem was exacerbated... 10036 was a full replication in The Outpost (unlit candle with particle, multiple candles) , SLL could not replicate as of yet. 9985 - I wasn't able to reproduce in The Outpost, but the SLL map has the symptom. Will keep trying but I believe the big problem started between 9944 and 9985 9981 took forever to produce the issue but it was a full replication. Going backwards... 9980 full replication after many tries, no SLL . gonna re-test 9979 ( this appears to be the one! ) 9979 same behavior as 9944. Only a partial replication and no issues in SLL ( re-tested, same behavior ) I cannot see how 9980 would cause this? @Dragofer are candle entities considered AF for physics because of the attached particle? @stgatilov any clue why rev 9980 would make candles misbehave more? Since this is part of a critical performance improvement I am hesitant to even consider any kind of rollback or removal in the final beta builds.

@Dragofer had good luck with the DDS exporter in GIMP. It allowed him to export at BC5 \ ATI2 \ 3Dc:

Sub-titles need to be manually created. If @Moonbo gives the go-ahead, I suppose a team member could create them for him?

Along with map merge, some folks are using Git https://wiki.thedarkmod.com/index.php?title=Git_and_Github_for_Mappers Map merge has been available since 2.13 Edit here is the link with animated illustrations of it in use:

All set! The fixed mission is now in the downloader.

I believe dmap bug was introduced in 2.07 or later and was fixed in 2.10. Someone probably dmapped it when updating the mission to fix asset compatibility but caused this artifact...?

WOO!!! Updated to the latest SVN binary, using the 10071 assets. At first it crashed on an AI Base Tactile error. I copied the latest scripts and def folder from SVN and it started but the crash happened soon after. I removed the def folder and it the crash could not be repeated. Time to step through def folder revisions! Def rev 16602 = no crash Def rev 16603 = crash ... I think got you!! tdm_prop_items.def rev 16603 appears to be the culprit.... Yes, there seems to be some relation between the sitting animations and the AI who happens to have pickup twice in the name of the target bottle?

Neat trick. Too bad such an approach can't easily generate parallax corrected cubemaps:

https://bugs.thedarkmod.com/view.php?id=6227 Cannot reproduce on rev 9985... moving forward Rev 10036 is good... moving forward Rev 10071 is good Rev 10071 with matching 16599 dev assets = good ( no crash ) ( maybe try to run the latest SVN with 16599 assets plus the blackjack patch assets ? ) Rev 10071 with 10107 assets = crash Rev 10072 = crash ( all testing was done with 10107 assets, if 10071 crashes the next step might be to revert assets too... that said, if 10107 asset changes are responsible TDM still shouldn't crash ) Rev 10073 = crash ( may need to retest 10071 ) Rev 10078 = crash Rev 10092 = crash Rev 10093 = crash Rev 10095 = crash Rev 10107 = crash Nothing in Rev 10093 should cause a crash like this. New backtrace seems similar to the old one but uses different hash lookup ? Thread 11 "thedarkmod.x64" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffaf6bf700 (LWP 3026)] idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin") at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462 462 for ( int i = argHash.First( hash ); i != -1; i = argHash.Next( i ) ) { (gdb) bt #0 idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin") at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462 #1 0x000000000074f67a in idDict::GetString (out=<synthetic pointer>, defaultString=0x12995cc "0 0 0", key=0x12e8bfb "pre_pickup_origin", this=<optimized out>) Going back to 10092 to see if I missed the crash somehow. Yep, same crash there. Rolling back to an earlier one... Ran outta time. I will continue tomorrow ( unless someone else wants to build from source and bisect between 10071 and 10078 )

TDM 2.10 and newer already have substantially improved data loading speeds due to SIMD mipmap and compression changes. RBDoom3BFG does support binary asset loading but managing binary assets is generally seen as too cumbersome for most mappers. TDM 2.10 and newer already supports RGTC normal map compression. If desired we could convert assets to that format. There is a reluctance to do so because material "program" keywords must decompress that data and this will lead to decompression artifacts in the final render. We would need to identify textures that no mission author would ever customize with keywords before deciding which ones to compress

Lights can be controlled via script. You could use setLightParms : https://wiki.thedarkmod.com/index.php?title=TDM_Script_Reference#idLight

While trying to find a good map to bisect against ( smaller mission ), I ran into repeated crashes in "COS: Pearls 'n Swine". Back trace: pearlsandswine_bt.txt

Thanks! Would you be will to try 2.11 dev builds in the interim?

I'll try to bisect this one tonight. Hopefully it was introduced in one of the dev or beta builds so we can pinpoint when it started.

Several team members have expressed interest into evaluating PBR but there is no hard target for any progress because it would be a lot of work. If someone wanted to take some existing TDM assets and convert them for use in Doom 3 BFG ( RBDoom3BFG ) so that they can be evaluated, it might speed up the initial phase work. ( Eg, make a small test map with all the basic visual components; AI models, wood, metal, water, glass (textures), and lighting ) We won't even ask for anyone to start this work until we have more commitment on the time-tables but we won't say no to any submission like this if someone is really motivated to get things going. Going back to my previous post, it seems there is a workflow to convert PBR to Specular: https://marmoset.co/posts/pbr-texture-conversion/ but I can't find any automation that does it.

Not sure what the license is but if the Nvidia Remix tool has textures with a creative commons license then someone could extract them and use the texture replace tool in Dark Radiant to update a mission with them. The textures are most likely using a modern PBR format with metalness and roughness, so without PBR support in TDM they would need to be converted to a diffuse \ specular design ( I believe there are tools that automate going from legacy to PBR but I am not sure whether any texture author tool can do the reverse? ) There is a long term plan to evaluate whether allowing mixed legacy and PBR content the way that the "RBDoom3BFG" Doom 3 port does might be viable in TDM. If it turns out to be viable, then TDM would be able to use these "remix" textures natively without conversion ( again, as long as they are open CC assets and can be exported ). As far as I can tell, Nvidia are locking down all remix aspects so that modders can only use it for Nvidia's intended purpose of upgrading old fixed-function games to RTX. They aren't interested in shader based games or DX9+ because the change to Ray Tracing won't be as dramatic. Anything using light-mapping with probes is going to get a negligible upgrade from changing the lighting model since lightmaps are already raytraced. They want really impressive before \ after pictures to sell the technology. Even TDM probably looks too good in the "before" state to be of interest to Nvidia. ( That said, I would gladly accept a ray tracing patch for TDM if Nvidia ever decided to create one for us... )

Please open a tracker about the Training Mission with replication steps

Not sure but non-primary monitor support is not yet fully implemented in TDM: https://bugs.thedarkmod.com/view.php?id=4430

This one is easier to evaluate: