If you are in Prague this summer, and wanting to satiate your Factorio cravings, you can stop in to the National Library of Technology Prague, where Factorio is loaded onto 150 computers for all to play. Entry is free for all visitors Monday to Friday 08:00 - 22:00 until the 31st of August. The PC's are running Linux (Fedora), loaded with a custom build of the game HanziQ put together, and you can host LAN servers and play with your friends.



On the 23rd of July we will be hosting our own Factorio LAN party at the library starting at 16:00 CEST (Prague time), so you can come along and play with us. It is advised to bring your own set of headphones if you are going to attend.

As we started to modernize our rendering backend, the absolute must have was to make it at least as fast as the old one. We had the chance to do things however we wanted, so we were excited about the capabilities newer APIs unlocked for us, and we had lot of ideas how to draw sprites as fast as possible.

But first, there is no need to reinvent the wheel, so let’s see how Allegro makes the magic happen. Allegro utilizes sprite batching, which means it draws multiple sprites that use same texture and rendering state, using a single command sent to the GPU. These draw commands are usually referred to as draw calls. Allegro draws sprites using 6 vertices, and it batches them into a C allocated buffer. Whenever a batch ends, it is passed to the OpenGL or DirectX drawing function that copies it (in order to not stall the CPU) and send the draw call.



That looks pretty reasonable, but we can’t do the exact same thing, because in DirectX 10, there are no functions for drawing from C-arrays directly, and it is mandatory to use vertex buffers. So our first version created vertex buffer to which current batch was always copied for use in a draw call, and we would reallocate a buffer with a larger size if the current batch wouldn’t fit. It was running quite fine, probably not as fast as Allegro version, and it lagged noticeably whenever the vertex buffer would need to be resized.

After reading some articles, for example optimizing rendering in Galactic Civilizations 3 and buffer object streaming on the OpenGL Wiki (which was very helpful), it became clear that the way to go is to have a vertex buffer of fixed size, and keep adding to until it is full. When we finish writing a batch to the buffer, we don't send a draw call right away, we write where this batch starts and ends into a queue, and keep writing into the buffer. When the buffer is full, we unmap it from system memory, and send all the queued draw calls at once. This saves on the expensive operation of mapping and unmapping the vertex buffer for each batch.



As we were trying to figure out how to serve data to the GPU in the most efficient way, we were also experimenting with what kind of data to send to GPU. The less data we send, the better, and Allegro was using 6 vertices per sprite with a total size of 144 bytes. We wanted to do point sprites which would require only 48 bytes per sprite and less overall maths for the CPU to prepare a single sprite. Our first idea was to use instancing, but we quickly changed our mind without even trying, because when researching the method, we stumbled upon this presentation specifically warning against using instancing for objects with low polygon count (like sprites). Out next idea was to implement point sprites using a geometry shader.



We tried it, and it worked great. We got some speedup due CPU needing to prepare less data, but when doing research how different APIs work with geometry shaders, we found out that Metal (and therefore MoltenVK) on macOS doesn’t support geometry shaders at all. After more digging, we found an article called Why Geometry Shaders Are Slow. So we tested using the geometry shader on a range of PCs in the office, and found that while it was faster on PCs with new graphics cards, the older machines took a noticeable performance hit. Due to the lack of support on macOS and the possible slowdown on slower machines, we decided to drop the idea.

It seems the best way to do point sprites is to use a constant buffer or texture buffer to pass point data to a vertex shader, and expand points into quads there. But at this time we already have all the optimizations mentioned in the first part, and the CPU part of rendering is now fast enough that we have put the point sprite idea on ice the for time being. Instead, the CPU will prepare 4 vertices per sprite with a total size of 80 bytes, and we will use a static index buffer to expand them to two triangles.

The following benchmark results are from various computers. The benchmark rendered a single frame at max zoom out (about 25,000 sprites) 600 times as fast as possible without updating the game, and the graph shows the average time to prepare and render the frame. On computers with integrated GPU there was little improvement because those seem to be bottlenecked by the GPU.



