Hello, the 1.1 release is the final release of the vanilla game. It will be maintained, so bugfixes, simple modding interface additions, or minor tweaks can happen, but that's about it.
So what's next?
We have a new blog post on our website detailing our future plans, You can read it on our website.
Your game will/should auto-update to 1.1.19 if you are not opted-in to any betas. The changelog with all the changes from 1.0.0 will show when you first load the new update.
If you want to go back to the 1.0.0 you can do so in the betas menu.
Its been 2 months since the 1.1.0 release, so most mods should have been updated. Please check the in-game mod updater.
Hello, Last week we have started the experimental cycle of 1.1 update releases. We have fixed the most game breaking and save corrupting issues, but the update is not quite stable yet. This means you have to opt into it using Steam's beta feature.
But beware: blueprint library and save files are not backwards compatible, so once blueprint library gets migrated to 1.1 or you save a map in 1.1 you won't be able to load them in stable 1.0.
Furthermore not all mods have been updated to 1.1 yet and modders might not keep up with changes in future patches, so expect things to break from time to time if you play a heavily modded game.
If you don't want to deal with a less stable game or your mods breaking, consider staying on the stable version 1.0 for the time being. And please, if you find any bugs, report them on the bug forum.
Major Features
Added logistic requests to spidertron.
Train stop allows to set limit of incoming trains.
Features
The continue button now respects the last type of game played (single player, MP host, MP client).
Added support to use blueprints, deconstruction planners, upgrade planners, and modded selection tools from the map view.
Hovering the alert notification will show arrows on the edge of the pointing to alert locations.
Rich text icon selector.
Newly unlocked recipes are highlighted until hovered.
Spidertron remotes now allow to add queue commands and a command to follow any entity.
Added vertical/horizontal blueprint flipping.
Transport belt drag building is locked into a line, can be turned off by an interface setting.
Ghosts can be fast replaced and rotated.
Ghost build can be used to fast replace non-ghost entities, which results in an upgrade order with (optionally) a direction change order.
Minor Features
When editing blueprint: Added a way to specify relative grid position for blueprint that is snapping to absolute grid. Blueprint preview rendering box is updated based on selected grid size and position.
Inventory transfer works on empty equipment grid slot the same as on empty inventory slot (moves all).
Equipment can be placed by moving.
Cursor replenishes when placing into the equipment grid the same way as when building in world.
Spidertron item shows its color.
Added a way to reset spidertron remote.
Spider tries to move legs away when they are blocking robots construction.
Power poles/underground belts built by dragging logic works also with ghost building.
Power pole ghosts show connections.
Power pole connections are saved in the blueprint. They still auto connect to other poles outside the blueprint.
Entities marked for deconstruction show the target upgrade.
Added tags, worker robots, rail signal states and recipes toggles into the settings to what show on the map.
Added support to use the add-stop and add-temporary-stop controls for the train you're driving in the map view.
Added hotkey (F10) to switch between viewed player in replay.
Added support to reset mod settings in the "failed to load mods" startup GUI.
Expanded undo to work with fast replace and upgrade planner.
Added unique technology icon for Advanced material processing 2 (Electric furnace).
Changed postprocessing effect in zoomed-to-world view.
Added detailed night lighting of entities.
Optimisations
Multithreaded belt update logic.
Overall small entity update time reduction + statistics of how much update time is taken by individual entities.
Balancing
Productivity module 1 decreases speed of the machine by 5% instead of 15%.
Productivity module 2 decreases speed of the machine by 10% instead of 15%.
Changes
the Close GUI key-binding (default value is "E") was renamed to Confirm Gui. It works the same as before for many cases (just closing the GUI), but in a lot of other cases, it works as confirm, which generally means the same as clicking the "green button".
Renamed clean-cursor to clear-cursor on all the relevant places (locale, key-binding name)
Equipment placing now uses the build key-binding instead of the cursor transfer. The default same key-binding is the same.
Changed maximum temperature of all fluids apart water and steam to be the same as the default.
Poles built by dragging are now actually build on the maximum connection distance from the last built pole instead of the previous logic that was working weird in a lot of corner cases.
Underground belt build by dragging now accept the existing piece you start building on as part of the dragging logic.
Hello, we have a new FFF blog post, discussing upcoming changes to Spiders, Ghosts, the main menu, and more.
Unfortunately due to limitations in the Steam blog formatting, the blog would look terrible on Steam, we have lots of nice .mp4 gifs which we just can't show properly on Steam. Therefore we will just be linking to the blog posts instead of rewriting them here.
Hello, we finished with the regular Friday Facts series, and yet, there is still so much we want to talk about. I want to clarify, that we are not going to release FFF every week, but there are a few of them coming in the near future.
1.1 - The real 1.0
The point of 1.1 isn't to add some new content, the main motivation is to finalise all the existing features so that they work together in a proper way. This may sound a little bit abstract and boring, but it will be explained more clearly in the upcoming FFFs. Believe me, the sentence "I didn't know I needed this until now" will come to your mind more than once.
The work on the 1.1 update started basically right after the 1.0 release, so there is already lots to show.
Right now we aren't going to make any promises as to when it is coming, but we will keep you updated on our progress with these blog posts, and give some notice before it is deployed. Though I'm quite certain that we are more than half-way through. To keep you happy until it is here, lets go through some of the changes.
Train stop limit
This is a tiny story about Boskid's train related side project for a feature that was requested quite often (1, 2).
The problem
So imagine the situation: You're sitting in your factory and you need more iron... classic. So you build a nice railway to bring ore from dedicated mining outposts back to your iron smelter. You build 2 ore outposts, and you set up 2 trains, 1 for each. The two trains have a similar schedule; one goes from Iron smelting 1 to Iron ore 1, and the other goes to Iron ore 2. This works fine.
However there are some problems when you want to expand your production. You want to just copy-paste Iron smelting 1, and have half the ore go to Iron smelting 2. Now you need to start manually reassigning trains, trying to balance the throughput of the mines, and what else. If an iron mine runs dry, then you need to rebalance the whole system, reassign all the trains from that station, and have some omniscient overview of all the different routes your trains are running.
With more mines and more smelting and more trains, this management becomes an incalculable problem, and frankly it is not fun (opinion).
The imperfect solution
There is a nice solution, which works (almost). That is to name all the ore stations the same, and all the smelting stations the same. When choosing a destination, the train can go to any of the train stops with that name, which means:
When you build a new ore outpost, you just name it 'Iron mine', and a train will come and pick up from it.
When you build a new iron smelting, just name it 'Iron smelter', and a train will come deliver some ore.
When you build a new train, just copy-paste the simple schedule, and it will start working effectively.
However there is a small issue with the system, that completely breaks the idea. The trains are not clever. They will path to an arbitrarily chosen train stop with the correct name, based on destination distance and a few other factors. This means that it can easily happen that all the trains end up only servicing 1 iron ore pickup, while there are other outposts full of ore with no trains coming to pick it up. You can somewhat relieve the issue using the circuit network to enable and disable the train stops, but it is only a half-measure. For instance you can still end up with 10 trains rushing to a single small iron ore pickup, which can cause the trains to queue on the mainline and jam everything.
The limit
It is pretty simple, as good solutions typically are. You can set a 'Trains limit' in the train stop GUI, and the train stop keeps track of how many trains are in the station or on their way to it, which we call a reservation. When a train is choosing it's next destination, it will check the limit of all the stops with that name, and if a train stop has too many reservations already, it will skip over it. If all the potential train stops are full, the train will just wait.
This pretty much perfectly solves the problem with naming all the train stops the same, and also solves a few other potential annoyances. For instance, previously your Iron smelter stacker would need to be big enough to fit all the iron ore trains at once, because you couldn't be sure that they wouldn't all return at the same time. Now you can set the train limit of the Iron smelting train stop to the maximum capacity of the station, which means you can build a smaller stacker, and be certain that it will never become over-crowded.
The train limit is also controllable with circuit network, so there are even more possibilities. One idea is keeping the train limit set to 0 until there is a full load of ore available at the station. You can also read the current number of reservations, which will have its own interesting uses.
There is an edge case we had to solve while working on the feature, what happens if the limit is lowered while a train is already on the way? Our first idea was to force all the trains that are on the way, to repath and find a new destination. This works in many cases, but if there is no train stop it could path to, it would end up stopping and waiting in the middle of the tracks, causing untold economic damage.
So we decided that even if the limit is changed, any trains with a reservation will still go there. This means it isn't strictly a 'hard' limit, but we think it is a good thing, as setting the limit to 0 provides an alternative way to control train behaviour compared to when the station is disabled. Basically the train will only consider the limit when first deciding which stop to path to, after that it doesn't care if the limit changes.
We also had to deal with the 'No Path' warnings. If all the train stops were full to their limit, the train would show 'No Path', which isn't very intuitive for the players. So when the train can't find a path due to the train limit it will show a special warning: 'Destination full'.
The impact
To an outside observer, this really may just seem like a tiny little thing, but for us it is one of the most exciting features of 1.1. I think it is also quite telling that something like this has been missing for a long time, given the popularity of the Logistic Train Network mod. While the train stop limit isn't quite as powerful as the mod (understatement), it is going to open up many possibilities and add a lot of interesting gameplay oppourtunities.
I don't know if I am alone in saying, but I like it when the rules of a system are very simple, and the complexity emerges from the interaction of these very simple systems. I think the train limit is a perfect example of a simple rule, that will lead to really interesting and complex behavior. I can imagine just riding around on a Iron train with a simple "Pickup Iron -> Dropoff Iron" schedule, and it driving me around the whole factory as the chaotic interaction of train stop limits and other trains means each time it needs to travel somewhere else. I can imagine also a lot of fun design considerations will be needed when building such a rail network, where the traffic is less predictable than a 'Static route' system.
Tips and tricks
The tips and tricks have been a feature of the game for a very long time. They began as a way to explain things to the players that were not explained anywhere else. The iconic example is the 'Alt-mode' tip. Playing without Alt-mode is painful, and even more painful to watch, so we had to tell the player somehow.
The early days
When I say early days, I mean the early days, before even the indiegogo campaign. The first implementation of the tips was straightforward, but a bit rough.
The tips and tricks GUI in version 0.6.4.
The initial design:
They would popup when you start the game.
You can click forward through them (no going backwards).
You can close the GUI, there was no way to re-open it other than loading a save game again.
The images were of inconsistent sizes, so the GUI would jump around and resize.
There was a built-in checkbox to turn them off.
It got the job done, but it needed some development as with the rest of the game.
The first refresh
Over time, the tips and tricks fell into a dark corner. It was always low-priority, and wasn't clearly a 'Graphics' or 'Programmer' task to improve them, it was something in-between. So that is where I came in, and took the task of making some improvements.
The tips and tricks GUI in version 0.16.51.
First improvements:
You can click forward and backward through them.
You can close and open them with a hotkey.
The images were retaken at a consistent resolution and zoom.
You can open them in multiplayer.
At this point we shifted focus to the other 'tutorial channels' as we were hoping that the new mini-tutorials and NPE would mean we don't need as many tips. We think it is better if things like item usages are explained in the item tooltip, rather than in another GUI elsewhere.
Apart from some GUI style updates, the tips and tricks were not changed significantly for the next few major versions.
1.0.0
On the approach to 1.0, I took a last quick look at the tips and tricks. The tips are one of the first GUIs the player sees when they start Freeplay, so I wanted to give them a last lick of paint before the full release.
The tips and tricks GUI in version 1.0.0
The improvements this time were the nice last finishing touches to bring the Tips and tricks to their final form.
Increased image size and updated all images to high-res.
Added frames and subpanels to match the visual design of the new GUI.
New button styles.
Generic close button in the top right.
So then that's that right? I finally rest, and watch the sun rise on a grateful universe...
The Inspiration for change
Even before 1.0 was released, I was inspired by the Mini-wiki found in Krastorio 2, and the Informatron mod.
The main spark, is the index of topics. It solves many problems:
You can see the title of all the tips right away.
You don't need to click through all the tips.
It naturally allows categorization of the tips.
The player has some idea of the tip content before clicking on it.
The small item icons are visually appealing.
However with the deadline of 1.0 approaching and not wanting to expand the scope any further, I just let the idea brew in my mind... until now.
The new tips and tricks
A picture is worth 1,000 words, and in this case, it is very true. So lets start at with that:
Lets go through and explain some of the initial changes:
There is now an index on the side.
Now that there is an index, we can remove the 'Forward' and 'Back' buttons.
There is a search button, we can search using the tip titles.
The tips are categorized and indented accordingly.
There is a 'Mark as read' button, we will get to that later...
Quite a few changes to the GUI layout, and it works really well. But we can go further.
An issue remains, an issue that is small, but in the long run and with compound interest, it becomes a big source of pain. The problem is that the Tips are still using images, which means they become outdated as we update things. We have retaken all the screenshots many times now over the years.
So what can we do about it?
The Simulation
In this case, a GIF is worth 1,000 images, so lets start with that:
What you're seeing is a GIF (technically an .mp4) on a webpage, but we are not putting GIFs in the game. What the GIF shows, is the Tips and Tricks GUI live rendering a real simulation of the entities inside the GUI. This marvel of technology is a divine gift from the very top (kovarex).
The simulation widget solves quite a lot of the initial problems with using screenshots/images, but we can go even further.
We can use the simulation not just to show a factory environment. Using the Lua scripting, we can create entire scripted scenes and demonstrations. This is much more effective in many cases. For instance seeing the building preview, the mouse movement, and hearing the 'real sounds', makes the tip much more meaningful.
Unifying with mini-tutorials
We are left with another problem, we still have the mini-tutorial GUI. So it is a weird and awkward situation that some things are explained in the Tips GUI, and other things via the mini-tutorials.
The mini-tutorial GUI is quite a challenge in itself, and it has a lot of similar problems to the old Tips and Tricks GUI. The mini-tutorial 'images' are just 'related' technology icons, with the 'related items' underneath. The text gives a short description of what you might expect from the tutorial.
It would be pretty nice if the mini-tutorials could have the same sort of features as the tips and tricks, an index, nice big images inticing the players to click the 'Play tutorial' button... etc.
So what if, we just somehow put the mini-tutorials in the tips and tricks GUI? It makes a lot of sense, and unifies the communication channel. You know now that if you need help with a topic in the game, there is one place you should look for some guidance, the Tips GUI.
The mini-tutorials had some nice features or their own, they would only show if the player had met some requirements, and would be suggested to the player if they performed certain actions. For instance the Train tutorials would only show after you have researched the railway technology. If we unify the two concepts, we can use the unlock and suggestion features for the Tips and tricks.
So we combine the functionality of the two systems. Mini-tutorials are still the same, but they are presented inside of a Tip, and we hook in the suggestion and dependency system to the tips. We added a 'Mark as read' button, and Tips will show once the dependencies are read.
We see this new unlocking and recommendation system as one of the more important improvements. It means the tips and tricks GUI starts with only the nescessary tips, and as you progress in the game, relevant tips are unlocked and shown to you. This is very similar to the way the game starts with only a few recipes, and the more complex aspects are unlocked over time.
The Tips are moddable!
Once last minor issue with the old tips and tricks, is that they were 'hardcoded' in a sense. They were loaded from a very specific JSON file in the core data directory. That means that it was not possible for mods to add or change any of the tips.
It is only natural then with this update and modernization of the tips, that we open up the system to modders. Internally the Tips work like any other prototype, so it is super easy for a mod to add their own entries.
The scope of tips
When adding the new tips, it was tempting to make tips for all of the things. However after some consideration, we decided to not go too far this way. We don't want the tips and tricks to become a 'Factoripedia' or 'In-game wiki'. In general, the items and entities and general mechanics should explain themselves in more direct ways, such as the entity tooltips.
What we want, is for the tips and tricks to explain mechanics and topics that are more complex, or hard to explain somewhere else. With that in mind, we decided on a few loose categories:
Things that are not related to some specific item, e.g alt info, ghost building.
When visual presentation helps a lot, e.g splitters, belt lanes, long handed inserters.
When it is something related to a combination of more items, e.g gates over rails, copy-paste stuff.
The "tricks" e.g the lab to lab movement, stack transfers, drag building.
Importantly, we should really only explain things that players actually don't get. I have never heard a complaint that someone doesn't understand how solar panels or accumulators work, so putting these into the tips and tricks would be just bloat, even if it technically fits the criteria.
Conclusion
We are quite happy with the result, the tips and tricks GUI was always one of those paradoxical systems that was both extremely useful and terribly ineffective at the same time. We really hope all the effort we have channeled into it will help.
Speaking of help, we need your help: What kind of tips would you have found useful when playing the game? Searching TIL on Reddit can be a source of inspiration, but it is still hard to compare the importance of individual independent Reddit posts, and also a lot of them are outdated. So, if you want to give us feedback, the FFF discussion is the best place (yes we do read Reddit).
Hello, the atmosphere in the last week was kind of special. We experienced the feeling of the final release being on the horizon many times. And we were shown that it isn't the case time and time again. So it feels very special when it is actually becoming reality. We were trying to be especially careful with any last minute changes to make sure that we don't introduce major bugs into our precious 1.0 release. The image of all the players having the game crash on some simple stupid bug is horrifying.
Thank you
People thanked us on many occasions for the hard work we do. It helped lift our mood in many of the desperate moments, when bugs and problems were piling up and we didn't see the end of the tunnel. We don't say it often enough, but the support from your side has been incredibly helpful throughout the years.
We thank all who helped us to save the game before it could even start by supporting the IndieGoGo campaign back in 2013.
We are grateful for all of the 18,855 bug reports. They were invaluable feedback that helped us reach our level of game stability.
We value almost all of the feedback to our FFF and game releases. A lot of game improvements came out of it.
We appreciate the work and creativity that went into creating the 5,603 mods. It certainly extends the potential for a lot of people, and of the ideas became great inspiration for us.
All the online videos, articles and streams were immensely helpful to spread the word.
We thank all who helped with the Crowdin translations, allowing the game to be played in a lot of different languages without us having to manage it directly.
We are grateful that people spontaneously helped to manage the Wiki and created some great tools, like calculators, cheat sheets or blueprint databases.
We value the effort put into organising events, like fMMO, Clustorio etc.
We appreciate that our community is very civilised, and people who contribute are generally nice to each other, and keeping the criticism on the constructive side.
And, lastly, we would like to thank all of you who bought the game, and allowed all of this to happen.
The 1.0.0
It took us 8.5 years. It has been an incredible ride and we have arrived at the destination! Factorio is leaving early access. This opens the game up to all the players who just don't play early access games, the same with reviewers who only cover finished games, which is very understandable. For this special occasion, we created a launch trailer. It tries to capture the story of the development in 45 seconds.
Since the main Trailer is kind of timeless, we updated it to the 1.0 state of the game.
When we released pretty much all the content in 0.18, there was nothing left for 1.0 other than the formality of "it is complete".The crash site, nuke, alien decoratives and polluted water are awesome, but not too impactful... As a result, we really wanted to add something to make the release special.
It is a vehicle that can be driven, or remotely controlled.
It can traverse obstacles and small bodies of water.
It has a built-in radar, and you can place blueprints in its vicinity.
It has an equipment grid, so it can build with construction robots and use combat equipment.
It has four rapid-firing rocket launchers that can shoot automatically.
It can be researched very late in the game (all science packs except Space).
Multiple of them can be deployed at the same time, but each requires its own linked controller.
This all means it can be used as a tank upgrade, a less automated version of artillery, or a builder/repairer. We look forward to seeing what other uses you can invent.
We haven't added it earlier as we saw it just as a gimmick without much contribution to the gameplay mechanics. This changed rather recently, when we had the idea of the remote control combined with the equipment grid. So we decided to extend our already crazy todo list, and add it as a last minute bonus.
The plan for 1.1
We were doing the best we could, to fix all the relevant bugs and issues for the 1.0 release, but we just couldn't do everything. So we had to prioritise just the more critical stuff. We would still like to address all of the remaining issues as there are currently around 150 bugs on the forums and around 80 internal tasks to be solved. The plan is to eventually go through all of them, and decide on how to resolve each one.
A good example is, that we have a "continue" button, but it just ignores multiplayer. You press continue automatically just to find out, that you are building alone for half an hour. It is my (kovarex) personal story actually.
This means, that 1.1 is going to just focus on filling the most obvious gaps in our existing feature set, not on adding some new major content.
Full circle
When we started with the Friday facts, it was at a time when we worked a lot, but if there wasn't any release for a while, people were starting to ask whether the game is still being worked on. So this was our first motivation. Eventually we learned many additional advantages of the blog, other than it being just a dead mans switch.
It established the communication channel between us and the community.
It started to be an internal every-week milestone to get something into a presentable form.
In some cases it even motivated us to add a cool last minute feature to make the topic feel more complete. (This is how the undo and copy-paste feature was created for example)
It became a great archive of the evolution of the game throughout the years. Opening old posts is like reading our own diary.
It became an every Friday habit for us and some of our players too, but we believe now is the right time to stop. There will hardly be a better moment to do so. It should be very understandable that we need a break, and we also need the freedom to think about the long term without the obligation to cut it into small chunks for FFF.
Since you can't expect weekly posts from now on, we wanted a way for you to be notified once we have something special to say. Feel free to give us your email address so we can let you know.