For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site.
It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar.
Here a proof of concept of the look:
The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit.
The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details.
It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones.
For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes.
The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent.
This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones.
These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers.
All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together.
The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.
Mods do crazy things
I've heard it many times and said it myself: "It's only ..., there aren't a lot of them in the base game so it should be fine." And then mods come along and bring a slap of reality: if a mod *can* do something a mod *will* do something.
The other week I got a bug report that the game was using a large amount of memory and took an excessive amount of time to exit. After reading over the bug report I had my theories as to why it might be happening but first I needed to reproduce it. A few failed attempts later I got the correct set of mods and mod settings to make it happen. To my surprise (well not really - it happens almost every time with these things now) - it wasn't what I thought it was going to be.
Sprites. Not the video-texture kind but the internal wrapper class we use to store information about the video-texture. The game was creating an insane amount of them due to what the mod was doing. Specifically: the mod was making a lot of variations of each biter, spitter, worm, biter nest, and spitter nest. Normally that's not a problem - the game can do that easily. The problem came from how worms work. Worms have multiple directions with multiple animations for each direction. The end result is each base game worm creates 7668 sprites. ... "It's only 7668 sprites per worm, there aren't a lot of them in the base game so it should be fine." The base game has 4 worms: small, medium, large, behemoth. This mod was asking the game to make 3020.
The base game:
188'056 sprites on the main menu
1.281 seconds from launch to the main menu
245 MB idling on the main menu
0.1 seconds to exit
The mods:
41'071'478 sprites on the main menu
47.395 seconds from launch to the main menu
15'791 MB idling on the main menu
47.5 seconds to exit
Many ideas and attempts later (plus fixing all the broken stuff introduced by those changes with the assistance of Oxyd) I had reduced the time complexity of making and destroying the sprites by a significant amount and found that some just weren't needed.
The result:
23'681'677 sprites on the main menu
37.444 seconds from launch to the main menu
5'484 MB idling on the main menu
2.9 seconds to exit
A significant improvement on every measurement. I always love working on these kinds of problems because they almost always involve a lot of thinking and experiments.
As always, let us know what you think on our forum.
Fixed that the Lua API would allow the same non-infinite technology to be queued multiple times. more
Fixed a crash when queuing things to be crafting during the crafting finished event. more
Fixed train pathfinding bug related to two different station connected to the same rail from different sides when one after another is in the schedule. more
Fixed rail signal consistency when rail is removed from reserved signal. more
Added "buffer-rename-workaround" config setting as a possible workaround for rendering glitches on some Sandy Bridge and Ivy Bridge GPUs. more
Fixed an issue that made unit group pathfinding fail often, resulting in very few biter attacks. more
Fixed that the hovering entity tooltip would still follow the cursor while in the menu. more
Fixed a crash when exiting the campaign during the same tick as a script-triggered autosave.
Fixed that incompatible dependencies would effect mod sort order.
Replay button in new game GUI is now remembered after confirm. more
Changed rendering of belts to use linear interpolation for minification to reduce flickering effect on some zoom levels. more
Fixed that units could sometimes get stuck forever. more
Fixed that multiplayer replay would crash the game if it contained a blueprint transferred using the blueprint library. more
Fixed that LuaEntity::destroy({raise_destroy=false}) would still raise the destroy event. more
Fixed that the style debug tooltips could in some cases show multiple at once. more
Fixed that robots could get stuck if the chest they're trying to put items into was blocked. more
Fixed that the update mods GUI would incorrectly disable the "Update selected" button in some cases. more
Fixed that building concrete/stone paths wouldn't use all tile variations in some cases. more
Fixed a performance problem related to large amounts of incredibly fast robots and storage chests. more
Fixed turret range overlay in map was not rendering correctly. more
Fixed that turret tooltips could show damage modifiers from the wrong force. more
Prevented possible number overflow in train condition gui. more
Modding
Added uses_stack to the thrown capsule item action.
Removed the rail-category prototype type.
resource_autoplace_settings has been made public (require('resource-autoplace').resource_autoplace_settings) and the API improved. It will automatically allocate a unique resource index for each patch_set_name. 'patch_set_name' and 'autoplace_control_name' can be independently specified. 'seed1' can be specified as a parameter. The global function 'get_next_resource_index' is obsolete and has been deleted.
Equipment shapes can be defined as "manual" (a set of points).
You might have noticed that a lot of rail related stuff was broken during these past releases, and now it is working more or less fine again. The story behind is is not so trivial.
Rail signal logic
The rail signal logic for automated trains is quite straightforward:
As a train moves forward, it tries to reserve signals in front of it. If it can reserve a signal, the whole block guarded by the signal gets reserved for the train. If the train can't reserve the signal, as the block is reserved or occupied by different train(s), it stops in front of the signal and waits. Once the train passes a signal and enters a new block, it removes the reservation on the signal and block it had reserved. Once it exits the block, the block can be reserved and entered by other trains.
This looks nice and simple, nothing fundamentally wrong could happen with this logic right? Especially since we have it there for almost five years and it all just works right?
If the answer to this was "Yes", it would be quite a stupid buildup, so the answer is "No" :).
The counter example
So in this example, the train is approaching from the right. The problem is, that it reserves the block number 2 twice since there is a special rule, that a train can enter a reserved or occupied block as long as it is reserved by itself.
Since the train reserved the block 2 twice but removed both of the block reservations by entering it, the second reservation, which the train still counts on, isn't applied on the block 2, and the block is basically open for any other train to enter. This can lead to collisions and surprisingly also desyncs since we don't save block reservations, but deduce them from signal reservations while the game is being loaded.
The solution
Once the problem was identified, the solution was quite straightforward. I added support for block to be reserved multiple times, removing the reservation decreases the counter, and the block is freed only if all the reservations are removed.
But the real bugs and problems started after, because we now need to be extra sure that the block is reserved exactly the same amount of times as it is unreserved. The logic around this was far from rigid before as it just wasn't needed. Quite a few strict checks were added all over the place, to make sure that an internally incompatible state doesn't appear, since we don't really want to have to fix these "this block is closed forever" bugs where it would be close to impossible figure out how the game got into that state.
P.S. Since we can now use train stops as waypoints, not only blocks, but rail signals can be reserved more than once as well, as a train can plan path in a circle and reserve the same signal twice along the path.
The effect
You can see how the internal changes of rails bumped our crash report counts, but it will hopefully go back to normal soon.
Well, you can't make an omelette without breaking some eggs... but overall the trend continues toward stability.
As always, let us know what you think on our forum.
Fixed using repeat_count in RotatedAnimation definition would cause crash. more
Fixed rail signal consistency in case of reserved signal being invalidated by building a rail that puts both sides into same block.
Fixed rail crash related to marking reserved signal for deconstruction.
Fixed that programmatically set locale for autoplace controls didn't work. more
Fixed that scrollpane consumed the mouse wheel events even when not activated, which blocked the other (parent) scrollpane. more
Fixed that re-pathing in chain signal sequence didn't respect the need for green exit when the re-pathing was based on manual change of target station. more
Fixed that changing state of rail signal by circuit network didn't properly update state of parent circuit signals. more
Fixed that rail signal disabled by circuit network didn't prevent train passing by it if it guards a block that is already reserved/occupied by the same train. more
Limited of usage of tab/shift-tab to move between textboxes as other objects didn't support it and it seems like it isn't worth to try to support it for everything. (https://forums.factorio.com/69656)more
Reduced the UPS impact of a large number of biters trying to pathfind. more
Fixed that tabbing could move to invisible or disabled widgets.
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Introduction as Demo In general, the Introduction scenario has been very well received. Feedback has been flooding in, and it has been very useful. Receiving screenshots from all of you has been great. We are mostly happy with the state of the gameplay, and it seems to be having the right effect on new players.
When 0.17 moves to stable, there will need to be a new version of the Demo. The Introduction scenario was always planned to be the Demo, but there are still some sticking points we want to address.
Loaders/Feeders/Consumers Back in FFF-284 we discussed a plan to promote new players to use belts. This solution worked very well during focus testing when the target points were Underground belts instead of Loaders. Even once we changed the targets to Loaders, players still built belts, but the effect was not as strong. My hope was that this could be solved when the Loaders received new art.
Loaders introduced a new issue which is a good example of contextual blindness. To me, the Loaders were simply a quest item consumer, conveniently placed so that after it was used, the player had accidentally set up some logistics automation. The items go in and disappear. To the players imagination, those items are being transferred to the adjacent structure.
This breaks a fundamental rule that was decided back in FFF-128 when Loaders were being considered. This rule is that there is only one way to move items between structures, by using Inserters. Even though the items were never actually transferred, and our intent was that the Loader consumes them, it is enough that the player might think they were transferred.
The next solution
Now that Loaders are gone, we needed a new 1x1 Consumer entity which the player must use inserters to fill.
We will be releasing it in the experimental this week so now is a good time to test it and send some last minute feedback. As usual, the introduction takes screenshots of your play-through, which can be found in the 'script-output' directory, please send them to us.
Combat robot and tank changes
There are some small tweaks we have made related to the Combat robots and Tank in this last week, and wanted to just quickly give a summary of the changes and our thoughts.
Tank no longer takes damage when hitting rocks We've noticed that the tank would take a huge amount of damage when hitting rocks, which isn't really fun. This change does nothing but remove irritation, and makes it consistent with hitting trees and cliffs.
Tank acid resist 50% -> 70% Tanks were a bit too squishy against the acid on ground, especially later in the game, where the acid of multiple types of Spitters/Worms stacks. Just some minor balancing really.
Defender robot recipe change We made a change to the recipe of Defender capsules for 0.17, which was adding flying robot frames as an ingredient. This makes the recipe more complex, and critically means you need to have a full oil setup running before you can craft them. We had an intention to buff the combat robots to compensate, but this did not come to pass. A problem with needing oil to produce the defenders, is that once you have oil, a lot of much better options (laser turrets, flamethrowers) become available, and the time taken to unlock all the prerequisite technologies delays their introduction.
So we decided to revert the change, and focus more on a niche use-case of the defender capsules. Without needing flying robot frames, you can produce the capsules without the need of any oil products. This means they are accessible earlier, and can be used to fight the medium biters that start appearing around the mid-game. We also decided to buff their base damage from 5 -> 8, to make them much deadlier against the 4 armor medium biters.
The other related combat robot changes of 0.17, namely the buff to follower robot count technologies, means they might now see some more use. With all the military science upgrades, defender capsules can become quite powerful.
Beams at night A small feature, but every little helps; Beams now show up nice and bright in the darkness:
As always, let us know what you think on our forum.