We also noticed higher speed-ups on AMD cards compared to nVidia cards. For example in my computer I have a GTX 1060 6GB and Radeon R7 360. In 0.16 rendering was much slower on the Radeon than on the GeForce, but with the new renderer the performance is almost the same (as it should be because GPU finishes its job faster than the CPU can feed it draw commands). Next we need to improve the GPU side of things, mainly excessive usage of video memory (VRAM), but more on that topic in some future Friday Facts...

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

Sanqui has been quite effective these last weeks getting stuck in with the mod portal, so we have some interesting additions to talk about.

Mod deprecation
A modder can mark a mod as deprecated, which indicates they are no longer updating or maintaining it. The typical case is a mod will add something relevant for the current version of the game (E.G, a mod to scan the players starting area), and then an update to the base game makes the mod obsolete. Just deleting the mod could potentially cause problems for people playing an older version, people might ask what has happened to it etc.



Marking as deprecated will keep the mod up on the portal, but it will be hidden from any public searches. This way people downloading using 'Sync mods with save' feature can keep playing, while new players won't stumble upon a mod that is no longer useful or up to date. It also preserves the downloads and discussions in case the author wants to revive it later.

Collaborators
It is often the case, that a mod author will want someone else to help them maintain and manage their mod, for instance if they are going on holiday when a major release is coming out. The way it has worked in the past, another modder would have to come and upload an updated version of the mod under their own name. Now a modder can set another player as a 'collaborator', which means they can help out will all the maintenance of the mod. Collaborators can do everything the author can do, except add or remove collaborators.



You might also spot the other feature, transferring mod ownership. This lets the author give the mod completely to a collaborator, in the case that they are no longer interested in working on the mod at all.

Discussions notice
Mod authors can now display a notice above their mod page discussions, informing the users of any useful information. For example, an author might prefer you to report bugs on their GitHub page, so the notice will inform users of where they should go. An additional option allows the author to disable the discussions completely, in the case they have their own forum/thread somewhere for discussions.



If you have any ideas for an improvement to the mod portal, please let us know on our Mod portal discussion subforum.

I feel that none of the propositions in the previous Friday Facts were really that great. We spent some more time thinking about the blueprints and the blueprint library while going through the player feedback, and we are now agreeing on what I like to call Proposal Zero, because it was the first idea and the first mockup I ever made related to this subject. Put simply, blueprints stay as items, and the blueprint library becomes a regular inventory, like a chest (that is of course accessible across all your saves).

The idea goes together well with the "quickbar is an action bar" idea explained in the FFF-191. The details and mockups for the action bar are taking shape, so expect more about it in a future FFF.

When working on GUIs, I like to create design documents where I try to explain how something works as objectively and as complete as possible. It ends up sounding like a boring legal document, but it helps force me to think of all the corner cases and possibly find problems. I will use this opportunity to also tell you how we usually work on the GUI. Here is what I have written so far:Blueprints and blueprint library Proposition Zero:

• In the text below, Blueprinting Tool = Blueprint, Blueprint book or deconstruction planner. Library = Blueprint Library. Book = Blueprint Book.
• Blueprinting Tools stay as items, they interact consistently throughout the game.
• The blueprint library: One window with one grid of large (or small?) spaces. The grid expands infinitely on a row-by-row basis (if any item is placed in any slot of the last row, a new row is added). This grid act almost identically as a chest. Items can be manually moved there, or fast transferred using any of the shortcuts that work for normal inventories (see comment below). This inventory grid can only hold blueprints, books or deconstruction planners.
• Special behavior: when picking up a Blueprinting Tool from the blueprint library, it is replaced with a "hand". This means that when pressing Q to drop it, it is not returned to the player inventory, instead, back to that slot in the blueprint library. This is so blueprints can easily be used directly from the library.
• The functionality of automatic blueprint library sharing in multiplayer is removed. The "shared blueprints" panel is removed. Blueprints and blueprint books in multiplayer will be shared by manually trading the items or by linking them in the chat. Blueprints or books linked in the chat can be clicked to pick up a copy that can be used as a normal item.
• Every Blueprinting Tool will have a unique identifier, so every blueprint item is unique, even if it has the same contents.
• The blueprint editing interface (the UI that opens when you right-click a blueprint) will have 2 new buttons:
  • Reassign: assign new contents to this blueprint. This is helpful when you want to update a blueprint and leave it in the same place in the player inventory, blueprint library or action bar.
  • Duplicate: create a new blueprint with a different unique identifier, but the same contents, and place it in the player cursor. This can be useful when players want to take a copy of a blueprint from the library to edit, experiment with or remove buildings from, without changing the original blueprint.
