Belt compression
The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities:
- Splitters are the only way to reliably compress a belt.
- Compression is automatic everywhere (inserters, sideloading, mining drills).
Non-automatic belt compression is kind of an nice example of emergent gameplay mechanic that I liked. It was not forced on players, but it allowed to get some extra efficiency if they cared enough. On other hand, the solution to the problem is kind of obvious, and having to use it in all the setups everywhere might add more repetitiveness than fun. So after some discussions, we decided to make compression automatic.
But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it:
The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now.
The result is, that the same setup in 0.16.25+ results in perfectly compressed belt:
The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result.
Crash log uploading
Introduction
Since 0.16.24, Factorio uploads its crash log to us whenever it crashes (This can be disabled from the options menu).
For a very long time we wanted to be able to do this. I would often say that the crash reports we get in the Bug reports forum are a very small percent of the actual crashes, and that we don't really know what is important or not unless there is a major bug that many people report. This was proven to be true after releasing 0.16.24. We had received hundreds of crash logs but nothing was posted in the forum and we quickly found a major problem and fixed it.
The way it works is that when Factorio crashes and a crash log was generated, in its dying moments it starts a new process that tries to upload factorio-current.log (and in some rare cases factorio-dump-current.dmp). Once on our server, we parse the stack trace from it and organize it with identical crash logs into folder. This way we can know which crashes occur more often, and allow us to prioritize more effectively. Our interface looks something like this.
So far it has proven to be very useful. In just 2 days Rseding fixed about 12 crashes that were found by our reporting tool, none of which were reported on the forum.
This does not mean you should stop reporting crashes on the forum. If anything it means you should report them more often. We very often need more information about the crash, such as steps to reproduce or a save game, but we have no way of contacting the person that uploaded the crash. So please continue to report crashes in the Bug reports forum.
Privacy concerns
Of course you can't mention the words "uploads data to our server" without some people being concerned about privacy. So I will try to address any uneasiness and apprehension about this new system by being completely transparent.
The log only contains basic system information (CPU, GPU and free memory), game display settings, operation log, crash stack trace for the main thread and in some rare cases a minidump. We send that information (if you didn't opt out), in our binary format, securely, through HTTPS to one of our servers. In the next version we even sanitized the log a bit so it does not contain anything that might be seen as a privacy breach, such as IP addresses. We also updated our EULA and included it in the game to mitigate any legal issues.
Even will all of this some people think that we are doing something wrong. To paraphrase what kovarex said: "The games I played send all kinds of data and they don't allow me to opt out, now we do it and are transparent about it and we are the bad guys?"
A few people mentioned we should make it opt-in not opt-out. Unfortunately this won't work, since very few people will actually check the options and alter the default behaviour, this means we will be back to square one where we rarely know what crashes happen and how often they happen.
Another idea was to have a prompt asking if you wish to upload the log or not, after every crash. Apart from the extra implementation time, players will still often click "Don't send", either because that's what they have been doing for many years or because they just want to quickly get back in the game or because they feel that the crash was somehow their fault.
This is an invaluable tool that helps us make the game much more stable and provide a great experience to everyone, while sending very little information to us. If you don't trust us you can of course opt out.
The mysterious Ryzen issue (aka memory corruption/cpu corruption/bad hardware/not our fault for sure)
The second most common crash that was reported in 0.16.24, with 61 unique crashes, was a mysterious crash in EntityRenderer::prepareRow. It's one of those crashes that pops up on the forums every few months, we are unable to find the cause, so we end up not fixing it. Some of us often blame it on memory corruption or CPU error, but I'm often the sceptical person saying that we can't use this excuse every time we can't find the cause of a crash.
Now that we have the crash uploading tool, we can do more. First of all we noticed that 100% these crashes were on an AMD Ryzen CPU. Even with all the crash logs we would still not figure out what was going on. So in 0.16.25 we started uploading minidumps when the EntityRenderer::prepareRow crash occurs. The few minidumps we received are still very strange and we are unable to figure out what is going wrong, with the easiest scapegoat being to throw the blame on bad hardware. This will probably be one of those bugs that will haunt us for some time...
As always, let us know what you think on our forum.