Bug: No more whole numbers in 3.0.0. :S

[Nort]

Just updated my DR to 3.0.0, and began aligning my textures, when I noticed that it stepped from whole numbers, to very slightly off numbers, like for example:
0 - 1 - 2 - 3.0000000000000004 - 4 - 5 - 6.000000000000001 - 7.000000000000001 - 8.
These numbers are consistent when using both the horizontal and vertical shift buttons. Even when I try to manually type in "6", it adjusts it to "6.000000000000001".

I'm afraid to texture things now, because I want textures to be in whole numbers.

[Nort]

...and it's consistent too: I just started a whole new map, and made a single brush, and no texture, and it still steps in these increments. :S

[Nort]

Oh, and it has auto-aligned every texture in my level to these off-numbers too! What have you done?! :S :S :S

[AluminumHaste]

It's just the representation in the editor. The map file itself is identical.

2.14:

Version 2
// entity 0
{
"classname" "worldspawn"
// primitive 0
{
brushDef3
{
( 0 0 1 -64 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 1 0 -7.5 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 1 0 0 -7.5 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 0 -1 -64 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 -1 0 -8 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( -1 0 0 -7.5 ) ( ( 0.0625 0 -0.1875 ) ( 0 0.0625 0.828125 ) ) "_default" 0 0 0
}
}
}

3.0

Version 2
// entity 0
{
"classname" "worldspawn"
// primitive 0
{
brushDef3
{
( 0 0 1 -64 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 1 0 -7.5 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 1 0 0 -7.5 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 0 -1 -64 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( 0 -1 0 -8 ) ( ( 0.0625 0 0 ) ( 0 0.0625 0 ) ) "_default" 0 0 0
( -1 0 0 -7.5 ) ( ( 0.0625 0 -0.1875 ) ( 0 0.0625 0.828125 ) ) "_default" 0 0 0
}
}
}

 

No extra 0's with a 1 on the end.

 

2.14:

 

3.0

[Nort]

Oh. So it's just "extra precision" then. ...but without actually having extra precision. It's still a bug, but not as disastrous as I thought.

[AluminumHaste]

Yeah, tag @OrbWeaver and @greebo

But this is the reason that they have beta tests for DarkRadiant, to catch things like this.

[greebo]

No harmful behaviour here, it's just a formatting issue, the underlying value doesn't differ.

The difference between 2.14 and 3.0 is the fmtlib version DR is using. It appears that the fmtlib update to version 8.1.1 introduced a change in formatting behaviour when omitting the format specifier. Explicitly setting the format specifier to "g" removes the rounding of the rightmost digits:

fmt::format("{0:g}", value)

 

[greebo]

And @Nort, I'd appreciate you editing your status update to clarify the situation, to not needlessly get people scared about map corruption.

[IZaRTaX]

I have the same issue

[greebo]

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

[Nort]

2 hours ago, greebo said:

And @Nort, I'd appreciate you editing your status update to clarify the situation, to not needlessly get people scared about map corruption.

Sure. I'll do that. Just understand that I was actually pretty scared there for a moment.

[greebo]

Thank you

[Nort]

Since this bug also affects the rotation step value, you actually lose the ability to enter such a value completely, and have to rely on direct input, or only rotate in 90 degrees, in order to rotate textures.

Hopefully solving this, will also solve the nasty effects I sometimes get when I use "Fit" with certain values, and the texture just becomes some kind of smear.