Read this post on our website.Hello,
we just released 0.17.73, with 0.17.74 coming very soon. This is just some bug fixes and further pathfinding improvements, and we hope to be able to mark the release as Stable next week.
The new tooltips (Twinsen)
As part of our big GUI update, I've been working on one particular part: the tooltips. We worked not only on updating the style, but also how the information is structured and sorted, added missing information, removed irrelevant information. This concerns entity, item and recipe tooltips, but almost all tooltips were touched one way or another. Many things were changed. I will go through some of the more important changes.
The new look
First thing to see is the new style Albert has worked on. They now have the same general style as the technology tooltips. We tried to keep them as compact as possible, as sometimes there is quite a lot of information to show.
For the screenshots in this blog post, I set the background to be non-transparent. Unfortunately they don't blend very well with our blog background, but in game you will notice that they are slightly transparent and the also have a blurring effect. Together with the shadows, they integrate nicely in the game.
Categorization
As you may have noticed already, some common properties like electricity consumption are grouped into categories. Most of the work was defining these categories and trying to figure out what makes sense. These categories help grouping the information but also gives more context to some entity properties. Properties that are directly related to the selected entity type are placed in the "root" category that has no name. This is to avoid having pointless categories like "Inserter" and "Transport belt".
New informationThe place where the categorization really shines is in the tooltips of power generating entities. Now it's much clearer what each entity does and what the ratios are. Entities related to nuclear power were especially confusing. Creating an optimal nuclear setup was almost impossible without the help of the wiki. Now all the important information is there.
Entity tooltips and item tooltips generally show the same properties, but I tried to make the entity tooltips show state information when possible. For example, here's how the item tooltips above look when the entities are placed in the game. Categories are even more useful now, since properties like the fuel inside the machine or the state of the fluid output pipe can now be grouped inside the relevant categories.
Other entities have more properties added to them, such as inserter rotation speed, rolling stock weight, laser turret energy use per shot, flamethrower turret burning and slowdown effect, and many more.
Tooltip separation
The recipe tooltip was kind of a Frankenstein's monster of recipe information and item information mashed together. We also had the problem with what properties to show when a recipe has multiple output products. The solution was to split the tooltips and show a "multi-tooltip" when hovering a recipe,
Now, when hovering over a recipe in the crafting menu the recipe tooltip will be shown. An additional item tooltip will be shown for every product, as a separate tooltip, if the item tooltip has a description and/or properties to show. While this improves things quite a bit in vanilla, complex mods will benefit from it even more. Recipes can now have their own textual description and each separate product can be explained independently if necessary.
The same mechanism is used for the tooltip shown when hovering a logistic request in the character window.
This means that an item tooltip will look the same regardless if it's shown while hovering a recipe, an item in the player inventory or a logistic request. No more mixing of information.
Most of the implementation is done, just a few tweaks and bugfixes left to do, plus any changes based on your feedback. If all goes well, the new tooltips will be part of one of the next experimental feature releases, which we hope to release in the next couple of weeks. After that, more GUIs to come.
Construction robot tile batching (Rseding)
One of the things I've wanted to tinker with for some time is having a construction robot build multiple things at the same time. Construction robots spend the vast majority of their time just flying around doing very little work and can technically use the cargo capacity research but only ever use it for logistic related things.
https://cdn.factorio.com/assets/img/blog/fff-318-not-batched.mp4
One of the main things which stopped me from looking into this in the past was performance concerns: figuring out which thing(s) a robot can work on in a batch gets expensive very quickly and with robots existing in the 10s of thousands range I can't just make each one 5 times as expensive.
A few weeks ago I thought I finally figured out a way to at least make robots able to batch build tiles without loosing too much performance. The thing is: when tiles are built they are built in large square patterns so I can safely assume there will be other tiles to be built directly next to a given tile that hasn't already been assigned a robot to work on. After some experiments and then several re-works to optimize what was already quite fast I was satisfied with the result.
https://cdn.factorio.com/assets/img/blog/fff-318-batched.mp4
Of course, the next question people ask is: what about doing it for entities? I could, but it doesn't make as much sense for them because they aren't always 1x1 (performance drops off quickly as the size grows - tiles are always 1x1), aren't typically built in tightly packed squares like tiles are, and in the common case it would just make robots more expensive to run while rarely making them build faster. So, for now they just batch build tiles.
https://cdn.factorio.com/assets/img/blog/fff-318-batched-comparison.mp4
As a more direct comparison, Boskid made this nice setup using two forces with different cargo bonuses.As with the tooltips, the tile job batching will be released as part of our next experimental feature release, which we're calling internally 'Stable 3' (0.17.69 is Stable 1, 0.17.74 will be Stable 2). As always, let us know what you think on our
forum.
Check out our 
