Beta testing 2.13

[Amadeus]

3 hours ago, nbohr1more said:

https://bugs.thedarkmod.com/view.php?id=6579

@Amadeus can you revert this and create new materials defs with the desired design eg: window_moolit_new (etc)?

Do your changes significantly improve existing missions so that only this mission is an outlier ( eg we would just include an override def in this mission ) ?

So I can definitely revert it if you'd like (gonna have to wait til Sunday or Monday though) but as Daft Mugi pointed out, this kinda looks like the tone mapper. When I tested these changes way back when, the windows didn't look as muted as they do in snatcher's screenshots. At the time, I also tested the windows on FMs like perilous refuge, PD3, and a handful of others and haven't noticed this issue. Either way, I'll take a closer look at this in a few days

[Daft Mugi]

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.

[nbohr1more]

1 hour ago, Amadeus said:

So I can definitely revert it if you'd like (gonna have to wait til Sunday or Monday though) but as Daft Mugi pointed out, this kinda looks like the tone mapper. When I tested these changes way back when, the windows didn't look as muted as they do in snatcher's screenshots. At the time, I also tested the windows on FMs like perilous refuge, PD3, and a handful of others and haven't noticed this issue. Either way, I'll take a closer look at this in a few days

Please do. I can clearly see the lack of illumination on the new texture even without bloom enabled on either 2.12 and 2.13.

I agree that the texture being called "unlit" is a bad name for it but mappers often choose the textures based on appearance rather than name so who knows how many missions we have where the author wanted an unlit look but couldn't get one vs wanted the current blue lit appearance.

[stgatilov]

20 hours ago, Daft Mugi said:

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.

I can't confirm this.
The minor clipping of letters O/D happens regardless of tonemapping, just the color of the paper is a bit different depending on tonemapping.
Not sure this has to be fixed though... it might be hard to avoid while using small font.

[stgatilov]

17 hours ago, snatcher said:

• Mandrasola: Some windows have lost their mojo

This might be the bumpy envmap change (6354).

For this kind of stuff, be sure to use the updated version of the mission, especially in 2.13 beta.
Which can be a bit hard now, since we have some issues with missions database.

UPDATE: Looked at the windows, they don't have envmap. So this is asset changes.

[stgatilov]

On 1/16/2025 at 8:12 PM, snatcher said:

An addition to my, never acknowledged (too much asking, I know), previous report:

• AT1: Lucy's quest: funny things going on in the background during the briefing

This is caused by the fact that I disabled tonemapping in the main menu.
With "r_tonemapOnlyGame3d 0", the issue disappears.

[Daft Mugi]

3 hours ago, stgatilov said:

I can't confirm this.
The minor clipping of letters O/D happens regardless of tonemapping, just the color of the paper is a bit different depending on tonemapping.
Not sure this has to be fixed though... it might be hard to avoid while using small font.

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?

16 hours ago, Daft Mugi said:

The A, G, S, and O characters are the most noticeable -- the bottoms are cut off.

 

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.

[stgatilov]

34 minutes ago, Daft Mugi said:

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?

No, it looks the same for me.

[Geep]

In looking at the animation, it struck me as odd that some characters become clipped while others apparently do not. The characters being clipped are those with a horizontal stroke at the bottom (G,S,O; exception: A). Maybe that indicates the sharpening algorithm is overly aggressive for those cases.

EDIT: Further thoughts about this...

 

Edited January 18 by Geep
add link

[wesp5]

Okay, so I noticed something else today and I can't say if this was already the case with 2.12 or is new in 2.13: If you select all missions to download at the same time, all of them are listed on the right side but it seems only some will actually be downloaded, so you need to do this multiple times. Is there a maximum number of missions that can be updated this way?

[datiswous]

On 1/2/2025 at 7:32 PM, stgatilov said:

* Shadows of Northdale Act 1 does not start (6509). (mission has been updated)

Does the mission work on 2.12 and 2.13?

See this post

Edited January 22 by datiswous

[stgatilov]

