• Blueprints in the blueprint library are sorted using case-insensitive natural compare. E.g. the sorting order now is "1", "2", "10", instead of the previous "1", "10", "2".
  
• Inserters will no longer drop what they are holding when disabled by the circuit network. more
  
• The deconstruction planner filter now treats any entity filter as also matching entity ghosts of that type.
  
• Multiplayer creation GUI now remembers game name. more
  

• Explosive Mine now only does damage to enemy units and structures.
  

• Added missing vehicle collision sounds (pipes, solar panels, etc...)
  
• Reduced volume of ore mining and tree chopping.
  

• Toggling fullscreen via options or Alt-Enter now keeps window on the same monitor. more
  
• Fixed that in long recharging queues some robots would never get a chance to recharge. more
  
• Fixed that it wasn't possible to click and drag blueprints into an empty blueprint book. more
  
• Fixed that deconstruction/blueprinting selection would be canceled if the selection ended on one of the always-visible GUIs. more
  
• Fixed the productivity bar in the furnace GUI wouldn't show in some instances. more
  
• Fixed exiting a multiplayer game hosted through the in-game multiplayer option. more
  
• Fixed that tile ghosts would always get selected over real entities. more
  
• Fixed that the heat-connection icon was not visible on entities other than boiler and reactor. (related to modding)
  
• Fixed that furnace with heat source couldn't be rotated before placing it.
  
• Fixed the gui of furnace using heat as energy source.
  
• Fix PvP Gui script error. more
  
• Fix that clearing items in Transport belt maddness didn't give the items back. more
  
• Fixed that rails marked for deconstruction wouldn't allow canceling deconstruction while a train was on them. more
  
• Fixed that biters would change orientation rapidly when they were near a player whom they couldn't attack. more
  
• Fixed that Rocket Silo would continue crafting for 1 tick after completing a rocket. more
  
• Fixed that lot of other keys that can be used to write characters in the edit box (or console) were not blocked from affecting the game if they are assigned to do a game action. Having text box active now means that all of the keys are blocked from affecting the game.
  
• Fixed (hopefully), that the stretching of bounding boxes of walls to touch their neighbours was not taking into account when marking things in the way for the blueprint. more
  
• Fixed that the description pane would change width depending on the content. It should now never change width. more
  
• Fixed that the shooting-target would render as valid to shoot with rockets when it actually wasn't. more
  
• Fixed that programmable speakers would get wrong instruments after importing pre-0.15.19 blueprint string. more
  
• Fixed that maximized Factorio window had thin border around it. more
  
• Fixed that vanilla and modded version of achievements could be mixed up. more
  
• Fixed that inserters would try to insert items into other non-burner inserters. more
  
• Fixed that fast-transferring modules into the rocket silo would put them into the module slots and the rocket at the same time. more
  
• Fixed that the "rocket launched without satellite" message couldn't be dismissed in some cases. more
  
• Fixed the mining drill GUI wouldn't show mining progress when it had a large number of modded module slots. more
  
• Fixed fast-replacing an assembling machine with overloaded ingredients would spill the items. more
  
• Fixed many ingredients or products in recipes would break the assembling machine GUI. more
  
• Fixed wrong values when using /config set allowed-commands with invalid values would crash the game. more
  

• Fixed that giving rolling stock entities invalid collision masks would crash the game. more
  
• Mod title and description can now be localised.
  
• Fixed a crash when mods use reset technologies during the technology researched event. more
  
• Fixed that modded GUI elements wouldn't get removed in some cases when the mod was removed. more
  
• Fixed source_effects applying effects to the source by the target instead of to the source by the source. more
  

• Fixed setting robot.energy for logistic/construction robots wouldn't account for the robot battery upgrade. more
  
• Fixed that setting LuaBurner::currently_burning didn't accept LuaItemPrototype as the docs said. more
  
• Added LuaEntityPrototype::count_as_rock_for_filtered_deconstruction read.
  
• Added LuaEntityPrototype::filter_count read.
  
• Added LuaEntity::spawner/units read.
  

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

• Blueprints in the blueprint library are sorted using case-insensitive natural compare. E.g. the sorting order now is "1", "2", "10", instead of the previous "1", "10", "2".
  
• Inserters will no longer drop what they are holding when disabled by the circuit network. more
  
• The deconstruction planner filter now treats any entity filter as also matching entity ghosts of that type.
  
• Multiplayer creation GUI now remembers game name. more
  

• Explosive Mine now only does damage to enemy units and structures.
  

• Added missing vehicle collision sounds (pipes, solar panels, etc...)
  
• Reduced volume of ore mining and tree chopping.
  

