Factorio - Klonan
Read this post on our website.

The Beacon Redesign (V453000)

The Beacon is one of the last entities that don’t have high resolution graphics yet. In the rather recent FFF-339, Albert presented the updated and redesigned Beacon. After your responses we realized some issues we hadn’t seen with the Beacon before, and we have taken some time to think about it...



The red tower design by itself is very impressive, which gave it so many plus points that we didn't focus enough on the fact that it is taking too much visual attention. In this case, this happens because of aggressive red colours, the big contrasty yellow eye-like circle, the entity being quite tall, and the electric beam animation. Random variations are usually helpful to make entities look nicer in clumps (like resources), but not in this case, especially as other built entities don’t have any variations.

The options to take from here would be to either update the original design, adjust the red tower, or start a new redesign.



The Beacon is a very special entity, either it doesn’t appear in a factory at all or very little, or it’s everywhere. It doesn’t really do anything by itself so it doesn’t really need to show much activity either.

The original design has its own problems and also saturates the screen very quickly, as they are bright, also tall, and they always move, attracting attention to the movement constantly.

As for the red tower, most of the top part would have to be removed which is almost a complete redesign already, but parts of the hole could be recycled for a new version...

We chose to start a new redesign, with the design goal of the Beacon trying to take much less attention.

The Beacon Re-redesign (V453000)

For everything we generally respect the idea of height, in the sense that the higher something is, the brighter it usually looks. The less important background is usually darker, while the foreground (entities) is usually brighter, especially at their top parts.

The red tower was put in a hole mostly to be able to create a really tall tower in a 3x3 bounding box yet not overlap the tiles above the entity too much.

What could be done instead is to put the whole Beacon in a hole entirely and therefore make it generally darker and less noticeable. This way we would change its idea from a tower to an underground electronic/powerful entity, and try to explain that the effect is being transmitted underground by cables.



Do notice that a lot of the meshes in the model are coming from Albert’s redesign, which was really helpful to get the new redesign done in a reasonable time.

The beacon is generally less saturated than any of the previous designs, which again makes it less intense, and makes it fit better in its typical habitat of concrete tiles, though it looks just fine on more natural terrain as well.

While the submerged design works well in terms of making the Beacon take very little attention away from the producer entities, there are multiple issues. Most importantly it doesn’t look like a Beacon on the first sight. As a side-effect, the Beacon starts looking very top-down without combating our perspective, though that would probably be possible to address by changing the design significantly.



And so a tower clawed its way back into the concept, to explain how the effect is transmitted. Just a slim and lightweight tower though, without taking too much attention.

The two black squares are actually module slots, and the Beacon now dynamically visualizes the modules inside.

This is conceptually questionable, as we definitely don’t want to start a precedent of adding visible module slots to every single entity, but the Beacon has no other use than the modules, so we think it's an acceptable exception.



The modules do take a bit more attention back again, but also remove some. With modules always visible, we could remove Alt-mode from the Beacon.

This means whenever you toggle Alt-mode on, you’re only seeing the overlay change on the producer entities.


See how much more breathing room do the assembling machines have in the screenshot above. As the Alt-mode overlay isn’t really useful most of the time on Beacons, we can afford to remove this visual clutter. It can of course be re-enabled by mods.



The module slots are procedurally tinted, so if a mod adds custom modules, it only needs to specify the tints at the definition of the module item without touching the Beacon at all.

https://cdn.factorio.com/assets/img/blog/fff-351-beacon-loop.mp4

It’s worth mentioning that one of the reasons why the Beacon got away without high resolution sprites for such a long time, is because it’s a late game entity for generally large factories, so the player mostly looks at them while zoomed out.

As you can see in the animation above, the tower has a subtle glow animation that explains the effect transmission when zoomed in, while almost invisible when zoomed out, trying to balance between being interesting close in, and non-disruptive far out.

The glow effect is also tinted by the colour defined by the module lights, in fact it averages the colour if two different modules are in the Beacon, which isn’t very useful for the base game but for some mods it could be a nice detail.



As usual, we plan to release the new Beacon next week.

Fluid Mixing Prevention - take 9001 (Rseding91)

The original concept of fluid mixing prevention sounded great: mixing fluids is (virtually) never desired - so let’s stop it from happening - that's simple. This is the part where the movie stops and the narrator says: "But it wasn't simple, it wasn't even close to simple..." To keep things short I'll just say: complexity compounded with more complexity and an entire game built without the concept of "fluids can't mix" meant over a year and a half later there are still parts that can't be handled "gracefully".

