Daft Mugi

Hmmm... Well, I'm out of ideas. Perhaps a fellow mission author or another dev can take a look.

Perhaps something related to You could try setting s_overrideParmsMode cvar to 0 as a test. If it works again, you'll know to change one of the volume spawnargs to make it work when s_overrideParmsMode is set to 1. For 2.13 missions, s_overrideParmsMode should be set to 1. You can also set s_overrideParmsMode to 2 to get a console message if there is a difference between old and new behavior.

If you have them installed (using the mission downloader) and they are the most up-to-date version, they won't show up in the mission downloader. It depends on the entry in the fms/missions.tdminfo file. @joebarnin, is that the case for your machine? When I do a test search, Now and Then and The Heart of Saint Mattis show up for me. Tech Info After installation, The Heart of Saint Mattis is excluded from the downloadable list. fms/missions.tdminfo: tdm_missioninfo heartstmattis { "downloaded_version" "2" } If "downloaded_version" is manually changed to "1", The Heart of Saint Mattis is included in the downloadable list with an update available mark (*). fms/missions.tdminfo: tdm_missioninfo heartstmattis { "downloaded_version" "1" } Deleting the missions.tdminfo entry will also make it show up in the downloadable list.

Thanks for the report. It's now fixed in SVN.

There isn't a date in the local mission info to sort by. Only the remote mission info (XML file) includes the date. You probably have the old "readme.txt" file. Unzip the new "readme.txt" from the training mission pk4 file.

I see what you're saying about the standard Windows UI terminology. That’s a fair point. That said, I find "activate/deactivate" can also be confusing, because "activate" tends to sound like you're starting the mission right away, and "active mission" could imply the mission is currently in progress. To clarify, a mission only becomes in progress after the player clicks "Start Mission" or loads a saved game. There are two separate contexts here: UI context — where you select a mission from the list. Game context — where you have a currently selected mission with UI actions, such as "Start Mission".

For what it's worth, I agreed with you. So, I changed installed/uninstalled to selected/deselected in the dialog windows and one other title. I think that's clearer and more accurately describes the change of state after pressing the select/deselect buttons. The change is in beta213-04. Before this change, I would be somewhat surprised each time I saw "Mission Uninstalled" after deselecting a mission. It sounded like the mission files had been deleted, which sounded pretty serious and not the action I thought I was doing. With it now reading "Mission Deselected," we can all rest easy.

Thank you for looking into this issue. I'm not sure about crisper is always better. I do think non-blurry is better, though. Here's an example: But this is a bit of a feature request (non-blurry fonts) rather than addressing the issue at hand, which is font distortion when r_tonemapOnlyGame3d "1". It seems that this issue is dependent on hardware/drivers, which is a bummer. Does the 2.12 tonemapper cause color banding in videos? Does TDM 2.12? Now that the 2.12 tonemapper is default, is r_tonemapOnlyGame3d "1" as default still necessary? Is there another way this issue of font distortion could be fixed? Perhaps creating a main menu tonemapper with some post processing would produce better results? Its purpose could be: consistent main menu regardless of in-game 3D settings, no color banding in videos, custom images exactly as mappers intended, and non-blurry fonts.

To clarify what I wrote above, sharpening significantly improves the clarity of font characters without causing clipping issues. However, enabling r_tonemapOnlyGame3d "1" specifically causes the characters to be clipped at the bottom, and sharpening cannot be enabled when r_tonemapOnlyGame3d "1". The fonts look really great when r_tonemapOnlyGame3d "0" and r_postprocess_sharpen "1".

That's interesting. I wonder why. Do you have any ideas what we can do about the characters getting clipped at the bottom when r_tonemapOnlyGame3d "1"?

Awesome - fixed! Thank you!

@stgatilov Do you think the same can be done with the loading screen? Sometimes there's distortion when loading a new map. (Note bright green artifact on lower-left edge in the screenshot.)

@stgatilov Even better news! The following commit fixed this issue regardless of r_tonemapOnlyGame3d setting. r10930 | stgatilov | 2025-01-25 | 7 lines Clear background during main menu. This fixes the issue e.g. with AT1: Lucy and tonemap disabled. The briefing there does not use any backgrounds, and no-clear policy results in HOM-like effects. Originally reported here: https://forums.thedarkmod.com/index.php?/topic/22635-beta-testing-213/#findComment-499723

Regarding the download mission list characters that Wesp5 was referring to, yeah, I couldn't confirm it either. It looks the same between 2.12 and 2.13. But, the mission title on the main menu screen does have characters clipped at the bottom when r_tonemapOnlyGame3d "1" (as seen in the animated screenshot). Are you able to confirm that? Some ideas: Postpone r_tonemapOnlyGame3d until TDM 2.14? Perhaps the clipping issue is related to post processing, so if r_tonemapOnlyGame3d "1" uses post processing, the characters might look correct? As an aside, it might be worthwhile to always have r_postprocess_sharpen "1" for the main menu regardless of in-game setting, because it makes fonts crisp and clear. Without r_postprocess_sharpen "1", fonts are blurry.

I'm not noticing a difference between 2.12 and 2.13 fonts in the download missions list. Can you share comparison screenshots? Perhaps a separate issue?

With r_tonemapOnlyGame3d set to 1, there are font distortions (as seen in the animated screenshot). The A, G, S, and O characters are the most noticeable -- the bottoms are cut off.