• Toggling fullscreen via options or Alt-Enter now keeps window on the same monitor. more
  
• Fixed that in long recharging queues some robots would never get a chance to recharge. more
  
• Fixed that it wasn't possible to click and drag blueprints into an empty blueprint book. more
  
• Fixed that deconstruction/blueprinting selection would be canceled if the selection ended on one of the always-visible GUIs. more
  
• Fixed the productivity bar in the furnace GUI wouldn't show in some instances. more
  
• Fixed exiting a multiplayer game hosted through the in-game multiplayer option. more
  
• Fixed that tile ghosts would always get selected over real entities. more
  
• Fixed that the heat-connection icon was not visible on entities other than boiler and reactor. (related to modding)
  
• Fixed that furnace with heat source couldn't be rotated before placing it.
  
• Fixed the gui of furnace using heat as energy source.
  
• Fix PvP Gui script error. more
  
• Fix that clearing items in Transport belt maddness didn't give the items back. more
  
• Fixed that rails marked for deconstruction wouldn't allow canceling deconstruction while a train was on them. more
  
• Fixed that biters would change orientation rapidly when they were near a player whom they couldn't attack. more
  
• Fixed that Rocket Silo would continue crafting for 1 tick after completing a rocket. more
  
• Fixed that lot of other keys that can be used to write characters in the edit box (or console) were not blocked from affecting the game if they are assigned to do a game action. Having text box active now means that all of the keys are blocked from affecting the game.
  
• Fixed (hopefully), that the stretching of bounding boxes of walls to touch their neighbours was not taking into account when marking things in the way for the blueprint. more
  
• Fixed that the description pane would change width depending on the content. It should now never change width. more
  
• Fixed that the shooting-target would render as valid to shoot with rockets when it actually wasn't. more
  
• Fixed that programmable speakers would get wrong instruments after importing pre-0.15.19 blueprint string. more
  
• Fixed that maximized Factorio window had thin border around it. more
  
• Fixed that vanilla and modded version of achievements could be mixed up. more
  
• Fixed that inserters would try to insert items into other non-burner inserters. more
  
• Fixed that fast-transferring modules into the rocket silo would put them into the module slots and the rocket at the same time. more
  
• Fixed that the "rocket launched without satellite" message couldn't be dismissed in some cases. more
  
• Fixed the mining drill GUI wouldn't show mining progress when it had a large number of modded module slots. more
  
• Fixed fast-replacing an assembling machine with overloaded ingredients would spill the items. more
  
• Fixed many ingredients or products in recipes would break the assembling machine GUI. more
  
• Fixed wrong values when using /config set allowed-commands with invalid values would crash the game. more
  

• Fixed that giving rolling stock entities invalid collision masks would crash the game. more
  
• Mod title and description can now be localised.
  
• Fixed a crash when mods use reset technologies during the technology researched event. more
  
• Fixed that modded GUI elements wouldn't get removed in some cases when the mod was removed. more
  
• Fixed source_effects applying effects to the source by the target instead of to the source by the source. more
  

• Fixed setting robot.energy for logistic/construction robots wouldn't account for the robot battery upgrade. more
  
• Fixed that setting LuaBurner::currently_burning didn't accept LuaItemPrototype as the docs said. more
  
• Added LuaEntityPrototype::count_as_rock_for_filtered_deconstruction read.
  
• Added LuaEntityPrototype::filter_count read.
  
• Added LuaEntity::spawner/units read.
  

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

Since a couple of weeks ago I was working for the 1M Party. Made some little graphic design jobs which finally became not that little and much more than "some little". I have to admit that I had quite some fun doing them, cause these small things are giving me the chance to experiment and play with the graphical identity of Factorio, like the happy logo variation, the small jumping gear, some layouts, the 1 color version of the Factorio logo and so on.




Luckily I finished the jobs with time enough as to come back to the game gfx. But to be honest, Jitka is the person who's really taking care of every single detail for the party, and preparing and organizing everything. She became a master with the stamp and other stuff that I can't reveal just to not spoil surprises.

Most of the time when converting normal-res graphics (NR) to high-res (HR), I like to take the chance to re-think the design of the entity. Normally after testing it in the game for so long, it is easy to find better solutions for old problems. But the main reason for re-designing an entity, is that it doesn't support the double resolution - because it was designed and optimized for NR - and sometimes it is because the style is primitive and doesn't fit with the actual standards of the game. Both reasons are true for the case of the electric poles.



Now that I see them again, after working for so long with the HR versions, I don't find them that bad, but it is true that there are problems, especially with the medium one. I will talk about it later. Let's start with the big pole, the 'easy' one.