When the concept was first talked about it seemed... off. Mixing fluids is not desired - and the solution is to full-stop prevent it? But let’s take that same solution and try to apply it to something else: belts. Mixing belt contents is (mostly) not desired (people have gone full crazy and made setups around it... but that's another story). So what if the game tried to stop you from mixing belt contents? Sounds crazy to me.

But it happens: belts get mixed and it's not as big of a problem as fluids getting mixed - why is that? Because there's a quick and easy way to fix the problem: just 'hoover up' the items from the belt and its fixed. There's no quick and easy way to fix mixed fluids - you have to pull up the entire length of pipe to get it all out. Even if you don't mix fluids - but just get the wrong one in a pipe - it's still a huge pain to fix.

This idea isn't new - it was talked about back when fluid-mixing-prevention started - but it was recently brought up again and we decided to give it a try: simple fluid mixing prevention. Just try to handle the most common case - manually building things - and in the more complex cases where mixing might happen, provide a quick-and-easy way to fix it: a button to flush all of a given fluid from the pipes.

https://cdn.factorio.com/assets/img/blog/fff-351-fluid-flush.mp4

This new simplified system will be ready for release next week, so you can give it a try and let us know what you think.
Factorio - posila87
Graphics
  • New electric mining drill graphics.
  • Tweaked electric mining drill icon to be a bit more colorful.
Minor Features
  • Hovering over the circuit network id in the entity circuit control window will now show a tooltip with the circuit network contents.
  • Added experimental Color Filters graphics option to attempt to improve accessibility for color-blind players.
  • The debug setting "show-time-usage" now 'line wraps' if it doesn't fit on screen vertically.
Bugfixes
  • Fixed crash when merging force that contained unit groups. more
  • Fixed character preview being empty when the character is in a vehicle.
  • Fixed script error when trying to load old PvP save games. more
  • Fixed setting vehicle driver/passenger to an offline player would crash the game. more
  • Fixed 4th parameter of noise.terrace function was parsed as literal number but was used as noise program register index. more
  • Fixed an issue with modded entities having an electric output flow limit of 0. more
  • Fixed that furnace recipe auto-selection didn't work correctly with temperature ranges. more
  • Fixed that LuaUnitGroup could be used while in an invalid destroyed state.
  • Fixed button for selecting signal or number would not switch from number to signal with left click. more
Modding
  • Changed mining drill graphics definitions. Graphics are now defined using working visualizations contained in graphics_set and wet_mining_graphics_set prototype properties. If graphics_set is not defined, old animations property will be loaded instead for limited backwards compatibility, but other old graphics properties will be ignored.
  • Mods can now be loaded from directories with the name of the mod but no version number.
  • Added color_filters to utility-constants.
  • Input fluid box with connection set to output or input-output will not have volume forced down by recipe fluid ingredient amount.
Scripting
  • Added LuaSurface::show_clouds read/write.
  • Added LuaPlayer::stashed_controller_type read.
  • Added LuaBootstrap::register_on_entity_destroyed().
  • Added on_entity_destroyed event fired after an entity registered with LuaBootstrap::register_on_entity_destroyed() is destroyed.

You can get experimental releases by selecting the '0.18.x' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Read this post on our website.

Electric mining drill redesign (Ernestas & V453000)
The electric mining drill is one of the older designs still in the game, and we have had our eye on it for a long time as a candidate for redesign.

We would have loved to rework the mining drill in 0.15 when we added high resolution graphics and the pipe patch for it, but we had many nuclear related graphics to do for 0.15, so we just did the necessary minimum and postponed the full redesign. Now was finally the time we could unleash Ernestas onto it.

The old design
The most problematic aspect we see is the weak radial animation that’s more like gently harvesting a field, rather than aggressively mining and destroying the planet.



The original mining drill is also very flat like a top-down square. In general we try to avoid square entities like the plague, as they tend to look disintegrated with the world because they don’t try to hide that their perspective isn’t correct.



The pipe patch for uranium ore mining makes the mining drill look like a different entity as it is massive compared to the ultra lightweight drill. Now that we can account for the pipe patch from the start of the design process, we can make it better integrated.

The new design
The drill bit is the part that does the action and therefore is the main characteristic for the entity. We spent multiple iterations trying to find the right shape for it first.

We tried a tricone, four metal drills, a cone shaped drill bit, and none of them worked. Mostly the problem was visibility or too many details, which became even worse while drilling. Having a small pixel area is what usually limits us on what we can create, and also things need to be recognizable from far away.



Through trying various options, we chose to use a similar solution to the burner mining drill, as that is already established in the Factorio language. It makes it clear that the miners are one family of entities.



The old animation had one big benefit - it could work non-stop and move around the collision box so it looks like it’s harvesting from various tiles. With the new construction of the drill, it has to lift to move around. However, the drill can be outputting resources even when the drill bit is lifted, so we have added a working LED and a tintable layer for resources being dropped to the output, making it clear when the drill is in a working state.



Since the movement of the drill is procedural and Ernestas was smart about optimizing the spritesheet space, we can save a lot of VRAM compared to the original mining drill (about 40MB). We were considering a lot more additional animations but it would multiply VRAM requirements too much, or it would become too procedural and too complicated to implement.

The resource layer, the pipe contents and the smoke emitted by the drill bit are all tintable layers, specified by resources, which make it very dynamic and mod friendly.



The remnants ignore rotations, but have 4 variations. Typical mining fields usually use only 2 rotations anyway, so this way it always looks a bit nicer.

Click to view full resolution

The sound of the mining drill has also been updated. Unfortunately Factorio does not support multiple working sounds per entity, which also means we can’t synchronize sounds with the animation. So Ian had to invent a sound that would work nonstop. Since there is almost always more than one mining drill working, it should be fine.

https://cdn.factorio.com/assets/img/blog/fff-350-08-new-drill-animation.mp4

We were finishing the mining drill in the last few weeks so we couldn't release it with the new icons. We didn't feel like creating a new icon for the old design and found it to be a cute little hint that the redesign is coming. Hopefully the confusion why the new icon looks completely different to the entity will be cleared up next week when we release the redesign presented in this post.
Factorio - wheybags
Graphics
  • Reworked Engine unit icon.
  • Tweaked the color of Sulfur icon.
Changes
  • Updates to mini-tutorials.
  • New descriptions for mini-tutorial list.
Features
  • Added support to manually set several paths through the config.ini [path] file. 'saves', 'scenarios', 'mods', 'archive', and 'script-output'
Bugfixes
  • Fixed choose-elem-button filters not being respected when clicking the button with an item in hand.
Scripting
  • Added LuaEntityPrototype::grid_prototype read.

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Read this post on our website.

Hello, today we have some big news.

The 1.0 plan (Klonan)
In FFF-321 we announced a release date for version 1.0. Given recent events we have decided to make an amendment to the date of 1.0.The new date we are aiming for is Friday August 14th 2020, which is 5 weeks earlier than the original date.

The main reason to change the release date is the release of Cyberpunk 2077.In January this year, CD Projekt Red announced a delay to the release of Cyberpunk 2077, to September 17th, 1 week before our Factorio 1.0 launch.We think any release close to such a monumental game is going to feel some negative effects, such as everybody playing and covering Cyberpunk and taking attention away from other games.

So we thought it was best to try release either before Cyberpunk or quite a while after it.Given the two choices, we opted to bring the release date forward. There are several reasons why we are choosing to release earlier:

Descoped goal
When we announced the date (FFF-321), we had plans for many things to be in the final release. The main topics were the new campaign, fluid algorithm improvements, and the full GUI rewrite.Due to independent reasons, we have cancelled the new campaign (FFF-331), postponed the fluid improvements, and cut a lot of the aspects of the GUI rewrite (FFF-348).

Staying on schedule
Apart from descoping some features, the other work we've been doing has been progressing at a good pace. The 0.18 experimental release structure (FFF-314) is really helping to keep things on track.The original estimate was made with some concession for delays, that "things always take longer than expected".Well for the last 6 months, most things haven't been taking longer than expected, and we've been finishing topics quite effectively.

The sooner the better
The general feeling in the office is that the game is pretty much done, and that we want to get it released as soon as possible.The sooner we get some closure on version 1.0, the sooner we can start thinking about fun and exciting new things.


So due to the co-incidence of cancelling several major features, we can afford to bring the release date forward. To be clear, we didn't cancel or postpone any features due to the Cyberpunk release date.

This new release date gives us 10 weeks, and from this point until Friday August 14th, the main focus for the team is on finalising the game, updating the trailer, and preparing marketing materials.



Locale plan and Locale freeze (Klonan)
One part of finalising the game comes in finalising the community translations of the game. For a long time we have used Crowdin for sourcing all the translations. Crowding has worked really well, and is deeply integrated into our workflow (FFF-48).

However some languages are not 100% covered, and there has not been any overall proofreading. For this reason we chose to look for a professional translation company to help fill in the gaps and proofread everything. We specifically needed a company that will work through Crowdin, as the community there has years of experience with the game, and the system won't need any management on our side.

After consultation with many companies and many other game developers for their thoughts, we have decided to partner with Altagram, based in Berlin, Germany.

With the final GUI update finished, we have frozen the locale, which means no more additions or changes (as much as is reasonable). There will be a proofreading of the English source texts, and after that a proofreading of all the target languages.

For absolute clarity, Altagram has detailed the plan and the process from their perspective:

    Once we get the greenlight that the community has completed their contributions to the translations in Crowdin, we’ll start proofreading the English source text to offer any grammar or stylistic improvements, as needed. Once the English is polished, we’ll get started on proofreading for the secondary languages.

    The linguists, who are all gamers themselves, and experts in game localization, will work their magic to ensure that the target language is as true to the source text as possible, to ensure that all players of Factorio, regardless of the language they play in, will have the same experience.

    Some things that the linguists will check for when proofreading the target language are: Ensuring that the text itself, especially all in-game terms, is consistent throughout; that spelling and grammar is correct; and that the translations carry the same meaning and emotion as intended.

    After we offer our suggestions, the texts will be sent back to the community for their final approval before implementation into the game.
From now until 1.0 release, Locale freeze mainly means that we'll only be working on topics that don't require new strings, such as bugfixes, new graphics, sound design, etc.

Prototype Explorer GUI/Prototypes GUI (Rseding)
Inspiration
Factorio has a lot of debug features and tools built into it over the years. Some of them are used extensively (show FPS/UPS) and others we wonder how we ever did without (GUI style inspection tooltip). Every one of them was added for a purpose and then ended up providing far more utility than its original purpose. With that in mind, and because they also end up being a lot fun (to me); I was working on fixing an issue I found with the GUI style inspection tooltip logic and thought to myself: wouldn't it be nice to have something like this for all the prototypes in the game? Is that even something I could do realistically? How would it look, how would it handle all the nesting that happens... but it sounded fun.

And so I decided to see what utility such a thing could have:
  • Figure out if a mod has tweaked or changed something - or if it was supposed to and didn't (common in modded bug reports and during mod development)
  • Provide a place to extract information that the game doesn't show anywhere else (not everything is exposed through the mod API, and it's unrealistic to expect anyone to remember the entire API)
  • Link from game concepts to the wiki explaining more about them.
