That's the root issue of why it's currently using so many digits: because the conversion just doesn't work correctly when going binary -> string -> binary. I kept upping the number of digits until I gave up on it and just changed the mod-settings.json file to mod-settings.dat at which point the iss...

On an unrelated note the trio regression suite shows that the modifications you've made causes the following test case to fail string.format("%#11.5g", 10e5) It produces the output 1.00000e+05 (which has 6 significant digits) instead of the expected output of (space)1.0000e+05 (with has 5 ...

That ain't no long double. This change breaks the formatting of doubles which rely on having more precision than a double to work.

There are two issues caused by this. The first is that the JSON is longer, in Clusterio for example the JSON is passed on to other instances and this being sent over commands causes the operation to take longer and more bandwidth. The second is that there's floating point values for which the encodi...

The command /c game.print(game.table_to_json{v=1/3}) Prints out {"v":0.333333333333333303727386009995825588703155517578125}, which is excessively many digits for a number with no more than 16 significant digits. The output looks like the exact form of a double precision number, but it's no...

Still happens on a semi regular basis on 0.17.79. It would be easy to add code that for example dumps a back trace of all threads when this is detected to happen.

These rules don't seem to be written down anywhere. Where do I go to learn about rules like this one about the use of the API?

The following code cases the game to be un-savable even though script local variables are not saved:

If I put them in the wrong folder please tell me what folder I'm supposed to put them in. These are the steps I've done on Linux: # In the factorio headless folder. mkdir -p scenarios/broken/ echo "print('======== original')" > scenarios/broken/control.lua bin/x64/factorio --start-server-l...

That is one way to view what is a desync. I have a more pragmatic view where I consider the game desynced when the state between the server and the client is uncontrollably diverging. If you were to take the "data on one client is different to data on another client" to its logical extreme...

Well, here's a Proof of Concept Scenario Script that does exactly what I'm suggesting and guess what it doesn't instantly desync. Is this wrong? Maybe, but this definitively demonstrates that what I'm suggesting not only is possible , it works just fine (even with heavy mode on!). (Please note that ...

Yes, I know very well that doing any action that affects the vast majority of the game state from a value returned by such an API will desync the game, but as clarified in this bug report GUI state is too expensive to CRC check and can therefore differ between client and server without desyncing the...

There's nothing wrong with run time subscription of events so long as you keep track of which events you have subscribed to and make sure the same events are subscribed to in on_load. You would be removing a useful feature if you prevented this. As for the admin check I really, really don't understa...

Are you saying you can't make game.kick_player kick the player regardless of how it's run? That seems strange. Having the option to let everyone run commands also seems a little strange if you consider it above admin.

Certain script action like game.kick_player requires the execution context to be a player that is promoted to admin. This makes absolutely no sense as the only way you can execute game.kick_player() is if you have permission to run commands, or if you clicked on a custom script GUI which does it for...

Not sure if this is strictly speaking a bug, but if you create GUI elements with properties that are different on the server and the client the game does not desync, (see example script below.) Not even the type matters. If you as in the example script below create a flow on the server and a button ...

Running /c game.reload_script() on a dedicated server started with --start-server-load-scenario with no players online and auto_pause configured to false causes the server to crash. See the attached log. The documentation for reload_script is also incredibly vague stating only "Forces a reload ...

An alternative to this proposal would be having an on_start event that is triggered when the server (or single player game) is started, and happens after on_load/on_init/on_configuraiton_changed but before any other event. My patched in scenario code could then use that event to initialize variables...

I agree that the 2-4 ticks of latency introduced by bunching up ticks into pairs is by design, but thinking about this more there's something about those 4 or so unaccounted ticks of latency in the system here that doesn't make sense. There seems to be parts of the client that is holding on to tick ...

When connecting over a gigabit lossless sub-millisecond latency link the game reports a jaw dropping 7-9 ticks of latency between the server and the client (this is looking at the show-multiplayer-statistics measure enabled from the debug menu.) At first glance it might not sound like much but it wo...