The model v.1 doesn't support HR, and I always thought that it could be much nicer.
This new v2.a model, is in fact a real one that exists not too far from my home. It's just perfect - in real life - but for Factorio it has some problems.
The base is too thin, it needs to cover 4 tiles, and it has 6 connections instead of the 3 that Factorio requires. I asked for having 6 connections and little variations in the position and rotation of the poles, to make it more natural in the game. But the amount of work and potential problems that this would cause makes it just not viable.
A really nice point of this model is how it rotates. It's very clear in its geometry, clean and transparent at the time of overlapping with other tiles.




After the first attempt, the proposed solution is more conservative. Getting back to the classic v.1.
v2.b is just trying not to freak out too much, and moves forward within the comfort zone. Just the same as the v.1, but better for HR and the modern Factorio style.
The problem of this model is the rotations, specifically the horizontal view, so I believe a 3rd version will come out after mixing the best parts of the other two.



The main problem with medium and small poles, is that they are normally located in the middle of your factory, so if you have a tight setup they can be very intrusive.
They need to be transparent. On the other hand, they have to be visible enough in order to feel comfortable at the time of playing.
That's why medium pole v.1 is a diagonal. It is just an experiment that tries to show the tiles behind as best as possible.
But to be honest I find a bit annoying the absurdity of having a diagonal pole that requires another support on the base just to be stable. What kind of engineer does a pole like that?
The good part of the v.1 is that it is very unique, and you can recognize this pole as from Factorio anytime you see it.
With this new model v.2a, I'm trying to simplify the shape as much as possible in order to be more light and transparent. The problem is that the horizontal rotation is not spectacular, and this sense of uniqueness is quite diluted.



So comes the medium pole v.2b, which is trying to keep the lightness of 2a, even increases it, and it tries also to recover this lost uniqueness from v.1.
Rotations are not super spectacular either, but for the horizontal rotations which are the most difficult ones, this model works pretty well.
I believe that a medium pole v.2c will come by taking the very best of the other models.



With this first version of the small electric pole, I had already a long and difficult process for building it. In my opinion there's not really any serious issue with it apart from the HR incompatibility. So basically v.2a is just a cleaned and stylized version of the v.1. Anyway it needs to be tested to see if it really works.


So that was a short and brief trip to the re-design for HR in Factorio. I just wanted to continue a little bit the last FFF, in order to show more deeply the process of creating an entity.
Many times we speak about technical stuff, meaning code and complicated tools, but we sometimes forget to talk about conceptualization and design, which is full of techniques and twists.
As you can see, everything in here is a work in progress, so we will probably speak about the final HR electric network in action soon. I hope you find it interesting.



As a bonus, I'd like to introduce you to the new version of the warning signals. I had to clean up the style a lot in order to make it very visible in any situation. Still work in progress so expect changes, but step by step Factorio looks better.

Any feedback from you is always interesting. See you in the forums.

Since a couple of weeks ago I was working for the 1M Party. Made some little graphic design jobs which finally became not that little and much more than "some little". I have to admit that I had quite some fun doing them, cause these small things are giving me the chance to experiment and play with the graphical identity of Factorio, like the happy logo variation, the small jumping gear, some layouts, the 1 color version of the Factorio logo and so on.




Luckily I finished the jobs with time enough as to come back to the game gfx. But to be honest, Jitka is the person who's really taking care of every single detail for the party, and preparing and organizing everything. She became a master with the stamp and other stuff that I can't reveal just to not spoil surprises.

Most of the time when converting normal-res graphics (NR) to high-res (HR), I like to take the chance to re-think the design of the entity. Normally after testing it in the game for so long, it is easy to find better solutions for old problems. But the main reason for re-designing an entity, is that it doesn't support the double resolution - because it was designed and optimized for NR - and sometimes it is because the style is primitive and doesn't fit with the actual standards of the game. Both reasons are true for the case of the electric poles.



Now that I see them again, after working for so long with the HR versions, I don't find them that bad, but it is true that there are problems, especially with the medium one. I will talk about it later. Let's start with the big pole, the 'easy' one.



The model v.1 doesn't support HR, and I always thought that it could be much nicer.
This new v2.a model, is in fact a real one that exists not too far from my home. It's just perfect - in real life - but for Factorio it has some problems.
The base is too thin, it needs to cover 4 tiles, and it has 6 connections instead of the 3 that Factorio requires. I asked for having 6 connections and little variations in the position and rotation of the poles, to make it more natural in the game. But the amount of work and potential problems that this would cause makes it just not viable.
A really nice point of this model is how it rotates. It's very clear in its geometry, clean and transparent at the time of overlapping with other tiles.