8 hours ago, datiswous said:

Does the mission work on 2.12 and 2.13?

A fresh version from the missions repo currently works only on 2.13 beta.
I posted a link to 2.12 version in that thread.

[snatcher]

On 1/2/2025 at 7:32 PM, stgatilov said:

* Added TDM version + engine revision in lower-left corner of main menu.

You don't need this in the "Official" release. Keep it for geeks (alphas and betas) but spare your global audience.

On 1/2/2025 at 7:32 PM, stgatilov said:

* Fixed unwanted mine deployment when player eats the last bit of food in hands (6598).

Okay but this is more of a hack than fix. It solves a problem for a particular scenario but it doesn't address the underlying issue and it ends up messing with the user interface (where did my compass go). The problem is still there: depending when some items are acquired and the number of items players can still unintentionally, in example, drop a flashbomb after drinking a potion.

On 1/2/2025 at 7:32 PM, stgatilov said:

* Improving the fonts continued (thread).

@Geep, are you sure your latest and greatest versions of Stone are in 2.13b1? I detect some artifacts I haven't seen in long time, specially in uppercase letters.

Edited January 24 by snatcher

[thebigh]

A lighting bug introduced, I think, in 2.12.

Heart of Lone Salvation, just on entering the cellar through the sewer pipe:

 

[snatcher]

On 1/2/2025 at 7:32 PM, stgatilov said:

* Fixed unwanted mine deployment when player eats the last bit of food in hands (6598).

20 hours ago, snatcher said:

Okay but this is more of a hack than fix. It solves a problem for a particular scenario but it doesn't address the underlying issue and it ends up messing with the user interface (where did my compass go). The problem is still there: depending when some items are acquired and the number of items players can still unintentionally, in example, drop a flashbomb after drinking a potion.

This long-standing issue should ideally be fixed in the SDK. In example: register the item onKeyPress and make sure onKeyRelease relates to the same item, otherwise abort.

The alternative is to add these checks in the individual items, in example:

object playertools_flashbomb : player_tools {

	void inventoryUse(entity userEntity, entity frobbedEntity, float buttonState);

	void inventoryUseKeyRelease(entity userEntity, entity eFrobbed, float holdTime);

	boolean playerTriggered;

	void inventory_item_select(entity userEntity, float overlay);
	void inventory_item_unselect(entity userEntity, float overlay);
};

void playertools_flashbomb::inventory_item_select(entity userEntity, float overlay)
{
	playerTriggered = false;
}

void playertools_flashbomb::inventory_item_unselect(entity userEntity, float overlay)
{
	playerTriggered = false;
}

void playertools_flashbomb::inventoryUse(entity userEntity, entity frobbedEntity, float buttonState)
{
	playerTriggered = true;
}

void playertools_flashbomb::inventoryUseKeyRelease(entity userEntity, entity eFrobbed, float holdTime)
{
	if (playerTriggered)
	{
		playerTriggered = false;

		// continue normally
	}
}

The downside of using the script system is that some missions come with their own custom items and these should to be revisited as well.

Edited January 25 by snatcher

[stgatilov]

17 hours ago, snatcher said:

You don't need this in the "Official" release. Keep it for geeks (alphas and betas) but spare your global audience.

I would say it's easier to leave it there than remove it specifically in final releases.
In fact, "the geeks" don't need it because they know they can open console and see the revision there.

Quote

Okay but this is more of a hack than fix. It solves a problem for a particular scenario but it doesn't address the underlying issue and it ends up messing with the user interface (where did my compass go).

I did not pay much attention to this, but I like the idea of fixing more reliably it in C++.
I wonder if we should still release the current hack, or revert it and do proper fix later?
 

[snatcher]

1 hour ago, stgatilov said:

I did not pay much attention to this, but I like the idea of fixing more reliably it in C++.
I wonder if we should still release the current hack, or revert it and do proper fix later?

This issue has been there like, forever. If the plan is to have a proper fix for 2.14 then it can wait one more year.