The list of benefits seemed worth at least tinkering with the idea.



Technical design
The first part I needed to figure out was - how was I going to get everything shunted into a GUI. Factorio is written in C++ and C++ does not have reflection. There's no easy way to say "for all of the variables this thing has, do this". Really the only way to get everything covered is to send each thing to the GUI. It's not pretty, but we also don't make changes to prototypes frequently at this stage in development. Additionally, if something is "wrong" it doesn't cause crashing/errors; it's an easy fix that anyone can do. A lot of boring typing later that part was covered.

Nothing is ever easy or simple
For each thing to show: show the name, show the value, show the type. It sounded simple but it never is.
  • The type can be incredibly verbose and or just useless to a human: what does this even mean? "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >" (it's a string...)
  • The value can be huge - so collapsing needed to be created
  • The value can be an array of something, so "empty" should be shown for empty arrays
  • Arrays of things with 1 value really should just show the 1 value
  • Optional things should show "empty" when not set
  • Some things will link to another thing so linking needed to be create
  • All of this has to work at any nesting level
But that's Factorio, and the polish is what makes it nice to use. I don't regret any of it.

Wiki linking
Near the early stages of development I decided that the easiest way to convey to anyone using this what some "type" is and how it's supposed to be used is to show the wiki page about it. The wiki has very detailed information about a lot of what this was going to be showing and it seemed only logical to utilize it. But I didn't want to hard-code links... that never ends well.

My idea: a page on the wiki that provides a mapping of game type -> wiki URL. The game would download the mapping and as it filled in the GUI if it found a type that existed in the mapping it would link it to the wiki. Bilka got the wiki side of it quickly setup. The game side... "nothing is ever easy or simple".
  • I didn't want to download the wiki page every time the GUI opened - that would be a waste
  • I didn't want to download the wiki page every time the game launched - the page wouldn't change frequently and so would be a waste
  • But the page still needed to be re-downloaded when it changed
  • I didn't want the game to pause while the download ran
  • It needed to be fault tolerant (not everyone has an internet connection, or can even say the page will download correctly)
And so, a simple "link the type to the wiki" turned into:
  • It remembers the last time it downloaded the wiki page and what the revision ID was
  • It only tries to download the revision ID the first time one of the GUIs is opened
  • If the revision ID changed, or it didn't have the mapping locally, it tries to download the latest wiki mapping
  • If the download succeeds, it saves it for next time and populates the GUIs links
  • If any of this fails it logs what went and silently continues running (this is a the internet after all, random failure is expected)
  • It all happens in a background thread so the game doesn't pause while this logic works
And it all works perfectly.



Native Lua serialisation (Boskid)
Last week I was requested by Rseding to look how could we implement a stateful Lua table iterator since we often iterate over Lua tables from C++ side, and this operation is slow. This forced me to learn some internals of Lua and how it stores tables. Up to this point, when a map was saved and the Lua state had to be serialised, we used serpent.dump (from serpent library) to convert the variable called global into a string on the Lua side and then take it out and store it within the save.

Since going through Lua tables from the C++ side happened to be quite easy, I have decided to implement, for an experiment - a native Lua serialiser. This allowed us to completely skip using serpent.dump and instead save them directly. My primary goal was to reduce the loading time since in the old format the saved data was a string that Lua had to parse and execute.

As was noticed later (not by me), the save speed improved a lot due to fact that no Lua operations are executed during save, just pure traversal over data to save in a linear time.

For measurements I was using one save file that has quite a lot of script data in it (script.dat is around 60MB), the result is the average over 3 test runs.
  • Saving:
    • Old = 285.429s
    • New = 2.847s
  • Loading:
    • Old = 47.034s
    • New = 22.755s

This values also includes some optimisations implemented by Rseding.

Changing the serialiser however has its costs. serpent.dump was doing serialisation of Lua functions stored in globals. They were officially unsupported by us anyway but some mods were using them "since they seem to work". With the new serialiser I have decided to not implement it at all due to its complexity and inherent limitations (closures were broken anyway). This broke some mods (even some base game scenarios) but it is rather easy to fix.

An additional consideration we had was if it should fail to save when there are Lua functions in global during save, or should it silently delete them (as happens with metatables). The first approach was considered to be the best to quickly catch all non conforming mods but later we have decided that deleting them on save (and providing some info into log file) was better because a migration was almost impossible due to a base game migration for 0.18.28 that requests to reload all script, that as a side effect: saves the Lua state which would abort saving immediately due to Lua functions still in globals.
Factorio - posila87
Gui
  • Minor visual changes and fixes to achievement and tutorial related guis.
Bugfixes
  • Fixed that changing script areas and positions through the map editor in multiplayer as the client didn't work correctly. more
  • Fixed a crash when clearing logistic requests. more
  • Fixed some styles being defined twice in style.lua. more
  • Fixed follower robot count alert not showing correctly. more
  • Fixed container gui not showing logistics filters properly in large containers. more
  • Fixed wrong open/close sound for chemical plant. more
Modding
  • Added support to play a sound when opening dropdowns through opened_sound.
  • Improved performance by up to 2.5x when the game needs to iterate Lua tables on the C++ side.
  • Improved save/load performance of mod script data.
Scripting
  • Lua functions are now explicitly disallowed in the script 'global' table.
  • Added LuaSurface::generate_with_lab_tiles read/write
  • Added LuaEntity::mine().

You can get experimental releases by selecting the '0.18.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
This is update contains large amount of potentially mod breaking changes. If you play heavily modded game, you may want to select 0.18.26 beta branch explicitly for couple of days until your mods get updated. We apologize for your inconvenience.

Graphics
  • New high resolution icons for all items.
  • New sprites for some equipment grid items.
Gui
  • Logistic chests have a different layout.
  • Visual improvements to the equipment grid.
  • Minor visual improvements to most of the game GUIs.
  • Minor layout changes to GUI of Combinators, Programmable speaker, Circuit and logistic connection windows, Rocket silo.
  • Added a close button to most game windows.
Sounds
  • New sounds for GUI interactions.
  • New sounds for game interactions, such as pipette, rotate entity, build ghost, mine ghost, switching gun.
  • Updating working sounds for many entities, such as substation, roboport, combinator.
  • New working sound for rocket silo.
  • New sound for night vision equipment, discharge defense equipment.
  • New tile build sounds for landfill, concrete, stone bricks and refined concrete.
Changes
  • Increased logistic filter count for requester and buffer chests from 12 to 30.
Scripting
  • Changed script.raise_event() to only allow mod-created events and specific game events.
  • Changed script.raise_event() to validate all required fields are provided for the given event being raised.
  • Added event filters for script raised revive, destroy, and created events.
  • Changed event erroring so errors during raise_event are properly blamed on the mod erroring.
  • Changed raise_event ordering to match standard event ordering.
  • All game events that support filters now filter correctly regardless of how they're raised (raise_event or actual game event).

You can get experimental releases by selecting the '0.18.x' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Read this post on our website.

It's been over 4 years since we planned the infamous GUI update. If all goes well, next week the game will get the last big GUI update for 1.0. While the state of the GUI is not close to our crazy plans we recently had for the GUI, it's above what we initially planned 4 years ago.

The update you will see next week includes:
  • A visual update to over 100 game GUIs
  • New high resolution icons for all game items (visible both in GUI and in the world)
  • New GUI sounds for most interactions

High resolution icons (V453000)

The plans

A bit more than a year ago Albert had posted twice (FFF-290 and FFF-291) about our thoughts, experiments, and plans of creating high resolution icons.

Factorio has a ridiculous amount of items and things that need icons, which by itself means it’s a lot of work to redo them. I did not work on the new icons non-stop for a year as there were other more pressing tasks to be done sometimes, but they still took a large amount of time to make.

As Albert mentioned earlier, we also wanted to create multiple mipmaps per icon to control scaling better than letting the engine rescale icons by crazy amounts, but it could multiply the amount of required images to astronomic numbers...

The process

Since we were very well aware of the amount of work that the icons would require, we tried to set up an efficient workflow first, and it paid off big time.



A rather simple Blender startup scene to standardize output paths and basic starting settings was a good start, but the part that saved my sanity was a python script which automatically creates mipmaps from given input images, and downscales images from nearest available higher resolution if an input is missing. And automatically puts the mipmap into the game, assuming the file names are correct.



This is huge because it means I could create the highest resolution image first and immediately put it in the game, and see if conceptually the icon is working.Once I would consider the highest resolution good enough, I could just downscale each of the resolutions manually in Photoshop and paint the extra necessary edits they would require.



The best part is that the mipmaps were not really extra work, they were actually a lifesaver. Creating a high resolution icon that is trying to be readable, look good, represent what it should and do all of it in any scaling level, can make iteration really difficult, as by changing a pixel in the image can introduce problems in completely unknown zoom levels.

It feels rewarding for "trying to do things right" when a solution that we initially thought is more proper looking but potentially more work, is actually more proper looking and less work in the end.



The result



Some icons have been around for years and the entities they represented have changed, but the icons have not. Because of this and many other reasons, some icons will take some getting used to as they look different now. As a benefit of working on the icons on and off for more than a year, I also got to play the game with them over the year and I have gotten used to them already.

Click to view full resolution

Since we have updated our GUI to draw in high resolution with GUI scales like 200%, the item icons suddenly have too low resolution, so we needed to update the icons. That’s what I was thinking at first, but as I started seeing high resolution icons in the game (on belts, assembling machines, cargo wagons, in the map markers, and everywhere else...) I realized how much impact the new icons actually have.

Please do try to get used to the more revolutionary icons first, but do let us know about problematic cases - reworking all icons is a gargantuan project, but redoing individual icons can be very quick and done silently without breaking any mods. That’s what we’ve been doing in almost every major release after all.

The GUI style update (Twinsen)

As mentioned in FFF-338, the plan was to finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0. While it didn]
In game you will notice that some layouts (such as logistic containers) were improved, broken layouts (such as the car/tank inventory) were fixed, plus about a hundred small things like better tilesets, better margins and paddings, proper centering of some elements, etc. Here are some examples of what you will see.



