As for the conclusion of the topic opened in the FFF-288 we finally decided to go for a balanced solution in which the player can recognize what entity was destroyed and also walk through them. The solution of going up in the Z-axis is really attractive for designing the destroyed models, but it gives a lot of headaches to the game designers due its need of a bounding box.
We are planning also a generic set of remnants for the modders who don’t feel like making the destroyed version of their own machines. Here an example of how a factory can look after a biter attack:
These remnants are still a work in progress, many of them are not yet finished and we are planning more iterations with this subject. By now you'll find a sneak peek in today's release (0.17.36).
Marketing plan for 1.0
The 1.0 will be a one time opportunity to drive the sales of Factorio, and as with the steam release, we don't want to leave its potential untapped.
I want to call myself a "Idealist Capitalist". This means, that I truly believe in capitalism as long as it is done in a fair way. I want to do as much as I can, to give good credit to capitalism by doing the right things myself.
The famous quote of "Do unto others as you would have them do unto you" and also "No bullshit policy" is something we take very seriously all the time during the development since the early days. Things like pricing $30 instead of $29.99, no sales, no micro-transactions, game stability over features, no selling-out to big companies that would use the game as cash grab while destroying the brand (we actually declined to negotiate "investment opportunities" like this several times already, no matter what the price would be), the same would be when it would potentially come to any exclusivity deals, which is its own subject...
We should also be true to this when it comes to marketing. In my eyes, there are good and bad aspects of marketing.
What I truly hate is banners and forced ad-videos, or radio spots that are just screaming at me and trying to get into my head without my consent. The idea, that I would basically pay for the ad that annoys me by buying the product feels deeply humiliating. So you can understand, that I don't want to pay marketing companies to do this to others.
On the other hand, there are a lot of marketing strategies that I'm okay with. I'm okay with media covering a commercial product, as long as I find it interesting. It is a very subjective definition, but it basically means, that it is not about pushing a product into your face, but offering you something that might give you some value even if you never buy that product. Articles about stories of companies, interviews with book/film/game creators are often very interesting, and piqued my interest in products many times before.
There are a lot of interesting themes that could be covered about Factorio, its creation story, its mindset of automation and conscious self-observation of what is the biggest time-stealing thing, the programming/engineering parallels and stories of people who consider their carrier path because of it. It also has a potential appeal to the big crowd of gamers from the past, who think that games are just mindless shooters with lootboxes these days.
This is the kind of content that I would be interested to read about the game if I didn't know about Factorio, and this would be the best advertising for us. So our goal would be to convince as many related media as we can to write about us when the time comes.
I'm talking about the kind of media that covers content related to the themes that Factorio tickles. So anything related to games, technical stuff, engineering, software development, teaching, networking, business, etc. And here comes the moment where I'm turning to you. You could give us pointers, what kind of magazines do you read that could be suitable? Let us know. Do you know anyone related to a media outlet that could cover us? Let us know. Do you have other ideas of what could we do for the release that is still true to our principles? We would like to know.
Another way is to make an interesting story that spreads itself, these are the examples:
We released version 0.17.35 yesterday, and it included a change that broke a lot of mods: Renaming the entity 'player' to 'character'.
Inside of the game engine, the previous naming scheme was a huge inconsistency, because the terms are generally well defined:
Player - The concept of the person controlling the game, doing input, playing the game.
Character - The 'real' little dude running around in the world.
A player can exist without a character, such as playing sandbox, and similarly a character (which is an entity) can exist with or without an attached player.
Having the character entity named 'player' led to a massive amount of collective confusion over the years, especially in regards to which methods can be called on the LuaEntity and LuaPlayer objects at runtime.
Another problem is in the naming of some 'defines' (constant values exposed for Lua scripting). If you want to access a characters main inventory, the value was called 'inventory.player_main'. This makes it sound like it gives the main inventory of the player, but no, it gives the main inventory of the character. If you are in sandbox mode, using 'inventory.player_main' will not give the correct inventory, you will need to use 'inventory.god_main'.
Ok, so taking a step back, why are we making these breaking changes now? The short answer is that there is no better option for us:
Change it for 0.18 - This would mean waiting months and months to make the changes, and push any bugs it creates further down the line. In the meantime, another major version of Factorio modding will have these inconsistencies.
Change it after we have 0.17 stable - We want stable to also be stable for modders. If you write a mod that works with the stable version, you wouldn't expect it to break in another stable version.
You should have changed it for 0.17.0 - Well yes probably, that would have been more ideal, but that was several months ago now.
Change during 0.17 experimental - This is the option we have chosen, it breaks some mods in the short term, and discourages people from updating, but long term its consequences are small.
We might make some more mod breaking changes in upcoming experimental releases. We'd like to thank all the mod authors and experimental players for their understanding and patience as we work towards the full game.
As always, let us know what you think on our forum.
Increased the maximal length of station name to 1024, mainly to allow wider usage of multiple tags in the name. more
Bugfixes
Fixed that making blueprints of locomotive ghosts wouldn't include the schedules. more
Fixed that worms and spitters didn't show attack parameters in description.
Fixed that the game would crash if it was closed when Sound Settings was opened. more
Limited the manual rail building distance to 3 times the normal building distance.
Fixed dangling tooltip bug related to widget reorganization in map generator GUI and possibly other places. more
Fixed that the train time condition label wasn't properly set to squashable resulting in wrong layouting in certain languages. more
Fixed truncation of labels containing rich text. more
Fixed PvP and Wave defense starting base entities wouldn't spawn if a mod added a tile with a certain collision mask and a name which sorted alphabetically above dirt.
Fixed PvP production score error when a mod or script adds another force during a round.
Fixed PvP error when using DEFCON mode.
Fixed that the shortcut bar selection list wasn't scrollable until the window was resized. more
Making disabling of features in map generator more clear by adding checkboxes for it. more
The wagon door opening animation (that is only available for horizontal/vertical direction) is now chosen based on the drawing sprite of the wagon selected instead of the orientation of the wagon. This means, that orientations really close to horizontal/vertical still use the animation. more
Fixed that changing map size didn't mark the map preset as modified. more
Fixed label text not updating correctly when cleared and had non-zero minimal width and height. more
Improved handling of whitespace characters in technology count formula parsing.
Checking that only the l (or L) variable used in the technology formula on startup, to avoid errors later on. more
Fixed NPE error at startup that could occur when using mods. more
Fixed GUI window of an entity not updating when pasting settings to that entity. more
Fixed error in consistency check of ghost connections related to multiple connections to entities only in the undo queue. more
Fixed train condition fulfilling indication for artillery wagon. more
IDXGIOutput::FindClosestMatchingMode returning an error is not treated as critical failure anymore. more
Fixed that the Mods GUI go-to-dependency buttons wouldn't work in some scenarios. more
Fixed that ghost building mode works the same as ghost building (with shift) when it comes to rail building. more
Fixed that upgrading entities in would leave invalid module requests. more
Fixed, that sorting changes were moving the scrolled position in the browse game gui. It is now consistent with the mods gui. more
Fixed some achievements being given to players while the save game is loading, not respecting player online time. more
Fixed LuaTransportLine::output_line read for right-hand output lines of a lonely splitter. more
Fixes to make tabbed pane work properly when it comes to squashing in different situations. more
Tweaked the algorithm that is putting trains on rails to work properly in junctions when constrained by the direction caused by blueprint/ghost train building. more
Modding
Renamed the character entity type and name from "player" to "character" to make it consistent with how we call/access it in all other places.
Renamed the technology personal-roboport-equipment-2 to personal-roboport-mk2-equipment and gave it corresponding icon to be consistent with other technologies of this kind.
Renamed the technology power-armor-2 to power-armor-mk2 to be consistent with other technologies of this kind.
Added optional storage tank prototype property "scale_info_icons".
Added "manual_rail_building_reach_modifier" to the utility-constants.
MapGenPresets' advanced_settings.difficulty_settings.research_queue_setting now works. more
Scripting
Mod GUI root elements (top/left/center/goal) are now contained in scroll panes, so when there is not enough space, it will become scrollable instead of being cut off. With enough space, it looks the same as before, the only change is, that the mod GUI contents can now not expect to be squashed by the screen, as it will just make a scroll bar instead.
Improved fluid simulation threading. Decreases CPU usage. Threading available on all operating systems. Simulation performance should remain unchanged.
Bugfixes
Fixed a crash when importing blueprint strings with power switch wires.
Fixed fluid mixing for fixed recipe assemblers. more
Fixed "Not enough rails" message after successful track placement. more
Fixed a crash when destroying entities during the on_pre_ghost_deconstructed event. more
Fixed that trains with "logistics while moving" disabled would not deploy robots when switched into automatic mode while waiting at a station more
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
The last 2 weeks have been less productive than we would like on the bug fixing front. The Easter festivities along with a wave of illness have dampened our efforts. We have still managed to push out 2 more experimental releases, and fixed a few desyncs. We encountered one specific desync in the mass MP stress test last weekend, caused by a characters inventory size changing (such as researching the toolbelt technology) while the player is respawning.
The graph of crashes paints a similar story to how the office atmosphere feels. It is natural though, most of the major crashes affecting most players are resolved, so all that remains are the more difficult issues that only affect a handful of players. This means that each bug fix is less effective at reducing the overall crash count.
This last weekend, we had over 500 total crashes reported, which is a slight improvement over the prior weekend's ~650. One thing that makes our progress hard to evaluate is that we don't know how many people are actually playing experimental. Most people play through Steam, and so far we have found no way of determining how many people are opted-in to the 0.17 experimental through Steam. It could be that the game is more stable, or it could be that less people are playing.
There are still over 250 open bug reports on our forum, so it seems it will be a few more weeks until the first stable 0.17.
Some people have been asking when we will release the new GUI and GFX updates that we promised before 0.17 release. The plan is that after the first 0.17 stable version, some of the team will be moved from fixing bugs to working on features. At the point where we have a meaningful amount of new content ready (A few GUIs, some new GFX, etc.), we will release it as a new experimental 0.17 version. We plan to give some explanation and notice about these 'mini-content releases' in a FFF before they are each released.
As mentioned last week, we did a stress test of the Factorio multiplayer last Saturday. We didn't have any crashes, but the server was really struggling at around 300 players, kicking players when they got near that mark. We reached a maximum of 350 concurrent players.
The stress testing is also a good way to find and fix desyncs, as the probability of a desync is about 100 times higher with this many players.
We made some more tweaks and minor improvements and we plan to make the test again. Every week the stress tests are more stable and allow more and more players. This will probably be a weekly thing for a couple more weeks until we are happy with the stability and performance of multiplayer.
So, tomorrow (Saturday 27th April) at around 8pm CEST we will be making another stress test. If you want to help out, join the server and play normally when the game starts. Details will be posted in the KatherineOfSky discord in the #mmo_stresstest channel. Or keep an eye out for the Steam announcement (event) notification. The server will probably become unstable or might require some restarts as we test, debug and trace things, so please bear with us.
Have you ever been playing a Freeplay game and realised you don't know what your next big goal is? And then, once you decide to pick a new goal, you realise while you worked on automating the last goal, there were 10 new technologies unlocked and now you don't know which to pick next.
These are the situations we hope to address with the new full Campaign. A guided Freeplay, in which the player plays through the whole tech tree, without being overloaded with choice, while still having the perminance and unidirectional progression of Factorio. The perminance problem has already been solved using the new map expansion technique which is playable in the Introduction scenario. Over the last year we have been working on the bigger design task of unravelling the tech tree and breaking it into a set of choices for the player.
This task has been made all the more Interesting as the tech tree is also constantly getting tweaks and revisions over that time as well.
I look forward to providing more insights but for now I will leave you with one example (read: spoiler):
Just to note, we won't be changing the freeplay tech tree, which will still have all the choice and diverging paths as it does now.
Factorio massive multiplayer stress testing
A few days ago I was contacted by Caledorn from the KatherineOfSky community. They were doing some tests to see if they can host a massive multiplayer event. I joined forces with him and started looking into the new and old problems we can fix in Factorio so we can host a large number of players. The last test was on Sunday. We had around 80-140 players playing without too many issues. But it was still a small test compared to our previous record of 400 players back in 2016.
Among some small tweaks, I added the ability to set a maximum number of map upload slots for the server. This should help tremendously for events such as these, where the map can get quite large, and there would often be a large flood of players joining, usually after a disconnect or server restart. This would cause a massive flood of map request packets coming to the server and very slow map uploads caused by uploading to way too many players. Now, when many players will try to join at the same time, they will pe placed in a queue and the game will wait for an upload slot to open up.
Another small annoyance in these events (or even small multiplayer games) is the constant annoying blinking of the "Server not responding"/"Player is being dropped from the game". I made some tweaks that should show this message less often. We also found a memory leak in input action handling, which Rseding has fixed.
There are still some technical problems to investigate and fix, so tomorrow (Saturday 20th April) at around 8pm CEST we will be making another stress test. If you want to help out, join the server and play normally when the game starts. Details will be posted in the KatherineOfSky discord. If we need more players, a Steam announcement (event) notification will be sent out, so keep an eye out for that also. The server will probably become unstable or might require some restarts as we test, debug, and backtrace things, so please bear with us.
High-res Icons part II
Last week I opened the subject of the high resolution icons FFF-290, more focused on the unisize method: re-scaling a single 64px bitmap to any size through trilinear interpolation. The results were very fine, and compared to the old version it was obviously a success.
This week we are focused on the mipmap method. Posila very quickly implemented the code for it, and even though I was willing to reject the technique due its extra work and complications, after testing it I changed my mind. Here a comparison with all the methods:
On the first glance the difference between unisize and mipmap is almost not noticeable, but when we surpass the boundary of zoom level 1.000, the mipmap starts to react a bit better. I was worried about the amount of work implied about the creation of the 4 levels for each icon, but after preparing a few of them, I saw that it wasn’t that much. Not to mention that having control over 4 different sizes is a big relief, especially the 16px and 8px versions.
The best part of the plan is that we can combine both methods, so we can make mipmaps only for the icons that require special attention, it is just about the Lua definition of the item.
Now, just for the joy of it, I’d like to show a sneak peak of what HR icons means for the GUI.
GUI at 100% scale
GUI at 200% scale
I hope this new contrast and definition results in a better experience for the player.
As always, let us know what you think on our forum.
The problem with rail building is that it has too many states. It depends whether you start building the rail with shift, to use the ghost mode or not, and then it also matters whether you still hold shift, to ignore trees or not. Moving from manual building to ghost rail building means cancelling the whole rail building and starting it again with the correct modifier.
The problems were reaching the surface from time to time, and Twinsen even drew a nice little state diagram of the rail building system.
It kind of peaked with this bug report. After some time, it became clear that we should simplify it.
This is a nice example, where we can talk about change we just released (0.17.29) in a FFF.
From now on, instead of 3 modes (building manually, ghost building, ghost building + tree/rock removal), we have only 2 modes, where the ghost building without obstacle deconstruction is not available anymore. So it doesn't matter anymore how you start the building, it just matters whether you are holding shift or not at the moment, which makes it consistent with the normal entity building and the ghost icon.
Once the topic is opened, it is hard to leave it so easily, so we agreed that the rail building could be streamlined even more. The current model is, that you have to build one straight piece of rail first, and then you can use the rail builder on the edge of that rail. It is annoying generally, and especially for the new players, because he might miss the way how it is being used, as the straight rails are built exactly the same way as other entities. The reason we did it this way was mainly, because when we first introduced the (new at that time) rail builder, we weren't confident enough that it could replace even the basic straight rail building. But since the rail building is stable enough, we might go one more step forward.
The plan is that the rail won't be used to build straight rails normally the way you can now. The rail item would be always used to build by the rail planner only. Instead of having to snap to an existing rail, you could just start building anywhere on the ground. Instead of showing the rail preview when holding the item, you would see the arrow as when starting the rail building, and you could rotate it with the R key. It would make sense, to make the arrow color/size different for starting a rail planner on the ground versus snapping to an existing rail, but other than that, it would be the same.
High-res icons
Until now with the old GUI non-scalable system, we hadn't had much of a problem with the icons. We use one single version of 32px to display in the GUI slots, and the zooming system of the game takes care of the re-scaling for the rendering in the world.
This is not a perfect solution because we use the same set of icons in the GUI and in the world. That means that the zooming level of the game can re-scale them up to 25% so we lose pretty much all control of the bitmaps, and the readability of them is affected. Now with the high resolution possibilities of the new GUI system, we need to double the size of the bitmap, therefore the original icons must be 64px in order to have a correct visualization at 200% GUI scale. We are still using them in the world, so the engine can rescale them up to 9.55%. The amount of out of control pixels is now much more serious.
Unisize vs Mipmap We are exploring some possibilities and we want to keep it simple. For now we are testing the limits of our old technique: one single bitmap for all the uses.
Delight yourself with this test icon placed on the belt. 64x64px size, every square is 8px. With it you can see how extreme the resizing can become: From maximum zoom level 3.053 = 76.325% icon size. To minimum zoom level 0.382 = 9.55% icon size.
To solve the problem for making it work in all the situations we design the icons in a very synthetic way. We simplify the shape to its purest meaning like the case of the assembling machines, where 1 gear + the color indicates level 1, 2 gears means level 2, etc.
This solution works but we have a lot of icons (~355), and many of them are very complex in their shape and/or meaning. In some cases this complexity is essential at the time of designing the icon -especially the entities- so we need to find the proper synthesis for each icon as we did with the assembling machines. They work fine at any zoom level, even at 128px. But with other entities, like the big electric pole, it's more complicated to keep this level of minimalism due to the fact that the shape itself is already complicated in its essence. If we make it less complex, we wouldn't be able to recognize it anymore.
A possible solution would be using a very minimalistic flat icon, but this wouldn’t be integrated as an object in the world. We don’t like that. The other solution is using mipmaps. So we use different versions of the same icon optimized for different zoom levels. We would notice the change of version at certain zoom levels, and for solving it we must complicate the situation. This complication would be not just for the code to create some crazy crossfading effect, but also for the designers to keep the several versions of the icon close enough as to not feel the change.
I would try to be pragmatic and I bet for the unisize solution based in a proper synthesis, but it’s not going to be easy for sure, like the entire history of Factorio development.
As always, let us know what you think on our forum.
Added ability to set a maximum number of map upload slots for multiplayer servers. Setting this is recommended to prevent the server from being flooded with map fragment requests from clients.
Optimisations
Optimized alt-mode icon background rendering. more
Bugfixes
Fixed that cut tool marked trees/rocks/cliffs for deconstruction when there was other valid entity in the selection. more
Fixed that movement by keys or clicking on an alert didn't unsnap the currently followed train in the map. moremore
Fixed that the game would crash when showing blueprint library tooltips. more
Fixed that the game would crash when showing a blueprint library tooltip in multiplayer when the blueprint/book was removed by another player.
Fixed alt-mode icon background for narrow icons was very subtle. more
(0.17.31) Fixed a crash when hosting multiplayer games in some scenarios.
You can get experimental releases by selecting the '0.17.x' beta branch under Factorio's properties in Steam.
Simplified rail building. Holding shift while rail building always activates the combination of ghost-rail-building + remove-obstacles, releasing shift returns back to normal manual mode. It doesn't matter anymore, whether the rail building started with shift or not. This removed the possibility to do ghost-rail-building without the remove-obstacles, but since it seems to be almost useless, we consider it to be worth the simplification.
font/color rich text tags now have to be properly terminated. This means eg: "[color=red]Red circuits" will now need to be "[color=red]Red circuits[/color]". This fixes a number of issues with handling start/end tags. moreeven more
Enter key will be shown as "ENTER" instead of "RETURN" on Windows and Linux. more
Minor Features
Added a shortcut for increasing/decreasing/resetting UI scale, mainly for debugging of proper automatic adjustment of UI, but people might find it useful for something as well.
Bugfixes
After a realization of a big misleading mistake, the pollution per second had to be renamed to pollution per minute, because it is what it actually is. more
Fixed that tree pollution absorption was recorded as pollution emission in the statistics.
Fixed that equipment electric network priority migration wasn't present. more
Crafting group selection by typing exact recipe match will now preserve the same way as selecting the crafting group manually. more
Restored previous behavior where normal (not only underground) pipe connections reconnected when a fluidbox got removed. more
Fixed crash when robots try to revive locomotive that has both front and back wheels on rails, but no rail in-between. more
Fixed that repair packs could be lost if they didn't fit in your inventory when using personal robots. more
Added missing pipe connection arrows to flamethrower turret. more
Fixed that custom GUI style values specified directly on the elements weren't updated after UI scale change. more
Fixed that the electric network GUI would sometimes be opened when starting deconstruction planner selection on an electric pole in the map view. more
Fixed that Textfield and Sliders didn't update its size properly on UI change.
Fixed UI change update in ModSettingsGui and MapGeneratorGui with preview open.
Fixed quickbar selection disappearing when cursor stack is refreshed with a new stack. more
Fixed that nested frame styles (horizontal flow, vertical flow, header filler flow, filler) weren't initialized/updated correctly in the GUI created by script.
Fixed that the loading indicator in the browse games GUI was left of the "Back" button. more
Fixed turret prototype definition allowed ammo_type of attack_parameters to be optional resulting in crash when the turret started to shoot.
Don't consider recipes with 0 minimum amount (and possible randomised result) when resolving automatic crafting of ingredients when crafting manually. more
Scripting
Changed the LabelStyle::want_ellipsis default value to true and it is never changed to be something else now. We are considering to even remove this style property completely, as we basically want the ellipsis always when the label is squashed.
Added tile parameter to on_player_built_tile and on_robot_built_tile.
Added emissions_per_minute property in the energy source, that is supposed to replace the emissions_per_second_per_watt which was basically wrong and hard to work with, both emissions_per_second_per_watt emissions definition will work for some time (at least in 0.17) so mods don't get broken.
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.