• Shortcuts to Blueprinting Tools can be created from the player inventory or from the blueprint library to the action bar:
  • Right clicking a shortcut to a Blueprinting Tool will open the blueprint editing interface, as if it was right clicked in its original location.
  • If a Blueprinting Tool is moved between the library and the player inventory, the shortcut in the action bar remains valid and unchanged.
  • If the Blueprinting Tool is moved outside any of these inventories (e.g., placed in a chest, or given to another player), the shortcut will become greyed out and cannot be interacted with, only cleared. If the Blueprinting Tool is placed back in the player inventory or blueprint library, the shortcut becomes valid again.
  • If the Blueprinting Tool is removed (or destroyed) from the library, and a different game is loaded that had a shortcut to that Blueprinting Tool, the shortcut will become greyed out forever, and it can only be cleared. This is to give feedback that there used to be a Blueprinting Tool there.
  • If a Blueprinting Tool is explicitly destroyed using the trash button, the shortcut will become greyed out forever and it can only be cleared. This is to keep consistency with the two rules above.
• Blueprint books will work very similarly to the library: it will be an inventory which can hold only blueprints (maybe also deconstruction planners?).
• Blueprint books will have the same sparse grid where you can arrange the contents as you like. 'Shift + Mouse Wheel' will move to the next/previous non-empty slot.
• Blueprint books will not have any special behavior or interactions while in the library, right clicking them will open the book in a separate window, possibly closing the Library. Clicking them will pick them up to the cursor.
• Blueprinting Tools are created using buttons in the Library. Blueprint string importing will also be there.
• Quick Copy pasting will be done using new copy-paste functions that work almost identically to blueprints. Pressing 'Ctrl + C' will place a copy tool, similar to a blueprint in the cursor. You can use this select a number of entities to copy. Pressing 'Ctrl + V' will place a quick paste tool in the cursor, similar to a blueprint with items. You can use this to place as many copies of the things you copied as you like.
• The quick copy and quick paste tools are not items. Pressing Q will simply clear the cursor and not return anything to the inventory.
• The quick copy and quick paste buttons will also be shown in the main GUI, next to the action bar. Hovering over the paste button will show a tooltip of the blueprint that is currently in the 'clipboard'.

Comments:

• Being able to use all the fast transfer shortcuts in the blueprint library makes it very consistent with a chest, but can lead to very nasty situations where one accidental click can transfer all the blueprints and books to your inventory, completely screwing the order and organization you had in the grid. At the same time "transfer everything" can be something some players might use often if they don't have many books.

Other:

• The blueprint editor GUI should allow you to zoom and pan around to better inspect it. You can add buildings while holding an item or ghost item from the action bar; for convenience a small interface will give you the possibility to place any ghost item in the cursor. This is intended for quick corrections. Things like connecting cables or changing entity settings will not be possible; for bigger changes use the Reassign button.
• The blueprint library button will be disabled until bots are researched or until any item is added to the library for the first time. This means less GUIs for new players to get lost in, also less of an invitation to use the controversial string importing at the beginning for the game.

Usually I create a very crude and simplified MS Paint mockup of any changed GUIs.


I use all this, the design document and mockup, to present the idea to the other devs, make some changes, and if we all mostly agree with it, all this goes to Albert so he can more thoroughly design the look and arrange all the GUI elements. There is usually a lot of back end forth between us so we can properly tie UI and UX together. After the mockup is finished, one of the programmers, usually Oxyd, Dominik or I(Twinsen) start putting it in game, with the help of kovarex who makes sure AGUI has all the new functionality we need in the back-end. After we have the interaction in the game and we are able to play with it, there is of course further tweaking.

Well, the process I wrote about is the ideal case, in reality every different part of the UI is done slightly differently, especially since we are still at the beginning and we are still trying to figure out the concepts of the GUI, but I hope we will be able to use this pipeline to go though the GUI like butter.

Let us know what you think of the proposed changes to blueprint on our Forum.

