1. Factorio
  2. News

Factorio News

Friday Facts #334 - New poison cloud animation, flying robot dying effect

Read this post on our website.

Poison cloud (Ernestas, posila)

The poison cloud animation is a placeholder spritesheet (that kovarex found somewhere on the internet), we have wanted to improve it for a long time, but since it was always such a small detail other things took priority. Well now is the time to finish everything, big and small.

https://cdn.factorio.com/assets/img/blog/fff-334-old-cloud.mp4

Some of the problems we see with the old placeholder animation:
  • The edge (where damage will apply) is not clearly defined
  • The center strongly obstructs vision underneath the animation
  • It breaks the perspective/height illusion with its very circular shape


The new animation was done quickly and without the need of any large changes to the Factorio engine. This is the mindset we are in these days, use the engine features we already have to finish things quickly and without trouble, and we try to stop ourselves going crazy with more detail.

https://cdn.factorio.com/assets/img/blog/fff-334-new-cloud.mp4

The smoke capsule itself spawns a bunch of smaller dummy entities which do the smoke drawing, while the damage is kept consistent by only using the central smoke cloud to apply damage.

Flying robot die effect (Dom, Klonan)

Unlike the poison cloud, the flying robots dying was never something that we felt strongly about changing, they just exploded and poofed out of existence. With the new particle system we had an idea of using a particle to show the robot falling to the ground. The experimentation was quick and effective, and we liked the effect. Using the 16 directions of the flying robot sprites, we can create a 16 frame animation of the robot spinning for free, which is a good trick.

https://cdn.factorio.com/assets/img/blog/fff-334-robot-dying.mp4

To complete the effect we needed to pay a bit of a price by creating some remnants on the ground. Dom didn't take long to model and render 3 remnant variations for each robot. Even if you don't see the robots falling and dying actively, the corpses on the ground can really add to the battlefield.



These new effects have been merged in our master branch now, so you can expect to play with them with the next 0.18 experimental release, likely early next week.

Version 0.18.6 released

Bugfixes


  • Fixed a crash related to multiple blocks reserved for different trains but later merged by placing a rail. more
  • Fixed that construction robots were missing their working animation. more
  • Fixed circuit network debug visualization text overlap. more
  • Fixed the circuit network tooltip backgrounds didn't highlight correctly. more
  • Fixed that script.active_mods wouldn't be accurate when loading save files in some cases. more
  • Fixed that the sync-mods-with-save feature would try to download mods it didn't need to in some cases. more
  • Fixed that trains pathfinder could create non contiguous path in case of single segment cycle with a junction. more
  • Fixed possible crash when units were attacking rails with train on them. more
  • Fixed pump would consume energy and play animation when it tried to transfer very small amount of fluid but failed to do so. more
  • Fixed creating fire entity by trigger effect invoked by a particle would crash the game.
  • Fixed overriding LuaSurface::brightness_visual_weight would cause light map to appear in map view. more
Scripting


  • Building entities with from items with 0 health will set the entity to 1 health instead of 0. more
  • Added LuaGameScript::reset_time_played() which will reset the 'Time played' to 0.


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

Friday Facts #333 - Terrain scrolling

Read this post on our website.

Hello,
We released 0.18.4 this week, same old same old, more bugfixes, more bugs, more changes. At this stage of development, not many interesting things are happening, we are just polishing what we have.

Minor terrain render optimization (posila)

Just a couple days before the release of 0.18.0 I had an epiphany about a terrain rendering problem that was bugging me for a really long time. When rendering terrain, we reuse the texture from the previous frame. How this was always done, is that we would render the texture shifted to the new position, fill up the gap, and then copy the final result back into the texture for reuse in next frame. So what was bugging me about this? This simple operation would result in rasterizing 2 screens worth of pixels. While that is not a problem for at least half decent GPUs from the past decade, it's a significant work load for integrated GPUs, which in general have an order of magnitude lower memory bandwidth than dedicated GPUs. It could also be equally bad for old low-end dedicated GPUs.

