0.16 to be declared stable

Rseding thinks that we have the least amount of bugs in the game we ever had. Mostly because of the automated reporting system and partly because of my pushing of everyone to fix everything before starting other tasks. The 0.16.35 (to be released soon) will be declared stable on Monday, if no critical problems are discovered.

0.17 plan

• Mini tutorials (kovarex, Twinsen, Albert, wheybags).
  We would like to iteratively improve the quality of the tutorials based on our first attempts and cover the rest of the game mechanics by it.
• Improved First Steps campaign and new main campaign (v453000, Albert, wheybags, Ben).
• Gui rewrite. (Twinsen, kovarex, Dominik, Albert).
  It is both improving the looks of the GUI and changing the way it works. Some of the drafts were already published in FFF-212 and FFF-191.
• New graphics back-end, SDL, OpenGL, DX11, v-sync fix, texture streaming, VRAM usage optimizations, shaders (posila, HanziQ, sindri, wheybags).
• Recipe tree GUI (Oxyd).
  This should be the foundation of some kind of ingame factoriopedia. It should provide the player fast ways to get the answer to questions like: "what is this item used to?" and "What is the graph of recipe dependencies for this".
• Mod integration improvements (HanziQ, Rseding).
  Mainly extend the feature of syncing mods with save from save loading to multiplayer game joining, mod browsing improvements, which should at least show the mod picture and more smaller things.
• Map Editor improvements, both technical and usability wise (Rseding).
• Map generator improvements and fixes, autoplace specification improvements and documentation (TOGoS).
• High-Resolution sprites for the rest of the game, including few changes to some entities (GFX).
• Final game balancing (kovarex, v453000, Twinsen).

• Spidertron (kovarex, GFX)
• Better car handling and car in latency state (Dominik)
• Better fluid physics
• Organised playtesting for the new GUI, campaigns and tutorials before release.

The big picture

Weird crash reports (Rseding91)

In 0.16.31 we released a bug fix for a specific modded scenario that involved some heavy refactoring of game logic that checked if an item could be put into a given entity. Once 0.16.31 was live we started to get an unusual amount of crash reports inside the Furnace::canInsert(...) logic which made no sense. I thought maybe my fix somehow broke the furnace logic but I couldn't see how it was possible.

I spent half an hour theorizing what might be happening but got nowhere. Then I decided to see if any of the other devs might have ideas. Still, we had no idea what could possibly cause it to crash where it was crashing. We finally decided to change our crash log uploading to include minidumps for this specific crash in hopes it would shed some light on the issue.

From one of these minidumps, we got a look at the raw assembly code causing the crash, which confused things even further, as it said it was executing code that didn't exist in the executable:

00007FF6DA0B13B2 48 8B 8D D8 00 00 00 mov         rcx,qword ptr [rbp+0D8h]
00007FF6DA0B13B9 41 B2 01             mov         r10b,1
00007FF6DA0B13BC 48 3B 8D E0 00 00 00 cmp         rcx,qword ptr [rbp+0E0h]
00007FF6DA0B13C3 74 51                je          Furnace::canInsert+106h (07FF6DA0B1416h)
00007FF6DA0B13C5 48 8B 03             mov         rax,qword ptr [rbx]
00007FF6DA0B13C8 E9 33 EC E3 FF       jmp         00007FF6D9EF0000  // Jump outside of the Factorio executable
00007FF6DA0B13CD 90                   nop                           // Padding
00007FF6DA0B13CE 90                   nop                           // Padding
00007FF6DA0B13CF ??                   ?? ??                         // Illegal instruction - crashes here
00007FF6DA0B13D0 75 3F                jne         Furnace::canInsert+101h (07FF6DA0B1411h)
00007FF6DA0B13D2 0F B7 41 04          movzx       eax,word ptr [rcx+4]
00007FF6DA0B13D6 45 32 D2             xor         r10b,r10b

When 0.16.33 went out the number of crashes in Furnace::canInsert(...) dropped by a factor of 15. We changed nothing about how it worked and somehow it was crashing less. After some further discussion this morning, we believe that we've got a plausible explanation as to what is going on:

Someone probably used something similar to Cheat Engine to cheat by modifying the program memory runtime. In fixing a bug, I refactored how Furnace::canInsert(...) operates enough that the executable now crashed in what ever the cheat engine script was doing. As we released new versions, the people using that script stopped using it because it was crashing their game, and so we stopped getting crash reports.

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