After the first attempt, the proposed solution is more conservative. Getting back to the classic v.1.
v2.b is just trying not to freak out too much, and moves forward within the comfort zone. Just the same as the v.1, but better for HR and the modern Factorio style.
The problem of this model is the rotations, specifically the horizontal view, so I believe a 3rd version will come out after mixing the best parts of the other two.



The main problem with medium and small poles, is that they are normally located in the middle of your factory, so if you have a tight setup they can be very intrusive.
They need to be transparent. On the other hand, they have to be visible enough in order to feel comfortable at the time of playing.
That's why medium pole v.1 is a diagonal. It is just an experiment that tries to show the tiles behind as best as possible.
But to be honest I find a bit annoying the absurdity of having a diagonal pole that requires another support on the base just to be stable. What kind of engineer does a pole like that?
The good part of the v.1 is that it is very unique, and you can recognize this pole as from Factorio anytime you see it.
With this new model v.2a, I'm trying to simplify the shape as much as possible in order to be more light and transparent. The problem is that the horizontal rotation is not spectacular, and this sense of uniqueness is quite diluted.



So comes the medium pole v.2b, which is trying to keep the lightness of 2a, even increases it, and it tries also to recover this lost uniqueness from v.1.
Rotations are not super spectacular either, but for the horizontal rotations which are the most difficult ones, this model works pretty well.
I believe that a medium pole v.2c will come by taking the very best of the other models.



With this first version of the small electric pole, I had already a long and difficult process for building it. In my opinion there's not really any serious issue with it apart from the HR incompatibility. So basically v.2a is just a cleaned and stylized version of the v.1. Anyway it needs to be tested to see if it really works.


So that was a short and brief trip to the re-design for HR in Factorio. I just wanted to continue a little bit the last FFF, in order to show more deeply the process of creating an entity.
Many times we speak about technical stuff, meaning code and complicated tools, but we sometimes forget to talk about conceptualization and design, which is full of techniques and twists.
As you can see, everything in here is a work in progress, so we will probably speak about the final HR electric network in action soon. I hope you find it interesting.



As a bonus, I'd like to introduce you to the new version of the warning signals. I had to clean up the style a lot in order to make it very visible in any situation. Still work in progress so expect changes, but step by step Factorio looks better.

Any feedback from you is always interesting. See you in the forums.

• Fixed that the server would crash if someone tried to connect when there were no blueprints being transferred. more
  

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

• Fixed that the server would crash if someone tried to connect when there were no blueprints being transferred. more
  

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

• Transports belt entities show belt speed in the tooltip and entity description.
  
• Reduced fluid wagon air resistance from 0.05 to 0.01
  
• Scenario names are now localised.
  

• Fixed login details getting lost (hopefully). more
  
• Fixed a crash that would happen if the game exited due to a script error that happened immediately after deleting a force. more
  
• Fixed int mod settings would show incorrect values in the GUI. more
  
• Fixed gun sounds would continue when switching weapons while firing. more
  
• Fixed a performance issue caused by spawners being active all the time in peaceful mode. more
  
• Fixed a crash when removing train stops next to other train stops and then building locomotives. more
  
• Fixed a rare desync related to opening your player inventory. more
  
• Fixed a crash when teleporting/setting the force of a offline roboport. more
  
• Fixed inserters with custom pickup/drop locations from mods would retain the custom data when the mods were removed. more
  
• Fixed a crash when deleting blueprint records from the blueprint library while another player is viewing the record tooltip. more
  
• Fixed that some clients wouldn't be able to connect to a server when blueprints were being uploaded. more
  
• Fixed that Factorio wouldn't start when run from an NFS partition. more
  
• Fixed crash on macOS older than 10.9 more
  

• Removed unused "energy consumption" from the roboport equipment. more
  

• Fixed that setting researched = true on level-based research in progress wouldn't update the research level displayed. more
  
• Fixed that game.write_file would cause desyncs if it failed due to file permission issues. more
  
• Fixed a crash related to the train changed state event. more
  
• Added events on_player_setup_blueprint, on_player_deconstructed_area, and on_player_configured_blueprint.
  
• Added LuaEntity::secondary_bounding_box read.
  
• Added LuaForce::worker_robots_battery_modifier read/write.
  
• Added LuaGuiElement::enabled read/write.
  

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

• Transports belt entities show belt speed in the tooltip and entity description.
  
• Reduced fluid wagon air resistance from 0.05 to 0.01
  
• Scenario names are now localised.
  

• Fixed login details getting lost (hopefully). more
  
• Fixed a crash that would happen if the game exited due to a script error that happened immediately after deleting a force. more
  
• Fixed int mod settings would show incorrect values in the GUI. more
  