While working on the GUI, we reached the infamous blueprint library, and we started talking about how to improve it. This lead to discussions about how we can improve the entire system of blueprints. The problem was not simple at all, and these discussions have been going on for a few days.

The current version of the blueprint library has several problems:

• Clicking a blueprint in the blueprint library means creating a blueprint, almost always. So if you click the blueprint library blueprint to build something and then press the Q key to clear the cursor, it goes into your inventory. This can easily lead to random blueprints slowly cluttering your inventory as you use blueprints directly from the blueprint library now and then.
• As blueprints in the game and in the library are two separate things, the players need to manually check that the blueprint library version of the blueprints are up to date. Once you play more games and use the blueprint library to share the blueprints between them, which is the reason for it to exist, it naturally happens that you end up having out-dated versions of blueprints in the library, as you changed them in the previous game, but you forgot to update them in the library. Also, updating the blueprint library isn't easy, as when you update some of your blueprints in the game, you have to search the corresponding original blueprint in the library, remove it, and move the new version to the library. A process which is annoying at the very least. I find this point to be the most troubling, as we want people to upgrade their blueprint layouts as they play, not just mindlessly copy-paste the first version of the blueprint they figured out over and over.
• The standard way of putting new blueprint into the blueprint library just puts it at the end of the blueprint library, and deleting any blueprint moves everything under it around. This means some blueprints are constantly changing positions and are hard to find.
• Once new players open the possibility of making blueprints, it opens many things at the same time for them. Construction robots, blueprints and their creation, deconstruction planners, blueprint books and the blueprint library. The easier (smaller) can we make this step, the better.
• Other UI annoyances such as exporting and importing blueprints through the obscure "Drop here to move blueprint" box.

• First of all, blueprint library and blueprint books will not have this list of blueprints. It will have a grid similar to the one in inventory, so you can arrange the blueprints better.
• There will be a way to do copy-paste quickly without having to create a blueprint. This solves one of the biggest sources of inventory cluttering, as now you have to make a blueprint for every copy-paste which ends up in the inventory after pressing Q. The most probable idea is, that pressing Ctrl+C would activate the 'copy' tool. You select what you want, confirm the selection with the blueprint dialog. After that, whenever you press Ctrl+V, you activate the last copy. Very similar to how computer clipboards usually work.

Apart from this, there is the problem of how to resolve the rest of the blueprint library problems.

This would be implemented together with the quickbar is just an action bar idea explained in the fff-191. The idea is, that blueprints would never be items. Quite an extreme change, as it would mean, no blueprints on belts, no blueprints in chests etc. In this scenario, we could still allow a mod to create/allow blueprints as items, but it wouldn't be the vanilla way to do it.
If you create a blueprint, there would be 3 things you could do with that.

• Use it (or not) and press Q, the blueprint would be destroyed. The reason for this, is that we want players to put blueprints explicitly in a slot or the library, instead of cluttering the main character inventory.
• Put it into the quickbar. The blueprint (or book) stays in the quickbar until it is removed or replaced by another blueprint. It is not in the library.
• Put it into the blueprint library, by opening it, and explicitly selecting a slot where to put it.

You can use blueprints directly from the quickbar or from the library. You can also pick a blueprint from the blueprint library and place it in the quickbar.
The tricky part is in the last point. There would be basically two kind of blueprints in the quickbar:

• Blueprints that are only in the quickbar, so it is the stores all the blueprint data.
• Blueprints that are just a reference to the blueprint library. This itself is quite a weird thing to have.

In this proposal, blueprints exist as regular items again, but to solve the problem of having two different versions of the blueprint in the game and in the library, blueprints could be linked. This means, that moving a blueprint from the library to your inventory would make the link with the library. Making any changes to the blueprint would automatically update the blueprint library version and, upon loading any other save that has blueprint linked to the same blueprint, the blueprint in the inventory would be also update to the new version.
This looks nice and all, but it has its own collection of problems.

• There are two kind of blueprint items now: blueprints that are only in the inventory and blueprints are also linked.
• What happens when you put your linked blueprint into a chest, is it still linked?
• What happens when your linked blueprint in a chest is picked up by another player?
• What if you have two identical blueprints in the library that are both linked to each other. Will the player always understand that changing one will change both?
• And many more...

