Version 0.16.32

Information about releases and roadmap.
User avatar
FactorioBot
Factorio Staff
Factorio Staff
Posts: 405
Joined: Tue May 12, 2015 1:48 pm

Version 0.16.32

Post by FactorioBot »

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.

User avatar
ChurchOrganist
Filter Inserter
Filter Inserter
Posts: 256
Joined: Sun Apr 17, 2016 12:45 pm
Contact:

Re: Version 0.16.32

Post by ChurchOrganist »

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??
Want to know where the biters chewing your power plant have come from??
Wondering where your next iron is going to come from??
You need Long Range Radar

system
Long Handed Inserter
Long Handed Inserter
Posts: 67
Joined: Tue Oct 18, 2016 3:05 pm
Contact:

Re: Version 0.16.32

Post by system »

Is mod-list next in list?

User avatar
_alphaBeta_
Inserter
Inserter
Posts: 45
Joined: Fri Jul 29, 2016 3:27 am
Contact:

Re: Version 0.16.32

Post by _alphaBeta_ »

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. :D 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.

usafphoenix
Long Handed Inserter
Long Handed Inserter
Posts: 58
Joined: Sun Aug 06, 2017 9:42 am
Contact:

Re: Version 0.16.32

Post by usafphoenix »

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.

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 7351
Joined: Fri May 09, 2014 1:01 pm
Contact:

Re: Version 0.16.32

Post by bobingabout »

There is a reason for the change, but I agree, having it as .json is nicer than having it as a .dat.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

User avatar
Gergely
Filter Inserter
Filter Inserter
Posts: 595
Joined: Sun Apr 10, 2016 8:31 pm
Contact:

Re: Version 0.16.32

Post by Gergely »

FactorioBot wrote:
  • mod-settings.json is now mod-settings.dat - settings will be auto migrated.
Wrong file!

seePyou
Long Handed Inserter
Long Handed Inserter
Posts: 98
Joined: Mon Apr 03, 2017 3:17 pm
Contact:

Re: Version 0.16.32

Post by seePyou »

Only item ingredients are automatically sorted in recipes.

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

User avatar
5thHorseman
Smart Inserter
Smart Inserter
Posts: 1193
Joined: Fri Jun 10, 2016 11:21 pm
Contact:

Re: Version 0.16.32

Post by 5thHorseman »

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.

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2632
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Version 0.16.32

Post by steinio »

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

Transport Belt Repair Man

View unread Posts

Aeternus
Filter Inserter
Filter Inserter
Posts: 835
Joined: Wed Mar 29, 2017 2:10 am
Contact:

Re: Version 0.16.32

Post by Aeternus »

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.

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2632
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Version 0.16.32

Post by steinio »

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... :P
Image

Transport Belt Repair Man

View unread Posts

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Version 0.16.32

Post by eradicator »

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(?).

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 7351
Joined: Fri May 09, 2014 1:01 pm
Contact:

Re: Version 0.16.32

Post by bobingabout »

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.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

User avatar
Gergely
Filter Inserter
Filter Inserter
Posts: 595
Joined: Sun Apr 10, 2016 8:31 pm
Contact:

Re: Version 0.16.32

Post by Gergely »

system wrote:Is mod-list next in list?
That would suck. Especially for me...

Sander_Bouwhuis
Filter Inserter
Filter Inserter
Posts: 292
Joined: Mon Dec 07, 2015 10:45 pm
Contact:

Re: Version 0.16.32

Post by Sander_Bouwhuis »

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.

mrvn
Smart Inserter
Smart Inserter
Posts: 5686
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Version 0.16.32

Post by mrvn »

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.

golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:

Re: Version 0.16.32

Post by golfmiketango »

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? :lol:), 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.

mrvn
Smart Inserter
Smart Inserter
Posts: 5686
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Version 0.16.32

Post by mrvn »

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? :lol:), 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.

henke37
Long Handed Inserter
Long Handed Inserter
Posts: 91
Joined: Mon Jul 18, 2016 5:43 pm
Contact:

Re: Version 0.16.32

Post by henke37 »

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.

Post Reply

Return to “Releases”