• Fixed gun sounds would continue when switching weapons while firing. more
  
• Fixed a performance issue caused by spawners being active all the time in peaceful mode. more
  
• Fixed a crash when removing train stops next to other train stops and then building locomotives. more
  
• Fixed a rare desync related to opening your player inventory. more
  
• Fixed a crash when teleporting/setting the force of a offline roboport. more
  
• Fixed inserters with custom pickup/drop locations from mods would retain the custom data when the mods were removed. more
  
• Fixed a crash when deleting blueprint records from the blueprint library while another player is viewing the record tooltip. more
  
• Fixed that some clients wouldn't be able to connect to a server when blueprints were being uploaded. more
  
• Fixed that Factorio wouldn't start when run from an NFS partition. more
  
• Fixed crash on macOS older than 10.9 more
  

• Removed unused "energy consumption" from the roboport equipment. more
  

• Fixed that setting researched = true on level-based research in progress wouldn't update the research level displayed. more
  
• Fixed that game.write_file would cause desyncs if it failed due to file permission issues. more
  
• Fixed a crash related to the train changed state event. more
  
• Added events on_player_setup_blueprint, on_player_deconstructed_area, and on_player_configured_blueprint.
  
• Added LuaEntity::secondary_bounding_box read.
  
• Added LuaForce::worker_robots_battery_modifier read/write.
  
• Added LuaGuiElement::enabled read/write.
  

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

Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources.

The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article.

Please fasten your belt as this will be a ride full of automation.



Here it all starts. As you might already know, almost everything in Factorio comes from 3D models created in Blender. This time I already had the combinator models ready as we updated them relatively recently (in 0.13).



In 0.15, we added many new operations for the combinators, which required additional display graphics, some of them having quite complicated shapes. For some obscure reason I was afraid that the old matrix of lightbulbs wouldn’t be able to represent such detailed symbols so I increased the resolution from 7x7 to 15x15. I wasn’t too happy with the result, but at that point time was a big pressing factor so we just kept it. The thin lines however lose quite a bit of the granular display nature and they behave quite poorly when zooming out.



Now when I had the chance of revisiting combinators, I tried to redo the symbols with 9x9 as I was thinking “Well, I probably abandoned 7x7 for a reason so let’s not try that.” However, I quickly found out that it’s actually very easy to fit all of the symbols in 9x9 so I tried 7x7 out of curiosity. I was very surprised to see that it’s actually totally fine and there was no reason to abandon the 7x7 grid. So, here you can see all the old-new displays.



Once the 3D models are prepared, I could get into rendering them very fast just by changing a handful of values. You can see that the original scene was already prepared for resolution doubling.



It’s worth mentioning how the rendering system actually works. The combinator objects are split into layers, separating horizontal and vertical models (because they are different due to projection), and rotating them between frames 1 and 2 in time.



With this, we can assign RenderLayers to combine the layers and output what we want.The next step is naming the outputs correctly and putting them in their own folders - for that we use a fake rendering scene which has only one purpose - collect the RenderLayers from the real model scenes, and save them to disk.



Once that all works we just need to press one button to output everything.



Many things can be achieved in a 3D program, but human touch in Photoshop is always a very vital step for vast majority of our graphics.The main technical criteria for Photoshop output is the ability to import the working file into After Effects as separate layers. I will show why this is necessary later.

Since there are 12 combinator variations, maintaining your 12 PSD files would become a pain sooner or later for many reasons, so I import everything into one big file.Here I typically space the imported layers out so that I can see and edit everything at the same time. We will center them back later. This way I can paint on all of them together which not only saves time otherwise spent by switching files, but it also lets me see the differences and make sure I'm not overdoing it on some of them.

Typically we duplicate the layers twice (groups in this case) and blend them with Screen and Multiply modes. Of course the blending only happens in carefully hand-painted spots, which gets us to the outputs we are trying to get out of Photoshop - masks which control the correction seen above. This is how one of them looks like:



A special thing to mention, we also generate ground integration with Drop Shadow functions in Photoshop, which has to be merged in a single layer so it could be exported. The problem with this is that it has to be done manually so again doing it just once in one big photoshop file is faster than in 12 different files.



The place where everything fits together is After Effects. Here we bring all of the rendered outputs from Blender together with the masks exported from Photoshop, and with some system combine them into image sequences which will later be processed by python scripts.



The obvious thing to do first are the combinator sprites, this is using the quite typical system of taking the rendered sprite, masking it and duplicating it to screen/multiply blend itself, of course feeding it the mask from Photoshop. The Photoshop masks are imported directly from the PSD file as layers, which is why it's important to have them ready for this step. In After Effects they have to be centered back to fit the render, to compensate for the spacing in Photoshop.

