[2.0.20] Correct the quality tooltips and other rounded information

[Romayne]

TL;DR

Tooltips/Entries explaining effects of buildings with quality, such as resource drain, should show the real value or state that it's approximate, rather than claim to be the exact value.

What?

"Big Drills can extract 12.5x more resources from an ore patch than a regular mining drill" is a false statement.
I made this statement (or approximately thereof), and was swiftly corrected and linked to a repository which shows the actual truth: It's 12x more resources.

https://github.com/wube/factorio-data/b ... ty.lua#L54

(1/6th of the 50% drain, so, 1/12th -- which is 0.083333.. in decimal form. And, consequentially, it is rounded to 8%.)

So how could I be wrong? How could I make such a statement and be so confidently incorrect? Well, the way I, as a player, saw it, was like so:

The game reports the resource drain to be 8% for legendary big drills. With the way drain reduction works, this means that the total extra resources a drill extracts should be easily found by doing 1 divided by the decimal amount of drain. So 1/0.5 for a regular drill for 2x, 1/0.41 for ~2.44x, and so on, until I did 1/0.08 for 12.5x. The only issue is that the game is lying to my face.

What I should see as a player is one of two things:
1. The game has a little apostrophe next to the value, and some disclaimer of 'values only approximate' somewhere I can see it. That way, I can see the game giving me a heads up of 'hey, this is just a guesstimate, it's not actually the full value."
2. The game shows the full and exact value to the best of its ability. If it's 1/3 the resource drain, instead of saying 33%, it says 1/3.

Why?

Like, why does this matter, right? This is just some big nerd rambling about some minor detail. Nobody really cares if their drills actually mine 0.5x less than they think, nobody's going to see that.

The problem this presents is that I can no longer trust the game to provide me with correct information, because there is no way to know if some statistic is true unless I verify it myself. This does not just break trust for big drills as shown, I no longer feel like I, the player, can trust ANY decimal value I see. The entire factoriopedia becomes moot, because I have to go onto the wiki, or some github repository, or wherever else to get the truth. And this happens because all values in this format can get this treatment, not just big drills.

Sure, if there was "values only approximate" I would still need to wiki, but at least the game would provide valuable information on what to trust and what not to. And sure, the difference is minor, but in a game where every machine plays a part, small factors add up until you can't ignore them anymore.

[BlueTemplar]

It would probably be close enough if the game gave 3 significant figures ?
So in this case :

Code: Select all

50(.0)%
41.7%
33.3%
25(.0)%
8.33%

(Not sure about the .0 for the exact values...)
?

See also :
viewtopic.php?f=6&t=119765

[Romayne]

It would probably be close enough if the game gave 3 significant figures ?
So in this case :

Code: Select all

50(.0)%
41.7%
33.3%
25(.0)%
8.33%

(Not sure about the .0 for the exact values...)
?

See also :
viewtopic.php?f=6&t=119765

Almost, but I also would want to see a trailing decimal to indicate there are more digits beyond what is shown. Something more like:

Code: Select all

50%
41.666..%
33.333..%
25%
8.333..%

and then a disclaimer in potentially smaller text of 'Values might not be exact.'

[LCStark]

Almost, but I also would want to see a trailing decimal to indicate there are more digits beyond what is shown. Something more like:

Code: Select all

50%
41.666..%
33.333..%
25%
8.333..%

and then a disclaimer in potentially smaller text of 'Values might not be exact.'

BlueTemplar almost got it right:

Code: Select all

50%
41.(6)%
33.(3)%
25%
8.(3)%

Though I think you're right, the ellipsis representation might be better for quick and easy understanding for everybody. The parentheses way isn't taught everywhere around the world.

[BlueTemplar]

It would probably be close enough if the game gave 3 significant figures ?
So in this case :

Code: Select all

50(.0)%
41.7%
33.3%
25(.0)%
8.33%

(Not sure about the .0 for the exact values...)
?

See also :
viewtopic.php?f=6&t=119765

Almost, but I also would want to see a trailing decimal to indicate there are more digits beyond what is shown. Something more like:

Code: Select all

50%
41.666..%
33.333..%
25%
8.333..%

and then a disclaimer in potentially smaller text of 'Values might not be exact.'

Ah, yes, that would be even better, but (weirdly enough,) I'm just not expecting too much here...

[Romayne]

Almost, but I also would want to see a trailing decimal to indicate there are more digits beyond what is shown. Something more like:

Code: Select all

50%
41.666..%
33.333..%
25%
8.333..%

and then a disclaimer in potentially smaller text of 'Values might not be exact.'

BlueTemplar almost got it right:

Code: Select all

50%
41.(6)%
33.(3)%
25%
8.(3)%

Though I think you're right, the ellipsis representation might be better for quick and easy understanding for everybody. The parentheses way isn't taught everywhere around the world.

Well, I never have seen ellipsis representation, nor do I know which one is more popular -- I was simply taught the trailing dots kind of notation in school. Whichever one is more understandable to the majority of players should definitely be used, though.

[Tinyboss]

Three decimals is fine, no need to indicate when THAT isn't exact. If you see .333 or .667, you know what's up. And even if it's some random looking value, who really cares if it's off by a few ten-thousandths?

8.(3)%

That's not going to be possible without some smart code that represents values as actual fractions all the way through the calculation. If you multiply a few floating point numbers together, you're not going to have all 3's after the decimal, even if that's the right answer. Errors accumulate.

[DefGie]

If 1/12 is in fact correct, I completely agree. Your "why" argument is sound.

How does the internal logic of the game process the 50%*1/6 resource drain (rhetorical question)? Seems likely it would not use a symbolic/fractional representation, but a computed decimal (or rather binary) value. Maybe the same rounding occurs before any gameplay logic is applied to the resource drain factor and 8% is in fact correct. This sounds the most probable to me.

If it is truly 1/12, putting (50%*1/6) after the 8% would work ok, as a workaround to avoid defining tables of actual value for quality tiers of actual entities. When the game provides definitive numbers for factory performance they should be definitive.

As an aside, I feel like it's weird that this is defined on the quality prototype and not per-quality on the entity prototype.

[Jap2.0]

Going off the first post, even a consistent 2 significant figures would be an improvement.