Daft Mugi
-
Posts
651 -
Joined
-
Days Won
15
Posts posted by Daft Mugi
-
-
I fixed another case of clipping into the ceiling during a mantle that starts in the standing position and ends in the crouching position (a.k.a forced-crouch mantle). The fix is included in beta212-07.
The fix changed a lot of code, so please let us know if you find any issues.
-
1
-
-
In TDM 2.12, some player footstep sound shaders were changed. That's something you might want to check as well.
The following diff snippet is an adjustment to metal volumes I made to one of your missions on my local machine, so it matches TDM 2.12. There are probably others, which are best left up to you. I used a diff tool to find what to update.
diff --git a/original/sound/tdm_sfx_movement.sndshd b/adjusted/sound/tdm_sfx_movement.sndshd index eecef04..5ae1843 100644 --- a/original/sound/tdm_sfx_movement.sndshd +++ b/adjusted/sound/tdm_sfx_movement.sndshd @@ -424,7 +424,7 @@ tdm_footstep_metal_run minDistance 1 maxDistance 30 - volume -17 + volume -20 editor_displayFolder sfx/movement/footsteps/player @@ -472,7 +472,7 @@ tdm_footstep_metal_crouch_creep minDistance 1 maxDistance 30 - volume -15 + volume -14 editor_displayFolder sfx/movement/footsteps/player @@ -488,7 +488,7 @@ tdm_footstep_metal_jump_land minDistance 1 maxDistance 30 - volume -9 + volume -13 editor_displayFolder sfx/movement/footsteps/player-
1
-
1
-
-
-
On 2/15/2024 at 12:18 PM, Baal said:
Volta 2 crashes to desktop on mission completion before the "mission complete" screen appears.
I was able to reproduce this in 2.12 beta as well as 2.11.
- Start mission
- setviewpos -5727 974 292 24 -57 0
- Wait for new objective
- setviewpos 3795 5676 -3164 18 160 0
- Wait for objective complete
- Shoulder body
- setviewpos -1643 3574 -1903 4 180 0
- Drop body on elevator platform
- Press elevator button
Setting "logFile 2", I was able to capture some console messages before the crash. "MISSION COMPLETED" displays twice instead of once. I haven't had a chance to look further into this.
WARNING:idClipModel::Handle: clip model 0 on 'bellero' (dc8) is not a collision or trace model WARNING:idClipModel::Handle: clip model 0 on 'bellero' (dc8) is not a collision or trace model WARNING:idClipModel::Handle: clip model 0 on 'bellero' (dc8) is not a collision or trace model MISSION COMPLETED MISSION COMPLETED ----- idRenderModelManagerLocal::EndLevelLoad ----- 0 models purged from previous level, 1031 models kept. --------------------------------------------------- Regenerated world, staticAllocCount = 0. Getting threadname failed, reason: No such file or directory (2) --------- Game Map Shutdown ---------- ModelGenerator memory: 133 LOD entries with 0 users using 2128 bytes. WARNING:idClipModel::FreeTraceModel: tried to free uncached trace model (index=0) --------- Game Map Shutdown done ----- Shutting down sound hardware idRenderSystem::Shutdown() ...shutting down QGL I18NLocal: Shutdown. ------------ Game Shutdown ----------- ModelGenerator memory: No LOD entries. Shutdown event system ---------------------------------------
1
-
20 hours ago, MirceaKitsune said:
Great take on it and solution from what I understand! Will the normal Beta 6 contain this patch? If so it's easier to wait till then, otherwise if it's important I can of course give the test build a try given it doesn't mess with my normal install.
In its current state, it might not be included in TDM. It needs more work, in my opinion. I wanted to give you and others a chance to try it and give feedback. Maybe it'll spark some ideas.
-
1
-
-
14 hours ago, Daft Mugi said:
Regarding worldspawn "forceAllShadowsBehindOpaque" set to "1", it doesn't seem to get restored on game load.
@stgatilov Thank you for fixing this!
-
32 minutes ago, stgatilov said:
@Daft Mugi, does it look like the issue you have?
I bet it does not.It's a different issue.
-
Regarding worldspawn "forceAllShadowsBehindOpaque" set to "1", it doesn't seem to get restored on game load.
To reproduce (works with any fixed mission using "forceAllShadowsBehindOpaque"):
- Add "forceAllShadowsBehindOpaque" "1" to the worldspawn in the map file.
- From main menu, "Start this Mission" or "Restart Mission".
- setviewpos
- Notice that the light leak is fixed (not present).
- Save game.
- Load game.
- Notice that the light leak is present (not fixed).
Example
1. From main menu, "Start this Mission" or "Restart Mission".
2. Run setviewpos.
3. Save game.(1736.483691.68-137.75).thumb.jpg.8d5741937a4d291be421b7590ab8465b.jpg)
4. Load game.
(1736.483691.68-137.75).thumb.jpg.e821d105119b55d3c6dea2e48f8d411f.jpg)
-
1
-
Thief's Den 3: Heart of Lone Salvation
1736.48 3691.68 -137.75 -5.4 101.1 0.0
Light leak:
(1736.483691.68-137.75).thumb.jpg.11389fefab1952663782383629f41934.jpg)
No light leak:
(1736.483691.68-137.75).thumb.jpg.2586700f27ed8937996e3728e9277bd6.jpg)
-
1
-
-
On 2/2/2024 at 3:29 PM, MirceaKitsune said:
Wanted to ask about my other point regarding the toggle states, whether you think that should be changed as well: When both running and creeping are set to toggle, shouldn't toggling one instantly disable the other? Unlike crouching the two can't be used in combination with each other, at the moment creeping happens to override running; It would be easier to know that when you exit running or creeping, you're always back to normal walking instead of the other mode if you forgot it turned on.
Well, let's explore this a bit. How can this be solved?
Currently, creeping overrides running (like you said).
Here are a couple issues or considerations:
- What about players who want to keep the fine control of toggling each one independently? Perhaps some players want to go from creeping to running.
- At the moment, the code is written in such a way (due to its Doom 3 history) that toggling creep can set the toggled run state, but toggling run cannot set the toggled creep state. The toggle creep key can set the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. Fixing this would require a lot of code rewriting.
Brainstorming: It almost sounds like increase and decrease speed keys are desired. Run key to go from creep to walk and from walk to run. Creep key to go from run to walk and from walk to creep.
If you're curious to give this a try, here's a Linux test build that matches beta212-05 (rev 16950-10635) with the following change: The toggle creep key sets the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. https://drive.google.com/file/d/1osTCQRf7LQ5wPvhGl2uRU4NcFnJPEu9_/view?usp=sharing
-
1
-
On 2/1/2024 at 2:24 AM, stgatilov said:
Antialiasing mostly affects some backend logic, while the commit changed data structures in frontend. It is very hard to believe they are linked in any way.
Yeah, I don't know what to say. Rev 10383 works fine and 10384 does not.
On 2/1/2024 at 2:24 AM, stgatilov said:Maybe the bug is not reliably reproducible?
It is always reproducible for me, meaning that every time I try to reproduce it, I can reproduce it.
On 2/1/2024 at 2:24 AM, stgatilov said:Maybe antialiasing is an important condition when it happens, but otherwise it is timing-specific, so accelerating frontend made it pop up. Or maybe antialiasing is just one way to slow gown backend and using maximum soft shadow quality or r_fboResolution 2 would make it happen too.
After some more testing, I found that r_multiSamples set at 2 or 4 has the glitch most often at that viewpos. When set to 8 or 16, it is still possible but less likely.
Setting r_fboResolution 2 made no difference.
If com_maxFPS is set to something lower, such as 30, the glitched frames display for a longer period of time.
On 2/1/2024 at 2:24 AM, stgatilov said:Maybe the particular behavior is driver-dependent (e.g. NVIDIA masks the error away).
Which GPU do you have? Which drivers do you use?
Which CPU do you have BTW?Yeah, I also wonder if it driver dependent or GPU dependent. I discovered the glitch while using graphics drivers Mesa 22.0.5, so I updated my OS and graphics drivers to Mesa 23.3.2 today as a test, and the problem is still there. It's strange that rev 10384 exposed this problem.
My machine specs and settings:
- Linux, Ubuntu 22.04
- AMD Ryzen 9 5900X
- AMD Radeon RX 6700 XT (Mesa 22.0.5 & Mesa 23.3.2 both exhibit the glitch)
- com_fixedTic 1
- com_maxFPS 60
- Anti-Aliasing 2x (r_multiSamples 2)
On 2/1/2024 at 2:24 AM, stgatilov said:Does it happen in the very specific viewpos and goes away if you move away slightly?
The video I shared shows the viewpos. Even at the same viewpos, the glitched frame will pop in and out. I've only seen this glitch happen in this single room in Accountant 1. If I move around the room at that viewpos, I can find other view positions that also expose the glitch.
Here's another viewpos for Anti-Aliasing 4x, 8x, and 16x. It requires moving the mouse slightly to get into the exact viewpos to expose the glitch. (1.7 -166.4 0.0) is not precise enough.
-1460.29 1425.48 172.25 1.7 -166.4 0.0
Glitched frame (Shows the curtain texture, covering most of the frame. Also, a hint of the red carpet texture?):
(-1460.291425.48172.25).thumb.jpg.ddc602adda48ac1463ab154f897da7bd.jpg)
Good frame (Same viewpos and Anti-Aliasing settings, when the glitched frame disappeared for a moment.):
(-1460.291425.48172.25).thumb.jpg.ee290e36154ecb7701e0bc7bebdeaa7e.jpg)
(Before and after rev 10384) I wonder if this might also be related to:
(Before and after rev 10384) Also, sometimes on the loading screen with Anti-Aliasing enabled, I get a glitched background, which does not show with Anti-Aliasing disabled. See left side of screenshot:
I don't know if the last two examples (distorted first frame on launch & loading screen distorted background) are related, but I thought I'd mention them just in case it helps track down the issue.
-
With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around.
I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission.
-
1
-
-
With TDM 2.12, the credits showed the cursor during the credits along with some warnings printed to the console.
Here's a fixed "credits.gui" file for Accountants 2 (version 3):
https://gist.github.com/daftmugi/f180850af5612eed149d93b8fa3c56c5Check the "Revisions" tab on the GitHub gist to see what changed. In short, it uses "nocursor" instead of "showCursor", and it fixes the number of args passed to "transition".
(-99603616-403.75).thumb.jpg.10f77b457699e323d8e1a3f6c67bfa89.jpg)
-
1
-
-
On 1/31/2024 at 2:07 AM, stgatilov said:
Does it happen if you disable Frontend Acceleration and set com_smp to 0 (don't forget to restore it back afterwards)?
Does it happens with clean config (i.e. after deleting darkmod.cfg) ?I found the setting that causes it. The glitch happens when anti-aliasing (r_multiSamples) is enabled.
EDIT: Bisecting shows that rev 10384 is the first commit to introduce this glitch.
EDIT 2: Happens when r_multiSamples is set to 2 (most likely) or 4 (less likely). When set to 8 or 16, it is still possible but less likely.
-
2
-
-
On 1/28/2024 at 10:57 AM, stgatilov said:
Is it reproducible?
Yes. Always.
On 1/28/2024 at 10:57 AM, stgatilov said:Does it go away if you disable "Frontend Acceleration" ?
No.
-
In beta212-05, does "screenshot_viewpos" now work properly when bound to KP_SLASH?
-
1
-
-
4 hours ago, datiswous said:
I added the console commands teleport, getwiewpos and setviewpos to the Console Useful Controls page on the wiki.
Would you mind adding "tdm_show_viewpos" to the list?
Also, would you mind adding "screenshot_viewpos" and "screenshot_viewpos <gamma>" to Reporting Problem?
-
Found a graphics glitch in Accountant 1. Not present in 2.11.
-1469.5 1439.2 138.25 17.2 -146.1 0.0
-
On 1/16/2024 at 6:32 PM, MirceaKitsune said:
Yet another confusing though less problematic aspect is the toggles not persisting between saves: I have running turned on, do a save, run into trouble and reload, then I'm suddenly slow again. Since crouching is persistent in saves, can the toggles for creeping and running do the same?
This is now fixed in SVN. The toggled run state is now saved to and restored from the saved game file.
-
1
-
-
-
- Popular Post
- Popular Post
The bug (6425) where the player view could sometimes clip through the ceiling during a forced-crouch mantle is now fixed in SVN.
Preview:
-
5
-
I added three "wait" commands (code rev 10628). Please let me know if it fixes KP_SLASH for you. The fix should be included in 2.12 beta5.
-
1
-
-
TDM is marketed as:
- It's a tremendous achievement - a detailed tribute to the Thief series. (link)
- Since The Dark Mod is designed to simulate the stealth gameplay of Thief, many things will be familiar to veteran Thief players. (link)
QuoteThe Dark Mod was [...] created to allow players to have Thief 1/2 style gameplay in a more modern engine. [...] The main goal was to allow fan mission authors to make new missions [...] but play more like the original games. (link)
It should be of no surprised when folks suggest making a change to TDM that fits more closely with Thief when it makes sense. The majority of active TDM players and mission authors I see today are also Thief players.
And, besides the folks here on this forum, there aren't many places where the dev team can get player feedback on TDM, especially players who gave up on playing TDM all together. The Thief (including TTLG) community is one of the only places where we can get feedback in general and from veterans of this stealth game type.
Feedback I received from a player:
QuoteIndeed extinguishing candles was more tedious than necessary, and shouldering bodies is something few players realized was possible (I shared that shouldering tip in several Twitch streams).
FWIW, [I played TDM during its early days]. Life kinda got in the way for a while, but some things just bugged me enough about TDM that I never got back into it. I may fire up TDM myself for the first time in a while thanks to the changes you're making. The TDM devs may not realize just how much NewDark affected TDM. Once Thief became easily playable on modern systems, players weren't willing to accept those annoyances anymore to get their Thief fix. Listening to the players' complaints goes a long way.
This is great news for our community.
- For our community, more players increase the likelihood of more devs, mission authors, and content creators.
- For the content creators, more players experience the content they make.
That said, I think most agree that TDM is not meant be a 1:1 copy of Thief, and that's a good thing. Changes to TDM should be carefully considered and playtested before release.
EDIT: To clarify, addressing player complaints does not mean copy Thief game mechanics. It means that when player complaints are addressed, a solution that is appropriate for TDM is implemented.
-
2
-
3 hours ago, datiswous said:
Maybe you can change the command into double wait; to make it more reliable?
Sounds like a good idea to me. I'll test out that change.
3 hours ago, datiswous said:Or is it possible to give the full command including the gamma change, so I can test with that included as well?
The full command is similar to:
tdm_show_viewpos 2; r_ambientGamma 1.3; wait; screenshot; tdm_show_viewpos 0; r_ambientGamma 1
(274.26-1039.08184.71).jpg.cd83e2aa1c47ac7276bad1d005028fd2.jpg)
(1736.483691.68-137.75).jpg.deb4fb4f22a5edd94f347db54ceec28b.jpg)
(1736.483691.68-137.75).jpg.b90869aab6b228c189302f19e065147b.jpg)
(1736.483691.68-137.75).jpg.1e8a396170384d746bfef327fdb6d18f.jpg)
(1736.483691.68-137.75).jpg.cd9330083744a3fc9c3a206a80746e62.jpg)
(-1460.291425.48172.25).jpg.61e69a0a8cbff47675961a0071e6dda4.jpg)
(-1460.291425.48172.25).jpg.0efdb3b58b088d604fb5ed214c741145.jpg)
(-99603616-403.75).jpg.2ddc2807808916cb90bf456f002bbfe2.jpg)
Shadow maps behavior
in TDM Editors Guild
Posted
Losing the option for stencil shadows would be extremely sad. TDM has the best stencil shadows implementation I've ever seen, and they look far better than shadow maps. They also perform wonderfully.
Stencil shadows not supporting shadows on translucent surfaces is a bummer, but that's a fine tradeoff.
Personally, I'd rather not see alpha-tested shadow occluders, because they look awful and are distracting. Shadow maps in general look bad and pixelated -- quite immersion breaking.
Another issue with shadow maps is that they substantially increase the usage of the GPU. For those using laptops or integrated GPUs, it could cause performance or heat issues. For those with decent dedicated GPUs, increased wattage (and therefore heat) can and does turn on its GPU fans. The wattage on my AMD RX 6700 XT can become tripled when using shadow maps. That's undesirable.
The advice I give players is: There really isn't a "best" shadows implementation these days. Some devs and players prefer one over the other. Regardless of which is chosen, stencil shadows and maps are used where needed. So, I'd try out both and pick the one you prefer.
Here's Fen complaining about shadow maps.
Complaint #1 (7:28):
Complaint #2 (23:46):
In his next video (Written in Stone - 4 - Chocolate Coated Brendel Bar), he turned on stencil shadows, and as far as I know, he never complained again.
The following area in Written in Stone shows a good example of alpha-tested shadow occluders. Yes, technically the moving leaves cast shadows, but it looks awful in game, in my opinion. I know others like it. The same scene using stencil shadows looks amazing in game. (The screenshots don't do a good job demonstrating how it looks in game.)
The current hybrid system is fantastic. It gives people choice. Those who prefer stencil shadows can use them; those who prefer shadow maps can use them. People become attached to the "art" and "style" of a mission, and changing the shadow implementation changes the art and style.
If one must be dropped, I'd say shadow maps should be dropped from the menu settings. Use shadow maps for volumetric lights and stencil shadows everywhere else.
And, I agree with nbohr1more that defaulting to rules consistent with stencil shadows is a good idea.