About the fact that we took 4 years, it's partly because (as is probably quite common in game dev) we underestimated the complexity of the GUI. Add on top of that some disorganisation and a constantly expanding and changing scope and you get a project that never finishes. So finally I decided to put my foot down, call it good enough and say no to the constant stream of changes.

That means it's not all good news. It doesn't look like the Blueprint Library will be getting an update before 1.0, currently making it a very low hanging fruit as far as the GUI is concerned.

Such a big update comes with some mod breaking changes, mostly related to changed Lua styles. In order to help modders in fixing the mods as soon as possible and also improving their styles to make them look closer to the base game, I made a long post in the . We initially intended to remove the old ]After it's released, let us know what you think in the release post, or report any bugs you find on the [url]bug forum.

Equipment grid improvements (Twinsen)

In the meantime, Ondra worked on some improvements to the equipment grid. As part of the icon update, this also includes some new graphics for the equipment sprites themselves.



UI sound effects (Ian)

As I mentioned in a recent post (FFF-341), I have been mostly working on UI sounds. My approach has been to get across the tactile feel of the buttons, plus the appropriate feedback for a particular action. But sometimes you don't really know until the rest of the team have heard them.

https://cdn.factorio.com/assets/img/blog/fff-348-gui-sounds.mp4

After prototyping ghost building for example, I thought I had a set of sounds that worked, however Vaclav gave me the valuable feedback that they were too much like 'in world' SFX and needed to be more electronic. This makes sense, as building with ghosts is really sending an instruction to the robots. We also have sounds for rotating entities, which is something you asked for. It provides a bit of useful and fun feedback which could be helpful if you hit the 'R' key by mistake when you meant to open your inventory.