One of the extreme examples is the Intel HD Graphics 3000 - an integrated GPU on the Sandy Bridge CPU architecture. When you sit still and the terrain can be reused without shifting, it would take 'just' 2 milliseconds to copy it to the game view. But when you started to move, the GPU time to render the terrain could go up to 5 milliseconds. And that is only at 1600x900 resolution. Not even 1080p. So, it was bothering me we were spending nearly 1/3rd of a frame time (16.66 ms) to render the terrain, when the engine has much more work to do to render the rest of the game (for comparison GeForce GTX 750Ti or Radeon R7 360 would do the same under 0.5 ms at 1080p).

The realization I had, was that I can 'scroll' the buffer texture. If I remember the offset of the top left corner, I can un-scroll it to the game view, and then instead of copying all the terrain back to the buffer, we can just adjust the offset and update the parts that changed. So, the number of pixels copied is proportional to how much the terrain scrolled. It is so simple I am embarrassed not to have figured this out years ago.

https://cdn.factorio.com/assets/img/blog/fff-333-tile-buffer.mp4

Most people could not have noticed this optimization, as most GPUs people have nowadays did the un-optimal thing in a fraction of a millisecond already. But it still made me very happy to be finally able to remove this inefficiency. Contemporary integrated GPUs are also significantly faster, and while it might not be as much of a challenge to render the game for them, they do share some resources with the CPU - be it the last level of cache, or CPU cooler, so the integrated GPU working hard may cause the CPU to slow down.

However, the point I wanted to illustrate by this post is how broad a range of GPUs there is. People see a 2D game and expect to be able to play it on essentially anything. If we want to live up to that expectations, we have to impose a lot of limitations on ourselves, because 'anything' also includes a couple orders of magnitude slower GPU than is found in an average gaming computer of today. CPUs got a lot faster in the last decade too, but mostly due to increasing the number of cores and adding wider vector computation units. They didn't get that much faster when executing serial code, which is unfortunately most of Factorio's game code. So if you play the game on a laptop with a Core 2 Duo and GeForce 320M, you'll run into framerate issues due to the weak GPU much sooner than a UPS slowdown due to the old CPU.

Side note: You might ask, why do we bother with caching the terrain in the first place and not just re-render it from scratch every frame. Short answer is - because Factorio's terrain rendering is insane due to its complicated tile transition rules, and re-rendering it every frame is just not fast enough.

Version 0.18.4 released

Balancing


  • Wave defense difficulty will scale with online player count.
  • Wave defense hard difficulty will give 50% less bounty on each kill.
Sounds


  • New sound for small explosion.
  • Combat robots now have their own explosion sound.
  • Shotgun has more variety so it sounds less repetitive.
  • Vehicle impacting wooden objects (e.g chests) now sounds subtly different to crashing into trees.
  • A few minor volume level changes including lowering the offshore pump and electric furnace.
Bugfixes


  • Fixed a crash when saving fails due to mod issues. more
  • Fixed a crash that would happen when the player entered a vehicle when some biters were aggroed at them. more
  • Fixed that cargo wagons built while a train is moving didn't animate the doors correctly. more
  • Fixed an error when using modded night vision defined in zip files. more
  • Fixed a performance issue with assembling machine result slot tooltips. more
  • Fixed that items marked with the mod-openable flag couldn't be opened from the quickbar in some cases. more
  • Fixed that train could fail with chain signal sequence escape maneuver when path goes multiple times through a rail segment.
  • Possibly fixed seam on terrain at certain position and zoom level. more
  • Fixed that sometimes wave defense would trigger victory before killing all spawners. more
Scripting


  • Fixed that writing to LuaForce::stack_inserter_capacity_bonus was limited to 200 instead of 254.