re comparison screenshots of the windows: Could it be the difference in tonemappers rather than something wrong with the assets? What does it look like with: r_postprocess_compress 0 r_postprocess_desaturation 0 r_postprocess_overbright_desaturation 0

How can an artist's visuals be preserved? With the goal of artistic preservation in mind, here are two ideas for a path forward: A graphics menu option for players: With TDM 2.12 tonemapper as default, have a graphics option for additional tonemappers, such as this TDM 2.13 tonemapper. This would respect artistic intent while still offering flexibility to players. A worldspawn option for mission authors: With TDM 2.12 tonemapper as default, allow the tonemapper to be configured by a mission author. This would respect artistic intent. With this method, perhaps -- like @nbohr1more mentioned above -- tonemapping for missions made for TDM 1.03 could be restored. Establishing the TDM 2.12 tonemapper as the default baseline moving forward—with optional tonemappers—would help ensure long-term visual stability. This strategy would honor the original artistic intent and maintain confidence among mission authors and asset artists.

This is due to the recent tonemapper changes. When r_tonemapOnlyGame3d is set to 1, the fonts are distorted. When r_tonemapOnlyGame3d is set to 0, the fonts look fine.

To add to what stgatilov said: For those who want to try this in-game, I recommend creating a binding to toggle between the original and new tonemappers for convenience. Initially, make sure the cvars start with values for one of the tonemappers. Bind a key: bind "b" "toggle r_postprocess_compress; toggle r_postprocess_desaturation 0 -0.2; toggle r_postprocess_overbright_desaturation 0 0.1" Check that the binding is toggling correctly as a group. In the console, you should see output like the following: set r_postprocess_compress = 1.000000 set r_postprocess_desaturation = -0.2 set r_postprocess_overbright_desaturation = 0.1 set r_postprocess_compress = 0.000000 set r_postprocess_desaturation = 0 set r_postprocess_overbright_desaturation = 0 To take comparison screenshots of something with motion, such as flames, sparks, or NPCs: First, stop the game time, and then take the screenshot. toggle g_stopTime It's recommended to start the game time after your are done taking screenshots as things that are far away from where "g_stopTime" was stopped can be in a weird state.

I appreciate the effort that went into implementing the new tonemapper. It’s clear that a lot of thought has been put into refining the visuals, and I wanted to share some observations and questions based on my experience. Using my monitor, which is optimized for creating art (100% sRGB, 100% Rec. 709, Color Accuracy ΔE < 2, Calman Verified), I’ve noticed the following: Visual Changes: The new tonemapper doesn’t appear to improve blown-out or overbright areas, as they remain overexposed. Additionally, the rendering feels more desaturated, with reduced contrast and significant color shifts (e.g., gold to bronze, red to salmon, white to gray). This results in a flatter scene with less depth and vibrancy. Firelight now feels more like the glow from fluorescent lighting, which shifts the overall tone and mood of scenes. The overall scene can appear hazy. Gameplay Impact: The new tonemapper can make it harder to notice when objects and doors are frob highlighted, which could make gameplay more challenging for players. Art Style Consistency: The new tonemapper can significantly change the visual style of existing missions, which might affect the overall player experience, especially for those familiar with the original look. Also, mission authors who have spent time carefully tweaking colors may find their work visually altered in unintended ways. While the new tonemapper may have strengths in certain scenarios, its impact seems to vary widely depending on hardware and context. Would it be possible to consider making the new tonemapper opt-in while gathering additional feedback? This might help ensure that everyone can choose the visual style that works best for their setup and preferences. Here are 4 sets of screenshot comparisons: Original: first in set. New Tonemapper: second in set.

For readables, the mouse wheel already turns pages. Or, do you mean make a readable a single long page with a scrollbar? If that's the case, it's hard to know until the code is looked at. For custom briefings, if there's an editDef, it should work. The editDef needs to have focus to scroll with the mouse wheel, which can done via "setFocus" or the user clicking the editDef text. (I'm thinking of briefing text, such as the one for the Training Mission. The one with the heading "The Dark Mod Training Mission" followed by "This trainer gives you...") The important properties are as follows: editDef aTextBox { text "some really long text" forecolor 0,0,0,1 hovercolor 0,0,0,1 // match forecolor wrap 1 readonly 1 }

@stgatilov This was fixed by the following commit: r10914 | stgatilov | 2024-12-08 | 8 lines Added a way to force-disable tonemapping everywhere if 3D game is not running (r_tonemapOnlyGame3d). This can be useful because the new tonemapping settings affect main menu rather negatively. Well, in fact even the simple gamma already affects cinematics the bad way, introducing ugly color banding on dark colors. Note: normally we should do tonemapping after 3D game is rendered but before GUI overlays are rendered. But this is a hard topic, because some of the GUI overlays are not actually GUI (e.g. underwater overlay), so this requires some kind of manual tagging. Better leave this for the future. When launching TDM: r_tonemapOnlyGame3d 1: first frame is fine. r_tonemapOnlyGame3d 0: first frame is distorted.

The "notes" dialog uses an editDef, which lacks scroll wheel support, unlike the listDef, which has scroll wheel support implemented. Perhaps scroll wheel support will be added to editDef in the future. I added mouse wheel support to editDef. The "notes" dialog should scroll when using the mouse wheel in the next dev build.