https://cdn.factorio.com/assets/img/blog/fff-348-ui-sounds.mp4

In the case of night vision equipment, I started by making a subtle whoosh type sound but Klonan suggested something more like the 'wind up' sound in Splinter Cell, so I made a kind of a homage to that using a mixture of a rising synth sound and an electrical contact effect.

https://cdn.factorio.com/assets/img/blog/fff-348-nightvision.mp4

I asked Posila if we could play a different building sound for landfill. Once this was done I spent a whole day creating and play testing a variety of sounds, being careful to balance the levels between the impacts and the subtle water splash behind it. I felt they work so well that when Vaclav asked me to look into changing the concrete tile sounds, I used a similar approach and that mechanic also feels much more satisfying now.

https://cdn.factorio.com/assets/img/blog/fff-348-landfill.mp4

Val has been working on more variety for the different sizes of enemies, plus some new sounds for walking on rails. From now on it will be mostly final mix adjustments, including final music mastering and making the whole soundtrack uniformly a bit louder.

G2A resolution (Klonan)

Back in FFF-303, we talked about our thoughts on the grey market websites and more specifically about G2As vow to pay back 10x the money lost to chargebacks.

Well its been a long time, but we're happy to say we have reached the conclusion of the story. You can read the press release from G2A {LINK REMOVED} and the interview with GamesIndustry.biz here.

