Modules of different levels and qualities need to be adjusted to be more consistent

[Smudgius]

The effects of different quality and level modules are highly inconsistent. Let me illustrate:
A rare (blue) one dot production module is better or equivalent to a normal two dot production module in every way. (same production bonus, less power used, less pollution, less speed penalty).
A rare two dot speed module gives (slightly) less speed than a normal three dot speed module.
A rare two dot quality module is flat out better than a normal 3 dot quality module - and exactly equivalent to a green three dot quality module.

To clarify: The issue isn't about whether modules are balanced or work as intended or any of that - but that there needs to be more standardization - either a green or blue (or whatever color) should always be better than the next tier normal upgrade, or it shouldn't - its a little frustrating to have to scrutinize every single module to see whether I am better off using a green two dot or a normal three dot, etc etc. I should be able to KNOW that a blue of this level is better than an X of that level.

P.s. LOVING Space Age - absolutely fantastic, great job dev team!

[Aricitic]

To add to this there is a discrepancy with the difference in quality bonus for Quality Modules themselves. I noticed this as I was doing basically the same as the OP.

For a Quality Module (1) the difference in all tiers (except Legendary) is 0.3. For Quality Module 2 the difference in all tiers (except Legendary is 0.6. However, for Quality Module 3 the difference in tiers is as follows: Normal to Uncommon: 0.7; Uncommon to Rare: 0.8; Rare to Epic: 0.7.

For clarity, I have no problem with the difference increasing, however, as this is ONLY done for Quality Module 3 and Productivity Module 2 (N-U: 1; U-R: 2; R-E: 3), it may be that some miscommunication occurred. I don't know, I'm not part of the team, so I have no idea how things are done and/or communicated, but discrepancies like this are often unintentional...

EDIT: Also of note: This is NOT a "bug report." It's merely an observation.

[Stargateur]

At least I think a rare module 3 shouldn't be worse than a legendary module 2.

Giving the current data, in my next run I would clearly go all legendary module 2 before craft any module 3.

[computeraddict]

However, for Quality Module 3 the difference in tiers is as follows: Normal to Uncommon: 0.7; Uncommon to Rare: 0.8; Rare to Epic: 0.7

This is display rounding iirc. The bonus has two digit precision but the display only has one digit precision and omits the 0.05 tail on some values.

[Aricitic]

However, for Quality Module 3 the difference in tiers is as follows: Normal to Uncommon: 0.7; Uncommon to Rare: 0.8; Rare to Epic: 0.7

This is display rounding iirc. The bonus has two digit precision but the display only has one digit precision and omits the 0.05 tail on some values.

I hope everyone will forgive me the following line of inquiry (i.e. forgive me for asking more questions and looking more into it)...

A difference in rounding the same number for any programming language sounds like a serious issue. And before anyone tries to tell me that they are different numbers, what's being rounded isn't 2.55 or 2.45; 3.25 or 3.15; 4.05 or 3.95; and 4.75 or 4.65 are not the numbers being rounded... 0.05 (or 0.n5 where 'n' is any number of consecutive zeros) is the number being rounded.

Out of curiosity, I decided to check what language Factorio is programmed in. It appears that the backend is programmed in C++ and there is a Lua interface above that (for modding, GUI -I assume-, etc). So I looked up the rules for rounding for both; in the case for both C++ and Lua anything 5 and above rounds up and anything 4 and below rounds down.
Additionally, it isn't uncommon to have multiple programming languages in any given program. Unity uses C++ for its backend with a C# interface, as one example. In these cases there are interfaces for both languages programmed in their respective languages to handle interactions with other languages. And even ignoring that all that's being passed in this instance is a double or a float (I assume).

If that's the case then this poses a (likely) serious issue. 0.5 (or 0.n5) should always round up. Any number higher than a 5 should do the same, any number lower should round down. That the display interface is somehow interpreting the same rule for the same number differently is bad... It goes from being a "curiosity" to a "bug." Perhaps an "isolated" bug, but one none the less.

Additionally, out of pure curiosity, I did a quick Google search for "Display rounds differently for the same number for different instances" -- which is obviously a "bad" search term, but, w/e... -- and the results yielded people asking how to specify the digit to round to...


Finally, the display rounding issue doesn't explain why Productivity Module 3 is the only module whose quality differences increase in value as quality increases...


Surely I'm not understanding something. I went to college for programming, but that was some time ago and I (sadly) haven't really been able to use it since then.

[BorisOZ]

However, for Quality Module 3 the difference in tiers is as follows: Normal to Uncommon: 0.7; Uncommon to Rare: 0.8; Rare to Epic: 0.7

This is display rounding iirc. The bonus has two digit precision but the display only has one digit precision and omits the 0.05 tail on some values.

I hope everyone will forgive me the following line of inquiry (i.e. forgive me for asking more questions and looking more into it)...

A difference in rounding the same number for any programming language sounds like a serious issue. And before anyone tries to tell me that they are different numbers, what's being rounded isn't 2.55 or 2.45; 3.25 or 3.15; 4.05 or 3.95; and 4.75 or 4.65 are not the numbers being rounded... 0.05 (or 0.n5 where 'n' is any number of consecutive zeros) is the number being rounded.

Out of curiosity, I decided to check what language Factorio is programmed in. It appears that the backend is programmed in C++ and there is a Lua interface above that (for modding, GUI -I assume-, etc). So I looked up the rules for rounding for both; in the case for both C++ and Lua anything 5 and above rounds up and anything 4 and below rounds down.
Additionally, it isn't uncommon to have multiple programming languages in any given program. Unity uses C++ for its backend with a C# interface, as one example. In these cases there are interfaces for both languages programmed in their respective languages to handle interactions with other languages. And even ignoring that all that's being passed in this instance is a double or a float (I assume).

If that's the case then this poses a (likely) serious issue. 0.5 (or 0.n5) should always round up. Any number higher than a 5 should do the same, any number lower should round down. That the display interface is somehow interpreting the same rule for the same number differently is bad... It goes from being a "curiosity" to a "bug." Perhaps an "isolated" bug, but one none the less.

Additionally, out of pure curiosity, I did a quick Google search for "Display rounds differently for the same number for different instances" -- which is obviously a "bad" search term, but, w/e... -- and the results yielded people asking how to specify the digit to round to...


Finally, the display rounding issue doesn't explain why Productivity Module 3 is the only module whose quality differences increase in value as quality increases...


Surely I'm not understanding something. I went to college for programming, but that was some time ago and I (sadly) haven't really been able to use it since then.

It's not rounding the same number differently, though.

The actual values for quality module 3 are as follows: 2.5%, 3.25%, 4.00%, 4.75%, 6.25%.
The values in the display are rounded down (technically incorrectly) to the following: 2.5%, 3.2%, 4%, 4.7%, 6.2%

As for productivity module 2, the numbers you mentioned are not what's in the game.
The actual values are as follows: 6.0%, 7.8%, 9.6%, 11.4%, 15.0%
The numbers displayed (again, rounded down, which is technically incorrect for some of them) are 6%, 7%, 9%, 11%, 15%

There are a few possible reasons for this, the simplest being that they just truncate the value in the display rather than rounding.

Each quality tier adds 30% to the base value, except legendary, which adds 60%.
I.e., Uncommon = x1.3, Rare = x1.6, Epic = x1.9, Legendary = x2.5, so the bonuses are the same for each tier.

At least I think a rare module 3 shouldn't be worse than a legendary module 2.

Giving the current data, in my next run I would clearly go all legendary module 2 before craft any module 3.

Why not? Legendary is much harder to obtain than rare, even with a tier difference. For all modules, a tier 1 legendary module is the same, if not better than a tier 3 common.
This makes sense because a) legendary is locked behind late-game research
b) Legendary modules are harder to get (more resources spent)

