Posted by Wheybags, Rseding, Dom, Albert on 2019-03-29

Removing RTL language translations Wheybags

I'm sorry to say that we have removed the RTL language translations (Hebrew and Arabic) in 0.17.20.

Until this point we've had a half implementation of RTL languages, where the text is simply flipped when we download it from Crowdin. This 'works' for a decent proportion of things, but not nearly 100%. In order to attain the level of polish we want for the 1.0 release, we would need to spend a lot of time implementing proper support for RTL layouts. This just doesn't make sense for us given our current goals, and the proportion of our player base which uses these languages (less than 0.1%). We decided that instead of completely gutting the translations, we could leave them in for those who enjoy them, but not to offer them in the GUI as defaults.

The languages will remain up on Crowdin, and the locale files will still be present in game, but there will be no option in the in-game language options dialog to choose them. If you want to use an RTL language, you will have to manually edit your config file to set your locale. Detailed instructions are available on our forum. What this also means, is that we won't be investigating any bug reports about RTL issues.

Interesting bug reports Rseding

Years ago when I was just getting into the programming field I was told by others that someone typically starts in the QA/bug tester positions and if they prove themselves can move on to do the "fun" work. That implies that the QA/bug tester positions aren't fun and that I should look forward to being done with those tasks. It was 4 years, 7 months, and 8 days ago (as of writing this) that I asked Kovarex about possibly letting me help fix bugs in Factorio and today bug fixing is my 2nd favorite part of working on Factorio (with optimizations taking first place).

The weirder and more difficult a bug is to track down the more I enjoy working on it and finally seeing it resolved. Naturally as I've spent so much time working on bug fixes (in the same code base - and always going for the difficult ones) I've gotten quite good at it. One of the fun parts of fixing the difficult bugs is putting the reproduction steps in the changelog and watching peoples reactions when they read the patch notes for that release.

Some of the more interesting ones from the 0.17 bug fixing so far:

The game would crash when bringing up the escape menu in multiplayer while in the middle of using blueprints/deconstruction planners then releasing the mouse button.

The game GUI would be hidden if the game was saved and loaded while the technology GUI was open.

Resizing the window while loading on 4k screens would cause the loading progress bar to not render (but text still worked fine).

The game would crash when removing the target rail of a temporary train order if the target rail was a dead end.

The game would crash if you opened the update-mods GUI, weren't signed in, then closed the sign-in prompt, clicked refresh, signed in, left the update-mods GUI, and came back to it (found from automatic crash logs).

The game would crash if the open GUI target become invalidated during the same tick as autosave starting (found from automatic crash logs).

The game would crash when trying to open the set-filter GUI on the ammo inventory of another player opened using the /open command (found from automatic crash logs).

The game would crash when if you re-joined a multiplayer game that you lost connection from while the tips-and-tricks window was showing (found from automatic crash logs).

The game would crash when accepting a Steam game invite if a previous attempt to manually join a multiplayer game was in progress. (found from automatic crash logs).

The game would crash when loading if you had a modded save with 2 different assembling machines with 2 different fluid recipes that both migrated to different recipes with different amounts of fluid inputs/outputs (found from automatic crash logs).

Most of these where ~10 line fixes but the reproduction steps took anywhere from a few hours to a day.

They still haven't beaten the best ones we've had previously:

The game would crash when clicking "Restart" from a running game if the new game happened to be created at the exact same memory address as the old game.

The multiplayer map transfer logic would get stuck forever trying to send the last packet if the CRC for the packet happened to be a specific value that some routers interpreted as bad/invalid/flagged to be dropped.

And finally the best: The game crashes randomly inside heavily threaded rendering logic if you have an AMD Ryzen CPU with older chipsets drives and BIOS. We still get crash reports from this one - a handful with each release. The fix for this one is simple: update the chipset drivers and BIOS. It's common enough that we'll most likely add a special message if we detect it happening. See this forum post.

Overall bug fixing is going well. We had a rough release earlier this week related to some GUI logic not working correctly. In the past we've talked about our automated test system (FFF-186) which normally tests game logic. With the rough release earlier this week it pushed me to get the test system in a shape where we can run automatic graphics tests (in hopes of avoiding the issues we had during the 2 broken versions). We still have a few small things to fix but otherwise the automatic test system can now run the full graphics interface while running the tests (in parallel). Just for fun, I set it up so it would arrange the windows in a grid:

New remnants for almost everything Dom, Albert

Since forever, when killing an entity we used generic remnants (with a few exceptions, walls, rails...). We only cared about the size of the entity and it is done.

This is an okay solution, but we want more specific and natural remnants, so it is possible to recognize which entity was destroyed. That’s not really super necessary because ghosts are normally providing this information, but we are polishing the game and making everything nicer when possible. So we started experimenting with the small electric poles.

We realised how simple things can become complicated in no time with Factorio. For starters, the old generic remnants are very flat because the character can walk on top them and they have no collision box. Also they are moved from the objects layer to the corpse layer which is rendered under it. Now that we want more specific and custom remnants for entities, sometimes we need to grow in the Z-axis, which can result in something like this:

No big deal, we just need to keep the remnants in the object layer and everything is solved. The new problem is the sorting of the objects layer. Factorio renders the objects from top to bottom and from left to right. Meaning that objects on top are covered by objects below them, and objects on the left are covered by objects to their right. So we need to be very careful with remnants invading tiles not assigned to them. This makes the composition more difficult because this can happen:

In this case we were lucky, because that looks nice, but in the other direction we wouldn’t be so lucky. With more heavy remnants like nuclear reactor or oil refinery, we are not going have this happy accident anymore. Of course we will try to make these happy accidents possible with any setup, but allow me to be skeptical in this regard.

No big deal again, we just stay in our assigned tiles and we’re safe. But our chaotic composition of destruction starts to be pretty much like an Ikea assembly kit. Everything in place almost as it was before. But we still have the Z-axis let’s use it.

Well, remember that the player can walk through it and the remnants don't have collision boxes. It’s going to be really weird seeing the player literally ignoring the physicality of the world. One potential solution proposed was to add a collision box to the remnants, so we avoid this nasty visual effect. This solution seems nice from the beginning but it touches so many aspects of the actual balance of the gameplay that we dismissed it.

We are still experimenting with it, and trying to find the best approach in between all these limitations. Hopefully soon we will find a proper solution.

As always, let us know what you think on our forum.