In short, G2A has confirmed that 198 of the ~300 Steam keys we had recorded from fraudulent purchases were sold on the G2A platform, and they have kept their promise and have sent us 10x the chargeback fees (which was roundabout $20 an order).

That is pretty much it. G2A were quite open during the discussions, and we don't doubt the results they have provided. We still don't recommend purchasing Factorio from any unofficial sources, and there is no ongoing relationship or agreement with G2A after this.

I'd like to thank the team members at G2A who put in the effort to try to close this topic, even though there are more pressing concerns at the moment for all of us.
Factorio - posila87
Features
  • Added new tutorial campaign levels 04 and 05. (more)
Changes
  • Added a search bar to the mod settings GUI.
Bugfixes
  • Fixed a crash when building entity ghosts that immediately get invalidated through script.
  • Fixed that the choose-elem-button elem_type "signal" didn't show special signals. more
  • Fixed that furnaces required module slots to be effected by beacons. more
  • Fixed that some select-a-thing GUIs didn't have search bars. more
  • Fixed that LuaEntity::revive({raise_revive=false}) would still raise the revive event.
  • Fixed a crash when trying to iterate game.forces with the maximum number of forces created. more
  • Fixed a desync related to fast-replacing modded beacons. more
  • Fixed performance issue with initializing huge Lua arrays, that could cause loading of some modded saves take forever. more