It kinds of leads us to not liking this option too much as well.

There would 10 slot blueprint bar under the quickbar (or action bar). It would be the only possible storage for blueprints, so no blueprints as items and no separate blueprint library. It would have unlimited amount of pages that can be added/removed/selected. This blueprint bar would be shared between all games.

The advantage of this is simplicity and straightforwardness, that there is suddenly only one kind of blueprint (instead of 3 in Proposal 2). No need to transfer from inventory to library and back. The storage and place where it is used from is the same.

The disadvantage is mainly the fact, that it isn't integrated with the quickbar (or action bar), so you can't use the default 1-10 shortcuts to access it.

Again, this goes together with the quickbar is just an action bar idea explained in the FFF-191. Additionally the action bar will have multiple pages of shortcuts. You can select what page of shortcuts you want to use in which of the 2 displayed bars. Something like this:



This is similar to proposal 3, but with blueprint-bar and action-bar merged. The action bar (with all the pages) would be shared between games. Blueprints could only be stored in the action bar.

I personally like this the most. Even the description of it is stupid simple. You just open different save, and you are guaranteed to have access to all the blueprints and action bar selections you created in the previous game(s). You can use keyboard shortcuts to access blueprints, you can combine pages of action bar of items and blueprints to your liking. For example, action bar with rail building would have rails, signal, locomotives, wagons, and different kind of rail building blueprints(or books).

The disadvantages of this solution are the limitations. If we keep the amount of action bar pages to 10 for easy access through keyboard shortcuts, it implies limited amount of space for the blueprints. I personally wouldn't see it as a problem as it is 10x10 slots should be enough for everyone right? :) But seriously if at least 30 should be free to be used by blueprints, and since we have blueprint books that have unlimited storage size, the amount of blueprints you could store would still be unlimited, only the amount of books (categories) would be limited.

How many people out there would have actually problems with the limitation of having around 30 blueprint books? Obviously the second solution is to allow more than 10 pages of quick bar, but it would come with different kind of problems.

The second problem that might be the fact, that you can't make a blueprint "just for this game" without putting it into the library. I personally don't see it as a problem, as the whole point of the blueprint library rework is to avoid the problems of merging two kind of storages of blueprints. This would force the player to have only one.

The third problem of this might be the fact, that the blueprints are not items anymore. Some people might prefer to store their blueprints in chests over the map in certain way. For example, putting oil setup blueprints in their oil setup map area etc. This wouldn't be possible anymore, as the blueprints would always have to be in the action bar somewhere.

As you see, it is quite a tough problem, and it is cases like this where your feedback is even more valuable than usual, so please let us know what you think on our forum.

On Monday June 18th, we marked the last version of 0.16 as stable. There were no major problems, so now we are almost exclusively working on 0.17. Work on 0.17 is progressing well:

• Regarding the new campaign, we are already internally playing a rough version of the new player experience.
• We are still trying to figure out the exact and final style and concepts for the improved GUI, but we have some GUI windows implemented in game already, plus many base widgets. We use those to get a feel of what works and what doesn't.
• The new graphics back-end rewrite is nearing finalization. A closed-beta branch was sent to a few players to test that rendering works correctly across different hardware. The rendering is faster and no major issues were reported so far. But there is still much to do, such as improvements to VRAM usage and many experiments with shaders.
• Since from the graphics department Albert is working on the GUI and V453000 is working on the new campaign, only Ernestas is left working exclusively on the entity graphics. He is reworking some more entities for high-resolution, so expect some teasers in the future.
• There are of course other small projects that are ongoing, such as improved pipe-fluid physics and improved map generation, but more on those when they are fleshed out.

Oh, and our coding always goes as planned without any problems.

With every major version of Factorio, we work on improving the Lua API and modding support. In 0.17 I've been looking at cleaning up my back-log of things that I've wanted to implement for quite some time but never got around to. Things such as:

• Sync mods with a server you want to join.
• Having multiple versions of a mod installed and being able to switch between them.
• Letting mods set entities to not require power.
• Adding support to clone entities/areas of the map from one location to another.