After that it’s just doing the same for all combinator types, rotations and shadows. The pipeline can look like this:

• Render - raw footage directly from Blender
• Ps-EDIT - applying the Photoshop masks
• Sequence - final positioning tweaks
• Output - separating the sequence into separate outputs for each combinator type (arithmetic, decider, constant)

The exact same applies for shadows. Rotations, dance!



This After Effects pipeline is quite typical for all of our entities. The system can differ in complexity but it’s something similar. The special part here is that combinators have a huge amount of shifting values for the wire connections in Lua, and we need to somehow define them. To be more specific, we have:

• Red wire input
• Green wire input
• Red wire output
• Green wire output
• Red wire input shadow
• Green wire input shadow
• Red wire output shadow
• Green wire output shadow

Even though the constant combinator doesn’t have any input, it still totals 80 shifting values just for the wire connections, not even mentioning shiftings for the displays, activity LEDs and the combinator graphics themselves. Doing each point manually would be insanely tedious, time consuming and to redo it you simply have to do it all over again, at which point you might as well just go hang yourself with a red and green cable.



When we combine it all, in total we exceed 111 shiftings. Because we are proper Lazy Bastards, we have a special pipeline to prevent doing all this manually. (Automation, anyone?)

In After Effects we take the centered sequence of combinator sprites and desaturate them. On top we put 1 pixel indicators for the wire connection points. The result looks like this, note the small colourful spots. The gray arrow is just for debug and to prevent mistakes.



The previous picture alone isn’t very useful as we do not have a tool which would just calculate the shifting outright so we need to process the pictures and filter them by colour. Each of the coloured pixels is going to be split into one file which results in a funny picture which has just 1 pixel for you to find in case you want to have a look manually. There is a simple colour code for the filtering:



The aim is to separate them all into their own exclusive folders, where they will be waiting eagerly to be processed and spat out by the next assembling machine script…

We already mentioned multiple times that we are using an universal python script to crop images and calculate the shifting required to re-center the cropped picture. This is generally useful simply because it’s cropping the data to the minimum possible bounding box, minimizing the file sizes of the game and leaving less work for texture Atlas cropping during loading time.

Now we can use this tool to calculate the wire shiftings for the combinators from the single-pixel images from the previous step. This doesn’t happen magically by itself, we still need to tell Spritesheeter what to do, so we can just casually generate the .bat command for Spritesheeter by another python script. Spritesheeter devours its prey per folder, which is why we separated each of the shifting pictures into their own folder. The output is 80 text files which look something like this, focus is of course on the 'shift = ...' line.



Note: the real combinator sprites, activity led and display sprites also go through Spritesheeter, outputting whole spritesheets where possible, like for example those two.




If you ever looked into entities.lua and searched for combinators, you probably noticed that it has quite a bit of code. More specifically, whole file has about 12,500 lines. When we separated combinator pictures (not even the whole code), it dropped to 10,500. That’s 2 000 lines of Lua mess to define the new graphics in. It’s safe to assume that it could take me over 2 days to do all this manually so I decided to generate the whole combinator-pictures.lua with another python script automatically.

Since I don’t have that much programming experience, I obviously quickly discovered that it isn’t as easy as I imagined it to be, and I quickly got into readability problems so I had to do some code cleaning up because I just got absolutely lost in it at one point. Even now it still has some messy parts, but overall it was a quite straight forward process.



It took me about 4 days it probably took a bit longer (about 1-2 days) than doing it manually, although if I had to redo just half once, it might have already evened out, but that’s all just guessing. Even fixing mistakes and errors is much easier as I can just fix a few scripts and re-generate the whole thing within seconds. Most importantly, I learned a lot of new things, and we can reuse the processing pipeline in similar entities like the electric poles or circuit connector module (the yellow box which appears when you connect something to circuit network), and many others.

We have pictures and code but we need to put all these files in the game. Taking the files manually and putting them into the game is not terribly hard, but you can forget some files, place them in wrong locations, or the folder/naming system between the game and the working directories can simply be different. So it’s very convenient to write another script which actually copies the files to the local git repository, after that it’s just about starting the game and seeing how it works.

Of course the code seemed to be correct by eyeballing it, but the game is stubborn about syntax and all those unimportant things so I had to do some fixes. This was a repetitive process between editing the 06-Lua generator and putting the files into the game, sometimes even having to re-generate sequences from After Effects and running the whole processing pipeline again.

After doing this a few times it was time for automation so I added a script which automatically triggers all of the 04-07 scripts, letting me to just fix issues and see them in action with just one double-click.