Modding
  • Added item prototype flag "draw-logistic-overlay".
  • Added support to play a sound when a robot deconstructs something through utility-constants "deconstruct_robot".
Scripting
  • Added on_force_reset event called when LuaForce::reset() is run.
  • Added remove_colliding_entities and remove_colliding_decoratives parameters to LuaSurface::set_tiles().
  • Added LuaSurface::get_script_area, edit_script_area, add_script_area, remove_script_area, get_script_position, edit_script_position, add_script_position, remove_script_position.
  • Added 'elem_filters' onto choose-elem-button LuaGuiElements to control what options appear in the picker GUI.
  • Added 'crafting-category' filter to EntityPrototypeFilters.
  • Added 'has-ingredient-fluid', 'has-ingredient-item', 'has-product-fluid', 'has-product-item' filters to RecipePrototypeFilters which can accept a nested set of FluidPrototypeFilters or ItemPrototypeFilters.
  • Added 'place-result', 'burnt-result', 'place-as-tile', 'placed-as-equipment-result' filters to EntityPrototypeFilters which can each accept a nested set filters.
  • Added 'name' filter to EntityPrototypeFilters, FluidPrototypeFilters, and ItemPrototypeFilters which accepts either a single name or a list of names to accept, similar to LuaSurface::find_entities_filtered.

You can get experimental releases by selecting the '0.18.x' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Read this post on our website.

New hope demo levels (Klonan)
A few weeks ago we discussed the changes to the demo and tutorial in the game (FFF-342). One piece of feedback we received after publishing the news was about the old 'New hope' campaign levels, and specifically the 'Abandoned rail base/Broken rail map'.