And in general looking at "hacks" that mods are currently doing and seeing if it's reasonable to make the game support what the mod was trying to do in a non-hacky way. Bilka and I have been going over the Mod Interface Requests section of the forums and cleaning it up; implementing things that make sense and taking care of outdated or won't-implement requests. Time and time again Bilka will ask "why can't I do X with a mod?" and the answer is almost always "because nobody asked for it so nobody added support for it". So with that said: if you're a mod developer and think the mod API is lacking something feel free to stop by the forums and ask for it.

A few weeks ago Demod was showing us some 3D printed belt keychains he made, and mentioned he wanted to send some to us. I showed it in our team slack channel and many us wanted them. A lot of 3D printing later, he sent us a nice package with gifts for most of us.



You can't receive fan mail without receiving some hate mail. We also received an anonymous package telling us to "eat a bag of d*cks", along with a bag of tasty gummy d*cks. The truth is I know who sent it and it was just a small practical joke. They were trying to show their frustration with the matching server in a friendly-funny way. We thoroughly enjoyed shoving them down our throat.



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

Earlier this week I received an unusual number of support emails, some players were having trouble redeeming their Steam keys on our website. In each case, the key they purchased was not a key eligible for a Steam key. Our order/account system isn't the most intuitive, so let me explain the ways in which people can buy the game, and how it relates to our website:

• Our website - You buy from our website, and you get a key from the Humble checkout. You use this key to upgrade an account, and you can redeem a Steam key.
• Steam - You buy on Steam, which adds it to your Steam account. You then link your Steam on our website, which upgrades your account.
• Humble Store - You buy a Steam key, which you activate on Steam, and then follow the steps above.
• GOG - You buy the game on GOG, which lets you download the DRM free version. You can also redeem a retail key, to upgrade your account.

So in the cases above, the only way to get a Steam key from our website, is by buying directly on our website. The players in question managed to get their hands on 3rd party retail keys. These retail keys aren't distributed for reselling anywhere, so the fact I was seeing a lot of emails coming in about these keys, was an indication something fishy was going on.

The source of these keys is GOG, I double checked this my comparing some of the keys these people purchased with the list of keys we generated for GOG, and they matched. My first suspicion was someone cheesing the GOG return policy, buying the game, redeeming the key, and then refunding it. I emailed our contact and there were only 21 refunds in the last 3 months, so it was not the case.

The second suspicion was that the GOG server was breached somehow. They reported no incident, but we disabled all the unredeemed keys anyway just to be sure. I checked with the list again, and none of the keys that we deactivated were used by any account. This led to the conclusion, at the very least, these keys were purchased legitimately.

So people are legitimately buying keys, GOG confirmed sales had shot up in the last week. Then the question, where are the sales coming from? One last email to GOG and we had our answer: Russian Federation. The reason? We have regional pricing on GOG at parity with Steam, which means someone buying from Russia could buy the game for ~$8.30. Once they buy on GOG, they can redeem the retail key, and sell it for about $20 on a 3rd party site. So one clever guy saw this opportunity, and started buying the game hundreds of times on GOG. The immediate solution is to remove the regional pricing, and in the long term we may be able to implement some 'GOG linking' similar to the current system for Steam users.

It is strange that it was only taken advantage of recently, as we have had regional pricing since our launch on GOG 2 years ago. It may be related to the recent price increase.

At the end of March, around when 0.16 was first made stable, we announced the price change from $20 -> $30. I thought it would be interesting to see what affect it had on sales, and as showing it better than telling, here is a graph of units sold between February and June:



It is quite clear there is a huge spike when we announced the change, and again just before we implemented it, but more interesting is the comparison from before and after. You can see that there is a noticeable decrease in sales before and after, but overall it is still quite strong and consistent. This reflects most of the player reaction to the announcement too, many people were commenting that they support the price increase, and believe the game is still worth the asking price (if not more).

Regardless of the recent changes, we have had consistent week-on-week sales of the game since our Steam launch, and we are fast approaching 1,500,000 copies sold. I think in part, this is due to our no sales policy, but that is a discussion for another day.

We were all excited early this week, when we saw the reveal of another title in the automation and simulation genre:

https://www.youtube.com/watch?v=W_lmP8jYVLs

From the point of a player I would say that the trailer looks amazing. The energy of it, the looks, the potential, the promise is fantastic. I don't doubt that our office will be playing from the day 0 once it is released. Let me quote /u/european_impostor by saying: "They've certainly talked the talk, now let's see if they can walk the walk".