Modding


  • Changed definitions of map colors of beacons, pipes, heat pipes, roboports and steam engines, so they can be overridden by friendly_map_color. more
  • Added ParticlePrototype::ended_on_ground_trigger_effect.
  • Added fuel burnt results to the item tooltip.
  • Loader remnants will pick rotation the same way as underground belts do. more


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

Friday Facts #332 - More sounds Map color tweaks

Read this post on our website.

Hello,
We released 0.18.2 and 0.18.3 this week. In terms of major releases, this one has very few bugs, so we haven't had a lot of pressure to crank out the releases at lightning speed.

New Sounds (Ian)

In the sound design department we have been hard at work to bring you a better gaming experience with the help of some new and improved sound effects. It struck me that the whole sound track used to have a lo-fi, almost 'dirty' feel, by which I mean the sounds were unclear, had a low resolution and possibly used recordings made with the wrong microphone positioning. So with Val's help we have set about improving some of these sounds. For example, there are new sounds for all the transport belts, they don't sound very different but they are smoother sounding and less annoying.

https://cdn.factorio.com/assets/img/blog/fff-332-belts.mp4

Similar to the transport belts, we also have sounds for the combat robots that are designed to harmonise with one another. Val made a bunch of synth tones for these and I chose the three sounds that make a pleasing harmony when you add them together.

https://cdn.factorio.com/assets/img/blog/fff-332-combat-robots.mp4

However in my haste to get these sounds in the Tuesday release, I missed that the fast and the express belts had an annoying high pitched whine in there. So I have EQ'd off the high frequencies and now they work better.

The main reasons for having sound design in a game is not just to increase realism and immersion but also for player feedback and to increase the fun factor. Sometimes these things are hard to get right, especially in a game like this where there are so many sound producing entities so close to one another, often with very busy animations. You expect to hear a busy sound, but when you play them all together... it can be a mess. Add to this the innumerable ways sounds can be combined, well you get the idea.

I have described this game as a sound designer's dream... and also nightmare. So try and bear with us while we get the balance right. We are also trying to do all this without a modern sound engine, which brings me to my next point.

Tech wise, Rseding has been busy updating the sound code. For example we now have the listener position on the centre of the screen by default, which makes more sense to me and helps when you are in the map mode. Zoom level and attenuations have also been increased.

Innumerable other small fixes to sound levels have been made and hopefully the game is starting to sound the way we want.

Updated map colors (Klonan)

In the 0.18.2 release this week we changed the map colors for a few entities from the default blue:
  • Heat Pipes
  • Pipes and Underground pipes
  • Pumps
  • Storage tanks
  • Beacons
  • Steam engines and Turbines
  • Roboports
To us it is nice to have a bit more differentiation between entity types/families on the map view (without going crazy), and we think we are carefully getting there.



These changes should especially help tell give some character to power setups, and big assembling blocks with beacons. We're happy with the way it is looking, and with more time we might decide on some more tweaks.



Community spotlight (Klonan, V453000)

Quite a lot of great things to share this week :).

[h3]KoS 500 player MP server[/h3]
Last Saturday, KatherineOfSky and Caledorn hosted a MP server with the goal to set a new record of over 500 players. The server was funded by the community through a GoFundMe.



They were successful, and managed to have at one point 521 players online. This is actually quite a surprise to us, especially since it was with the fresh 0.18.1 version of the game.

You can watch the full stream of the MMO event here.

[h3]New 0.18 Any% speedrun record[/h3]
Nefrums set a new speedrun record this week playing 0.18. He is getting close to a sub 2-hour run, just 5 minutes to optimize!

[previewyoutube][/previewyoutube]

[h3]The Biggest and most Useless Rail Network Ever...[/h3]
Reddit user minibetrayal created a Turing machine using Train network logic gates, comprising of 4,800 Locomotives, 6,172 Train stops, 56,030 Rail signals, and over 1,300km (800 miles) of Rail.

https://cdn.factorio.com/assets/img/blog/fff-332-rail.mp4

If you would like to know more, there are details in the Reddit thread.

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