Hello,
This week has been non-eventful. We are fixing bugs. There is not much to say, and I have updated the graph to reflect the status of the ongoing Dev vs. Bug war:
The massive spike is the specific crash we talked about in the last FFF.
We will be attending EGX Rezzed in 2 weeks. This week I have been finishing all the preparation work, such as furniture and equipment rental, accommodation, our itinerary etc. We will have a booth in the South Vault, with a couple of PCs for playing the game. If you are also attending be sure to pop by (We might have some free swag).
This will probably be the only conference we will exhibit at this year, as there is some non-trivial team effort in arranging our attendance, and we want to focus that effort into finishing 1.0. Saying that, each time we exhibit at a new conference we learn a lot, and its good to have a couple under our belt before deciding our post-1.0 event plans.
There were different kind of Splitter compression problems over the years and we had to apply more and more fine-tune tricks to keep it as good as possible in all the special cases, which became even more complicated with input/output priorities etc.
Our situation became worse in 0.16 by the fact, that we started to have the debug option of show-transport-line-gaps, which suddenly made even the smallest gap, previously unnoticeable, possible to be seen by the players. On top of that, once we made the gaps 0.25 of a tile in 0.17, even without the debug option, the circuit network can now easily notice any slight compression imperfection. This basically means, that the proper compression of a belt has more value.
When we encounter situations like this in the bug reports (and similar), we have to try to fix it.
In this situation for example, the timing of the incoming items allows the Iron plate to move through the Splitter, but in a way, that it is slightly further from the previous. The internal code is logical, but from the players perspective, it doesn't really make sense that adding an extra item on the input can make the output little bit less compressed.
There were a few different ideas of how to fix it. One of them was that the Splitter could basically have a tiny internal inventory that would work as a buffer. But due to the change to the logic and possible performance implications, we decided this idea isn't good enough.
The solution we settled on is actually quite simple. This is the way how Splitter worked before, it had 0.5 tile long ramps of inputs, and 0.5 tile long ramps of outputs.
So we just extended the input ramp by a little (+0.2 tiles) and used that extra length as a small buffer. With some extra logic to properly transfer the position of the items from input to output, this solution was able to solve all the little timing problems.
The only real change for players is that Splitters need 20% more items for the belt to be fully backed up which is kind of insignificant.
As you might remember, even if you've bought Factorio from Steam, in order to join multiplayer, the game asked you to register an account. We have the typical restrictions on username characters: alphanumerics and the characters ._-.
Back in December, one of our developers made a slight code edit that inadvertently made it possible to register an account from in-game without checking whether the username is valid... In two months we have gathered 1,945 registered accounts that don't conform to the intended restrictions. Things mostly work fine with arbitrary usernames, but one big problem is that it's impossible for server owners to ban people with spaces in their usernames!
Most people who registered an account like that intended no harm, but sadly we can't let arbitrary usernames stand, so they will be asked to change their username on factorio.com when they attempt to log in.
My apologies to users too sexy for your party, NOT THE BEES!!!!!, your mum lives in a tent, and ' or 1=1; --.
As always, let us know what you think on our forum.