I propose removing the hack and temporally go for updated scripts for the mines and the flashbomb. Whenever the fix is ready you can revert back these scripts. In the meantime, the issue is minimized (*) with no impact on anything else.

(*) Custom items in missions will still drop.

Find the updated tdm_playertools.script attached to this post.

EDIT - The script is a few posts below.

 

Edited January 25 by snatcher
Wring script uploaded

[stgatilov]

4 hours ago, thebigh said:

Heart of Lone Salvation, just on entering the cellar through the sewer pipe:

I can't reproduce with fresh mission downloaded from the mirrors.
I tried SVN and beta213-01. Tried stencil / shadows. Tried tdm_open_doors / tdm_close_doors.
The lighting always looks the same to me, no weird light leak as on your screenshot.

[snatcher]

I uploaded the wrong script in the previous post. It has just been updated.

[snatcher]

And updated one last time. Actually, here it is to avoid confusion.

tdm_playertools.script

[Amadeus]

3 hours ago, snatcher said:

This long-standing issue should ideally be fixed in the SDK. In example: register the item onKeyPress and make sure onKeyRelease relates to the same item, otherwise abort.

The alternative is to add these checks in the individual items, in example:

object mod_playertools_flashbomb : player_tools {

	void inventoryUse(entity userEntity, entity frobbedEntity, float buttonState);

	void inventoryUseKeyRelease(entity userEntity, entity eFrobbed, float holdTime);

	boolean playerTriggered;

	void inventory_item_select(entity userEntity, float overlay);
	void inventory_item_unselect(entity userEntity, float overlay);
};

void mod_playertools_flashbomb::inventory_item_select(entity userEntity, float overlay)
{
	playerTriggered = false;
}

void mod_playertools_flashbomb::inventory_item_unselect(entity userEntity, float overlay)
{
	playerTriggered = false;
}

void mod_playertools_flashbomb::inventoryUse(entity userEntity, entity frobbedEntity, float buttonState)
{
	playerTriggered = true;
}

void mod_playertools_flashbomb::inventoryUseKeyRelease(entity userEntity, entity eFrobbed, float holdTime)
{
	if (playerTriggered)
	{
		playerTriggered = false;

		// continue normally
	}
}

The downside of using the script system is that some missions come with their own custom items and these should to be revisited as well.

This does seem like a far more elegant fix than my admittedly hacky solution. It's definitely worth trying IMO.  Would it be to late to try and fit this in for 2.13?

[snatcher]

If we get "the proper fix" in 2.14 we will owe you one, @Amadeus. Thanks for initiating all this.

May ask you to edit your post and remove all instances of "mod_" from the quote? (just for the record). I did this quickly in the morning and made some mistakes. The final script is good, though.

By having the proper fix in the source code:

• Players can consume food without dropping anything afterwards
• Players can deplete items of a kind (drink the last potion) without dropping anything afterwards
• We can re-enable the current item after unshouldering bodies without dropping anything afterwards
• Missions will not be impacted

 

37 minutes ago, Amadeus said:

[...] Would it be to late to try and fit this in for 2.13?

I will do a deeper analysis if my script makes it into the next beta.

Edited January 25 by snatcher

[Geep]

21 hours ago, snatcher said:

@Geep, are you sure your latest and greatest versions of Stone are in 2.13b1? I detect some artifacts I haven't seen in long time, specially in uppercase letters.

@nbohr1more, could you please arrange that the dat and dds files from my recent cumulative font update are incorporated into 2.13b2? Thanks. (I double-checked that the Stone 24pt dat & dds therein are those from mid-June, as expected.)

[Daft Mugi]

On 1/18/2025 at 11:10 AM, stgatilov said:

No, it looks the same for me.

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"?

[Daft Mugi]

On 1/18/2025 at 1:38 PM, Geep said:

In looking at the animation, it struck me as odd that some characters become clipped while others apparently do not. The characters being clipped are those with a horizontal stroke at the bottom (G,S,O; exception: A). Maybe that indicates the sharpening algorithm is overly aggressive for those cases.

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".