From the point of a Factorio developer, I would say that it makes me proud and insecure at the same time. As the game is undoubtedly inspired by Factorio, it makes me proud that we most probably helped to make this "genre" become a thing. It makes me insecure as well, as it could also completely overshadow our game. To that, I would say, that if they managed to do a game that is better then Factorio on every level, then they deserve it. If there are still going to be areas where Factorio is better, the potential success of the game can actually help us, as when more people come to play the game, more people will eventually look for alternatives in the similar way as the people asking for "other games like Factorio" from time to time.

If there is some takeaway for us, then it is, that we shouldn't wait with finishing the game too much. Let us know what you think on our forum.

• Changed the battery item icon to be more consistent with the technology icon.
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

• Fixed loading script data when a mod is disabled. more
  
• Fixed that 0 time interval was shown as an empty string. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around.





But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed:



Eventually, we figured out, that we are not the first one trying to solve the problem.The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:

The load game dialog is currently the first dialog we are trying to implement with the new tileset and the mockup Albert created recently. The mockup looks like this:



The idea is, that all the dialogs will have this flow from left to right, on the very left, you go back, on the very right, you continue to the next window. The same logic would be consistent in all the dialog windows. Options for example, have only the Back button in 0.16:



It is currently quite weird, as it is not clear whether it is confirm or cancel. Actually, if you press Escape you exit the options without saving it, but if you press "back" you confirm the changes.

So these will also have cancel on the left and confirm on the right. Escape is the same as clicking back.



Please note, that all of the pictures are work in progress.

Hopefully you are not getting tired of hearing about the GUI, because this game sure has a lot of them, and the next one to talk about is the Map Generator GUI.Since we will have high-resolution spreadsheets for the GUI, all the mockups below are done on 200% UI scale, so they are scaled down on this page. You can click each image to see it in full size.

You will notice things were moved around quite a bit. The seed and the replay toggle were moved to the top since they are not part of the preset. Then the preset dropdown, the reset to default button and the description, which are visible at all times so you know what you are editing. Everything inside the tabs is part of the preset.





A new tab is the Enemies tab. The generation settings (Frequency, Size, Richness) are moved from being hidden in the terrain settings, to it's own category. Also the important Peaceful Mode is right at the top.




Finally the advanced tab contains the rest of the settings. Map width and height will now also be part of the preset.




The map exchange string can help you save all your settings in a string, but more importantly to share it with others. Clicking one of the buttons opens an in-window pop-up. The pop-up can be closed just by clicking outside. Player can use the "copy to clipboard" button, but can also copy directly from the textbox.



Now for the neat part: the map preview will be part of the map generator window. Clicking the "Preview" button expands the window (possibly with some quick animation). You can then change the settings as you like, then click Update to see the new map. You can have the map update automatically as you change the settings, by enabling the option. "Real-time update" is off by default since the preview generation can be a bit slow, and having the preview constantly flickering as you change the setting would be pretty annoying.

Notice that the "Preview" button has a warning icon next to it (in the images above). Hovering over it will give you a warning that the preview can spoil the exploration part of the game and should be used to understand the settings. My hope is that the majority of players will open the preview, play with the settings, then close the preview and re-roll the seed before pressing play.


(click to view full size)

We plan that almost every widget in this GUI (and the of the game) will have tooltips briefly explaining what everything does, since for example not even us developers know what Enemy base Richness actually does any more.
As a bonus, here is a mockup with all the ores showing their richness.

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

• Fixed belts in blueprints weren't selectable in the blueprint GUI.
  
• Fixed bad mouse-point when holding blueprints with belts.
  
• Fixed wrong connectivity in underground belt fast replace. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.

• Fixed changing filters in cars wouldn't wake up inserters. more
  
• Fixed train driving directions when not accelerating while driving backwards. more
  
• Fixed copy-pasting between surfaces would render incorrectly. more
  
• Fixed that empty storage tanks had the sound of fluid. more
  
• Circuit connection distance check fix. more
  
• The logic that shows rail signal indicators now respects bounding box and collision box of the currently held signal. more

• Fixed allow_copy_paste only worked on the source entity. more

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.