The whole process isn’t exactly short, but automating the steps helps so much, especially when we get to the last step of really making it work right. At that point it is extremely important to be able to say “Can we change this, can we improve that?” and your answer is “Yeah, just change these two things and let it re-generate.” It lets you focus on quality instead of thinking how much time would it take to do all the process manually again, and I really enjoy working this way, not to mention that every time I learn something new to make the tools even better and faster next time. Doesn’t that remind you of some game?

While we're on the topic of combinators and automation, Reddit user /u/mgabor has spent the last month working on an automated way of importing MIDI to Factorio as programmable speaker songs, introducing MIDItorio.

https://www.youtu.be/wOfsikccYvw

Hopefully this article was interesting for you, let us know what you think on our forum.

Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources.

The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article.

Please fasten your belt as this will be a ride full of automation.



Here it all starts. As you might already know, almost everything in Factorio comes from 3D models created in Blender. This time I already had the combinator models ready as we updated them relatively recently (in 0.13).



In 0.15, we added many new operations for the combinators, which required additional display graphics, some of them having quite complicated shapes. For some obscure reason I was afraid that the old matrix of lightbulbs wouldn’t be able to represent such detailed symbols so I increased the resolution from 7x7 to 15x15. I wasn’t too happy with the result, but at that point time was a big pressing factor so we just kept it. The thin lines however lose quite a bit of the granular display nature and they behave quite poorly when zooming out.



Now when I had the chance of revisiting combinators, I tried to redo the symbols with 9x9 as I was thinking “Well, I probably abandoned 7x7 for a reason so let’s not try that.” However, I quickly found out that it’s actually very easy to fit all of the symbols in 9x9 so I tried 7x7 out of curiosity. I was very surprised to see that it’s actually totally fine and there was no reason to abandon the 7x7 grid. So, here you can see all the old-new displays.



Once the 3D models are prepared, I could get into rendering them very fast just by changing a handful of values. You can see that the original scene was already prepared for resolution doubling.



It’s worth mentioning how the rendering system actually works. The combinator objects are split into layers, separating horizontal and vertical models (because they are different due to projection), and rotating them between frames 1 and 2 in time.



With this, we can assign RenderLayers to combine the layers and output what we want.The next step is naming the outputs correctly and putting them in their own folders - for that we use a fake rendering scene which has only one purpose - collect the RenderLayers from the real model scenes, and save them to disk.



Once that all works we just need to press one button to output everything.



Many things can be achieved in a 3D program, but human touch in Photoshop is always a very vital step for vast majority of our graphics.The main technical criteria for Photoshop output is the ability to import the working file into After Effects as separate layers. I will show why this is necessary later.

Since there are 12 combinator variations, maintaining your 12 PSD files would become a pain sooner or later for many reasons, so I import everything into one big file.Here I typically space the imported layers out so that I can see and edit everything at the same time. We will center them back later. This way I can paint on all of them together which not only saves time otherwise spent by switching files, but it also lets me see the differences and make sure I'm not overdoing it on some of them.

Typically we duplicate the layers twice (groups in this case) and blend them with Screen and Multiply modes. Of course the blending only happens in carefully hand-painted spots, which gets us to the outputs we are trying to get out of Photoshop - masks which control the correction seen above. This is how one of them looks like:



A special thing to mention, we also generate ground integration with Drop Shadow functions in Photoshop, which has to be merged in a single layer so it could be exported. The problem with this is that it has to be done manually so again doing it just once in one big photoshop file is faster than in 12 different files.



The place where everything fits together is After Effects. Here we bring all of the rendered outputs from Blender together with the masks exported from Photoshop, and with some system combine them into image sequences which will later be processed by python scripts.



The obvious thing to do first are the combinator sprites, this is using the quite typical system of taking the rendered sprite, masking it and duplicating it to screen/multiply blend itself, of course feeding it the mask from Photoshop. The Photoshop masks are imported directly from the PSD file as layers, which is why it's important to have them ready for this step. In After Effects they have to be centered back to fit the render, to compensate for the spacing in Photoshop.

After that it’s just doing the same for all combinator types, rotations and shadows. The pipeline can look like this:

• Render - raw footage directly from Blender
• Ps-EDIT - applying the Photoshop masks
• Sequence - final positioning tweaks
• Output - separating the sequence into separate outputs for each combinator type (arithmetic, decider, constant)

The exact same applies for shadows. Rotations, dance!



This After Effects pipeline is quite typical for all of our entities. The system can differ in complexity but it’s something similar. The special part here is that combinators have a huge amount of shifting values for the wire connections in Lua, and we need to somehow define them. To be more specific, we have:

