Factorio Forums

Minor Features

• Added string import/export to PvP config.

Changes

• Only item ingredients are automatically sorted in recipes.

Bugfixes

• Fixed LuaEntity::get_merged_signals() would always require a parameter. (58861)
• Fixed a crash related to mod settings losing precision when being saved through JSON. (58859)

Modding

• mod-settings.json is now mod-settings.dat - settings will be auto migrated.

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

mod-settings.json is now mod-settings.dat - settings will be auto migrated.

Does this mean we'll no longer be able to edit the mod settings file directly??

Is mod-list next in list?

FactorioBot wrote: Changes

• Only item ingredients are automatically sorted in recipes.

I was puzzled, when I loaded up my current factory, on why I wasn't getting any flamethrower ammo. I then noticed the inputs were reversed between light and heavy oil, so perhaps I had too many beers the day before while playing. Yet, I had ammo in my inventory that came from somewhere. Then it finally hit me that this recent change was probably the culprit. Now I have a feeling when I load up this build later today that I'll need to change it back again.

please, for the love of god, revert mod-settings.dat BACK to json.
it's uneditable now. so if changes are made that break something, you have to delete the whole damn thing

EDIT: have to revert to 0.16.31 until this is restored.

There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

FactorioBot wrote:

• mod-settings.json is now mod-settings.dat - settings will be auto migrated.

Wrong file!

Only item ingredients are automatically sorted in recipes.

I have no idea what that means... Anyone?

seePyou wrote:Only item ingredients are automatically sorted in recipes.

I have no idea what that means... Anyone?

They sorted all recipe items, which broke some recipes' inputs for liquids as the inputs used to be - say - water on the left and petrol on the right but flipped. So they flipped them back.

bobingabout wrote:There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

Which reason?

Prolly performance. But the issue now becomes that the mod configuration file becomes inaccessible to the common user - a tool would need to be written to access the file and make changes, then save the updated structure as that DAT.

Aeternus wrote:Prolly performance. But the issue now becomes that the mod configuration file becomes inaccessible to the common user - a tool would need to be written to access the file and make changes, then save the updated structure as that DAT.

I guessed they will encrypt all files after and after to open the door for paid DLCs...

steinio wrote:

bobingabout wrote:There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

Which reason?

My guess: The "Can't store 0.33333" in .json issue from 16.31(?).

eradicator wrote:

steinio wrote:

bobingabout wrote:There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

Which reason?

My guess: The "Can't store 0.33333" in .json issue from 16.31(?).

basically, the way binary is stored caused a loss of accuracy when converting between Binary (internal) and Decimal (.JSON), so they changed to .dat so they could store the Binary directly. 0.33333 is just one example of where it messes up.

system wrote:Is mod-list next in list?

That would suck. Especially for me...

bobingabout wrote:

eradicator wrote:

steinio wrote:

bobingabout wrote:There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

Which reason?

My guess: The "Can't store 0.33333" in .json issue from 16.31(?).

basically, the way binary is stored caused a loss of accuracy when converting between Binary (internal) and Decimal (.JSON), so they changed to .dat so they could store the Binary directly. 0.33333 is just one example of where it messes up.

That makes no sense to me.

If you work with float internally you have about 7 decimal digits precision, and with double you have about 16 decimal digits precision.

If you set the value to "0.03333333" then you have enough for float, while "0.03333333333333333" is enough for double. How far away (i.e., imprecise) is too much? Floating point numbers cannot hold precise numbers anyway. For instance, 0.1 cannot be represented and 0.9 also not.

Changing to a binary format is NOT the way to go in my opinion.

Sander_Bouwhuis wrote:

bobingabout wrote:

eradicator wrote:

steinio wrote:

bobingabout wrote:There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.

Which reason?

My guess: The "Can't store 0.33333" in .json issue from 16.31(?).

basically, the way binary is stored caused a loss of accuracy when converting between Binary (internal) and Decimal (.JSON), so they changed to .dat so they could store the Binary directly. 0.33333 is just one example of where it messes up.

That makes no sense to me.

If you work with float internally you have about 7 decimal digits precision, and with double you have about 16 decimal digits precision.

If you set the value to "0.03333333" then you have enough for float, while "0.03333333333333333" is enough for double. How far away (i.e., imprecise) is too much? Floating point numbers cannot hold precise numbers anyway. For instance, 0.1 cannot be represented and 0.9 also not.

Changing to a binary format is NOT the way to go in my opinion.

Also there is a standard for floating point numbers that dictate strict rounding rules and allow you to convert to decimal and back without any loss of precision. You just have to do it right and not simply cut of floats after 5 digits.

mrvn wrote:Also there is a standard for floating point numbers that dictate strict rounding rules and allow you to convert to decimal and back without any loss of precision. You just have to do it right and not simply cut of floats after 5 digits.

Is there? I don't know if factorio really uses bare C++ floating point types (and kinda doubt it), but either way, I'm sure it's easy to come close, but hard to truly nail this. And presumably, factorio needs (or at least wants) to really nail this, to avoid desyncs.

Cross-platform architecture-variant-independent round-trippable floating-point pretty-printing is hard AF to implement perfectly. Not saying it's an insurmountable problem, just wonder if maybe you're not quite aware of what a profound clusterfuck floats are in x86. I could easily see it taking a competent-man-month, or something in that ballpark (0.999999999999999999999999999999997 x 10⁰ competent-man-months? ), and a non-negligible hardware budget, to nail down 100% perfectly.

That stated, some liberally-licensed prior art surely exists, somewhere, from which the really tricky bits could be stolen.

golfmiketango wrote:

mrvn wrote:Also there is a standard for floating point numbers that dictate strict rounding rules and allow you to convert to decimal and back without any loss of precision. You just have to do it right and not simply cut of floats after 5 digits.

Is there? I don't know if factorio really uses bare C++ floating point types (and kinda doubt it), but either way, I'm sure it's easy to come close, but hard to truly nail this. And presumably, factorio needs (or at least wants) to really nail this, to avoid desyncs.

Cross-platform architecture-variant-independent round-trippable floating-point pretty-printing is hard AF to implement perfectly. Not saying it's an insurmountable problem, just wonder if maybe you're not quite aware of what a profound clusterfuck floats are in x86. I could easily see it taking a competent-man-month, or something in that ballpark (0.999999999999999999999999999999997 x 10⁰ competent-man-months? ), and a non-negligible hardware budget, to nail down 100% perfectly.

That stated, some liberally-licensed prior art surely exists, somewhere, from which the really tricky bits could be stolen.

It's actually quite trivial to implement. All it takes is to tell the compiler to use strict ieee floating point math and the right format string when printing them. The downside is that strict float behaviour disables a bunch of optimizations and has to constantly fix the x86s extra precision. So you would loose ups. On the plus side though you would gain cross architecture compatibility. E.g. if fatorio ever is ported to arm or powerpc or such then that becomes essential.

Personally where I needed to save/load floats in my microkernel for an RaspberryPI (no ieee conform printf()/scanf() for floats) I've decided to print them out in hexadezimal notation. That way you can print the exact bit pattern of the mantisse without the base 10 throwing in rounding errors. Neatly avoids the whole issue. E.g. 0x13a173E+1a. Saddly there is no standard for that.

They actually discussed floats and portability somewhere. I've misplaced the link, sorry. But they did mention that trig functions are not part of the IEEE spec and are nonportable. So they made their own ones.