Factorio Forums

We are playing really big map and desync causes long pause because it generates 1GB+ report. How do i disable it?

You upload the desync report to the bug report forums and we fix the desync problem so it doesn't happen again.

Rseding91 wrote:You upload the desync report to the bug report forums and we fix the desync problem so it doesn't happen again.

Our desyncs are 'fixed for 0.15'. How do we disable desync reports for 0.14?

Edit: Fix typo

Xeanoa wrote:

Rseding91 wrote:You upload the desync report to the bug report forums and we fix the desync problem so it doesn't happen again.

Or desyncs are 'fixed for 0.15'. How do we disable desync reports for 0.14?

You can't and probably never will be able to.

Disassembly you say? Thought i'd never have to hack an app. Too bad.

Please let me know if you managed. I've lost all interest playing 0.14, waiting for about 5 minutes several times a session just breaks the spirit, and the inconvenience of trying to avoid them doesn't help.

Xeanoa wrote:Please let me know if you managed. I've lost all interest playing 0.14, waiting for about 5 minutes several times a session just breaks the spirit, and the inconvenience of trying to avoid them doesn't help.

You do realize that at a minimum if you do manage to disable the creation of desync reports (unlikely as you'd need to patch the server and all peers) you still have to reconnect and re-download after a desync?

If you give us the desync report we can fix the issue forever and then you never have to wait for a download or a desync report to be created.

If the bottleneck is the write speed (1 GB is kinda much), it is kinda possible to speed things up, I guess (I've tested this on small games).

I did it on ubuntu.
While the the game hangs up completely if it is unable to open file for writing (for example if the directory is readonly), which I'd say is a bug, it is possible to let it write to ram which should be fast. For this you'll probably have to sacrifice the amount of ram the size of the desync log. And ubuntu has tools to automatically remove those logs to free the space for the next ones.

So, in ubuntu I've opened the terminal in the factorio folder and then used the following commands: I got this knowledge from stack overflow, it also suggests alternative method, but I didn't fancy fiddling with kernel modules.

Guess on windows you could find equivalent tools but I'm of no help here.

Also, funnily, pretty much every I've traversed while searching "redirect directory to /dev/null" starts with "A particular program is making log files, I cant disable them and I want to prevent their creation" and among the discussion there's always "why on the earth someone would not allow to configure writing logs?"

I have a feeling write speed is not the reason it's slow. Otherwise they'd take only a few seconds. Usually it takes 2-3 minutes just for the report.

Adil wrote:If the bottleneck is the write speed (1 GB is kinda much), it is kinda possible to speed things up, I guess (I've tested this on small games).

I did it on ubuntu.
While the the game hangs up completely if it is unable to open file for writing (for example if the directory is readonly), which I'd say is a bug, it is possible to let it write to ram which should be fast. For this you'll probably have to sacrifice the amount of ram the size of the desync log. And ubuntu has tools to automatically remove those logs to free the space for the next ones.

So, in ubuntu I've opened the terminal in the factorio folder and then used the following commands:

Bash

These are preparations, if you have "archive" dir, just clear it. If you have inotify-tools you don't install them.

Code: Select all

sudo apt-get install inotify-tools
mkdir archive

This one makes "archive" to be in ram.

Code: Select all

sudo mount -t tmpfs -o size=1m tmpfs ./archive

The ram should be freed on the reboot, or with `sudo umount -a`, which worked good enough for me. I don't know more proper way, sorry.

The following sets up event handler, that removes files after their creation.

Code: Select all

inotifywait -m archive -e create | while read path action file; do rm "./archive/$file"; done;

That command takes up the particular terminal window and you can end it with ctrl-c, when done playing.

I got this knowledge from stack overflow, it also suggests alternative method, but I didn't fancy fiddling with kernel modules.

Guess on windows you could find equivalent tools but I'm of no help here.

Also, funnily, pretty much every I've traversed while searching "redirect directory to /dev/null" starts with "A particular program is making log files, I cant disable them and I want to prevent their creation" and among the discussion there's always "why on the earth someone would not allow to configure writing logs?"

We already do saving to RAM first and to disk at the same time. We use a 20 x 1 MB cycling buffer while saving. As pieces of the map are saved they're written into a 1 MB chunk of the buffer and when that chunk is full it's swapped over to the thread that in parallel is compressing and writing those chunks out to disk.

Our MODDED game is desyncing! Nobody fixes that!

cpy wrote:Our MODDED game is desyncing! Nobody fixes that!

Yes we do. The last few modded desyncs ended up being core-game desyncs with work arounds to prevent the desyncs until 0.15 is released.

Now this conversation is getting into a loop. And over a nothing, really. It's not like the addition of a switch will require a major rewrite that will severely impact the game fps or something.

Adil wrote:And over a nothing, really. It's not like the addition of a switch will require a major rewrite that will severely impact the game fps or something.

And now everyone has desync reports disabled. So desyncs don't get fixed. If you want to avoid descyns don't do the things that are causing the desyncs until they are fixed.

I fail to follow your logic.

Nexela wrote:And now everyone has desync reports disabled.

Why is that?
There are times to disable it and there are times when it doesn't hurt. Have it as a command line option and then only people who really need that will bother.
And even if it is disabled. So what? It's their choice.

Nexela wrote:So desyncs don't get fixed.

Not to mention that a mere creation of the log doesn't mean anything. It ain't gona send itself without the user.

I'm not uploading 1400MB desync logs because of some power pole placement with HEAVILY modded and scripted game!

Quote from modded bug report forum:
Desyncs in modded game will be ignored most of the time, until it is clearly proven that the desync is not caused by scripting.

So there you have it. Let us disable all reports with mods detected and everyone will be happy. Do you even know how long that friggin report generates?

How about you fix the cause of the desync then?

If it's caused by the base game, file a bug report.
If it's caused by a mod, complain to the author.
If it's caused by a piece of code you wrote yourself and have no idea how to fix it, ask in the modding help forum.

If you could disable desync reports, desyncs would still be annoying, just slightly less so. Seems better to fix the cause.

cpy wrote:I'm not uploading 1400MB desync logs because of some power pole placement with HEAVILY modded and scripted game!

Just deleted 12 GiB of logs on my second machine because I was running out of disk space. It only has a 120 GiB SSD. At least they should not stay there infinitely.