• Red wire input
• Green wire input
• Red wire output
• Green wire output
• Red wire input shadow
• Green wire input shadow
• Red wire output shadow
• Green wire output shadow

Even though the constant combinator doesn’t have any input, it still totals 80 shifting values just for the wire connections, not even mentioning shiftings for the displays, activity LEDs and the combinator graphics themselves. Doing each point manually would be insanely tedious, time consuming and to redo it you simply have to do it all over again, at which point you might as well just go hang yourself with a red and green cable.



When we combine it all, in total we exceed 111 shiftings. Because we are proper Lazy Bastards, we have a special pipeline to prevent doing all this manually. (Automation, anyone?)

In After Effects we take the centered sequence of combinator sprites and desaturate them. On top we put 1 pixel indicators for the wire connection points. The result looks like this, note the small colourful spots. The gray arrow is just for debug and to prevent mistakes.



The previous picture alone isn’t very useful as we do not have a tool which would just calculate the shifting outright so we need to process the pictures and filter them by colour. Each of the coloured pixels is going to be split into one file which results in a funny picture which has just 1 pixel for you to find in case you want to have a look manually. There is a simple colour code for the filtering:



The aim is to separate them all into their own exclusive folders, where they will be waiting eagerly to be processed and spat out by the next assembling machine script…

We already mentioned multiple times that we are using an universal python script to crop images and calculate the shifting required to re-center the cropped picture. This is generally useful simply because it’s cropping the data to the minimum possible bounding box, minimizing the file sizes of the game and leaving less work for texture Atlas cropping during loading time.

Now we can use this tool to calculate the wire shiftings for the combinators from the single-pixel images from the previous step. This doesn’t happen magically by itself, we still need to tell Spritesheeter what to do, so we can just casually generate the .bat command for Spritesheeter by another python script. Spritesheeter devours its prey per folder, which is why we separated each of the shifting pictures into their own folder. The output is 80 text files which look something like this, focus is of course on the 'shift = ...' line.



Note: the real combinator sprites, activity led and display sprites also go through Spritesheeter, outputting whole spritesheets where possible, like for example those two.




If you ever looked into entities.lua and searched for combinators, you probably noticed that it has quite a bit of code. More specifically, whole file has about 12,500 lines. When we separated combinator pictures (not even the whole code), it dropped to 10,500. That’s 2 000 lines of Lua mess to define the new graphics in. It’s safe to assume that it could take me over 2 days to do all this manually so I decided to generate the whole combinator-pictures.lua with another python script automatically.

Since I don’t have that much programming experience, I obviously quickly discovered that it isn’t as easy as I imagined it to be, and I quickly got into readability problems so I had to do some code cleaning up because I just got absolutely lost in it at one point. Even now it still has some messy parts, but overall it was a quite straight forward process.



It took me about 4 days it probably took a bit longer (about 1-2 days) than doing it manually, although if I had to redo just half once, it might have already evened out, but that’s all just guessing. Even fixing mistakes and errors is much easier as I can just fix a few scripts and re-generate the whole thing within seconds. Most importantly, I learned a lot of new things, and we can reuse the processing pipeline in similar entities like the electric poles or circuit connector module (the yellow box which appears when you connect something to circuit network), and many others.

We have pictures and code but we need to put all these files in the game. Taking the files manually and putting them into the game is not terribly hard, but you can forget some files, place them in wrong locations, or the folder/naming system between the game and the working directories can simply be different. So it’s very convenient to write another script which actually copies the files to the local git repository, after that it’s just about starting the game and seeing how it works.

Of course the code seemed to be correct by eyeballing it, but the game is stubborn about syntax and all those unimportant things so I had to do some fixes. This was a repetitive process between editing the 06-Lua generator and putting the files into the game, sometimes even having to re-generate sequences from After Effects and running the whole processing pipeline again.

After doing this a few times it was time for automation so I added a script which automatically triggers all of the 04-07 scripts, letting me to just fix issues and see them in action with just one double-click.



The whole process isn’t exactly short, but automating the steps helps so much, especially when we get to the last step of really making it work right. At that point it is extremely important to be able to say “Can we change this, can we improve that?” and your answer is “Yeah, just change these two things and let it re-generate.” It lets you focus on quality instead of thinking how much time would it take to do all the process manually again, and I really enjoy working this way, not to mention that every time I learn something new to make the tools even better and faster next time. Doesn’t that remind you of some game?

While we're on the topic of combinators and automation, Reddit user /u/mgabor has spent the last month working on an automated way of importing MIDI to Factorio as programmable speaker songs, introducing MIDItorio.

https://www.youtu.be/wOfsikccYvw

Hopefully this article was interesting for you, let us know what you think on our forum.