It seems a lot of you in the community really really enjoyed the new hope campaign levels, and several of the team here share the same feelings. After we scrapped the plans for a new campaign and reverted to the old demo, we had initially dismissed the idea to revive the New hope campaign...

However due to popular demand... we have decided to bring back the favourites, the first 2 levels of the new hope campaign. This time though, they will also be included in the demo version of the game. This represents a very significant increase in scope for the demo, increasing the demo content to include research, red science, green science, trains, and much more.

These levels should be ready for release within a week (but no promises).

Level 04 - Science and Automation
This mission is a continuation of demo mission 03 where you build radars to scan the surrounding areas. You start with a small factory already operational. The radar detects a distress beacon and you must build a car to get there in time before the signal dissipates. This level introduces the labs and science packs, as well as providing the first taste of real automation.



At the end of the level, you pack your supplies in the car, and drive off to locate the distress beacon, before it fades out for good.
Level 05 - Abandoned rail base
This level starts with you pulling up to the base, however you arrived too late and the base is already destroyed. Your goal is to re-establish the science production and rebuild the rail network.



After rebuilding the railway and the mining outposts, you must produce a large number of materials to finish the level. At the end of the level, there is a notice that this is the end, and we would recommend playing Freeplay next.
Whats new?
The main work over the last weeks has been bringing the ancient maps up to date with modern Factorio. For instance now that we have more specific remnants, the ruined bases really look much nicer.



Also we have made a big effort to update the tile and map generation to make use of the new terrains, cliifs, and decoratives, most effectively...

Replacing terrain in a map (V453000)
The original Abandoned rail base level was nice, but it aged with all the changes to terrain generation that happened since.



The goal is to recreate the gameplay of the original level, but replace the terrain with modern one, including decoratives and cliffs.

The most gameplay-defining elements are entities and water on the map. Cliffs would be as well, but those didn’t exist when this level was introduced.

Tiles and decoratives we’ll just replace, and trees we’re going to try to get close enough. Of course, a lot of things like pollution absorption numbers have changed since the level was introduced so it won’t be absolutely the same regardless.



The first step I took was finding the random map seed that I want to use for the level. I do this by generating a random map in Freeplay, and I run a take_screenshot command, with two requirements:
  • The name of the output image is the seed of the map so I can reproduce the image just by reading the image name.
  • The resolution to 1 pixel = 1 tile so I can easily align it in Photoshop and read the coordinates (even though Photoshop uses a different coordinate system, at least staying in the same units helps).




I take the same resolution screenshots from the original mission with and without tiles, and put the random seed images on top.

Having the visual preview with being able to move the image allows me to find the desired seed and offset quite quickly and position it really precisely.

Now of course we can’t just paste the entities from the original level to this random surface as there are some conflicting areas, like the huge lake in the middle of the map.



So we have to remove unwanted lakes and resource patches.This is done by generating multiple maps with the same seed, but one without water (starting area only) and resources, and transferring areas between them.

Next up we can add water from the original level.



This step is quite special, in the original mission I replaced water by concrete, and created a blueprint from it. There’s better ways I could have done this, but for some reason I didn’t want to deal with offsets in this piece of script, and I’ve already used this method in some other place earlier so this solution came to my mind first.




Another script replaces all the concrete with real water. The bigger issue is that the original level had water all the way to the edge of the map (you can for example see the sharp edge on the right) and the water generation changed as well so manual edits are in order.



When we have water, it’s finally time to clone in the original entities.



To avoid conflicts, I use the clone_area tool which also removes entities in the destination surface. I’ve been able to go through this whole process in a single working day thanks to all the map editor features Rseding added and Lua commands we’ve created when working on the now cancelled campaign. Tools, experience and knowledge are hard to cancel. :)



And then we draw the rest of the owl. Fix places where the automated cloning hasn’t been good enough, add more ruins to be explored, tweak the gameplay and we will have a finished scenario.

Bots throw cliff explosives (Klonan)
Recently we made some improvements to the cliff explosive effects. However one thing we missed was that the bots needed to be updated separately, due to them using different logic to create the explosion. While it was an easy fix (copy paste some Lua definitions), it feels like it is treating the symptom rather than treating the cause. It isn't good to have the same thing defined in two separate places.

So never one to pass up a nice opportunity to have some fun, Rseding changed the way the 'Blow up cliff' job works, so it will always use the correct effect:

https://cdn.factorio.com/assets/img/blog/fff-347-robot-throw.mp4

Now instead of the robot hovering over the cliff, it will throw the same cliff explosive projectile as the player would. Not only this fixed the issue for good, but it looks a lot cooler.
...