[Aricitic]

It's not rounding the same number differently, though.

The actual values for quality module 3 are as follows: 2.5%, 3.25%, 4.00%, 4.75%, 6.25%.
The values in the display are rounded down (technically incorrectly) to the following: 2.5%, 3.2%, 4%, 4.7%, 6.2%

As for productivity module 2, the numbers you mentioned are not what's in the game.
The actual values are as follows: 6.0%, 7.8%, 9.6%, 11.4%, 15.0%
The numbers displayed (again, rounded down, which is technically incorrect for some of them) are 6%, 7%, 9%, 11%, 15%

There are a few possible reasons for this, the simplest being that they just truncate the value in the display rather than rounding.

Each quality tier adds 30% to the base value, except legendary, which adds 60%.
I.e., Uncommon = x1.3, Rare = x1.6, Epic = x1.9, Legendary = x2.5, so the bonuses are the same for each tier.

It is rounding the same number though. As stated in my previous post (I hope, I did have to rewrite it), the rounding isn't happening on the 2.5, the 3.2, the 4.0, the 4.7, or the 6.2; it's happening on the 0.00, the 0.05, the 0.00, the 0.05 and the 0.05 (ok, technically the same two numbers). Rounding, as I understand mathematics, happens on the final relevant digit, and disregards all other numbers. If you are rounding to the 'nth' decimal it will take the 'nth+1' decimal, determine if it is above or below 5, and change the preceding decimal if necessary.

So, based on the information you are providing the rounding is happening on either a 5 or a 0. 0 twice and 5 three times.

That's what I meant, and thank you for the clarification for what you meant.
Also, truncating it would certainly explain the "rounding error."


Secondly, you are taking the wording I used a little too literally. I truncated what I typed to save time and space.

What I said was: "For clarity, I have no problem with the difference increasing, however, as this is ONLY done for Quality Module 3 and Productivity Module 2 (N-U: 1; U-R: 2; R-E: 3), it may be that some miscommunication occurred. I don't know, I'm not part of the team, so I have no idea how things are done and/or communicated, but discrepancies like this are often unintentional..."
The key points are: "the difference increasing" and "N-U: 1; U-R: 2; R-E: 3".

The numbers you provided are what the text says, I'm not disputing that, but I wasn't writing what the text said, I was writing the difference between "Normal to Uncommon" (7-6 = 1), "Uncommon to Rare" (9-7 = 2), "Rare to Epic" (11-9 = 3). I'm pointing out that the change between each is greater than '0', whereas all other module's have zero change between their modifiers (for the sake of brevity I'll use the previously mentioned Quality Module 3): "Normal to Uncommon" (3.25-2.50 = 0.75), "Uncommon to Rare" (4.00-3.25 = 0.75), "Rare to Epic" (4.75-4.00 = 0.75).

Clearly, the difference in the change for Productivity Module 2 increased by 1 each time the quality increased, and for Quality Module 3 it did not increase at all. I have also verified that this is true for all other modules, and that is my point here.


Finally, I'm not trying to say anything you have said is specifically wrong... merely that we are miscommunicating, hence the (attempt at) clarification above. (also, please note that it is currently 1:06 AM where i am and I was just about to try to go to sleep, so my writing may not be as clear - etc - as I would prefer.)