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.
This naturally leads us to:
0.17 plan
Major features of 0.17:
- 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 andFFF-191.
- New graphics back-end, SDL, OpenGL, DX11, v-sync fix, texture streaming, VRAM usage optimizations, shaders (posila, hanziq, jindri, 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).
Possibly:
- 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
0.17 is a 1.0 candidate, but due to all the new rewrites (new GUI, new graphics, new tutorials, new campaigns), it is very likely that there will be unforeseen changes we need to do. So 0.18 should be a rather short release where we polish the GUI and campaign based on player feedback and also fix any final or long-standing bugs, possibly fix long-standing minor issues and once it becomes stable, it will be declared 1.0 once stabilized.
Weird crash reports
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