Changes

• Added autosave slots to "The Rest" settings gui. more

Bugfixes

• Fixed a crash with crafting machines using burner energy sources and items that produce burnt results. more
• Fixed that the bonus GUI could show incorrect values for modded inserter bonuses. more
• Fixed that additional layers of multi-layer recipe icons were tinted when building. more
• Fixed that restoring a window minimized to the macOS dock would freeze the graphics. more
• Fixed a crash related to failed audio initialization and switching audio devices.
• Fixed a crash when creating surfaces during the chunk deleted event. more
• Fixed that projectiles didn't draw oriented lights at the correct orientation. more
• Fixed that the 'create_spidertron()' Lua function didn't set the correct minable result name. more
• Fixed that 'item on ground' didn't show item amount in the tooltip. more
• Fixed a crash when restarting after syncing mods with save if the mod(s) were disabled and the save had a valid replay. more
• Fixed working sound's volume or speed not being matched to activity when fading, for example with pipes. more
• Fixed overlaping red and green wires connected to a power switch. more
• Fixed that moving a container with which a loader was interacting would not disconnect the loader.
• Fixed that vehicle ammo slot filter selection would show ammos that the slot cannot accept. more
• Fixed vehicle ammo slot style when filtered. more
• Fixed train lights in preview would render for trains on surface a player is on, not for the surface being rendered. more
• Fixed that cloning item entities wouldn't clone the to-be-looted flag. more
• Fixed that boilers wouldn't consume fuel if fed fluid at maximum temperature. more
• Fixed a desync related to custom blueprints. more
• Fixed transport belts not decompressing overcompressed items in certain cases. more
• Fixed drawing an extra shadow for health bars of items on ground and items on belts.
• Fixed that connecting circuit or copper wires in map view did not work if the Build and Drag map controls conflicted. more
• Fixed override_sound_type having no effect. more
• Fixed a crash when trying to filter car/spider ammo slots. more
• Fixed visual artifact in water when zoomed out.
• Fixed 'on_entity_renamed' Lua event not including 'player_index' if copy-pasting to a train stop. more

Scripting

• Added 'entity' to LuaPlayer::open_map and LuaPlayer::zoom_to_world, which specifies an entity to follow.
• Added LuaRailPath::is_front read.
• Added LuaEntityPrototype::alert_icon_scale read.
• Added LuaBootstrap::get_prototype_history().
• Added LuaGameScript::console_command_used read.
• Added is_split to on_player_fast_transferred.
• Added LuaPlayer::drag_target read.
• Added LuaControl::surface_index and force_index read.
• Added LuaEntity::inserter_target_pickup_count read.

Modding

• Added LoaderPrototype::allow_rail_interaction and allow_container_interaction.

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

[ 2023-02-01 15:07:42 CET ] [ Original post ]

Hello, another year has come and gone. We know this year we were very sparse with any details about the expansion, and it is what you all really want to hear about. Trust me we really want to tell you about it, and in time we will. There are still major sections of the gameplay being changed and adjusted, and if we tell you about them now, the information would quickly become outdated and inaccurate. For now, we can offer this Christmas postcard Albert has made, which has a sneak peek of some new item icons.
As well, we do have some other topics we can discuss, on our website.

[ 2022-12-30 14:36:27 CET ] [ Original post ]

Changelog for 1.1.73 and 1.1.74

Bugfixes

• Fixed items dropped on underground belts could be inserted at a wrong position when transport lines were facing east or south. more
• Fixed DNS CNAME records confusing the SRV lookup on Windows more
• Fixed a crash when hovering over some rich text tags and destroying the object they refer to. more
• Fixed that "request from buffer chests" option wasn't copied between spidertrons. more
• Fixed that "request from buffer chests" option in spidertrons reset to default when prototypes changed. more
• Fixed directories in file dialogues not being sorted alphabetically on some systems. more
• Fixed dropdown button font color when clicked. more
• Fixed a crash when switching preferred audio device failed.
• Fixed not being able to remove script areas in the map editor. more
• Fixed that LocalisedString didn't support fallback groups in some cases when parsed from Lua. (https://forums.factorio.com/104297, https://forums.factorio.com/104303)
• Fixed a crash when a mod defines an entity that kills itself when created. more

Modding

• Added fallback groups format for localised string which picks the first correct translation. more
• Transparent black in RecipePrototype::crafting_machine_tint won't cause the tint to fallback to value of default_recipe_tint. more
• Added CarPrototype::immune_to_cliff_impacts, true by default. If set to false - entity will take damage when it collides with cliff prototype entities.

Scripting

• Added LuaPlayer::cursor_stack_temporary read/write.
• Added LuaPlayer::request_translations() for batching translation requests.

[ 2022-12-16 15:08:14 CET ] [ Original post ]

Hello, engineers! I'm a newer face at Wube and have been mainly working on expansion content for about one year now. Today, I'm here to share some exciting non-expansion news for our Mac players. Read the full blog post on our website.

[ 2022-11-25 11:05:09 CET ] [ Original post ]

Changelog for versions 1.1.71 and 1.1.72

Minor Features

• Added preferred audio device output setting.
• Added the current binary architecture to the main menu version string.
• Improve mod update checking for large mod collections

Optimizations

• Added native support for Apple Silicon Macs.

Graphics

• Loaders now show their item filters in alt mode.

Bugfixes

• Fixed a crash when canceling deconstruction of a pipe to ground while the GUI was open. more
• Fixed entity ghosts would draw wires even if prototype of inner entity disabled it. more
• Fixed incorrect panning of CyclicSound (for example, flamethrower turret's stream sound). more
• Fixed that ScriptRendering requested string localisation during on_init when it was not available. more
• Fixed Generator tooltip ignoring fluid emissions multiplier. more
• Fixed that teleporting cars between surfaces would create the build effect smoke. more
• Fixed a crash related to undoing mining of another forces entities after the other force had been deleted. more
• Fixed it was possible to acquire forbidden items in the Transport belt madness levels. more
• Fixed that linked-belt was missing from the collision mask defaults. more
• Removed 'Fuel emissions' label from Burner info panel. more
• Fixed that expansion parties could destroy spidertrons while building new bases. more
• Fixed a crash when doing alt-reverse selections in zoomed-in map mode. more

Modding

• Added Alt reverse selection support for selection tools. more

Scripting

• Added LuaGuiElement::close_dropdown().
• Added LuaInventory::is_full().
• Added 'include_bar' parameter to LuaInventory::count_empty_stacks().

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

[ 2022-11-22 15:08:19 CET ] [ Original post ]

Minor Features

• Added mod portal bookmarks to install mods gui

Bugfixes

• Fixed show-player-robots debug option would render lines for characters on other surfaces. more
• Fixed using incorrect sound settings when there is no configuration file.
• Fixed a crash related to teleporting spider vehicles with burner energy sources between surfaces.
• Fixed that the return value of some lualib noise functions didn't have the metatable for noise expression arithmetic. more
• Fixed simulation widgets showing savefiles trying to apply migrations in multiplayer. more
• Fixed upgrading pair of underground belt ghosts that makes them in reach would flip one of them without updating rotation point of nearby belts. more
• Fixed that logistic containers didn't deduplicate filters when importing them from untrusted sources which could crash the game. more
• Fixed a hard crash when a mod called deconstruct_area() with mismatched force and the player undid deconstruction of tiles. more
• Fixed highlight-box targeting entity not rendering before first update. more
• Fixed spider-remote would lose connection when spider changes surface. more
• Fixed SpidertronRemotePrototype was silently forcing stack size to 1 and not marking prototype as non stackable. more
• Fixed that sounds with fade_out_ticks would synchronize when pausing the game while the sounds are fading out. more
• Fixed idle sounds would synchronize when pausing the game. more
• Fixed idle sounds for accumulators not starting in certain scenarios. more
• Fixed idle sounds playing when they shouldn't for entities with max_sounds_per_type set.
• Fixed inserters not highlighting the entity they would pick up from if said entity is a ghost while the inserter is not. more
• Fixed a save's suggested save name not being updated when using non blocking saving. more
• Fixed a crash when GUI style errors are found during loading. more
• Fixed an item duplication when fast replacing underground belts with a damaged item. more
• Fixed that loader could get stuck when feeding a burner generator. more
• Fixed a crash when opening blueprint book item while tick is paused. more
• Fixed a unit group that is building a base could have all its members distracted and still build a base. more

Scripting

• Added LuaTechnology to LuaPlayer::opened.
• Added LuaEntityPrototype::ammo_category read.

[ 2022-10-27 14:02:56 CET ] [ Original post ]

We have a long history of trying to bring Factorio to other platforms, including consoles and mobile phones (not including April Fools). We even worked with some external companies, but the projects never even got to the point where they would run technically, let alone the complicated part of making the game playable using controllers or touch screen. After all the attempts, we even had a Friday Facts prepared that was going to say something along the lines of "we don't plan to bring Factorio to other platforms". However that turns out to me not the case, and we also have an update about the progress on the expansion. Read the full blog post on our website.

[ 2022-09-23 11:10:24 CET ] [ Original post ]

Graphics

• Updated transport belt icons.

Bugfixes

• Fixed unregistering multiple events at once would not clear event filters. more
• Fixed inactive mining drill playing its working sound for a moment when panning over it. more
• Fixed a crash when pressing Alt+F4 or clicking the X button when in sound settings. more
• Fixed a crash when changing the force of a logistic container marked for deconstruction. more
• Fixed a crash in production score script when a rocket launch product has probabilistic amount. more
• Fixed a crash in production score script when a resource entity is given no mineable products. more
• Fixed collision mask util not ignoring other flags when checking "not-colliding-with-itself" masks. more
• Fixed the player losing contents of the cursor when starting the round in tightspot scenario. more
• Fixed wave defense losing all upgrades after some prototype changes. more
• Fixed inactive entity working sound playing its fade-out when pausing and unpausing the game.
• Fixed that mod ordering didn't work correctly when searching in the install mods GUI. more
• Fixed that the 'starting points' in MapGenSettings wasn't loaded when importing a map exchange string. more
• Fixed that event filters for on_pre_ghost_deconstructed and on_pre_ghost_upgraded weren't filtering correctly. more
• Fixed that changing render threads to 1 while menu simulations were visible would crash the game. more
• Fixed rocket silo would get stuck when rocket_parts was set during launch. more
• Fixed smooth zoom behavior at high game speeds. more
• Fixed a performance issue when many roboports re-activate at the same time. more
• Fixed that the sync-mods-with-save GUI didn't work correctly when failing to download in some situations. more
• Fixed solar panel equipment was unable to produce full expected power when solar multiplier was larger than 1. more
• Fixed boiler's energy source buffer size was not updated when prototypes data changed. more

Modding

• Added torso_bob_speed to the spider vehicle prototype.

Scripting

• Added LuaEntityPrototype::torso_bob_speed read.

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

[ 2022-09-16 08:57:15 CET ] [ Original post ]

Changelog of versions 1.1.61 to 1.1.67

Minor Features

• Added support for SRV records on Windows.
• Added support for SRV records on Linux and MacOS.

Changes

• The game no longer requires re-entering server passwords when restarting to sync mods or mod settings.
• When joining modded games mods and settings are synced at the same time reducing the number of restarts needed.
• Integrated SDL_Mixer for audio mixing, which is now the default mixer.
• Added PulseAudio driver for the SDL audio backend.
• Added Wayland driver for the SDL video backend.
• Updated the --audio-driver command line option description for Windows, and added the option for Linux and Mac.
• Storage tanks can now show fluid connection info.

Bugfixes

• Fixed server getting stuck at "Saving the map for player" for 20 seconds sometimes if a client disconnects shortly after connecting.
• Fixed server getting stuck at "Saving the map for player" forever in some rare situations.
• Fixed highlight box on curved-rail would not render selection box correctly. more
• Fixed heavy-mode when character dies in multiplayer. more
• Fixed that the "run forest, run" achievement could be unlocked by shooting trees instead of running them over. more
• Fixed a crash when trying to read LuaEntity::neighbours on a WallConnectable when one of the neighbours is a ghost. more
• Fixed recipe highlights in the assembling machine GUI. more
• Fixed an issue with the prototype explorer GUI and guns. more
• Fixed false-positive desyncs when using mods and running /c game.force_crc() or /toggle-heavy-mode more
• Fixed a crash when defining a fluid stream prototype with zero particles. more
• Fixed a GUI layering issue related to some error messages. more
• Fixed not being able to open blueprint books in books through the quickbar. more
• Fixed LuaSurface::find_entities_filtered would fail to find entities by collision mask if they only collide with tiles. more
• Fixed that pump that cannot interact with fluid wagons would crash on save after position change. more
• Fixed a desync when canceling deconstruction of cliffs when a robot has already thrown the explosive. more
• Fixed startup mod settings would show as being able to be reset while the game is running. more
• Fixed an issue when installing mod dependencies related to base-game dependencies. more
• Fixed an issue with biter AI that could freeze the game. more
• Fixed a crash when viewing other player inventories when changing controllers. more
• Fixed that the LuaPlayer::remove_alert 'prototype' parameter wouldn't accept an actual prototype instance. more
• Fixed character inventory was not auto sorted when changing armor. more
• Fixed that the reset-to-default tooltip for string mod settings wasn't fully localised. more
• Fixed a crash when trying to draw a wire connected linked container in a blueprint. more
• Fixed linked containers with filters would not preserve filters while there are no containers placed. more
• Fixed a crash when using SDL audio backend with configurations other than stereo. more
• Fixed a desync when using LuaGameScript::get_train_stops when there are multiple stops found.
• Fixed a crash related to transport belts and item entities. more
• Fixed linked container content was cleared when entity dies leaving a ghost. more
• Fixed linked container content was cleared when fast-replacing through script. more
• Fixed locomotives on curved rails would not snap to train stops. more
• Fixed a crash related to audio. more
• Fixed that it was possible to provide invalid path_resolution_modifier value to LuaSurface::request_path. more
• Fixed double click interaction with number input. more
• Fixed teleporting spidertrons across surfaces while also changing their position. more
• Fixed manual filter insertion logic with modded container entities. more
• Fixed a crash related to multiplayer latency and modded selection tools. more
• Fixed an inserter activity progress being incorrect for certain orientations.
• Fixed a sound instance leak. more
• Fixed integer mod settings would allow decimal values. more
• Fixed that renaming a spidertron wouldn't include the player during the Lua event. more
• Fixed a lag spike when finishing selection of entities in chart view far from the center of the map. more
• Fixed a crash related to copy tool when cursor stack was cleared during setup blueprint event. more
• Fixed multiple instances of the same working sound syncing up, causing "phasing" artefacts.
• Fixed fluid wagon fluid tooltips would round the amount shown incorrectly.
• Fixed some sounds playing in fog-of-war when they shouldn't.
• Fix modded entities not showing input-output fluid connection arrows more
• Fixed LuaControl::enable/disable_flashlight when LuaPlayer points at a player with CharacterController. more
• Fixed incorrect fluid arrows on chemical plants, pumpjacks and oil refineries more

Modding

• The mod settings GUI will now show the 'tooltip' icon for any settings that have tooltips.
• Added a reset button to each mod setting in the mod settings GUI.
• Modded tips and tricks information is remembered when the associated mods are temporarily removed/disabled.
• Added support for container entities with filters by using inventory_type = "with_bar" or "with_filters_and_bar".
• Added EntityPrototype::build_grid_size. Supported values are 1 (for 1x1 grid) and 2 (for 2x2 grid).
• Added EntityPrototype::use_exact_mode.
• Added support for circuit connections to linked containers.
• Added the entity prototype flag not-in-made-in to allow hiding things from the 'made in' recipe tooltip.
• Added FluidBox::hide_connection_info. When true the blue fluid connection arrows will not be drawn.

Scripting

• Added LuaControl::crafting_queue_progress write.
• Added LuaTile::tile_ghost.
• Added 'to_be_deconstructed', and 'has_tile_ghost' filters to the options for LuaSurface::find_tiles_filtered.
• Added LuaEntityPrototype::indexed_guns. It works as LuaEntityPrototype::guns but returns an array.
• Collision-mask prototype filters for Entity, Tile and Decorative now support a 'contains-any' and 'contains-all' modes.
• Added support to set player.opened to script inventories.
• LuaEntity::get_connected_rail also returns rail_direction and rail_connection_direction going back to origin rail.
• Added on_pre_ghost_upgraded event.
• Added LuaEntity::get_rail_segment_rails.
• Added LuaEntity::is_rail_in_same_rail_segment_as.
• Added LuaEntity::is_rail_in_same_rail_block_as.
• Added LuaEntity::get_parent_signals.
• Added LuaEntity::get_child_signals.
• Added LuaEntity::get_inbound_signals.
• Added LuaEntity::get_outbound_signals.
• Added LuaEntity::rocket_silo_status read and defines.rocket_silo_status
• Added LuaBootstrap::register_metatable.
• Added LuaLogisticNetwork::can_satisfy_request.
• Added LuaLogisticNetwork::get_supply_counts.
• Added LuaLogisticNetwork::get_supply_points.
• Added LuaEntityPrototype::use_exact_mode read.
• Added LuaEntityPrototype::active_energy_usage, idle_energy_usage, lamp_energy_usage reads.
• Added rocket_silo_input, rocket_silo_output, rocket_silo_modules inventory defines.
• Added LuaEquipmentGrid::unique_id read.
• Added LuaForce::color read.
• Added LuaForce::custom_color read/write.
• Added target to on_pre_ghost_upgraded.
• Added target and direction to on_cancelled_upgrade.
• Added LuaEquipmentGrid::find/count methods.
• Added LuaEntityPrototype::tile_width/tile_height reads.
• Added LuaEntity::tile_width/tile_height reads.
• Added range_modifier, cooldown_modifier, consumption_modifier fields to AmmoType concept.
• Added LuaEntity::stop_spider().

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

[ 2022-08-29 09:19:01 CET ] [ Original post ]

Changelog for versions 1.1.60 and 1.1.61

Changes

• The game no longer requires re-entering server passwords when restarting to sync mods or mod settings.
• When joining modded games mods and settings are synced at the same time reducing the number of restarts needed.

Optimizations

• Improved game startup time when using mods.

Bugfixes

• Fixed that item requests didn't subtract items picked up from ground when reviving ghosts. more
• Fixed burner inserter would not fuel itself when drop target was full. more
• Fixed that inserters would report status other than "Waiting for space in destination" in certain cases. (https://forums.factorio.com/102225, https://forums.factorio.com/65351)
• Fixed that Lua collision mask util didn't check for tile prototypes. more
• Fixed that map pings would always round up the pinged location. more
• Fixed that replays would always say mods didn't match. more
• Fixed that canceling syncing mods with a save would exit the GUI.
• Fixed that canceling syncing mods with a save through escape would leave the partially downloaded mods.
• Fixed that the circular dependency error doesn't list all mods. more
• Fixed a deadlock on loss of ConnectionAcceptOrDeny message. more
• Fixed a desync when fast-replacing burner generators.
• Fixed server getting stuck at "Saving the map for player" for 20 seconds sometimes if a client disconnects shortly after connecting.
• Fixed server getting stuck at "Saving the map for player" forever in some rare situations.
• Fixed highlight box on curved-rail would not render selection box correctly. more
• Fixed heavy-mode when character dies in multiplayer. more
• Fixed that the "run forest, run" achievement could be unlocked by shooting trees instead of running them over. more
• Fixed a crash when trying to read LuaEntity::neighbours on a WallConnectable when one of the neighbours is a ghost. more
• Fixed recipe highlights in the assembling machine GUI. more
• Fixed an issue with the prototype explorer GUI and guns. more
• Fixed false-positive desyncs when using mods and running /c game.force_crc() or /toggle-heavy-mode more
• Fixed a crash when defining a fluid stream prototype with zero particles. more
• Fixed a GUI layering issue related to some error messages. more
• Fixed not being able to open blueprint books in books through the quickbar. more
• Fixed LuaSurface::find_entities_filtered would fail to find entities by collision mask if they only collide with tiles. more
• Fixed that pump that cannot interact with fluid wagons would crash on save after position change. more

Modding

• The mod settings GUI will now show the 'tooltip' icon for any settings that have tooltips.
• Added a reset button to each mod setting in the mod settings GUI.

Scripting

• Added LuaEntityPrototype::height, torso_rotation_speed, automatic_weapon_cycling, chain_shooting_cooldown_modifier, chunk_exploration_radius reads.
• Added LuaEntityPrototype::animation_speed_coefficient.
• Added LuaEntityPrototype::manual_range_modifier.
• Added LuaEntityPrototype::dying_speed read.
• Added sample_index parameter to LuaFlowStatistics::get_flow_count().
• Added LuaControl::crafting_queue_progress write.
• Added LuaTile::tile_ghost.
• Added 'to_be_deconstructed', and 'has_tile_ghost' filters to the options for LuaSurface::find_tiles_filtered.
• Added LuaEntityPrototype::indexed_guns. It works as LuaEntityPrototype::guns but returns an array.
• Collision-mask prototype filters for Entity, Tile and Decorative now support a 'contains-any' and 'contains-all' modes.

[ 2022-06-29 09:44:15 CET ] [ Original post ]

Changes

• Significantly reduced the intensity of the red screen flash when the player character takes damage.
• Changed fish so they won't swim into inactive chunks. more
• Changed slowdown capsule and posion capsule icons to be matching in size. more
• Added email authentication to login GUIs.

Bugfixes

• Fixed that overwriting ItemRequestProxy item requests wasn't working properly in some cases when the same item was already requested. more
• Fixed that loading a mod with a corrupted image file would crash the whole game on Linux. more
• Fixed a crash with ghost overbuilding and script interactions. more
• Fixed that infinite technologies didn't respect ignore_tech_cost_multiplier. more
• Fixed that LuaEntity::belt_neighbours didn't work on ghosts. more
• Fixed an issue with item-with-inventory extending inventories and quickbars. more
• Fixed that a train stop helper would not draw when hovering inserters next to rails that were not straight connected to a train stop. more
• Fixed a crash when fast replacing electric pole marked to be deconstructed when there is another ghost pole on top of it. more
• Fixed a crash when creating a blueprint with connected electric pole while it has an upgrade target set to not electric pole. more
• Removed a NaN check when loading map. more
• Fixed a screenshot for save file preview would not account for a force of a player. more
• Removed duplicated frame in grenade and cluster grenade animation. more
• Fixed a map loading issue when changing mod dependencies and nothing else. more
• Fixed a crash when trying to perform some actions while in multiplayer. more
• Fixed rotating entities with non-symetric bounding boxes didn't work correctly. more
• Fixed that already built pipes to ground could show removal indicators for pipes they are bridging when selected.
• Fixed the runtime multiplayer settings GUI wouldn't fit on screen. more
• Fixed that inserters could be flipped in some cases when they weren't supposed to allow it. more
• Fixed that cliff deconstruction wasn't issued when the corrected cliff collision box overlapped with ghost entities. more
• Quickbar shortcuts to items in blueprint books can be used again. more
• Fixed grenade shadows.
• Fixed it was possible to put blueprint book indirectly into itself more

Scripting

• Added on_research_cancelled.
• Added on_player_reverse_selected_area.

[ 2022-05-11 12:29:29 CET ] [ Original post ]

Changelog from version 1.1.54 to 1.1.57

Minor Features

• The multiplayer games browser can now filter games that are hosted on dedicated servers.

Gui

• Some GUI fixes and improvements for screen resolutions under 1920x1080
• Set the default GUI scale on the Steam Deck to 100%

Optimizations

• Improved overall performance by 5-10% when fully zoomed out.

Bugfixes

• Fixed west variation of Boiler and Heat exchanger graphics. more
• Fixed save/load instability occuring when the game was saved after a robot threw cliff explosives but before the cliff exploded.
• Fixed a crash when script tries to connect rolling stock during rolling stock destruction. more
• Fixed LuaTransportLine::output_lines on a splitter's output transport line would incorrectly consider it an input transport line of that splitter. more
• Fixed LuaTransportLine::input_lines would not return both input lines of a splitter.
• Fixed that when train was created, a wrong end could be selected as a front when rolling stock at expected trains front was facing backward.
• Fixed that it was possible to specify artillery-projectile as a place_result of an item. more
• Fixed unnecessary disk writes when showing background simulations. more
• Fixed that sometimes the host would not have admin rights when hosting a multiplayer game from a save.
• Fixed LuaSurface::find_tiles_filtered would not cover bottom right tile.
• Fixed that too many open RCON connections would crash the game. There is now a limit of maximum of 128 simultaneous RCON connections. more
• Fixed a crash related to modded trains that could change travel direction due to air friction computation. more
• Fixed energy consumers would get too much energy when supplied through multiple electric networks. more
• Fixed a crash due to LuaLogisticCell not being invalidated when owner entity is being deleted. more
• Fixed that non-lamp entities could be given the 'lamp' electric usage priority which would crash the game. more
• Fixed locomotive placement would snap to wrong train stop when there are multiple stops available. more
• Fixed that the whitelist button was enabled in the /config GUI. more
• Fixed searching for items in controller gui would not highlight item stacks in the trash slots. more
• Fixed that building underground belt ghosts with smart belt building would crash if ghosts are immediately revived by script. more
• Fixed very high deconstruction_time_to_live value would lead to deconstruction orders expiring too soon. more
• Fixed that a multiplayer client could desync several times in a row, making the server save the map for desync report multiple times.
• Fixed that crafting recipes with products exceeding their stack limit would produce only a single full stack when crafting by hand. more
• Fixed tips and tricks GUI staying open when changing controllers, and not being able to close it afterwards. more
• Fixed PvP config for health bonus didn't apply correctly.
• Fixed that if the game couldn't connect to a server due to corrupted data, it wouldn't show any error to the user. more
• Fixed that the Steam version wouldn't start on Linux and OSX.
• Fixed poison cloud sound fade out.
• Fixed tooltips for vehicles would still show entry instructions even when no passengers are allowed. more
• Fixed train stop names with different amounts of leading spaces being treated as equal in some cases but not in others. more
• Fixed idle machines without idle sound counting towards the max_sounds_per_type limit. more
• Fixed that changing the force of artillery wagons didn't work. more
• Fixed a crash when using non-rectangular equipment. more
• Fixed a crash when building underground belt or pipe ghosts over belts/pipes of other forces. more
• Fixed character corpse armor variations being inconsistent with character armor variations. more
• Fixed a consistency issue if a Lua event handler cancelled deconstruction of an entity that was marked for deconstruction as a result of fast-replace. more
• Fixed that some error messages wouldn't be translated. more
• Fixed that biters might remain inactive when they should be activated. more
• Fixed that units could teleport through cliffs if they bunched up close together. more
• Fixed that setting LuaGuiElement::zoom to 0 would crash the game. more
• Fixed a crash when changing mod options while the cursor hovers the "Back" button. more
• Fixed a crash due to recursive chain signal update. more
• Fixed that if a non-attack distraction command failed, it would raise the on_ai_command_completed event repeatedly. more
• Fixed that opening web links in the Linux Steam build of the game could take unreasonably long. more
• Fixed that logistic requests, item filters and similar could be set to the copy-paste tool when clicking the slot while holding that item. more

Scripting

• Added 'is_military_target' filter to the options for LuaSurface::find_entities_filtered.
• Added LuaFluidBox::get_fluid_system_id() method.
• Added LuaItemPrototype::reverse_* read for selection tool.
• Added LuaEntity::radar_scan_progress read.
• Added LuaEntityPrototype::logistic_parameters read.
• Added LuaEntityPrototype::heat_buffer_prototype read.
• Added LuaHeatEnergySourcePrototype::heat_buffer_prototype read.

Modding

• Added LocomotivePrototype::max_snap_to_train_stop_distance.
• Added AutoplaceControl::can_be_disabled.

[ 2022-04-01 14:54:24 CET ] [ Original post ]

No doubt you have heard about NFTs, the latest Blockchain innovation. With some big gaming companies exploring NFTs, where does Factorio stand? Read the full blog post on our website.

[ 2022-04-01 12:20:51 CET ] [ Original post ]

We are a games company based in the Czech Republic. Russia's invasion of Ukraine affects us directly. We have team members there, we have friends there, and we get information first hand. There is no excuse for the actions of the Russian army, they have little regard for civilians including children. We support Ukraine and have made contributions to relief efforts. We support Russians that stand against the actions of the Russian government. You can help too, even if it is just with your voice. World leaders are listening: every voice counts.
The Czech National museum, which has bullet scars from the Russian invasion of Czechoslovakia in 1968. Please, keep the discussions about the world events (if you can't help it) specifically in threads related to this post, as we want to keep the rest of the content on topic.

[ 2022-03-02 10:56:10 CET ] [ Original post ]

Hello, Today is actually the 6 year anniversary of Factorio launching on Steam, and just recently too we passed 3 million total sales (and we're even past 3.1 million at this point), so it is quite a milestone. It is great for us that the game is still selling consistently year on year, even though we never take part in sales or bundles. Read the full blog post on our website.

[ 2022-02-25 16:06:37 CET ] [ Original post ]

Hello, long time no talk, we've got some catching up to do... Almost 1 year ago we said "we don't think that [the expansion] will take less than a year to develop". Well it has been less than a year and it is not finished, so we kept our word on that :). But while it might not be finished, there is a still a lot we have done so far. Read the full blog post on our website.

[ 2022-02-04 13:36:58 CET ] [ Original post ]

Changes

• When using /swap-players undo queues are now also swapped.
• Improve performance of querying if an entity is registered for deconstruction from O(N) to O(1).
• Adjusted default music volume.

Bugfixes

• Fixed that if biters took damage from a forest fire, they would path toward the player who started it, no matter the distance. more
• Fixed that replacing a tile between a colliding hidden tile (with check_collision_with_entities set to true) and an entity would not yield an item.
• Fixed that LuaGameScript::ban_player would incorrectly use reason as a player name when given player was never in game. more
• Fixed that the saving progress bar and other popups were placed behind the transparent pause overlay. more
• Fixed a scenario could be created with temporary-state trains which were not properly deleted. more
• Fixed a crash when using --map-settings while loading a multiplayer map. more
• Fixed that trying to manually mine a resource that needs a mining fluid would sometimes produce sound of mining. more
• Fixed script rendered arcs could be considered invisible when they were visible. more
• Fixed that LuaEntity::belt_neighbours would return LuaEntity based on EntityGhost's inner entity, not the EntityGhost itself. more
• Fixed fish preventing tiles building with check_collision_with_entities enabled.
• Fixed that trains would not account for the train stop snap distance when already at the train stop with the back of a train. more
• Fixed the intro music volume being set incorrectly.
• Fixed that --start-server-load-latest when given an empty saves folder wouldn't work correctly. more
• Fixed missing efficiency tooltip and incorrect fuel consumption tooltip value in generator equipment with burner energy source.
• Fixed ghost electric poles connecting to ghost electric poles of other forces. Neutral force is exempt from this change. more
• Fixed that biters would sometimes prefer running away over choosing another target. more
• Fixed trains pathfinder would crash when a train is in a loop next to segment end and was requested to go to rail target in the middle of a loop. more
• Fixed multi-level technologies showing the same saved progress in technology GUI. more
• Fixed an icon of recipe notification on item group would show even if there are no recipes visible in a given context. more
• Fixed a crash when defining too many icon variations. more
• Fixed changing station name with rich text tags could crash when moving cursor by words. more
• Fixed LuaBurner::inventory did not work correctly for some burner-energy-source entities. more
• Fixed a crash caused by undoing an entity deconstruction which another player already cancelled. more

Modding

• Added EntityPrototype::protected_from_tile_building, true by default. If set to false - entity won't block tile mining/building (with `TilePrototype::check_collision_with_entities` enabled).
• Added LandMinePrototype::trigger_collision_mask.
• Added EntityWithOwnerPrototype.
• Added EntityWithOwnerPrototype::is_military_target and allow_run_time_change_of_is_military_target.
• SimpleEntityWithForce now inherits from SimpleEntityWithOwner.
• SpiderEnginePrototype::military_target is no longer used. If anything is provided it will make related SpiderVehiclePrototype to become a military target instead.

Scripting

• Added LuaEntityPrototype::trigger_collision_mask read.
• Added LuaEntity::is_military_target read. This deprecates LuaEntity::is_entity_with_force.
• Added LuaEntityPrototype::is_entity_with_owner, is_military_target and allow_run_time_change_of_is_military_target read.
• Added LuaEntity::get_spider_legs().
• Added LuaEntity::neighbours read for cliffs.

[ 2022-01-21 16:18:51 CET ] [ Original post ]

Minor Features

• The permissions list in the permissions GUI can now be localised.
• Removed feature where reactor collision box would increase when connected to neighbouring reactor (character can now walk in-between connected reactors)

Bugfixes

• Fixed that biters could get stuck trying to attack an entity they were standing on. more
• Fixed issue regarding placing an electric pole over a ghost of an electric pole connected to an enabled power switch. more
• Fixed a crash related to units and mod events. more
• Fixed ghost entities of other forces being considered valid drop targets. more
• Fixed ghost electric poles connecting to electric poles of other forces. Neutral force is exempt from this fix, it can connect to everything. more
• Fixed that LuaEntity::disconnect_neighbour was unable to disconnect specified pair of electric poles when they were on different surfaces.
• Fixed gate cloning related to opened state. more
• Fixed that on_game_created_from_scenario event didn't fire after pressing "Save and Play" from map editor. more

Modding

• Added LuaTilePrototype::check_collision_with_entities, false by default. If set to true - checks for collisions with entities before building or unearthing the tile.
• Removed ReactorPrototype::neighbour_collision_increase.

[ 2021-12-23 15:47:21 CET ] [ Original post ]

Bugfixes

• Fixed transport belts picking up items on ground when rotated. more
• Fixed that game.map_settings.path_finder.fwd2bwd_ratio could be set to nonsensical values. more
• Fixed main menu track playing only once. more
• Fixed that units could get stuck close to their goal. more
• Fixed that the small research bar in a technology slot wouldn't show for the technology currently in research. more
• Fixed a crash which was caused by early garbage collection of LuaObject because LuaObject method closures didn't hold a back reference to the object. more
• Fixed barelling recipe icons having incorrect tint with index-based fluid color definitions. more
• Fixed barelling recipe icons having incorrect alpha with fluid color definitions in 0-255 range.

Scripting

• LuaObjects are now saved using binary format instead of previous format with intermediate Lua table. This speeds up general handling of LuaObjects and makes saving and loading with a lot of them noticable faster.
• LuaObject::isluaobject now returns true instead of a magic string.
• Clarified LuaGameScript::finished. more
• Added LuaGameScript::finished_but_continuing read.
• Added LuaGameScript::reset_game_state() method.
• Implemented new website for Lua API documentation.

[ 2021-12-10 08:46:39 CET ] [ Original post ]

Bugfixes

• Added tip about power pole coverage when drag-building.
• Fixed that the distance between first and second pole in the dragging electric poles tutorial was 6 tiles instead of 7.
• Fixed LuaGameScript::save_atlas() function would crash the headless server. more
• Fixed possibility for the victory screen to be hidden behind other GUIs under specific circumstances more
• Fixed generator and fluid energy source tooltip showing 0 fluid consumption if burning fluids with 0 fuel value or consuming fluids with temperature close to the default. more
• Fixed the inserter "hand stack size" tooltip missing if the research-based bonus value was 1. Now it is shown if the value is greater than 0. more
• Fixed the inserter "hand stack size" tooltip ignoring stack_size_bonus prototype property.
• Fixed cloning linked-container would clear its inventory.

Modding

• Added FluidEnergySourcePrototype::destroy_non_fuel_fluid, true by default.
• Added GeneratorPrototype::destroy_non_fuel_fluid, true by default.
• Changed tip trigger name from "unlocked-recipe" to "unlock-recipe" to be consistent with the way other triggers are named.

Scripting

• Added LuaEntityPrototype::inserter_stack_size_bonus read.
• Added LuaFluidEnergySourcePrototype::destroy_non_fuel_fluid read.
• Added LuaStyle::bar_width read/write.
• Added LuaPlayer::show_on_map read/write.
• Reworked table saving and loading to be non-recursive. This allows to have extreme table nesting inside of `global` variable.

[ 2021-11-25 12:54:12 CET ] [ Original post ]

Changes

• Reduced multiplayer latency on very good connections by up to 66ms(4 ticks). more
• Changed multiplayer latency calculation to be smoother. This should reduce multiplayer stutter on bad connections.
• Changed default network send rate from 30 to 60 packets per second and added an option to configure the rate in server-settings.json.

Bugfixes

• Add a 70% damage bonus to discharge defenses with Energy Weapons Damage 6 and 7. more
• Fixed flamethrower turrets not reporting the correct damage bonuses
• Fixed gun turret tooltips showing the ammo in the middle of the other stats
• Fixed artillery wagon and artillery turret tooltips not showing the damage of the loaded ammo
• Fixed drawing wall filler when hovering mouse over ghosts. more
• Fixed crash when trying to connect wire after wire type in cursor stack was changed by script. more
• Fixed roboport would not output signals for 1 tick when electric pole was mined while having circuit wire from same circuit network. more
• Fixed that the pole drag building skip trigger didn't work, so the tip was always shown even when the player used drag building.
• Fixed LuaItemStack::get_tile_filter would incorrectly return entity filters. more
• Fixed mining drill GUI not being openable if the drill didn't have module slots or energy source with GUI. more
• Fixed a crash when using 0-length debug names in Lua bytecode. more
• Fixed that setting the scale parameter to zero in a spidertron leg definition would cause a "double value not in range for fixed point number" error. more
• Fixed crash when destroying a vehicle on the same frame a tooltip is created for the vehicle's weapon and ammo bar. more
• Fixed that building an entity over other forces' ghosts and undoing would transfer ownership of those ghosts to the undoer's force.
• Fixed a crash when setting inserters to require no power when rotating/extending. more
• Fixed "create-trivial-smoke" triggers being interpreted as "create-entity" triggers in the prototype explorer which could cause a crash. more
• Added migration for saves with inserters that have NaN hand height or hand length.

Modding

• Added TurretPrototype::energy_glow_animation_flicker_strength.
• Removed obsolete pollution-visualization sprite, which was replaced by pollution_color utility constant.
• Sub items are now removed from items used in hand-crafting.

Scripting

• Added LuaEntity::connected_rail_direction read.
• Added TrainScheduleRecord::rail_direction.
• Added LuaGuiElement::swap_children().

[ 2021-11-06 08:18:38 CET ] [ Original post ]

Bugfixes

• Fixed an API error when checking for updates for a large number of mods. more
• Fixed that inserters wouldn't remove burnt result items from assembling machine recipes with no item outputs. more
• Fixed vehicle weapon slots GUI not highlighting with the corresponding ammo slot when selected
• Fixed tank cannon weapon showing a "1" in the vehicle weapon slots GUI
• Fixed that entities not containing certain collision masks would never collide with tiles. more
• Fixed a crash when opening the tutorials GUI through Lua command. more
• Rocket silo no longer drains more energy at night. more
• Fix tank cannon showing smaller range than the cannon shells. more
• Fix ugly death GUI when the game is paused in MP. more
• Fix 'Game finished' GUI had an incorrect tooltip for the green button. more
• Fixed that copy paste entity tips were dependant on the copy-paste tool tip instead of copy paste entity category.

Modding

• Added OffshorePumpPrototype::check_bounding_box_collides_with_tiles.
• RocketSiloPrototype::lamp_energy_usage now can be zero.

Scripting

• Added freeplay remote interface to read the value of `skip_intro`. more

[ 2021-10-13 12:32:29 CET ] [ Original post ]

Features

• Added auth server bans feature for multiplayer games. When enabled this will inform the Factorio.com authentication server of ban and unban commands issued in multiplayer sessions. Designed to combat griefers in multiplayer games, it will also query the authentication server for a ban recommendation when a user tries to connect.

Bugfixes

• Fixed that trigger prototype flag filters didn't work correctly when an entity had no flags set. more
• Fixed a crash after inserting fuel into burner inserter while it was already trying to fuel itself. more
• Fixed that unrelated entities were highlighted when using a cut tool. more
• Fixed that in editor mode undoing deconstructions did not instantly revive affected entities. more
• Fixed that setting the direction of a script created character entity didn't work correctly. more
• Fixed that items with fuel value would be put into furnace fuel inventory when there was enough fuel but item could be smelted. more
• Fixed inserters picking up items on ground marked for deconstruction. more
• Fixed that the low power tip didn't show in some circumstances.
• Tweaked some of the triggers to show/skip tutorials related to drag building.
• Fixed that Furnace's working_visualisations would not apply recipe tint on fadeout. more
• Fixed crash due to usage of standard library function that is missing on macOS 10.11. more

[ 2021-09-24 11:27:32 CET ] [ Original post ]

Bugfixes

• Fixed that rotating belt direction when dragging allowed "stash" the rotate and continue in the original direction. more
• Fixed that loading a game that was saved during drag building didn't clear the internal drag building state causing blueprint snapping not working properly. more
• Fixed that LuaGameScript::check_prototype_translations() didn't check technologies. more
• Fixed that items with data would not stack properly in crafting machine source inventory when recipe requires more than a stack of ingredient. more
• Fixed that pasting a blueprint over existing train could cause a desync. more
• Fixed that it was possible to interact with locomotive's fuel slots while out of reach. more
• Fixed wrong status text when a mining drill drop target is marked for deconstruction. more
• Fixed wrong mining drill status when a resource is depleted while the mining drill is missing the required fluid. more
• Fixed the blueprint snap-to-grid reference point being drawn behind entities in some situations. more

Scripting

• LuaEntityPrototype::resource_categories now supports characters.
• Added on_equipment_inserted and on_equipment_removed events that fire any time any equipment is added/removed from a grid.

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

[ 2021-09-07 07:45:05 CET ] [ Original post ]

Changes

• New Titillium style font for Cyrillic languages.

Bugfixes

• Fixed inconsistency when fast-replacing ghosts with circuit connections. more
• Fixed an issue with drag-building electric poles with long wire reach. more
• Fixed a crash related to tutorials and modding. more
• Fixed an issue with LuaEntity::set_request_slot() and duplicates. more
• Fixed that picking blueprints from the library through quickbar slots didn't fire the Lua cursor stack changed event. more
• Fixed items with durability/ammo wouldn't merge properly in some cases. more
• Fixed a roboport "recharging" icon appearing when not connected to the electric network. more
• Fixed an issue with roboports left in recharging state when revived from ghosts. more
• Fixed an issue where an error sound played when pasting onto a power switch from anything other than another power switch more
• Fixed that the non-blocking saving option would be reset when resuming a multiplayer game using the continue button. more
• Fixed 'Close preview' button having cut off text in some locales. more
• Fixed a crash when deleting surfaces with script-connected electric poles. more

Scripting

• Added LuaEntity and LuaUnitGroup::set_distraction_command.
• Added LuaSurface::find_nearest_enemy_entity_with_owner().
• Added LuaForce::is_friend() and is_enemy().

[ 2021-08-20 10:35:58 CET ] [ Original post ]

Bugfixes

• Fixed belt drag building on the edge of building reach. more
• Fixed that canceling upgrade of underground belt didn't make the corresponding operation with the (potentially) connected belt on the other side.
• Fixed making blueprint from underground belt with direction upgrade order.
• Fixed technology icons of flamethrower and rocketry. more
• Fixed hang when deleting blueprint/deconstruction/upgrade planner or blueprint book held by an inserter. more
• Fixed hang when trying to delete blueprint/deconstruction/upgrade planner or blueprint book that was moved to different inventory in the meantime. more
• Fixed pressing delete key in save/load game menus multiple times would pop-up confirmation dialog multiple times. more
• Fixed that the close map generator preview button icon was too large. more
• Fixed that the show/close map generator preview button didn't loose hover after the preview was shown.
• Fixed that Cut and copy paste tools select trains in the standard selection mode, even when trains are ignored in this mode. more
• Fixed crash related to wrong identification of non-default values in the mod settings gui. more
• Fixed that linked custom inputs didn't work for some game controls. more
• Fixed that the train fuel tab didn't work right for clients in multiplayer. more
• Fixed a crash when using the prototype explorer GUI after just changing mods. more
• Fixed rare corner case related to removal of mods and entities in more than 1 electric network. more
• Fixed item product overload logic when using variable output items. more
• Fixed crash when starting game without base mod and with --disable-prototype-history. more
• Fixed a crash when using set_stack in blueprint books. more
• Fixed a crash when cloning script-disabled beacons. more
• Fixed a crash when using repeat_count with frame_sequence in animation definition. more
• Fixed a crash when trying to build a rolling stock between other rolling stocks from a single train. more
• Fixed ghost entities had reflections on water.
• Fixed a desync related to processing on_gui_opened event of opening blueprint records in multiplayer games.
• Fixed a crash when trying to pick a fluid wagon with fluid in clone tool. more
• Fixed that copying assembling machine recipes didn't update fluidbox temperature filters in some cases. more
• Fixed that robots could sometimes leave roboports very slowly if they were called to work in the middle of descending into a roboport. more
• Fixed trains GUI status button tooltip not updating. more
• Fixed LuaPlayer::build_from_cursor would flip direction when every other building underground belts/pipes. more
• Fixed Train GUI wait condition bars display with 0 slot cargo wagons. more
• Fixed in-game EULA showing HTML character sequences. more

Scripting

• Fixed clearing LuaCustomChartTag.icon by writing nil or empty SignalID.
• Added LuaPlayer::start_selection and clear_selection.
• Added freeplay remote interface methods for adjusting the crashsite.

Modding

• Added overlay layer to the tree variation definitions. more
• Fixed parameter substitution when used with standard parameter more
• Removed unused equipment prototype property "ability_icon".
• Added select_group_row_count, select_slot_row_count, inventory_width, module_inventory_width, tooltip_monitor_edge_border, normalised_achievement_icon_size, tutorial_notice_icon_size and flying_text_ttl to utility constants.

[ 2021-07-17 06:09:00 CET ] [ Original post ]

Hello, long time no see :) We obviously have a lot to talk about when it comes to the game changes we recently did, or plan to do, but we don't want to share any of it yet. Yet, there is currently a topic very relevant to us and we can share it without revealing any specific changes to the game. Today's post will be quite technical and related to programming, so if you just came for the game news, you can safely skip this one. You can read the full blog post on our website: https://factorio.com/blog/post/fff-366

[ 2021-06-18 14:11:36 CET ] [ Original post ]

Bugfixes

• Fixed multiple issues related to placing blueprints with electric poles near other electric poles or ghost thereof. more
• Fixed a lighting issue with QCK Prism mousepads. more
• Fixed recipe notifications when a recipe is hidden from hand crafting. more
• Fixed that units dying wouldn't contain the unit group they were part of. more
• Fixed a crash when migrating entities across types in some cases. more
• Fixed several crashes when writing to disk fails. more
• Fixed that searching descriptions of some items didn't work correctly. more
• Fixed that fast-replacing gates would remove wall control behaviors. more
• Fixed desync related to manually fast replacing both ends of underground belt in a way, that they don't connect in the end.
• Fixed a crash when trying to edit the whitelist on a server while autosave happens. more
• Fixed counting tiles when part of search area hits non existing chunks. more
• Fixed that gate technology had no description. more
• Fixed loaders would leave a gap on belt when items started moving. more
• Fixed nuke did not vaporize things in the epicenter of the blast and would leave corpses and remnants behind.
• Fixed a crash when using items with inventories that contain construction robots. more
• Fixed a crash when making a new game from a scenario with the map editor in a vehicle. more
• Fixed not being able to leave large cars with certain shape. more
• Fixed that using large values in the map editor "tick custom" field didn't work correctly. more
• Fixed that radar coverage preview wasn't visible when the mouse was above invisible parts of the GUI. more
• Fixed Terrain water checkbox in map generation settings didn't have the tooltip info icon. more
• Fixed that the mining drill GUI couldn't be moved off screen. more
• Fixed science pack requirement objective in supply challenge. more
• Fixed that tooltips of slots in the statistics GUIs didn't account for force bonuses. more
• Fixed that upgrading underground belts marked for upgrade didn't properly upgrade the (potentially) connected belts on the other side. more
• Fixed LuaEntityPrototype::module_inventory_size would return nil when entity has 65535 slots for modules. more

Scripting

• Added a machine-readable JSON format of the runtime documentation, which can be used by developer tools to provide code completion and related functionality.
• Added vertical_alignment parameter for LuaRendering::draw_text.

[ 2021-06-18 12:00:35 CET ] [ Original post ]

Scripting

• Added LuaEntityPrototype::air_resistance read.

Bugfixes

• Fixed black border in spidertron technology icon. more
• Fixed that having non standard UI scale would render screen white. more
• Fixed that train could get stuck in destination_full state with available goals when a train stop was built next to ghost rail. more
• Fixed that LuaPlayer::disable_alert() didn't work for custom alerts. more
• Fixed that piercing damage didn't work correctly with turrets. more
• Fixed that LuaSurface::clone_brush() didn't clone entities correctly. more
• Fixed trees with not-flammable flag would still catch on fire. more
• Fixed blueprints and copy-paste tools didn't capture planned direction changes of entities. more
• Fixed that changing train stop limit would not set last player. more
• Fixed desync when beacons lose power. more
• Fixed spidertron item icon would look different after changing the spidertron color back to its default value. more
• Fixed that Tips and tricks trigger related to setting up a logistic chest request was also triggered when setting up the personal request.
• Fixed that achivements could block the finished game window.
• Fixed crash when loading font wingding.ttf. more

[ 2021-05-27 12:02:21 CET ] [ Original post ]

Graphics

• Reworked all technology icons, and provided higher resolutions used by high GUI scale.
• Changed item icons for armors, to match the progression and tech icons better.

Changes

• Armor stages on the player character show as 1st with Light armor, and as 2nd with Modular armor.

Bugfixes

• Roboport normal resolution graphics have been updated to be a downscale from the high resolution graphics. more
• Fixed cut-tool showing distinct selection color when holding shift. more
• Fixed armor rich text tags not using the correct icon. more
• Fixed pumpjack showing item drop indication arrows. more
• Fixed being unable to confirm the migrated content window if there was a game GUI open behind it. more
• Fixed a bad Lua event when invalidating the owning players controller during the gui closed event. more
• Fixed scaling of icons on buttons with more than 200% UI scale.
• Fixed issue where ghosts overlapping with non-ghost entity in cloned area is not cloned. (fixes https://forums.factorio.com/97861)
• Fixed using upgrade planner without explicit filters on entities marked for upgrade would not upgrade the existing upgrade orders.
• Fixed a crash with mods and chunk generation in some cases. more
• Fixed the wrong technology level shown on the icon in the currently selected technology.
• Fixed the missing notification (i) icon on the recipe group button, when there are more groups, so the tabs are shown as buttons instead.
• Fixed a crash when trying to undo actions done on a surface that was deleted in the meantime. more
• Fixed that train would sometimes NO_PATH during repath while in intersection where the path passes through a block that is already occupied by that train. more
• Fixed a crash when the link_id of a linked container is changed while a non-admin has the GUI open. more

Modding

• Added "add" and "remove" modes to the Infinity pipe and Heat interface.

Scripting

• Removed the "tile-build" SoundPath type. It has been replaced with "tile-build-small", "tile-build-medium", "tile-build-large", allowing mods to specify which size they want to refer to.
• Added LuaEntityPrototype::related_underground_belt read.
• Added "add" and "remove" modes to `InfinityPipeFilter` and `HeatSetting.`

[ 2021-05-07 08:06:55 CET ] [ Original post ]

Bugfixes

• Fixed various issues related to how chat tags are open. more
• Fixed that replays would break after winning the game. more
• Fixed that listbox would loose focus when clicking on other widgets that can't be focused anyway.
• Fixed GUI crash when furnaces would select recipes that have more products than it's output inventory size. more
• Fixed that fluids could be purged from the whole fluid system in certain cases. more
• Fixed a crash when loading save files in some cases. more
• Fixed locale related to deconstruction planner tile selection mode. more
• Fixed advanced rail signal tutorial losing items held in the cursor. more
• Fixed Alt+F4 would close the game on Windows even when other modifier keys were pressed. more
• Fixed that NAT-punching didn't work correctly. more
• Fixed that some infinite crafting recipes didn't work as intermediates. more
• Fixed color blending with a fully transparent color would produce slightly darker original color. more
• Fixed that clicking gps tags in chat would also trigger chart drag causing chart to be not centered on gps tag. more
• Fixed market gui would show wrong numbers when an offer has the same item multiple times. more
• Fixed crash when an entity marked for an upgrade is selected for another upgrade in multiplayer in some cases. more
• Fixed turret range could sometimes render long line to the top left corner of game window.

Modding

• Added defines.prototypes which contains all prototype type names (eg: defines.prototypes.entity = { container, furnace, assembling-machine, ... })

[ 2021-04-16 11:29:58 CET ] [ Original post ]

Minor Features

• Blueprints and copy paste of entities with upgrade order are created based on the upgrade order instead of the current entity. more
• Enabled upgrading entities marked for upgrade, in which case, the upgrade target is used as the source entity for the upgrade planner filters.
• The announcement of player death now contains GPS tag with the location.

Balancing

• Increased the tank braking power from 400kw to 800kw. Before this change, the tank acceleration (600kw) was actually even greater than the braking force.

Bugfixes

• Fixed incorrect color lookup table interpolation for ambient light around noon.
• Fixed that built electric pole from map view was also opened with the same click with alternative key binding. more
• Fixed that laser and fluid turret bonus, wasn't shown properly in the toooltip. This bonus is not used in vanilla which uses ammo category bonus. more
• Fixed that part of the flamethrower turret and flamethrower ammo turret description, which describes the properties of the flame bound to it stargets didn't show the bonus damage from upgrades. more
• Fixed that mod install could cause removal of blueprint entities if it didn't remove the entity, but just made it not acceptable to be used in blueprint. more
• Fixed that the confirm load game dialog with 2 green arrow buttons had tooltips with (E) to confirm, while the E to confirm doesn't work here as it would be ambiguous. more
• Fixed crash related to using smart ghost belt building with a mod that specifies belt without related underground belt. more
• Fixed that renaming Spidertron didn't trigger on_entity_renamed. more
• Fixed that disabling side menu guis through script would sometimes leave an empty frame. more
• Fixed that crafting machines wouldn't wake up when the speed effect was changed in some situations. more
• Fixed that focus-search didn't in some GUIs work while in the map editor. more
• Fixed that chat icon selector didn't remember the last opened tab when used outside the game.
• Fixed that pressing Escape with the chat icon selector opened in a dialog outside the game closed the whole dialog instead of closing just the selector window.
• Fixed that pressing Control + F to search in the chat icon selector that is opened on top of a non-game window that already had search activated the bottom window search.
• Fixed that enabled train stops would cause schedule records for trains on different surfaces to be rendered as available. more
• Fixed rare crash when using Map editor -> Convert save. more
• Fixed electric pole connection consistency issue related to fast replace of modded entities. more
• Fixed that building by moving ignored the position where the player built the last entity. more
• Fixed a crash that could happen when viewing the tooltip for certain types of ammo. more
• Fixed that ammo tooltips sometimes wouldn't show damage info. more

Modding

• Added mod dependency modifier "~", which marks the mod as required, but doesn't affect mod loading order, so these kind of dependencies can be circular.
• Prototype/EntityWithHealth::healing_per_tick is now also used by trees, so their automatic healing is no longer hardcoded. more
• Loaders are now able to take or insert more than 1 item per transport line per tick. more

Gui

• Tweaked search in the install mods GUI, so the search order prioritizes the results more naturally.
• Unified the search button in the mod settings GUI.
• Improved some descriptions in Map Generator GUI. more

[ 2021-03-26 15:37:21 CET ] [ Original post ]

Bugfixes

• Fixed that all entity GUIs in the map editor entity-editor and spectator controller were invisible.
• Fixed Train overview GUI not updating the list remark. more
• Fixed typos in Construction robot tip. more
• Fixed a crash when quitting while using the linked-container entity type with power armor in it.
• Fixed that sounds could sometimes be heard when they shouldn't. more
• Fixed regenerating tile variations during save migration would not break up old large tiles and would only reset their variations to 0.
• Fixed "probability" property of size variants in the tile definition was ignored when "weights" property was left out.
• Fixed searching mod settings tab would leave tabs disabled. more
• Fixed a crash of transport line migration in some cases of mod removal. more
• Fixed that train stop gui could indicate more trains than there are when trains are removed or merged while gui is opened. more
• Fixed a conflict between setting the players cursor through script and holding blueprint library blueprints. more
• Fixed that building entity with multiple items to place would take unrelated items from inventory. more

Modding

• Added CustomInputPrototype::include_selected_prototype when true the event will include selected_prototype = {base_type=, derived_type=, name=} when applicable.

Scripting

• Added LuaCustomInputPrototype::enabled_while_spectating, enabled_while_in_cutscene, include_selected_prototype, and item_to_spawn read.

[ 2021-03-03 10:47:05 CET ] [ Original post ]

Changes

• Added shortcut info tooltips to all of the relevant confirm buttons and close buttons.
• Lowered priority of surface changing shortcut in editor to not be in the way if Control + is used for something. more
• Changed personal logistic requests for ammo so they don't get delivered to the spidertron you're driving. more

Optimizations

• Improved performance when building blueprints in multiplayer. more

Bugfixes

• Fixed Artillery wagon and turret showing wrong tooltip title in deconstruction planner. more
• Fixed control setting buttons wouldn't have a tooltip when they started without a set value. more
• Possible fix for multiplayer server crashing when a client tries to connect. more
• Fixed a crash in multiplayer when upgrading or deconstructing. more
• Removed and tweaked some hidden locale to hopefully make 100% possible. more
• Added explicit values to the circuit network range specification in the tips and tricks. more
• Fixed that the copy and paste tips and tricks simulation wasn't working properly. more
• Fixed that LuaFlowStatistics::get_flow_count didn't work correctly. more
• Fixed that instant blueprint building in the map editor didn't work with undo. more
• Fixed missing status for wall controlling gate by circuit network. more
• Fixed a crash when saving when using LuaItemStack::create_grid() on stacks with a count > 1. more
• Fixed that enter to confirm a logistic request count didn't work. more
• Fixed pole dragging corner case. more
• Fixed padding in the sync mods with save window when scroll is activated.
• Fixed invalid "Can't reach" message when using ghost cursor to build rails in the latency state.
• Fixed wrong status of rail signal next to rail with wrong direction.
• Fixed that manual rotation of entity with rotation upgrade order didn't clear that order. more
• Fixed in calculation of required modules when combining real and requested modules during blueprint creation. more
• Fixed that blueprint containing only entities placeable off grid was built off grid even with snap to grid specified. more
• Fixed crash caused by scrolling blueprint book in a blueprint shelf that is not yet synchronised. more
• Fixed that tips & tricks simulation sounds were continuing to play when switched to a tutorial. more
• Fixed that player could get stuck by entities created in the tutorials. more
• Fixed some unnecessary error sounds in a special cases when building power poles. more
• Fixed that exiting high speed moving train could result in a player being stuck. more
• Fixed mod dependency tooltips in some cases. more
• Fixed that the upper 1/3 part of the color picker button in the train stop gui didn't work. more
• Fixed walls would not be buildable on valid positions in some cases. more
• Fixed crash related to modded underground pipe ghosts with multiple connections with different lengths. more
• Fixed that it was sometimes possible for an entity to attack an entity on a different surface. more
• Fixed inaccurate range indicator in spidertron. more
• Fixed that some sounds that were audible when viewing a certain part of the map in map view wouldn't stop when closing the map view. more
• Changed defines.flow_precision_index.one_second to five_seconds since that's what it actually is.
• Fixed crash related to loading that trigger migration to remove invalid upgrades.
• Fixed that confirming the low value in logistic request didn't update the value. more

Scripting

• Added move_stuck_players bool parameter (false by default) to the create_entity method.

[ 2021-02-19 08:06:55 CET ] [ Original post ]

Changes

• Added hotkey (default O) to toggle the train overview GUI.

Bugfixes

• Fixed that gates would open for spidertron. more
• Fixed tank weapon cooldown rendering. more
• Fixed that changing the force of a player or spidertron would lose logistic requests. more
• Fixed that deleting the last scenario didn't correctly clear name, description and preview in the new game gui. more
• Fixed that it wasn't possible to manually merge trains in chests. more
• Fixed a crash when rendering rich text tooltips in some cases. more
• Fixed the Trains/Train stop GUI showing trains on other surfaces. more
• Fixed player dying in a scenario inside simulation widget would end currently running scenario. more
• Fixed that create_entities_from_blueprint_string didn't insert train fuel. more
• Fixed that building blueprints in the game next to uncharted areas didn't work as expected. more
• Fixed biters and groups in Wave defense overloading the pathfinder. more
• Building gets interrupted when moving between map and game view. more
• Fixed building error message spam when building transport belts over obstacle. more
• Fixed that undoing deconstruction of building with modules created extra module request. more
• Fixed inconsistency related to building out of reach and moving. more
• Fixed that the selected map generator preset was not correctly saved when generating a map for multiplayer or map editor. more
• Fixed that the map generator GUI would only save it's state when pressing Next/Play. more
• Fixed that dropping single items into machines using modules didn't clear the module requests. more
• Fixed that the stations list wasn't sorted using natural sort order. more
• Fixed the blueprint import with odd odd grid offsets. more
• Fixed that the game didn't show name of the item in the request slot tooltip when it is disabled for being already set. more
• Fixed that the undo button tooltip didn't update when clicked. more
• Fixed bad tooltip indentation when instruction can't fit one line. more
• Fixed overbuilding underground pipe ghosts with real pipes underground pipes. more
• Fixed inconsistency in direction selection when being a client in a multiplayer game. more
• Fixed that overbuilding pole out of reach didn't consider the pole to be part of the drag buliding logic. more
• Fixed that the "Continue" button wouldn't remember whether the last game was single-player or multi-player when non-blocking saving was enabled. more
• Fixed rare electric network migration error related to loading save without all the related mods. more
• Fixed crash related to using belt traversing in latency state. more
• Fixed crash triggered by desync while entities are marked for upgrade in latency state.
• Fixed non precise belt traversing behviour in latency state.
• Fixed a desync related to upgrading entities in the latency state.
• Fixed upgrading unpair underground belt by smart ghost building.

Scripting

• Added on_research_reversed.

[ 2021-02-08 12:07:49 CET ] [ Original post ]

Hello, the 1.1 release is the final release of the vanilla game. It will be maintained, so bugfixes, simple modding interface additions, or minor tweaks can happen, but that's about it. So what's next? We have a new blog post on our website detailing our future plans, You can read it on our website.

[ 2021-02-05 09:28:41 CET ] [ Original post ]

Hello, we have a stable version! Check out the full details on our latest blog post: Friday Facts #364 - 1.1 stable
Your game will/should auto-update to 1.1.19 if you are not opted-in to any betas. The changelog with all the changes from 1.0.0 will show when you first load the new update. If you want to go back to the 1.0.0 you can do so in the betas menu. Its been 2 months since the 1.1.0 release, so most mods should have been updated. Please check the in-game mod updater.

[ 2021-01-29 10:00:38 CET ] [ Original post ]

Hello, your votes have helped to nominate use for the 'Sit back and relax' Steam award, thank you all so much! Now the voting for the Winner of the category is open, so be sure to make your voice heard and vote!

[ 2020-12-26 13:00:10 CET ] [ Original post ]

Hello, Last week we have started the experimental cycle of 1.1 update releases. We have fixed the most game breaking and save corrupting issues, but the update is not quite stable yet. This means you have to opt into it using Steam's beta feature. But beware: blueprint library and save files are not backwards compatible, so once blueprint library gets migrated to 1.1 or you save a map in 1.1 you won't be able to load them in stable 1.0. Furthermore not all mods have been updated to 1.1 yet and modders might not keep up with changes in future patches, so expect things to break from time to time if you play a heavily modded game. If you don't want to deal with a less stable game or your mods breaking, consider staying on the stable version 1.0 for the time being. And please, if you find any bugs, report them on the bug forum.

Major Features

• Added logistic requests to spidertron.
• Train stop allows to set limit of incoming trains.

Features

• The continue button now respects the last type of game played (single player, MP host, MP client).
• Added support to use blueprints, deconstruction planners, upgrade planners, and modded selection tools from the map view.
• Hovering the alert notification will show arrows on the edge of the pointing to alert locations.
• Rich text icon selector.
• Newly unlocked recipes are highlighted until hovered.
• Spidertron remotes now allow to add queue commands and a command to follow any entity.
• Added vertical/horizontal blueprint flipping.
• Transport belt drag building is locked into a line, can be turned off by an interface setting.
• Ghosts can be fast replaced and rotated.
• Ghost build can be used to fast replace non-ghost entities, which results in an upgrade order with (optionally) a direction change order.

Minor Features

• When editing blueprint: Added a way to specify relative grid position for blueprint that is snapping to absolute grid. Blueprint preview rendering box is updated based on selected grid size and position.
• Inventory transfer works on empty equipment grid slot the same as on empty inventory slot (moves all).
• Equipment can be placed by moving.
• Cursor replenishes when placing into the equipment grid the same way as when building in world.
• Spidertron item shows its color.
• Added a way to reset spidertron remote.
• Spider tries to move legs away when they are blocking robots construction.
• Power poles/underground belts built by dragging logic works also with ghost building.
• Power pole ghosts show connections.
• Power pole connections are saved in the blueprint. They still auto connect to other poles outside the blueprint.
• Entities marked for deconstruction show the target upgrade.
• Added tags, worker robots, rail signal states and recipes toggles into the settings to what show on the map.
• Added support to use the add-stop and add-temporary-stop controls for the train you're driving in the map view.
• Added hotkey (F10) to switch between viewed player in replay.
• Added support to reset mod settings in the "failed to load mods" startup GUI.
• Expanded undo to work with fast replace and upgrade planner.
• Added SteelSeries GameSense support. more

Graphics

• Added unique technology icon for Advanced material processing 2 (Electric furnace).
• Changed postprocessing effect in zoomed-to-world view.
• Added detailed night lighting of entities.

Optimisations

• Multithreaded belt update logic.
• Overall small entity update time reduction + statistics of how much update time is taken by individual entities.

Balancing

• Productivity module 1 decreases speed of the machine by 5% instead of 15%.
• Productivity module 2 decreases speed of the machine by 10% instead of 15%.

Changes

• the Close GUI key-binding (default value is "E") was renamed to Confirm Gui. It works the same as before for many cases (just closing the GUI), but in a lot of other cases, it works as confirm, which generally means the same as clicking the "green button".
• Renamed clean-cursor to clear-cursor on all the relevant places (locale, key-binding name)
• Equipment placing now uses the build key-binding instead of the cursor transfer. The default same key-binding is the same.
• Changed maximum temperature of all fluids apart water and steam to be the same as the default.
• Poles built by dragging are now actually build on the maximum connection distance from the last built pole instead of the previous logic that was working weird in a lot of corner cases.
• Underground belt build by dragging now accept the existing piece you start building on as part of the dragging logic.
• Removed 'mineable wreckage' entity. more
• Removed the (+/-) buttons for logistic requests, instead they expand dynamically when something is put in the last line.
• Wave defense can now only be won by launching a rocket.
• Invalid names of icons in preview icons of blueprint tools now load as unknowns instead of canceling the import string process for that item. more
• Fluids in train circuit logic treat summed < 1 fluid values as 1 instead of 0.
• Clicking non-empty quickbar slot with something in cursor sets the quickbar slot to the cursor value rather than selecting the quickbar value.
• Invalid rail signals output no values into circuit network.
• Added a confirmation message when loading saves with removed mods or changed mod settings.
• The cut tool now properly includes trains. It showed trains in the selection preview, but ignored them.
• Added alternate control locales for keyboard and mouse scroll control binds. more
• Disabled loading of saves before 0.18.0 version (You can use 1.0 to load older saves and re-save them).
• Adjusted the artillery turret collision box so it is possible to squeak through.
• Removed the 'Rocket silos stats' GUI.
• Arithmetic combinator 'Each' signal can now be used in either left or right parameter.

Gui

• Added unique icons for technology effects.
• Added list of affected entities to the technology effect tooltips.
• Menu background now features various factory simulations instead of a static picture.
• When entering vehicle, the vehicle window is shown next to the character gun window, instead of replacing it.
• Moved the character/vehicle gun window to the left of the quickbar.
• Removed the "Character" tab from the character window.
• Changed the flat character screen option to be defaulted to true.
• Added held stack item slot for inserter window.
• Improved the tips and tricks window: it contains index, search and allows interactive text tags to be used.
• Added search to loading/saving, settings, shortcuts selection, multiplayer host settings windows and rename stop.
• Moved the ammo/used-up/health indicator of items down, so it is not obstructed by the number.
• Added underline for hyperlinks.
• Personal request button have custom text + red diode when it is out of network or when the personal requests are turned off.
• Logistic/Trash request buttons show only one number when the trash and request count is the same.
• Train elapsed time condition has confirmation button and only updates the time when confirmed.
• Fixed styles for: browse games GUI, host game settings, opened character and select upgrade slot.
• Tabbing into a textfield selects the text.
• Removed tiles stay in the list of components in the blueprint setup GUI with 0, the same way as entities, so they can be easily enabled.
• Added minimum/maximum temperature and heat capacity info to the fluid tooltip.
• Added usage instruction to capsules/fish.
• Fixed fish tooltip so it shows consumption/healing instead of shooting/damage.

Sounds

• Added blueprint building sound.
• Added undo sound.
• Added sound for rail planner activation.
• Added sound for copy/paste.
• Added sound for opening items and armor.
• Added sound for selection start and selection finish. Related to blueprint tools.
• Added sound for pipe to ground as per the pipe.
• Added sound effects and a specific music track to the main menu.
• Assembling Machine 2 and 3 made less noisy
• Robot repair reworked to sound more high tech
• Removed dead space at the end of some sounds which may have stopped sounds playing
• Ghost rail building now has the ghost building sound
• Lowered volume on game won and lost sounds
• Assembling Machine 2 and 3 made less noisy.
• Robot repair reworked to sound more high tech.
• Removed dead space at the end of some sounds which may have stopped sounds playing.
• Ghost rail building now has the ghost building sound.
• Lowered volume on game won and lost sounds.

Bugfixes

• The list of bugfixes and modding changes is too long, if you are interested, you can see full changelog on our forum. more

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

[ 2020-12-03 16:32:59 CET ] [ Original post ]

Hello, We have just published a new Friday facts post on out website, You can read all about it here: https://factorio.com/blog/post/fff-363 Let us know what you think at the usual places!

[ 2020-11-13 11:01:29 CET ] [ Original post ]

Hello, we have a new FFF blog post, discussing upcoming changes to Spiders, Ghosts, the main menu, and more. Unfortunately due to limitations in the Steam blog formatting, the blog would look terrible on Steam, we have lots of nice .mp4 gifs which we just can't show properly on Steam. Therefore we will just be linking to the blog posts instead of rewriting them here. Please read the full blog article on our website: https://factorio.com/blog/post/fff-362

[ 2020-10-30 08:51:42 CET ] [ Original post ]

Hello, we finished with the regular Friday Facts series, and yet, there is still so much we want to talk about. I want to clarify, that we are not going to release FFF every week, but there are a few of them coming in the near future.

1.1 - The real 1.0

The point of 1.1 isn't to add some new content, the main motivation is to finalise all the existing features so that they work together in a proper way. This may sound a little bit abstract and boring, but it will be explained more clearly in the upcoming FFFs. Believe me, the sentence "I didn't know I needed this until now" will come to your mind more than once. The work on the 1.1 update started basically right after the 1.0 release, so there is already lots to show. Right now we aren't going to make any promises as to when it is coming, but we will keep you updated on our progress with these blog posts, and give some notice before it is deployed. Though I'm quite certain that we are more than half-way through. To keep you happy until it is here, lets go through some of the changes.

Train stop limit

This is a tiny story about Boskid's train related side project for a feature that was requested quite often (1, 2).

The problem

So imagine the situation: You're sitting in your factory and you need more iron... classic. So you build a nice railway to bring ore from dedicated mining outposts back to your iron smelter. You build 2 ore outposts, and you set up 2 trains, 1 for each. The two trains have a similar schedule; one goes from Iron smelting 1 to Iron ore 1, and the other goes to Iron ore 2. This works fine. However there are some problems when you want to expand your production. You want to just copy-paste Iron smelting 1, and have half the ore go to Iron smelting 2. Now you need to start manually reassigning trains, trying to balance the throughput of the mines, and what else. If an iron mine runs dry, then you need to rebalance the whole system, reassign all the trains from that station, and have some omniscient overview of all the different routes your trains are running. With more mines and more smelting and more trains, this management becomes an incalculable problem, and frankly it is not fun (opinion).

The imperfect solution

There is a nice solution, which works (almost). That is to name all the ore stations the same, and all the smelting stations the same. When choosing a destination, the train can go to any of the train stops with that name, which means:

• When you build a new ore outpost, you just name it 'Iron mine', and a train will come and pick up from it.
• When you build a new iron smelting, just name it 'Iron smelter', and a train will come deliver some ore.
• When you build a new train, just copy-paste the simple schedule, and it will start working effectively.

However there is a small issue with the system, that completely breaks the idea. The trains are not clever. They will path to an arbitrarily chosen train stop with the correct name, based on destination distance and a few other factors. This means that it can easily happen that all the trains end up only servicing 1 iron ore pickup, while there are other outposts full of ore with no trains coming to pick it up. You can somewhat relieve the issue using the circuit network to enable and disable the train stops, but it is only a half-measure. For instance you can still end up with 10 trains rushing to a single small iron ore pickup, which can cause the trains to queue on the mainline and jam everything.

The limit

It is pretty simple, as good solutions typically are. You can set a 'Trains limit' in the train stop GUI, and the train stop keeps track of how many trains are in the station or on their way to it, which we call a reservation. When a train is choosing it's next destination, it will check the limit of all the stops with that name, and if a train stop has too many reservations already, it will skip over it. If all the potential train stops are full, the train will just wait.
This pretty much perfectly solves the problem with naming all the train stops the same, and also solves a few other potential annoyances. For instance, previously your Iron smelter stacker would need to be big enough to fit all the iron ore trains at once, because you couldn't be sure that they wouldn't all return at the same time. Now you can set the train limit of the Iron smelting train stop to the maximum capacity of the station, which means you can build a smaller stacker, and be certain that it will never become over-crowded. The train limit is also controllable with circuit network, so there are even more possibilities. One idea is keeping the train limit set to 0 until there is a full load of ore available at the station. You can also read the current number of reservations, which will have its own interesting uses. There is an edge case we had to solve while working on the feature, what happens if the limit is lowered while a train is already on the way? Our first idea was to force all the trains that are on the way, to repath and find a new destination. This works in many cases, but if there is no train stop it could path to, it would end up stopping and waiting in the middle of the tracks, causing untold economic damage. So we decided that even if the limit is changed, any trains with a reservation will still go there. This means it isn't strictly a 'hard' limit, but we think it is a good thing, as setting the limit to 0 provides an alternative way to control train behaviour compared to when the station is disabled. Basically the train will only consider the limit when first deciding which stop to path to, after that it doesn't care if the limit changes.
We also had to deal with the 'No Path' warnings. If all the train stops were full to their limit, the train would show 'No Path', which isn't very intuitive for the players. So when the train can't find a path due to the train limit it will show a special warning: 'Destination full'.

The impact

To an outside observer, this really may just seem like a tiny little thing, but for us it is one of the most exciting features of 1.1. I think it is also quite telling that something like this has been missing for a long time, given the popularity of the Logistic Train Network mod. While the train stop limit isn't quite as powerful as the mod (understatement), it is going to open up many possibilities and add a lot of interesting gameplay oppourtunities. I don't know if I am alone in saying, but I like it when the rules of a system are very simple, and the complexity emerges from the interaction of these very simple systems. I think the train limit is a perfect example of a simple rule, that will lead to really interesting and complex behavior. I can imagine just riding around on a Iron train with a simple "Pickup Iron -> Dropoff Iron" schedule, and it driving me around the whole factory as the chaotic interaction of train stop limits and other trains means each time it needs to travel somewhere else. I can imagine also a lot of fun design considerations will be needed when building such a rail network, where the traffic is less predictable than a 'Static route' system.

Tips and tricks

The tips and tricks have been a feature of the game for a very long time. They began as a way to explain things to the players that were not explained anywhere else. The iconic example is the 'Alt-mode' tip. Playing without Alt-mode is painful, and even more painful to watch, so we had to tell the player somehow.

The early days

When I say early days, I mean the early days, before even the indiegogo campaign. The first implementation of the tips was straightforward, but a bit rough.
The tips and tricks GUI in version 0.6.4. The initial design:

• They would popup when you start the game.
• You can click forward through them (no going backwards).
• You can close the GUI, there was no way to re-open it other than loading a save game again.
• The images were of inconsistent sizes, so the GUI would jump around and resize.
• There was a built-in checkbox to turn them off.

It got the job done, but it needed some development as with the rest of the game.

The first refresh

Over time, the tips and tricks fell into a dark corner. It was always low-priority, and wasn't clearly a 'Graphics' or 'Programmer' task to improve them, it was something in-between. So that is where I came in, and took the task of making some improvements.
The tips and tricks GUI in version 0.16.51. First improvements:

• You can click forward and backward through them.
• You can close and open them with a hotkey.
• The images were retaken at a consistent resolution and zoom.
• You can open them in multiplayer.

At this point we shifted focus to the other 'tutorial channels' as we were hoping that the new mini-tutorials and NPE would mean we don't need as many tips. We think it is better if things like item usages are explained in the item tooltip, rather than in another GUI elsewhere. Apart from some GUI style updates, the tips and tricks were not changed significantly for the next few major versions.

1.0.0

On the approach to 1.0, I took a last quick look at the tips and tricks. The tips are one of the first GUIs the player sees when they start Freeplay, so I wanted to give them a last lick of paint before the full release.
The tips and tricks GUI in version 1.0.0 The improvements this time were the nice last finishing touches to bring the Tips and tricks to their final form.

• Increased image size and updated all images to high-res.
• Added frames and subpanels to match the visual design of the new GUI.
• New button styles.
• Generic close button in the top right.

So then that's that right? I finally rest, and watch the sun rise on a grateful universe...

The Inspiration for change

Even before 1.0 was released, I was inspired by the Mini-wiki found in Krastorio 2, and the Informatron mod.

The main spark, is the index of topics. It solves many problems:

• You can see the title of all the tips right away.
• You don't need to click through all the tips.
• It naturally allows categorization of the tips.
• The player has some idea of the tip content before clicking on it.
• The small item icons are visually appealing.

However with the deadline of 1.0 approaching and not wanting to expand the scope any further, I just let the idea brew in my mind... until now.

The new tips and tricks

A picture is worth 1,000 words, and in this case, it is very true. So lets start at with that:
Lets go through and explain some of the initial changes:

• There is now an index on the side.
• Now that there is an index, we can remove the 'Forward' and 'Back' buttons.
• There is a search button, we can search using the tip titles.
• The tips are categorized and indented accordingly.
• There is a 'Mark as read' button, we will get to that later...

Quite a few changes to the GUI layout, and it works really well. But we can go further. An issue remains, an issue that is small, but in the long run and with compound interest, it becomes a big source of pain. The problem is that the Tips are still using images, which means they become outdated as we update things. We have retaken all the screenshots many times now over the years. So what can we do about it?

The Simulation

In this case, a GIF is worth 1,000 images, so lets start with that: https://cdn.factorio.com/assets/img/blog/fff-361-tips-110-gif.mp4 What you're seeing is a GIF (technically an .mp4) on a webpage, but we are not putting GIFs in the game. What the GIF shows, is the Tips and Tricks GUI live rendering a real simulation of the entities inside the GUI. This marvel of technology is a divine gift from the very top (kovarex). The simulation widget solves quite a lot of the initial problems with using screenshots/images, but we can go even further. https://cdn.factorio.com/assets/img/blog/fff-361-tips-110-drag-building.mp4 We can use the simulation not just to show a factory environment. Using the Lua scripting, we can create entire scripted scenes and demonstrations. This is much more effective in many cases. For instance seeing the building preview, the mouse movement, and hearing the 'real sounds', makes the tip much more meaningful.

Unifying with mini-tutorials

We are left with another problem, we still have the mini-tutorial GUI. So it is a weird and awkward situation that some things are explained in the Tips GUI, and other things via the mini-tutorials. The mini-tutorial GUI is quite a challenge in itself, and it has a lot of similar problems to the old Tips and Tricks GUI. The mini-tutorial 'images' are just 'related' technology icons, with the 'related items' underneath. The text gives a short description of what you might expect from the tutorial.
It would be pretty nice if the mini-tutorials could have the same sort of features as the tips and tricks, an index, nice big images inticing the players to click the 'Play tutorial' button... etc. So what if, we just somehow put the mini-tutorials in the tips and tricks GUI? It makes a lot of sense, and unifies the communication channel. You know now that if you need help with a topic in the game, there is one place you should look for some guidance, the Tips GUI. The mini-tutorials had some nice features or their own, they would only show if the player had met some requirements, and would be suggested to the player if they performed certain actions. For instance the Train tutorials would only show after you have researched the railway technology. If we unify the two concepts, we can use the unlock and suggestion features for the Tips and tricks. So we combine the functionality of the two systems. Mini-tutorials are still the same, but they are presented inside of a Tip, and we hook in the suggestion and dependency system to the tips. We added a 'Mark as read' button, and Tips will show once the dependencies are read. https://cdn.factorio.com/assets/img/blog/fff-361-hiding-tips.mp4 We see this new unlocking and recommendation system as one of the more important improvements. It means the tips and tricks GUI starts with only the nescessary tips, and as you progress in the game, relevant tips are unlocked and shown to you. This is very similar to the way the game starts with only a few recipes, and the more complex aspects are unlocked over time.

The Tips are moddable!

Once last minor issue with the old tips and tricks, is that they were 'hardcoded' in a sense. They were loaded from a very specific JSON file in the core data directory. That means that it was not possible for mods to add or change any of the tips. It is only natural then with this update and modernization of the tips, that we open up the system to modders. Internally the Tips work like any other prototype, so it is super easy for a mod to add their own entries.

The scope of tips

When adding the new tips, it was tempting to make tips for all of the things. However after some consideration, we decided to not go too far this way. We don't want the tips and tricks to become a 'Factoripedia' or 'In-game wiki'. In general, the items and entities and general mechanics should explain themselves in more direct ways, such as the entity tooltips. What we want, is for the tips and tricks to explain mechanics and topics that are more complex, or hard to explain somewhere else. With that in mind, we decided on a few loose categories:

• Things that are not related to some specific item, e.g alt info, ghost building.
• When visual presentation helps a lot, e.g splitters, belt lanes, long handed inserters.
• When it is something related to a combination of more items, e.g gates over rails, copy-paste stuff.
• The "tricks" e.g the lab to lab movement, stack transfers, drag building.

Importantly, we should really only explain things that players actually don't get. I have never heard a complaint that someone doesn't understand how solar panels or accumulators work, so putting these into the tips and tricks would be just bloat, even if it technically fits the criteria.

Conclusion

We are quite happy with the result, the tips and tricks GUI was always one of those paradoxical systems that was both extremely useful and terribly ineffective at the same time. We really hope all the effort we have channeled into it will help. Speaking of help, we need your help: What kind of tips would you have found useful when playing the game? Searching TIL on Reddit can be a source of inspiration, but it is still hard to compare the importance of individual independent Reddit posts, and also a lot of them are outdated. So, if you want to give us feedback, the FFF discussion is the best place (yes we do read Reddit).

[ 2020-10-09 06:43:15 CET ] [ Original post ]

Features

• Added Spidertron and Spidertron remote.
• Added Freeplay crash site.

Graphics

• Added polluted water visual effect.
• Added biter base decoratives.
• New visual effects for the atomic bomb.

Sounds

• Significantly reduced the volume of robots deconstructing and entity destroyed alert.
• Reverted mining drill sound to the 0.17 version with high pitched part removed.
• Reverted inserter, furnace and assembling machine sounds to the 0.17 version.
• Changed the checkbox click sound (based on dropdown open sound).
• Changed the "green button sound" to have a normal button sound.

Modding

• Added EnemySpawnerPrototype and TurretPrototype properties: spawn_decoration and spawn_decoration_on_expansion.
• EntityPrototype water_reflection can now be defined inside graphics_set.
• Added ExplosionPrototype properties: Explosion prototype: scale_animation_speed, fade_in_duration, fade_out_duration, scale_in_duration, scale_out_duration, scale_end, scale_increment_per_tick, scale_initial, scale_initial_deviation, scale, and scale_deviation.
• ParticleSourcePrototype particle is now optional, added smoke property.
• Added ProjectilePrototype properties: speed_modifier and turning_speed_increases_exponentially_with_projectile_speed.
• Added LightDefinitionItem::source_orientation_offset.
• Added DecorativePrototype::decal_overdraw_priority.
• Added AreaTriggerItem::show_in_tooltip.
• Added 'set-tile' and 'camera-effect' trigger effects.
• Added CreateDecorativesTriggerEffectItem properties: apply_projection and spread_evenly.
• Added CreateExplosionTriggerEffectItem properties: max_movement_distance, inherit_movement_distance_from_projectile and cycle_while_moving.
• Added DamageTriggerEffectItem properties: vaporize, lower_distance_threshold, upper_distance_threshold, lower_damage_modifier and upper_damage_modifier.
• Added PlaySoundTriggerEffectItem properties: min_distance, max_distance, volume_modifier, audible_distance_modifier and play_on_target_position.
• Added ProjectileAttackParameters::projectile_orientation_offset.
• Added build_blueprint_small, build_blueprint_medium and build_blueprint_large to utility sounds.
• Renamed build_big utility sound to build_large.

Scripting

• Added LuaEntity::autopilot_destination, vehicle_automatic_targeting_parameters and time_to_next_effect read/write.
• Added LuaItemStack::connected_entity read/write.
• Added LuaEntity::is_entity_with_force, is_entity_with_owner and is_entity_with_health read.
• Added LuaEntity::spawn_decorations().
• Added on_cutscene_cancelled, on_player_configured_spider_remote and on_player_used_spider_remote events.
• Added optional spawn_decorations parameter to LuaGameScript::create_entity.

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

[ 2020-08-14 09:12:45 CET ] [ Original post ]

Read this post on our website. Hello, the atmosphere in the last week was kind of special. We experienced the feeling of the final release being on the horizon many times. And we were shown that it isn't the case time and time again. So it feels very special when it is actually becoming reality. We were trying to be especially careful with any last minute changes to make sure that we don't introduce major bugs into our precious 1.0 release. The image of all the players having the game crash on some simple stupid bug is horrifying.

Thank you

People thanked us on many occasions for the hard work we do. It helped lift our mood in many of the desperate moments, when bugs and problems were piling up and we didn't see the end of the tunnel. We don't say it often enough, but the support from your side has been incredibly helpful throughout the years.

• We thank all who helped us to save the game before it could even start by supporting the IndieGoGo campaign back in 2013.
• We are grateful for all of the 18,855 bug reports. They were invaluable feedback that helped us reach our level of game stability.
• We value almost all of the feedback to our FFF and game releases. A lot of game improvements came out of it.
• We appreciate the work and creativity that went into creating the 5,603 mods. It certainly extends the potential for a lot of people, and of the ideas became great inspiration for us.
• All the online videos, articles and streams were immensely helpful to spread the word.
• We thank all who helped with the Crowdin translations, allowing the game to be played in a lot of different languages without us having to manage it directly.
• We are grateful that people spontaneously helped to manage the Wiki and created some great tools, like calculators, cheat sheets or blueprint databases.
• We value the effort put into organising events, like fMMO, Clustorio etc.
• We appreciate that our community is very civilised, and people who contribute are generally nice to each other, and keeping the criticism on the constructive side.
• And, lastly, we would like to thank all of you who bought the game, and allowed all of this to happen.

The 1.0.0

It took us 8.5 years. It has been an incredible ride and we have arrived at the destination! Factorio is leaving early access. This opens the game up to all the players who just don't play early access games, the same with reviewers who only cover finished games, which is very understandable. For this special occasion, we created a launch trailer. It tries to capture the story of the development in 45 seconds. [previewyoutube=BqaAjgpsoW8;full][/previewyoutube] Since the main Trailer is kind of timeless, we updated it to the 1.0 state of the game. [previewyoutube=J8SBp4SyvLc;full][/previewyoutube] When we released pretty much all the content in 0.18, there was nothing left for 1.0 other than the formality of "it is complete".The crash site, nuke, alien decoratives and polluted water are awesome, but not too impactful... As a result, we really wanted to add something to make the release special.

• It is a vehicle that can be driven, or remotely controlled.
• It can traverse obstacles and small bodies of water.
• It has a built-in radar, and you can place blueprints in its vicinity.
• It has an equipment grid, so it can build with construction robots and use combat equipment.
• It has four rapid-firing rocket launchers that can shoot automatically.
• It can be researched very late in the game (all science packs except Space).
• Multiple of them can be deployed at the same time, but each requires its own linked controller.

This all means it can be used as a tank upgrade, a less automated version of artillery, or a builder/repairer. We look forward to seeing what other uses you can invent. We haven't added it earlier as we saw it just as a gimmick without much contribution to the gameplay mechanics. This changed rather recently, when we had the idea of the remote control combined with the equipment grid. So we decided to extend our already crazy todo list, and add it as a last minute bonus.

The plan for 1.1

We were doing the best we could, to fix all the relevant bugs and issues for the 1.0 release, but we just couldn't do everything. So we had to prioritise just the more critical stuff. We would still like to address all of the remaining issues as there are currently around 150 bugs on the forums and around 80 internal tasks to be solved. The plan is to eventually go through all of them, and decide on how to resolve each one. A good example is, that we have a "continue" button, but it just ignores multiplayer. You press continue automatically just to find out, that you are building alone for half an hour. It is my (kovarex) personal story actually. This means, that 1.1 is going to just focus on filling the most obvious gaps in our existing feature set, not on adding some new major content.

Full circle

When we started with the Friday facts, it was at a time when we worked a lot, but if there wasn't any release for a while, people were starting to ask whether the game is still being worked on. So this was our first motivation. Eventually we learned many additional advantages of the blog, other than it being just a dead mans switch.

• It established the communication channel between us and the community.
• It started to be an internal every-week milestone to get something into a presentable form.
• In some cases it even motivated us to add a cool last minute feature to make the topic feel more complete. (This is how the undo and copy-paste feature was created for example)
• It became a great archive of the evolution of the game throughout the years. Opening old posts is like reading our own diary.

It became an every Friday habit for us and some of our players too, but we believe now is the right time to stop. There will hardly be a better moment to do so. It should be very understandable that we need a break, and we also need the freedom to think about the long term without the obligation to cut it into small chunks for FFF. Since you can't expect weekly posts from now on, we wanted a way for you to be notified once we have something special to say. Feel free to give us your email address so we can let you know. For now please enjoy the game, and well be back!

[ 2020-08-14 09:02:54 CET ] [ Original post ]

Graphics

• Electric mining drill graphics now fill bounding box more accurately.

Bugfixes

• Fixed hovering over unit that was going toward an entity would crash if the entity was destroyed. more
• Fixed crashes/desyncs related to various different operations on a shelf of a player that just joined, and his blueprint shelf meta-data hasn't be synchronized yet.
• Fixed crashes/desyncs related to swapping item with a blueprint/book in the blueprint library that is not yet fully transferred into the game. more
• Fixed electric mining drill circuit connection graphics.
• Fixed crash when picking up something using the quickbar while setting up a blueprint from the inventory.
• Fixed that blueprint book GUI was scrolling to the top whenever something was done. more

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

[ 2020-08-10 19:11:00 CET ] [ Original post ]

Read this post on our website

0.18 mods will be loadable in 1.0 (Klonan)

With 1.0 approaching, we want to ensure that the day of the launch goes as smoothly as possible, and shows the game in the best light. Something that would really work against that would be if the update broke a bunch of mods and disgruntled all of our most dedicated players. So we are making efforts to ensure that mods that work in 0.18, will work without any update needed in 1.0. Theoretically this isn't so difficult, as the 0.18 release structure has meant that mods have maintained compatibility with all the latest changes, and in essence 1.0 will just be a small update of 0.18. However it does take a bit of special handling:

• 1.0 will allow mods marked for 0.18 to load.
• The mod portal will show 0.18 mods when browsing in 1.0.

Avoiding breaking mods also means we need to be very careful with changing anything, even something as simple as renaming a sprite can break dozens of mods. I think we never realised how easy it is to break mods before we started this new release structure. Big apologies and big thanks to all the modders who stuck with us through these breakages. We hope that what this effort means, is that on the day of 1.0, players new and old alike can login to the mod portal and have a very large catalog of mods they can enjoy right away, and that the modders can relax and enjoy the game instead of worrying about updating all their work. However, we cannot say 100% that all mods will work, it is possible one of the features in 1.0 (like the new nuke or alien decoratives) will break some mods.

Mining drill redesign revisit (Ernestas, V453000)

In FFF-350 we presented the new electric mining drill graphics, and released them in 0.18.31 shortly after. However, we hadn't realized soon enough that it had some issues... The most obvious one is the tile overlapping. All of our graphics try to find a balance between overlapping the tile a lot to be aesthetically nicer, and not overlapping the tile at all to be technically correct and readable.
With the electric mining drill we got bolder than with other entities, and overlapped the tile more. This problem got massively strengthened by the fact that the mining drill outputs directly to a belt, so it doesn't even have the typical gap where inserters usually are. The secondary but related issue would be that the entity is no longer as recognizable as before. We attribute that mostly to the new height that the drill has, as it gets a bit overcomplicated, and not as clear what the shape of the entity is.
Originally the main reason to add the higher structure was because we wanted to create a much more complicated miner movement (both horizontally and vertically), and to fit pipe connections easily. However the miner movement was too complicated so we didn't do it, and the pipe connections are kind of an edge case. We could have addressed just the issue of overlapping the tile above the mining drill, but that would already cost some amount of time and we felt like we could go one step further.
It was tight in time, which is why we're presenting it now, but we decided to move the whole structure down, so the mining mechanism would move on ground-based rails. After a lot of effort put into moving things, redesigning parts of the drill, and reworking the pipe connections, Ernestas has arrived to the new version.
The electric mining drill is one of few entities that the player sees from the very first stages of the game, all the way to the end. Long story short, it's a really important entity so we wanted to get it right. We were happy with the concept of the mining drill redesign for the "aggressive ground penetration" against the "gentle harvesting" of the original, but we traded away a few of the good parts about the old mining drill graphics, like clarity and identifiability. This revisit tries to fix that, and we believe now it's good. The new mining drill graphics have been released with 0.18.44 (today). As it could break some mods, we wanted to push the new graphics as soon as possible to give mod authors a chance to fix their mods for 1.0.

Technology icons update (Dominik, V453000)

As many graphics have changed over the years, more and more related technology icons became outdated. We didn't have enough time to do a complete rework of the technology icons as we did with the item icons, but we could at least update the clearly outdated ones.

Crash site: The beginning (Ernestas, V453000)

Even though a simple one, Factorio does have a story - An engineer crashes on a planet and through building a complex factory, becomes capable of launching rockets back into space (...or builds the sickest combinator contraption instead). This story is quite well represented - building a crazy factory in the process, ending with an epic rocket launch - except the beginning is not. The player character just appears in the middle of the map with nothing showing where they came from. When we were working on the crash site for the NPE, we created the special assembling machines, a lab, a power generator and chest capsules.
The NPE has been removed, but Albert didn't design just those special ship chunks. The central piece of the composition was always meant to be a large spacecraft - but per usual, we didn't have enough time to finish it, and since it wasn't really gameplay breaking, we released 0.17 without it. Although the NPE was removed and its custom crash site entities remained only for modding and custom scenario use, we would like to finish the main crashed ship. The plan always has been that if we're investing a lot of time into designing the crash site entities, then we better use them for Freeplay as well, as that's the main game mode. Recently Ernestas picked up Albert's 3D model and finished texturing it, bringing it to life, and to the game.
Klonan has also added a short skippable cutscene at the start of Freeplay, where the crash site is revealed. The crashed segments are randomly placed, and there's a little bit of resources to be found in each of the ship segments (the 8 combined iron plates that until now just appeared in your inventory). All of the crash site parts can be mined, but it gives no reward, takes a long time, and the crash site can't be re-built. The crash site is spawned at the start of the game, so it won't show on pre-1.0 maps. The crash site will be released in 1.0, on 14th August 2020 - at 11am Prague time.

[ 2020-08-07 09:30:49 CET ] [ Original post ]

Graphics

• Updated the technology icons.
• Updated the "Make a copy of blueprint" icon.

Gui

• Added simple credits gui.
• Updated the style of progressbar dialogs.
• Updated the style of map editor.

Changes

• Changed the default debug settings to only show grid and nothing else.

Bugfixes

• Fixed that Blueprint books in the library didn't propagate its modded icon backups properly into the game.
• Fixed that Blueprint books in item form did loose its modded icon backed up state when saved between versions 0.18.37 and 0.18.42
• Fixed that swapping ghost cursor with an item didn't clear the quickbar selection immediately.
• Fixed PvP script error when starting a new round with duplicate starting areas. more
• Fixed PvP scenario not restoring character bonuses after respawn. more
• Fixed that most of the windows were not squashing as they should when they couldn't fit the screen.
• Fixed squashing of save name label in the load/save map dialog and load/save map progress windows.
• Fixed that biters could attack entities beyond their attack range. more
• Fixed crash when opening train gui through non-locomotive while in map view in latency state. more
• Fixed that the deconstruction planner was ignoring specified tile filters when removing tile ghosts.
• Fixed that the deconstruction planner with normal tile setting was ignoring tiles when the selection contained only tile ghosts + tiles.
• Fixed that the deconstruction planner with tile ghost filter selected didn't select (with whitelist) or ignore (with blacklist) the tile ghosts.
• Fixed that the deconstruction planner with tiles and rocks only and blacklist always ignored tiles.
• Fixed lights of entities just outside of right or bottom border of screen were drawn twice sometimes.
• Fixed drag-placing ghost item in zoomed-to-world view would drag the view instead. more
• Fixed that barreling recipes were generated for "fluid-unknown".

Scripting

• Empty LuaPrototype collision masks will now return an empty table, rather than nil.
• LuaEntity::circuit_connected_entities and LuaEntity::circuit_connection_definitions return data for entity ghosts. more

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

[ 2020-08-06 17:33:13 CET ] [ Original post ]

Bugfixes

• Fixed a crash when holding a blueprint book.
• Fixed that blueprint book in an item form didn't have mod-persistent icons.
• Don't drag map when in zoomed in map mode and building blueprints.
• Don't place map tags when building blueprints.
• Fixed crash in rendering due to game state being modified by buildability checks for drawing blueprint placement visualization on chunks in fog-of-war when zoomed-to-world.

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

[ 2020-08-03 17:52:15 CET ] [ Original post ]

Changes

• The tiles and entities filtering logic in the deconstruction planner is now independent.
• Selecting first entity filter switches tile mode to never when it has the default normal mode and no filters.

Bugfixes

• Probably fixed problem with blueprint preview data not being empty when blueprint is empty.
• Improved layering of rocket in rocket silo, so it occludes inserter hands. more
• Fixed inventory consistency check failing when loading some saves. more
• Fixed inventory error messages in god and editor controller. more
• Fixed smoke might not be spawned from generator entity if its animation was too short. more
• Fixed underground belts and loaders would not draw half-belt with layers correctly. more
• Fixed localised strings in text objects created through script rendering API, would be untranslated after saving and loading. more
• Fixed that right-clicking blueprint book with empty blueprint being selected destroyed the whole book.
• Fixed that cut and copy created empty blueprint when nothing was selected with alternative selection type.
• Fixed that the mouse "cross" selection cursor was not present when selection tools from the blueprint library were held in the cursor.
• Fixed that the latency state of deconstructing using tool from library didn't take the tool settings into consideration.
• Fixed the alert tooltips showing all surface names in the tooltip when multiple surfaces existed.

Modding

• Added LuaEntityPrototype::rocket_entity_prototype read.

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

[ 2020-08-03 05:59:11 CET ] [ Original post ]

Bugfixes

• Fixed clearing ghost from cursor would not clear quickbar selection. more
• Fixed blueprint book not shrinking when the last item was destroyed.
• Fixed crash when Lua received event of player selecting area to deconstruct.
• Fixed upgrading book by item would not work while being in editor. more
• Fixed biters not grouping before attacking an artillery outpost. more
• Fixed crash related to saving blueprint which has all the entities/tiles as question marks.
• Fixed desync when loading blueprint shelf with modded entities. more
• Fixed that swapping blueprint cursor into a non transferred blueprint didn't trigger the transfer.
• Fixed that cycling blueprint book in the shared blueprint library could also cycle the index for other players holding the same book.
• Fixed that cycling book wouldn't mark blueprint storage to be resaved, so the indexes would be lost if no other changes were done.
• Fixed a desync when returning to a multiplayer game while the book active index was changed in a different game. more
• Fixed that the action to put item into a blueprint library was not based on the latency hiding state of held item, which could result into the action doing nothing when the item held was not in the server state yet.
• Fixed that quickbar links into items contained in blueprint books in the player inventory didn't work.
• Fixed that it was possible to setup empty blueprint of other player if the original player was still having the quickbar link to it.
• Fixed that quickbar links did work only for the main inventory of player, so it didn't work for currently equipped armor for example.
• Fixed that LuaInventory.insert() didn't work properly for blueprint books. more
• Fixed crash when reassigning blueprint with non-even snap grid size to contain rails. more
• Fixed crash when holding a blueprint from the blueprint library while being dead. more
• Fixed that the info for selecting entities to be upgraded was mentioning entities that were marked for deconstruction, even when these are ignored by the upgrade planner.
• Fixed that ordering deconstruction didn't cancel upgrade order. more

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

[ 2020-08-01 06:43:47 CET ] [ Original post ]

Read this post on our website.

Launch party cancelled (Jitka)

The COVID pandemic around the globe is making it really hard to plan any event these days, and we were pretty optimistic just a few weeks back. However the situation here is now changing for the worse it seems. The number of positively tested cases of COVID here in Czech has been increasing in relatively high numbers every day for the past two weeks, and the restrictions are again taking place. In Prague, face masks are required to be worn again where more than 100 people gather indoors, no events over 500 people are permitted as of last week, etc. The current uncertainty together with the fact that at least half of the invited guests will not be able to attend the party (including some members of our own team), have led us into making a tough decision: we have decided to cancel the Factorio 1.0 release party we were intending to throw on 4th September 2020. For those of you who already purchased a ticket(s) - the full ticket price will be refunded. We hope there will be another opportunity to meet you all in the foreseeable future, but for now, please accept our apologies for any inconveniences caused. This wasn't an easy decision for us to make, but we believe it is the right one.

Youtuber/Twitch/Press suggestion (Klonan)

Over the last weeks and months, we have been preparing for the marketing of our 1.0 launch on the 14th of August (just 2 weeks to go now). Part of our plan is going to be sending out some free press keys to Youtubers and streamers and other content creators, in the hopes they will give the game a try, and help spread the word. To prepare, Jitka and I have been doing our research and compiling a list of suitable individuals to send a key to. It is not a shocking fact to find out that Youtube is massive, and I think even if we spent a year everyday going through it, we still wouldn't find 10% of channels that we would like to send a key to. So we decided to start this simple form, that you can use to suggest your favourite Youtubers to us, and help us make sure they don't miss out on the review keys when we are sending them. If you are interested and would like to help us out, you can fill in the form here.

Polluted water (V453000, posila)

As we're done with redesigning graphics for 1.0, we could focus on other graphical improvements. Because we are so close to release, it's a good idea to focus on things that are unlikely to break the game and don't cost too much time, while having as large an impact as possible. One of the biggest themes of the game is pollution. Considering that, it's one of the least visible elements in the game - you can only see it in the map view, and on dying trees. It would be lovely if we could make grass or decoratives die too, but that's something way too technically complicated for now. But one thing that could and does show pollution is water! For a very long time weve had green water tiles in the game and we've used them in campaign missions.

Two water tile types, one or the other. As it's 'just' tiles, it wasn't really feasible to use both of them - because transitions between them would be too abrupt. Not to mention water tiles would have to generate that way, and dynamically change as the map gets more polluted, leading into more technical problems.

Manually placed tiles in map editor. However, since water has been updated to use a shader rather recently (FFF-323), we could make it look polluted dynamically. After some typical posila dark magic of interpolating and converting the pollution values on chunks, we could blend between a primary and secondary tint of water tiles. This way it is also directly tied to the red cloud you can see on the map so it's consistent.
Polluted water slowly spreading. The green water tiles still exist if scenarios want to use them, they just always show as polluted. The pollution effect won't show if the 'Show animated water' setting is off, or if pollution is disabled in the map settings. Mods can also adjust or disable the effect it by changing the secondary water tints in the tile prototypes.

Biter decoratives (Ernestas, V453000, posila)

When the whole family of biters got their redesign, one of the plans for later was to give them their own biome in the world. We had some temporary decal and decoration sprites prepared for a long time now, but somebody needed to add them to map generator. In the end, we didn't want to spend an awful lot of time on tweaking generator properties to place them just right, and also we wanted them to be created under new bases as biters expand, therefore we decided to add special logic to generate them as spawners and turrets are created. If your mod already has its own solution for creep, you can disable base game one by clearing spawn_decoration prototype property on spawners and worms. Our initial naive implementation was placing the decals just randomly, and Ernestas turned the number of the decals created up to 11 to make them cover the ground the way he liked. That in turn made me (posila) unhappy, because in the middle of biter bases there were too many decals overlapping each other, that even your GTX 1080 would take notice of the increased workload, and a laptop with an integrated GPU would fall to its knees. That made me realize that artists probably wished our tile renderer had a texture splatting feature. But I wasn't really ready to change the specification for tile renderer yet again and rework it to add more new features into it this close to the release. We also really didn't want to add an option to disable the rendering of decals as that together with already existing option to disable decoratives would make terrain look completely plain. So instead we changed the decal placement logic use Poisson-disc sampling, which produces points that are randomly placed but somewhat evenly spaced out from each other, and this fixed the excessive overlapping. Once we knew it could actually be generated (including bases created by biter expansions), Ernestas could finalize the graphics. Mucus, mold, eggs, worms, all kinds of bodily fluids and slimes. You can see how this immediately looks much more like a 'nest'.
We decided not to bother with a migration as we need to focus also on other things (like fixing bugs), so existing biter bases on older maps loaded in 1.0 won't have these decoratives. We imagine a lot of people will want to start a fresh map anyway, and it's a nice identifier of a 1.0 map. Both the polluted water and the biter decoratives will be released on 14th August in 1.0.

[ 2020-07-31 11:06:33 CET ] [ Original post ]

Graphics

• Improved the blueprint grid visualisation, so it shows a rectangle instead of just the corners.
• Added blueprint grid visualisation when building in the world.

Bugfixes

• Fixed cleaning ghost cursor. more
• Fixed crash when clicking a blueprint book upgrade slot with an upgrade planner in hand.
• Fixed navigating in a blueprint book item when opened directly from a quickbar. more
• Fixed that it was possible to put book into itself using hand->swap and clean cursor.
• Fixed that the hand functionality didn't work properly for gun and ammo and gave misleading error messages in some cases.
• Fixed "slice" property of animation definition was interpreted as dicing parameter, possibly causing large memory allocations. more
• Fixed that grabbing gun/ammo, swapping it with some other item in the inventory and pressing Q, gave a message of inventory full, instead of the item in cursor not being returnable to the hand location
• Fixed that Internal inventory stack transfer messages weren't specific enough, or not present at all.

Modding

• Renamed sprite and animation properties for sprite dicing from "slice", "slice_x" and "slice_y" to "dice", "dice_x" and "dice_y", because "slice" collided with property of rotated animation definition used for defining spritesheet sliced into multiple files. Sprite dicing is a technique of chopping large sprite into smaller ones to improve packing in sprite atlas.

Scripting

• Fixed a typo (per vs pre) in the on_pre_permission_group_deleted event name.

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

[ 2020-07-30 07:16:26 CET ] [ Original post ]

Major Features

• New blueprint library GUI. Its user interface had been aligned with the way inventory works in as many ways as possible. more

Features

• Added blueprint building from the map view.
• Blueprints can have snapping dimensions specified. When they are built by dragging, they are only built in the grid relative to where the build started.
• Blueprints can have absolute map snapping specified, so the blueprints are always aligned to the global grid.
• Blueprint books can be inserted into blueprint books, cycling through the books works in a hierarchical way.
• Upgrade planners and deconstruction planners can be inserted into blueprint books and the blueprint library.
• Blueprint books, upgrade planners and deconstruction planners can now have custom icons specified.
• All blueprints tools have an editable description.
• Added Blueprint reassign tool. It allows to set new contents of a blueprint by world selection.
• All blueprint tools have a copy function.
• All the blueprint tools are usable directly from the blueprint library.
• Quickbar links to blueprint tools are persistent when moving them between library shelves and inventories.
• Most of the blueprint tools manipulation in the blueprint library is part of a multiplayer latency hiding.
• Icons on the blueprint tools and filters in the upgrade planners/deconstruction planners are preserving the original values so whenever the mods would be re-added, the original values can be restored, unless the player clears the related icons manually.
• Any blueprint contents that are not available due to mod removal are also kept in the blueprint persistently, so blueprints can be copied and transferred in multiplayer without losing its original data.
• Added downgrading feature to upgrade planner. It works on blueprints, books and also when applying in the world.
• Clicking an upgrade planner button in the blueprint or a book now provides a list of all available upgrade planners to be applied.
• Upgrade planners now also update the relevant icons of blueprints and books.

Minor Features

• Grabbing an item from a blueprint book has the same hand item functionality as when holding an item from inventory, so it goes back to the original position when clean cursor is triggered.

Gui

• All the blueprint tools now show all possible actions it can perform in the tooltip.
• Control settings search now also searches by the currently assigned key-binding.

Optimizations

• Decreased the header size of blueprint-storage and of individual blueprints with backed up modded entities, as only the id mapping relevant to the blueprints (and whole storage) is now saved.

Bugfixes

• Fixed that exporting blueprint didn't include the unconfirmed blueprint changes into the exported string.
• Fixed blueprint preview icons rendering scale when blueprint was held in cursor.
• Fixed that blueprint was not detecting modded data to be lost when loading unless one of the top level entities or tiles were to be lost. This means, that a blueprint with vanilla constant combinator (for example) with a modded signal will no longer silently lose the modded signals on resaving the blueprint storage when the mod is not currently active.
• Fixed that biters when faced with a rock might get stuck in an infinite pathfinding loop. more
• Fixed that clicking a technology in the research queue, holding the mouse down and moving it over the cancel button would make the cancel button flicker. more
• Fixed slider tooltip would show old value. more
• Fixed terrain particles would be spawned when walking over belts. more
• Fixed player movement on belts in latency state was not exactly matched with the real game state logic. more
• Fixed that the set-request GUI didn't respect the show-all-items setting. more
• Fixed that burner assembling machines could cause inserters to get stuck holding extra fuel in some cases. more
• Fixed noise.terrace function did not assert that constant parameters are constant.
• Fixed that item durability tooltips used the wrong locale key in some places. more
• Fixed that upgrading inserters in blueprints wouldn't preserve modded pickup/drop locations. more
• Fixed that exporting empty blueprint books didn't work correctly. more
• Fixed that the mods GUI didn't have any mod selection by default. more
• Fixed that positions of entities in blueprint string were not properly fixed to be aligned to grid according to our rules and centered.
• Fixed a crash when mods destroy the character entity during the on_gui_closed event. more
• Fixed a crash when canceling loading some modded saves. more
• Fixed that artillery turrets didn't fully use the shooting speed research. more
• Reduced flicker of mining drill indicator lights when zoomed out. more
• Fixed lua documentation for LuaGuiElement::index read. more
• Fixed that biters would try to attack over large distances individually instead of in groups. more
• Map tag edit GUI can now be confirmed with Enter key even when the textbox is not focused. more
• Fixed a pathfinder crash related to entities and tiles using collision layers 11 to 15. more
• Fixed the changelog GUI indentation.

Modding

• Implemented compileIntoCurrentProcedure for the "if-else-chain" noise expression type. This allows non-constant values to be used as conditions.
• Added "modulo", "ceil" and "floor" noise expression types.
• Added "bitwise-and", "bitwise-or", "bitwise-xor" and "bitwise-not" noise expression types.
• Added "sin", "atan2" and "cos" noise expression types.
• Added "less-than", "less-or-equal" and "equals" noise expression types.
• Changed turret base_picture animation to actually play the animation.
• Added several properties to ExplosionPrototype to control light fading through applying a multiplier to the light's size and intensity. "light_intensity_factor_initial" (default 0), "light_intensity_factor_final" (default 0), "light_intensity_peak_start_progress" (default 0), "light_intensity_peak_end_progress" (default 0.9), "light_size_factor_initial" (default 0.05), "light_size_factor_final" (default 0.1), "light_size_peak_start_progress" (default 0.1), "light_size_peak_end_progress" (default 0.5)

Scripting

• Added permission events: on_permission_group_edited, on_pre_permission_string_imported, on_permission_string_imported, on_per_permission_group_deleted, on_permission_group_deleted, and on_permission_group_added.
• Simplified the rules of entity positions aligned to grid in the blueprint. Now they have the same rules as entities in the world.

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

[ 2020-07-29 15:49:46 CET ] [ Original post ]

Read this post on our website.

Blueprint library finishing touches (kovarex)

At the time of writing the Friday Facts last week, not all of the planned changes were finished, here is the finalisation, so here we go.

Persistent library contents

The problem is old. You play a modded game and have your blueprints in the library. Then, you decide to put the mods aside for a reason (to join a MP game, or just try a different modset). At that moment, if we didn't handle it in a special way, all your mod-related content in your blueprint library would be removed. We solved the main part of the problem already quite some time ago. But with the upcoming support of other tools in the blueprint library it had to be extended. Special system was created for these things:

• The preview icons of the blueprint tools
• The filters of the deconstruction planner
• The upgrade specification of the upgrade planner

If the related ID isn't available any more while loading a game. Instead of just plainly removing it, it is marked as unknown and the original textual representation of the ID is stored in a special way. The tool can still be normally used. Clearing the "unknowns" removes the information about the slot for good, but if you don't clear them it stays there.


Once you load the appropriate mods again, the IDs are restored.

Upgrades

The UX of upgrading blueprints/books with the upgrade planner was meant to be provisional, but somehow, it remained in use for quite some time. Currently, the only way to use it is to click the button with an upgrade planner in your cursor, which is sometimes quite annoying, as you don't even have access to your inventory or Blueprint library when you want to click the button, so you have to close the window, find the upgrade planner you want to use, open the window with the upgrade planner already in cursor, and then use it. So this window was created. When you click the upgrade window, the game searches all the upgrade planners available to you (inventory and blueprint library) and lets you select which one to apply, and always offering the default upgrade planner.
As you probably noticed from the picture, I couldn't restrain myself from adding a little feature. Upgrade planners can be now used both ways: as upgrade with left click and downgrade with right click. It obviously works also when upgrading in the world. The problem is, that you can already do 3 different kind of things with the tool, and there are generally quite a lot of people that don't know about basic things you can do, like cancelling a deconstruction orders or force-building a blueprint. Because of that, we added instructions to every tool so the users won't miss it.

Snapping

This is a great example of a feature, that I expected to be done quickly and easily... but you know how it goes. The first problem is related to build and drag. Most of the blueprints don't work that well when you just build and drag them. https://cdn.factorio.com/assets/img/blog/fff-357-dragging-blueprint.mp4 The second problem is that blueprints are often designed to work in a grid, but there is no way to enforce it. Either you have to build slowly and cautiously, or you misclick often. And with the new feature of building in map, the problem was just elevated. This is what the second checkbox is for, it forces the blueprint to be built in a grid aligned to the map center. To ensure, that the user can configure individual blueprints in a way that they would match perfectly, the relative position of the blueprint to the grid can be configured by moving the red flag.
https://cdn.factorio.com/assets/img/blog/fff-357-blueprint-snapping.mp4 Thanks to Boskid, our beloved tester, a big pile of bugs had been already identified and fixed, so there is a chance of the BP library being released next week.

Story of the nuke (Dominik, Posila, Ernestas, V453000)

Since more than a year ago Dominik has been updating and improving all kinds of visual effects in the game - particles, splashes, explosions and so on. During most of the time weve also been getting valid questions - "But what about the nuke?".
It was the plan from the start that the explosion of the atomic bomb would come last. Not because its the lowest priority, quite the opposite - however its also by far the most challenging effect to create, both on the technical and graphical side, so we kept improving how particles/explosions work, and experimenting with graphics for effects - essentially practicing and preparing ground for the nuke. The most major challenge visually is the sheer size of the explosion. Normal explosions already benefited greatly from more flexible and various scorch marks and particles, and improving the explosion sprites themselves, but thats not enough here. The atomic bomb has such a giant explosion radius that we simply cannot (mostly because of VRAM requirements) create an explosion sprite that would cover all of it. https://cdn.factorio.com/assets/img/blog/fff-357-explosion-solo.mp4 Weve tried to make an explosion as large as we could fit in a reasonable spritesheet, and limit its frame count as much as we could as well. Just like we did in the old days when VRAM was much more of a concern. This mushroom cloud does not cover nearly enough though, so for sure some part of the effect needs to be procedural. The VRAM is not the only problem though, the biggest challenge for the visuals is yet again the perspective of square tiles, where visually the game looks like the player is viewing it at 45 angle, but everything is presented as if viewed top down. Both of these things are intentional and graphics get the shorter end of the stick when it comes to compensating for this dichotomy (FFF-133). After discussing many really different approaches we could take, we decided to create a combination of a central spritesheet, with a shockwave of smokes being moved outward from the center. https://cdn.factorio.com/assets/img/blog/fff-357-circular-damage.mp4 We tried to make graphics hide this perspective problem as always, and made the explosion move slower vertically, resulting in a visually correct ellipse. As you can see in the animation above, this exposes the problem of entities dying in the vertical direction before the waves get to them. So we made the damage apply slower in the vertical direction as well. This does mean you can minmax and run away vertically when shooting the atomic bomb under your feet and you will have a better chance of survival, but that shouldnt be too much of an issue Weve also added a secondary damage radius, so its more forgiving if youre just barely getting hit while running away. https://cdn.factorio.com/assets/img/blog/fff-357-random-improved.mp4 For further improvement, weve added a ton of random elements to how the particles move and when they disappear which again makes the edge of the explosion less obvious, but also helps diminish the crescent-like shapes at the end. The explosion is so large that even creating a scorch mark of an appropriate size for it is a problem, so Ernestas created a scorch mark as big as we could afford, and added a whole new tileset to the ground zero, with decoratives to smooth the edges out a bit.
The atomic explosion also destroys everything in a small radius at the center (killed entities dont spawn corpses, decoratives are destroyed and cliffs disappear), which makes the explosion feel a lot more powerful and impactful.The nuclear tiles remain there forever and are visible from the map view as they have their own map colour, though you can place concrete over them to hide the evidence of your actions. https://cdn.factorio.com/assets/img/blog/fff-357-final-nuke.mp4 To complete the effect, weve added a brief overbright of the whole screen based on how far the players screen is from the explosion, and added sound effects which also react to distance from the explosion. You will be able to enjoy becoming death, the destroyers of worlds, in the new fashion on 14th August, in 1.0.

[ 2020-07-24 10:06:10 CET ] [ Original post ]

Read this post on our website.

kovarex - the story of motivation

This wall of text is about my personal struggle with Factorio and life, feel free to skip to the next subject if you wish to see the actual Factorio content. Since two years ago, I started to have these problems, it was harder and harder to force myself to work on the game and I didn't enjoy it that much. So I was looking for a way to have a break. I know exactly when I disappeared from the Factorio development, it was August 26, 2019, the release date of World of Warcraft classic. The planned 3 weeks of playing kind of extended to be more like 3 months. One of the big reasons was, that I already had 60 level priest when I realized that tanks are so hard to come by, so I re-rolled a tank learned how to play it and levelled it to 60. It was a great fun to finish all the dungeon content and acquire the pre-bis (pre raid best in slot). This all just to find out tanks are far from a hot commodity when it comes to raiding, where you need just a few in the 40 people raid. At this point, I thought, that I would come back to work with full power, but I just couldn't. When I tried to work, I had this strong, almost physical feeling of disgust, that was impossible to overcome. It was clear to me at this point, this is the the typical burnout situation. It is far from surprising after that many years of working that hard. The attempts to get to work were mainly motivated by guilt, and I knew well, that it is hardly a good motivation for anything. Trying to overcome it by sheer willpower would just make it worse, so I just stayed distant. The team was still working on its own and making good progress, so I was taking advantage of it and continued to have a break and spent more time with my family and on leisure activities. As the situation was not getting that much better, there were even proposals of selling the company and getting rid of the responsibility for good. For most people, this would sound like a rational choice, but I was far from open to doing that. I generally don't like to do something just because it is the norm. The norm is to try to always keep growing exponentially, getting investors, expanding, getting more people, never stopping, never resting until you are the biggest and most horrible company, or you die trying. This approach dictates, that once you can't expand the enterprise, you need to sell it so others can grow it. And I don't like it. I didn't forget at all why we started working on this game. We wanted to make the game(s) that we couldn't find, and we wanted to have fun doing so. We wanted the game to be primarily fun for us, not for a focus group that has the most financial potential. So, even if we faced the hypothetical decision : Either we sell it to a big publisher, or we shutdown the studio, I choose the latter, because you can't put a price tag on the fact, that we still own the game. In the latter case, we could come back to it any time when we feel like the time is right, instead of having to watch it being milked as micro transaction filled cashgrab by some company. So, this was my lowest point personally I was generally not feeling well, and was lost in searching for purpose. One of the biggest reasons that I didn't feel well was, that I was becoming more and more lazy. When you don't have to overcome daily obstacles and annoyances, you become more and more lazy, until even the most basic things start to be huge pain in the ass, and you don't generally feel well, this is where I was. In the meantime, I was occasionally playing some simple games with my 4.5 year old son (Earn to die and Into space 2). I was trying to find some nice cool games that we could play together, but I didn't find anything, feel free to give me suggestions in the comments. So I figured, that he could actually try to play Factorio. I started a peaceful game for him, showed him how to move around, mine and craft basic stuff, and let him play. He was just running around and having a blast that he can mine trees and explore. Some other day, I joined the game, and built some small factory so basic technologies are unlocked and he could play around with that. Eventually he set himself a project to create a wall around the entire factory. He was focused and he kept at it, and 3 days later he came at me, and showed it to me, and he was so proud. Some time later, he played alone for a while, and than he showed me some very basic mining/smelting setups. It was very weird, but it worked. This is when I realised how great Factorio is for children, you can scale the skillset from very very basic up to almost infinity. He can't read, he didn't know numbers greater than 4, and yet he managed to play, and in a few days, he kind of recognized numbers up to 10 without even realizing. When I showed him how construction robots and personal requests work, he was super enthusiastic and talked about construction robots to everyone he met :). Once he asked me "Father, what is this thing in the list of things I can order?" ... "This is atomic bomb" .. "Oh, I want to order it" .. "No, we don't even have it researched" .. "But, why is it in the list then, it doesn't make sense" ... "Hmm, you are right, it doesn't, I might actually fix that." So I opened Factorio source code after a long time, and made the change, that the filter and logistic request selections didn't contained things yet to be researched (unless you force-unlock it in the settings). I made a change to Factorio, and it felt good, and I started to want more, this is how I got from the lowest point. I wasn't yet prepared for big projects mentally, so I did few other small tweaks, and I started to visit the office occasionally, which gave me more and more energy, I was not working because of guilt, I was working because of joy again. This is when I decided to face the big elephant in the room: the blueprint library. I was scared to approach such a big project in my previous state, but now I felt brave enough. I started working on it and I was able to work in full-power mode again, the work went forward fast. I had to overcome a lot of annoying obstacles on the way, which had positive effect on my overall laziness very fast. As the new BP library started to shape up, I started to feel something almost forgotten, I was proud of what I was doing, yay :)

The story of the Blueprint

The story of blueprint and the blueprint library development is quite long and convoluted, we mentioned it in 12 FFF already and it wasn't always quite right. But I believe, that we are getting to the final stage with the current rework. Small tweaks and improvements can be always done, but the general feeling is like "Yea, this works, finally".

First mention

The first mention of a blueprint (apart the blueprinting mod) was in FFF-16, 6 and half years ago!

First blueprint implementation (0.9)

Blueprints were obviously a great upgrade when you compare it to the state of just not having them. But everything was very plain and primitive from today's perspective. You had to actually craft the blueprint (for one advanced circuit) and the setup window was not the greatest:
Note that the confirm button was the blueprint button. The exact example of us doing GUI in the logical way but not an intuitive way.There was no way to change the blueprint once it was set up, you could only clear it (for the price of one electronic circuit).

First improvement of the blueprint management (0.13)

Blueprints started to be important, so we added some very basic way to edit them and a way to include tiles and modules. (FFF-131)
Also, the blueprint book was introduced (FFF-108, it cost 15 advanced circuits and could hold only blueprints directly.

First plan of blueprint library (0.15)

The fact, that you didn't have a way to backup your blueprints and you would just plainly loose them when you died, or moved to a different game was quite harsh, so we started to work on the blueprint library. Our first mention of it was in the FFF-156.

First implementation (0.15)

The first implementation was pretty rough and first shown in the FFF-161
Note, that the play button was the way to export the blueprint into your game as an item, so you can put it into your inventory and use it.

First redesign

We, mainly Oxyd (FFF-170), quickly realized that this needs to be more intuitive, so the way it was exported was streamlined, you just drag and drop into your inventory. https://cdn.factorio.com/assets/img/blog/fff-170-drag.gif Another way of exporting was done secretly: When you held a blueprint record while closing the library window. It was seemingly useful as you could just grab it from the library and build, but once you were done and pressed Q to clean the cursor, the item was just spilled into your inventory. It was common at these times, that your inventory was slowly getting cluttered with random blueprints and you had to do a cleanup from time to time. The Blueprint editing window was also improved:

0.16 Blueprint preview was updated

It was "only" about connecting the belt/pipe/wall entities, but it added a lot to the understandability (FFF-211).

The endless discussion phase

We knew there were still a lot of problems with the blueprint library and we were desperately trying to figure out how to solve them in various different crazy ways (FFF-249). But a week later, we agreed on a relatively simple solution (FFF-250 and FFF-255): From the player perspective, blueprints are always just items,and blueprint library is just something like a persistent chest. Quickbar, movements, stack transfers, everything works exactly like with items, and the BP library technical magic is done under the hood. After some time (32 weeks actually), we presented a UI mockup for the planned blueprint library FFF-282.This was the big plan, but since 0.17 release was approaching and there were just too many other things to do, we postponed it.

0.17 release - More tools

In this version we added a lot of tools:

• Upgrade planner
• Copy/cut paste (with history)
• Undo

And we also extended the amount of things blueprint can handle -mainly trains (FFF-263):
We just made a few small tweaks for 0,17, to make the usage of blueprints less of a pain, mainly the ability to make a quickbar reference directly to the blueprint library. Using it created a new item that is copy of the BP library record, so you can build from it and pressing Q to clean the cursor just deleted the blueprint instead of cluttering the inventory. But blueprint library still didn't get any real improvement.

Current blueprint library

In 0.18 release, I improved the blueprint setup window so it matches our new GUI style:
But the blueprint library still didn't get any real improvement.

New blueprint library

So, if this buildup led to nothing, it would be pretty lame so as you would expect the blueprint library is now finally getting a real improvement.

1) The looks

It looks nice now and mainly fits the style of the rest of the game:

2) The manipulation

As it was agreed 2 years ago (fuck), the blueprints in the blueprint library are manipulated as items in every way. Twinsen forced me to agree on this way, and I wasn't that convinced at that time, but when I started to implement it, it was instantly clear, that this is way better than any other proposal. You don't have to learn anything new and just manipulate the objects exactly the same way you are used to and it just feels right. There is quite something happening in the background when transferring Blueprints, as they are still very different types of objects in the inventory and in the blueprint library, but the user is now completely shielded from this.

3) The unification

All the related UI was unified to look the same, in current version for example, opening a blueprint book as an item looks very different compared to opening it in the blueprint library, and it even has different features.

4) The identification

Now we get to the new features, first of all, every blueprint tool has editable name, description and icons.For Blueprint book, upgrade planner and deconstruction planner, these icons are optional, but overwrite the dynamic icons shown for them. This might be mainly useful for books that you want to just have the same preview regardless of currently selected blueprint. When the names and descriptions become more important to the user, he can switch to the list view.
Small thing that helps is that the upgrade planner now updates also related icons of the blueprints and books https://cdn.factorio.com/assets/img/blog/fff-356-upgrade-book.mp4

5) The books in books

It is something we wanted for a long time, and it was highly requested, so now, it is possible. The maximum depth is set to 6, mainly to prevent the UI from getting out of hand.
It is just logical, that iterating through the book contents works hierarchically now: https://cdn.factorio.com/assets/img/blog/fff-356-hierarchal-scrolling.mp4

6) The tools in books and library

Since both the upgrade planner and the deconstruction planner are also kind of virtual and configurable, it just makes sense to allow them in books and the blueprint library. The preview of the book is changing when you switch between different types of objects. https://cdn.factorio.com/assets/img/blog/fff-356-tools-in-books.mp4

7) The copy

Since blueprint manipulation is now always moving the blueprint around, never making a copy (apart the export-import workaround), we really needed this feature to make an explicit copy. The nice touch is that the copy is made based on the current unconfirmed edit of the blueprint, so you can make slightly modified versions of it quite fast. https://cdn.factorio.com/assets/img/blog/fff-356-copy.mp4

8) The reassign

My personally most wanted feature. You can change the contents of the blueprints while the name, description, icons, quickbar links and positioning is preserved. https://cdn.factorio.com/assets/img/blog/fff-356-reassign.mp4

Building in map

Rseding had a great timing with his feature of building blueprints directly in the game map. https://cdn.factorio.com/assets/img/blog/fff-356-blueprint-in-map.mp4 These changes are being finalised and tested, so they should be available in the upcoming weeks just in time before 1.0.

[ 2020-07-17 22:10:54 CET ] [ Original post ]

Gui

• New high resolution tips and tricks images.
• Visual improvements to the tips and tricks GUI and the rocket silo stats GUI.

Graphics

• New remnants for assembling machines and land mine.
• New visual effects for slowdown capsule.

Changes

• Changed sorting order of items: Same items but without data are first. Descending order of Health/Ammo/Durability.
• Units are now affected by the 'movement_slow_down_factor' defined in their attack parameters.
• Slowdown capsules slowdown factor increased from 50% to 75%.

Sounds

• Updated sounds for assembling machines 1, 2, and 3.
• New sounds for mining and eating fish.
• New sound for spitter spawner, repairing robots.
• New sound for throwing capsules, grenades, combat robots.
• Various levels adjusted including new default sound settings.

Bugfixes

• Fixed that force.reset() wouldn't clear saved research progress. more
• Fixed disabling, renaming or destroying unreachable train stop would not cause repath of trains in NO_PATH to go to next station.
• Fixed bonuses GUI showing duplicate entries if it was open when a research finished. more
• Fixed auto-launch would send rocket when there were still empty slots for payload. more
• Fixed corruption related to sorting module inventories.
• Fixed logistic robots would keep trying to feed chest which has item stacks over the stack size. more
• Fixed entities with wire rendering disabled in entity prototype would still have wires rendered in screenshots. more
• Fixed upgrading mining drill would disable input fluid box if resource was depleted. more
• Fixed pause game control input was not working when in multiplayer. more
• Fixed that the RCON interface would sometimes send an extra empty reply. more
• Fixed that groups of enemies wouldn't be distracted by a player in a car or tank. more
• Fixed tank icon having accidental border. more

Optimizations

• Improved performance of sorting inventories.
• Improved performance of inventory highlights.

Scripting

• Added on_player_flushed_fluid event.
• Added LuaPlayer::hand_location. more

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

[ 2020-07-15 13:32:08 CET ] [ Original post ]

Read this post on our website. We've been updating, reworking and redesigning many graphics, and the majority of entities have had high resolution for a while now. With 1.0 we're trying to be as "complete" as feasible.

Slowdown effect

As one of the less used items in the game, the slowdown capsule got kind of forgotten. The slowdown capsule has multiple parts - the item icon, the effect, and the animated sticker that shows on slowed enemies. We've already updated the item icon which sets some expectation for the effect and sticker, like what color should it have. The poison capsule has already taken blue, and green or brown would be very similar to rocket or nuclear fuel in the icon, so we chose orange. https://cdn.factorio.com/assets/img/blog/fff-355-slowdown-sticker.mp4 It makes a lot of sense to also use the same graphics with different tints for the acid sticker from spitters/worms. https://cdn.factorio.com/assets/img/blog/fff-355-acid-sticker.mp4 In a way the slowdown capsule is doing the same to them, as they are doing to you, except the acid damage. Take that, nature.

Crude oil resource

Resources got high resolution sprites for 0.15, but we didn't have time for the crude oil spills. The new ones are very similar.

Assembling machine remnants

We've been waiting with remnants for assembling machines as they were planned to get a redesign. It doesn't seem likely we'll be able to finish the assembling machine redesign before 1.0, so we've finally given them their own specific remnants at least.

Land mine remnants

The last missing remnant was the land mine, which didn't have high resolution until the icon update, so here it is.

Conclusion

With version 0.15.0 we released the first batch of high resolution graphics for many entities. In FFF-187 which announced 0.15.0 experimental and presented all of the new graphics, we stated:

"During 0.15 stabilization we will be adding more high resolution graphics, with the aim to do everything. Let's see how that goes, but seeing what we already have, we are confident we can get it done sooner or later."

You as readers of this periodical might have already heard the "stuff takes longer than expected" a few times, so "the sooner or later" is now, 3.5 years from then. There are still more graphical updates coming in the following few weeks, but this is it for the high resolution updates.

[ 2020-07-10 10:31:02 CET ] [ Original post ]

Graphics

• High resolution power switch graphics.

Bugfixes

• Entities of other forces that are mined and brought back by undo are now set to have player force upon the undo application. more
• Fixed a desync when unit group radius settings are changed.
• Fixed that the final health value in the entity damaged event was wrong. more
• Fixed a performance problem with the production stats GUI. more
• Fixed the double slider with discrete values functionality. more
• Fix 'Train stop names' checkbox showing tooltip with no locale entry. more
• Fixed rendering of pipe pictures and covers when fluid box compound covers some fluid boxes without pipe pictures or covers. more

Gui

• Visual improvements to the bonuses GUI.
• Visual improvements to the tutorial list GUI.

Minor Features

• Gps tags are now surface aware.

Scripting

• Added on_player_clicked_gps_tag event.

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

[ 2020-07-06 13:21:16 CET ] [ Original post ]

Read this post on our website.

The launch party (Klonan)

To celebrate the launch of the game later this summer (only 6 more FFFs to go!), we have decided to throw a party! It is going to be at the same venue as our 1 million sale party (FFF-192). It will take place on Friday the 4th of September, 2020, at lut Lzn here in Prague. We are inviting a lot of people to the party, such as other Czech game developers, Youtubers, and of course we will be there. As we want you (the fans) to be able to come, we have some tickets for sale. The reason to sell them, rather than give them away, is so that we don't have 'messers' saying they will come when they don't intend to. You can buy a ticket here. While the COVID-19 pandemic might be 'over' here in Czechia (Czechs hold 'farewell party' for pandemic), the reality is, the situation could change with great speed. It is likely many won't be able to come due to travel restrictions, or we may even need to cancel the event. Please keep this in mind while you are considering whether to come. We hope everything lines up in our favour, and we look forwarding to meeting you.

High resolution power switch (V453000, Dom)

One of the leftover entities that didnt get the love of a high resolution update yet is the power switch. It has waited this long mostly because we werent sure about its design and because it is not a very frequently used entity. However, after all this time we dont have better ideas for the design, so we dont want to change it significantly. And of course we have other higher priority things on our plate now, so reworking an infrequently used entity doesnt sound too pragmatic. Other than that, the 3D source file is a mess, unsurprisingly as its the first thing (FFF-102) I worked on for Factorio. Back then I was trying to create a texture painting system where we could paint RGB masks instead of grayscale ones, to control multiple channels at the same time.
Not only was this not as useful as I had thought (it was more efficient for me to just get used to switching between textures), but unfortunately this also caused something in Blender to go wrong, and the scene crashes frequently. Luckily I was able to combine forces between Blender 2.8 where I could actually paint textures but couldnt render, and 2.79 where I could render but not paint. If youve been even remotely following the development of Blender, your first question is probably why are we not using 2.8 as its been out for quite a while now.
Our workflow is quite specific and the early versions of 2.8 simply didnt support all of the obscure features that we use. On top of it all, we have a lot of tools and scripts that would probably break in 2.8, and eventually it got so late in our development cycle that we couldnt just afford to be insecure about our software, when 2.8 introduces all kinds of new changes. Were very much looking forward to switching to 2.8 after 1.0.
Here we have a high resolution version of the power switch, including a destroyed version from our remnant specialist Dominik.By the way, the power switch was actually one of the first entities we had high resolution sprites for. I had prepared them shortly after finishing the power switch years ago. However the way we create high resolution entities was only really established a while after that, so it wouldnt fit today any more. We plan to release the updated power switch next week.

[ 2020-07-03 10:32:09 CET ] [ Original post ]

Read this post on our website

Locale plan update (Klonan)

Earlier this week I received the English proofreadings from Altagram, and overall I integrated over 500 suggestions into the game. Most were small, such as replacing "can't" with "cannot", things like that. It was the exact sort of external scrutiny we really needed, as it showed some areas where we were quite inconsistent. It feels like things are in a better place now, even if the majority of changes are relatively unnoticeable. However it was very noticeable to our great community translators on Crowdin. When we update the English strings, the translations have to be updated on Crowdin. For the last few days I've been working through the issues raised on Crowdin, and there was a lot of good input on that last 1% of the changes. So this concludes the 'English proofreading' phase. Starting on Monday, Altagram will start proofreading the target languages, and filling in any missing strings where needed. This should take about 3 weeks. Since Altagram has their own translation system for their team, it isn't really feasible to include Crowdin in this part of the work, they will just take the content from Crowdin at the start of the process, and after 3 weeks, push what they have back to Crowdin. So any translation work by volunteers on Crowdin for these 3 weeks would be wasted. So we ask that, if you want to volunteer your time, save it for a little while. Any work done on Crowdin this weekend will be included. We deliberately made this buffer between the English corrections and the Target proofreading so that the players on Crowdin have an opportunity to contribute before Altagram starts. After Altagram has pushed their corrections back to Crowdin, we will start the 'Community review' part of the process. This is when the work that Altagram's team has done is reviewed by players and feedback is given to Altagram via Crowdin issues. This helps us make sure the terms of the translations are consistent with the established community usage, and ensure there are no contextual issues or misunderstandings.

The plan for trailers (V453000)

Rather recently weve started working on trailers, and first of all we needed to decide what exactly we want to do with them.The goal is that we will have the main trailer updated to the latest graphics, as all of it is rendered by a Lua script. It of course wont be absolutely the same, since many things have changed or have been added, but we are going to try to match it as close as possible as we are very happy with this iconic trailer. We are very happy with the other one as well, but we wont update the Gameplay trailer, at least not for now. This has multiple reasons - mainly that its created entirely by manual screen recording which is a lot more work to try to replicate, and the gameplay message of it is still relevant today. Its not helping that if we were to revisit this trailer, wed like to make some changes/additions to the voiceover, which would mean creating a completely new voiceover, as added parts would just not feel perfectly integrated. Long story short, were aiming to prepare a new third trailer dedicated to releasing 1.0 instead. We believe a special 1.0 Launch trailer will have more impact than just refurbishing the existing gameplay trailer, as it is more interesting to provide something fresh, tailored specifically for its use case. Last but not least, the release of 1.0 is a big milestone and we find it appropriate to give it its own trailer.

1.0 Launch trailer preparations (V453000)

Of course Im not going to spoil all the details of what is actually going to be in the new trailer, but there is one specific section I have so many feelings about, its irresistible not to share them. Factorio is much more than just the result product. Its been a journey, and a very unique one. I think the process of how Factorio has been created is so important to the result, that its worth giving it a special place in the new trailer. More specifically, this will be done by a series of clips, ranging from Factorio 0.1, transitioning all the way to 1.0, showing how Factorio evolved over the years. There isnt enough time to go through all of the major versions as the trailer is going to be rather short, so I reduced the selection to versions:

• 0.1 as "the original idea";
• 0.6 as "the prototype" (0.7.0 was released with FFF#1);
• 0.12 as "the early access game" (stable 0.12 was the first version on Steam Early Access);
• 0.18/1.0 as "the version for launch".

It is technically possible to load a savegame from 0.1 in 0.18 if you go through the necessary middle-version steps. So I just started casually playing version 0.1, imagining Id just continue it in 0.6, build a bit there, then jump to 0.12, and so on... Note: none of the images below are final, as the trailer is being worked on.
A random factory being built in 0.1 When I had a small factory built I started to wonder how do I actually bring this to 0.6... As always, its not that simple. While technically working, loading obviously does not handle all of the changes to the game, like map generation, entity sizes, or recipes...
A random factory being built in 0.6 I didnt even bother trying to migrate after realizing that this would mean Id have to show 0.18 with 0.1 map generation, and just tried to build a new factory in 0.6 and then again a new one in 0.12. This seemed like a reasonable approach as each of the versions works quite significantly differently, so the resulting factories should also be different, right?
A random factory being built in 0.12 Not so much. Since the trailer is short and quick, its absolutely critical to minimize confusion as much as possible. This is why after a few days I restarted it all, and started by designing the final clip in 0.18, and going backwards, with the aim to have the factories look very similar. Of course newer save games cant be loaded in older versions of the game, so I just had to take a screenshot of a factory with a grid, and try to replicate it in the older version by hand. Having played each of the versions earlier at least gave me a good overview of the differences between versions and made it easier to realize what should be highlighted in each.
A concept of a factory for the trailer in 0.18 When I create factories for screenshots (like FFF), I almost always use the /editor as things can be done very quickly that way. It wasnt necessarily a surprise that 0.12 did not have the same editor as 0.18 does, but I was completely shocked actually experiencing the differences.
A concept of a factory for the trailer in 0.12 For example, console commands could not be run in the map editor, entities would get removed by X instead of normal clicking, blueprints would not place real entities, the game could not be unpaused in map editor (making placing items on belts almost impossible), and so on. And it wasnt just the map editor, having gotten used to Cut/Copy/Paste, pipette and Shift+R and so on, the game suddenly felt extremely clunky to use and everything took much longer than it normally takes. I placed in map editor what I could, and after that put a lot of items in chests to build more, and spent some time playing the factory, making science and generally making the factory run in order to have things move in the final video.
A concept of a factory for the trailer in 0.6 The process was getting progressively more difficult with 0.6 and 0.1, some things making me actually laugh instead of cry, or both. Im not going to paste our complete changelog from the last 8 years, but Ill just point out a few things that really stood out.

• The old quickbar was so confusing, I could never find things in my inventory, because they were hiding in the quickbar.
• Technologies did not guarantee that if you unlock something, you are able to craft it. No technology tree view without a search function made this even harder to find something.
• Hand-crafting did not automatically craft intermediate ingredients in 0.1, making crafting feel a lot worse.
• In 0.6, trains had to be connected by the "Connect rolling stock" hotkey after being built. I never knew this was the original purpose of that hotkey.
• When taking an entity in your cursor, it automatically rotated to be facing towards you (just like in minecraft) in 0.1... in a 2D game it does not make nearly as much sense though, and I was totally confused what was going on until kovarex explained it to me.
• I definitely forgot to build a vertical train station longer because trains didnt stretch in 0.12 like they do now.
• Building rail signals and train stations is a lot of pain without the visualisation helpers we have now.

A concept of a factory for the trailer in 0.1 You can see the last few screenshots always share some features. This will be even better in their final version, making the video flow much better between these clips. It felt quite interesting to just play the old versions after all this time. In a way it felt like playing a different game or some spinoff. Apart from the immediately obvious differences in graphics, the core idea of mining-smelting-assembling was still there, but with so many differences... Especially in the interaction, its usually small differences, but they really add up. This really made me appreciate what we have come to so much more, and in a way remind me that the details weve spent time on were really worth it. Eventually I got through it all and I can now record clips for the trailer. Youll be able to see them on 14th August.

[ 2020-06-26 12:14:35 CET ] [ Original post ]

Bugfixes

• Fixed desync related to non-deterministic transport belt merging order when multiple merges happen in the same tick. more
• Fixed alignment of number input entries.
• Fixed that undo didn't remove deconstruction task to remove things in the way. more
• Fixed stray tooltip bug in the map generator window. more
• Fixed of saving control inputs related to mouse buttons 4+. more
• Fixed minor clipping issue. more
• Fixed that train fuel request were unreliable. more

Gui

• Windows with item and count to be selected have count/confirm buttons disabled when item is not yet selected.
• Logistic request related item and count windows now have notched sliders for 0 to 10 stacks selection. Different numbers that are not multiplies of stacks can be still written into the textboxes.
• Added an interface option to show both crafting and logistic windows in the character screen.

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

[ 2020-06-26 11:09:49 CET ] [ Original post ]

Changes

• Full English text proofreading and corrections.

Bugfixes

• Fixed Trains gui listbox labels not being readable when hovered. more
• Fixed a crash when using LuaChunkIterator. more
• Fixed a desync related to placing blueprint with assembling machine with not yet researched recipe. more

Gui

• Windows with item and count to be selected are now merged into single window and double click on the item auto-confirms the window with the default count. Windows affected are logistic request, signal selection and (debug tool)infinity count selections.

Modding

• All mining results of resources are forced to be unlocked in the selection lists, even when recipe to create them exists as well. more
• Added ItemPrototypeFlags::always_show, which forces the prototype to be always visible in the selection lists regardless of related recipes.
• Added RecipePrototype::unlock_results bool (true by default). When set to false, the recipe doesn't unlock the item to be shown in selection lists.
• Added RotatedSprite::counterclockwise bool (false by default). Set to true to indicate sprites in the spritesheet are in counterclockwise order.
• Added CharacterPrototype::has_belt_immunity bool (false by default).
• Entities no longer require the order string be set when there's no item-to-place them.
• Added EntityPrototype::remove_decoratives. "true", "false", or "automatic". Defaults to "automatic".
• Added TurretPrototype::attack_target_mask and ignore_target_mask. more
• Changed roboport tooltip to not show robot recharge rate when the roboport has no charging slots. more

Scripting

• Added LuaRecipePrototype::unlock_results read.

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

[ 2020-06-24 12:45:40 CET ] [ Original post ]

Read this post on our website.

New website (Sanqui)

Over the course of the past year, you have seen the team put a lot of effort into polishing the game to get it ready for a full release. There's no doubt this is the most important effort here: we're all here to play the game. At the same time, the website is often the first thing people encounterand in for many, return to every week! Unfortunately, until this point the looks of our websites have been neglected. The current set of websites are a complete mishmash of styles that are not coherent and do not fit with the look of the game.
Which website am I looking at again? We set out to rework the looks of our websites last year to make them harmonize with the final game. Albert and Ale worked together to design the new website and make mockups in a process not too dissimilar to the GUI work in the game. Of course, web technology is a different beast from anything the game uses. My task was to take the mockups for each page and implement them as closely as possible (my own creative liberties notwithstanding).
The process from original page to mockup to the new version My approach to creating websites is conservative, and in a way mirrors the philosophy we use when developing the game. The Factorio website doesn't use a fancy modern JavaScript framework. I'm not a JavaScript hater. There is no harm in using JavaScript to make parts of the website interactive, and of course many web applications wouldn't be possible with it. But for a website like ours, avoiding the use of bloated JavaScript frameworks helps keep everything load and render quickly, and of course the website can be browsed without JavaScript as well. To get the looks right, I set out to create a CSS framework to visually mimic the Factorio GUI style. Where possible, I avoided the use of images. This keeps the page fast and ensures it stays sharp on all resolutions and levels of zoom. For instance, the buttons match their game counterparts closely, but are made only using shadows.
The only exception is the arrow facing to the right, which simply isn't possible to reproduce using CSS (I tried!). However, even then the performance is kept slick because the graphics for it are embedded in the stylesheet. The layout for new pages with sleek grids is enabled thanks to modern CSS technologies like Flexbox and CSS grid (no floats, no tables).
At the same time, the mod portal also received the new design.
I also took the effort to unify login sessions between the main website and the mod portal, so you no longer have to log in twice. This Friday Facts is the last time you're seeing the current (old) style, so enjoy it while it lasts! The new website will go live sometime next week. Once the new design is out, don't forget to click on the rocket!

Website content update (Klonan)

My part in the website update was going through all the pages and updating the content, with a side goal of reducing overall the number of pages we have, either by merging pages or just deleting pages we no longer value. Since 1.0 is so close, I decided to just 'pretend' that 1.0 is already out, and update the content to match it. That means there is no mention of early access, ongoing development, roadmaps, alpha releases, etc. This allowed me to clean up quite a lot of the pages, and make them much neater and more clear. This might cause some confusion until 1.0 is actually released, but that's just 2 months away now, so its not a big concern for me.

Artwork page

While going through the Presskit, I found myself wanting to include some of the 'cool' images that we've made over the years that aren't really screenshots. Things like the 2020 Rocket poster, or the Player and the biter giving a toast the new year. Initially I thought I would just throw them in the Presskit page willy nilly, and that will get them out there. We have some really nice images that are good for things like Youtube thumbnails, Website articles and reviews, etc. so I really wanted them to be accessible at least somewhere. However having them only on the presskit might mean they aren't really discoverable to the average player or new website visitor. So I decided to add a brand new page, the Artwork page. Initially I just added the nice flashy posters, the 2020 rocket, GDS cover, etc. but I figured there are lots of interesting images we can include from the years of publishing the FFFs. So I went through all the 350+ blog posts, to try to find the best images to put up on the page. I wanted to avoid images that shows old graphics or potentially confusing/outdated information.
It feels like this Artwork page is a great showcase of all the work we've done over the years, and I am really happy with how it turned out. Gathering the best images and compiling them into the single page, it started to seem like we really are reaching the finish line, and we will have some closure on the alpha development. Its been a long journey, and while we have a lot to look forward to with Factorio development, part of me feels a bit sad knowing this chapter of the game is drawing to a close.

[ 2020-06-19 10:42:51 CET ] [ Original post ]

Graphics

• New beacon graphics.

Features

• Changed fluid mixing to a simpler version that only checks when manually building most things.
• Added a flush fluids button to the pipe, underground pipe, and storage tank entity GUIs.

Gui

• Show only unlocked items in filter selection (inventory and quickbar) and logistic/trash requests. Other selections like signal selection/upgrade selection are not affected. New interface settings (off by default) bypasses this and allows the player to see all items as before.
• When selecting an element from a slot that has already value, the selected value is now going to be highlighted with the related tab (if applicable) selected.

Bugfixes

• Fixed a few weird pixels in heat exchanger East sprites. more
• Fixed player mining animation had the backpack affected by the color mask. more
• Fixed mining drill status after disconnecting it from logistic network. more
• Fixed massive script time usage in Wave defense scenario after configuration changes. more
• Fixed that infinity GUI filters didn't list all items.
• Fixed issue with upgrading ghost of assembler with pipes. more
• Fixed new electric mining drill was missing integration layer. more
• Fixed crash when unit group is destroyed while its goto behavior is being updated. more

Modding

• Changed beacon graphics definitions. Graphics are now defined in graphics_set prototype property. If graphics_set is not defined, old animation and base_picture properties will be loaded instead for limited backwards compatibility.

Scripting

• Added LuaFluidBox::flush().
• Added LuaPlayer::auto_sort_main_inventory read.

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

[ 2020-06-16 09:45:44 CET ] [ Original post ]

Read this post on our website.

The Beacon Redesign (V453000)

The Beacon is one of the last entities that dont 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 hadnt 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 dont 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 doesnt appear in a factory at all or very little, or its everywhere. It doesnt really do anything by itself so it doesnt 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 Alberts 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 doesnt 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 dont 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, youre 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 isnt 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 Its worth mentioning that one of the reasons why the Beacon got away without high resolution sprites for such a long time, is because its 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 isnt 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 lets 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 lets 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.

[ 2020-06-12 11:07:10 CET ] [ Original post ]

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.

[ 2020-06-10 11:16:09 CET ] [ Original post ]

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 thats 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 dont try to hide that their perspective isnt 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 its 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. [url=https://cdn.factorio.com/assets/img/blog/fff-350-07-remnants-fullsize.png]
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 cant 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.

[ 2020-06-05 11:57:25 CET ] [ Original post ]

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.

[ 2020-06-01 14:38:08 CET ] [ Original post ]

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, well start proofreading the English source text to offer any grammar or stylistic improvements, as needed. Once the English is polished, well 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,class std::allocator >" (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.

[ 2020-05-29 13:04:12 CET ] [ Original post ]

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.

[ 2020-05-28 16:42:01 CET ] [ Original post ]

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.

[ 2020-05-26 16:52:11 CET ] [ Original post ]

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 its 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. [url=https://cdn.factorio.com/assets/img/blog/fff-348-icons-1-fullsize.png]
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. Thats 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. Thats what weve 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 [url=https://forums.factorio.com/viewtopic.php?p=492101#p?????>upcoming breaking mod changes topic. 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 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 here 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.

[ 2020-05-22 16:06:51 CET ] [ Original post ]

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.

[ 2020-05-19 12:00:10 CET ] [ Original post ]

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 didnt exist when this level was introduced. Tiles and decoratives well just replace, and trees were 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 wont 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 cant 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. Theres better ways I could have done this, but for some reason I didnt want to deal with offsets in this piece of script, and Ive 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, its 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. Ive 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 weve 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 hasnt 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.

[ 2020-05-15 13:50:12 CET ] [ Original post ]

Graphics

• Added player footprints and footstep visual effects.
• Added car and tank dust and particle trail visual effects.

Changes

• Construction robots throw cliff explosives from afar the same as players do, instead of dropping them at the cliff.
• Changed rail segment visualisation colors to be more different from rail signal colors (red/green).
• Clicking a GUI now brings it to the front. Most noticeable when using the map editor or debug GUIs where they overlap.

Bugfixes

• Fixed that Fast splitters were missing a piece visually in East rotation top_patch more
• Fixed that inserters could insert modules for recipes into module slots in some rare cases. more
• Fixed that robots blowing up cliffs was different than manually blowing up cliffs. more
• Fixed limiting cargo wagon to 0 slots would break progress visualization for full cargo and empty cargo train conditions. more
• Fixed teleporting player between surfaces while the player was in a map view would not invalidate tile renderer cache. more
• Fixed that the "use different settings per save" setting didn't work for single player games. more
• Fixed crash due to use-after-delete when single unit builds a base in position that does not collide with the unit. more

Modding

• Added the Prototypes GUI (ctrl + shift + E).
• Added the Prototype Explorer GUI (mouse over most anything + ctrl + shift + F).
• Added support to play different sounds for entity ghosts depending on the size of the entity in the ghost through build_sound (for small), medium_build_sound and large_build_sound on the entity ghost prototype.
• Added support to play a sound when switching weapons defined through utility-sounds 'switch_gun'.
• Added support to play a sound when picking up items (F key) through utility-sounds 'picked_up_item'.
• Added optional 'turn_speed' to projectile prototypes.

Scripting

• Added "include_fuel" field to LuaItemStack::create_blueprint.
• Changed LuaSurface::create_entity so it places resource entities to center of a tile as map generator would. This can be overridden by optional snap_to_tile_center parameter. more

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

[ 2020-05-12 13:52:40 CET ] [ Original post ]

Read this post on our website.

He who does nothing, breaks nothing (posila)

In the recent patch notes, there was a line "Fixed landfill spawning under player when building landfill elsewhere. More" and some people on Reddit were wondering how did this bug happen in the first place, and asked for the long version and even suggested we could even use it for Friday Facts, and I thought: "Yeah, if I am going to spend time writing this, we should consider using it in FFF so someone else doesn't have to spend time writing something else." ... but I am going to stretch it out. https://cdn.factorio.com/assets/img/blog/fff-346-landfill-bug.mp4 The landfill bug reported after the release of 0.18.21. Disclaimer: I have not been around during the ancient parts of this story (speaking of which, it's my 5 year anniversary at Wube, yay!), and changes I have been around for, or even done myself, I might not remember correctly. So this might not be accurate. In fact, let's say the story is purely fictional and any resemblance to real world events and people is just a coincidence.

Tile transitions... again.

For the first couple of years of Factorio development, water drew a transition over ground tiles. The graphics for the transition tiles was taking too much space from the ground tile, so it was not possible to draw a single tile of ground surrounded by water... nor 1 tile wide tile bridge going through water. In addition to that, the transition graphics was tileable only with grass terrain. To enforce these constraints, the map generator was enhanced by tile correction step, the purpose of which was to make sure, that the terrain is possible to draw without any graphical artifacts. (If you wonder why the game didn't use Wang tiles instead, I know they were considered, but why they were not used I don't know. Based on the original water transitions it looks to me like things started with the intention to use them, but they ended up not working well with noise-based map generation. That's just my speculation though). Of course, the tile correction was executed also when tiles were changed by means other than the map generator. From script for example. Mods that allowed players to place tiles emerged. One of them was Landfill, which was adopted into the base game eventually, and as far as I remember, the major trigger for that were reports from people who happened spawn on large island, and after 20 hours of playing the map, they found out they could not continue it. Adding landfill to the game solved those issues but created a new one. When placing landfill, the tile correction logic could decide to "correct" the tiles the player was standing on - trapping player in the water (bug report). https://cdn.factorio.com/assets/img/blog/fff-346-correction-bug.mp4 Bug report from 2016 - Placing landfill traps the player As the team working on the game grew, it was decided to do another pass on the terrain graphics, put much more time into it, and change things around. As you probably already know (since we keep talking about it in past weeks), the ground draws shore transitions over water tile now, and shores are not limited to grass terrain any more. This made tile correction mostly obsolete, but it is still used to enforce some soft tile placement rules during map generation. For example that deep water should not be adjacent to ground tiles. Since we were leaving the logic in anyway, the possibility to define new tiles such that they would not be allowed in just 1 tile wide remained also. Again, as you probably remember from 2 weeks ago, the new transition graphics and newly possible 1 tile wide creeks made it feel like player is getting stuck on invisible walls, or is unable to step over a really narrow gap in the ground. In addition, we already had the character slide a little bit around entity corners, and the new corner tile transitions that were visually diagonal, made me miss this behavior when colliding with tiles. So I started reworking how player character collided with tiles and how those collisions got resolved. What I found worked well, was to ignore the bounding box of the character and just test the terrain directly at player's position. If the tile type at that position is walkable, the player doesn't collide, if it is not walkable, we figure out shape of the transition on that tile and make the character to collide only on some parts of the tile. (note: this assumes walkable tiles draw transitions over non-walkable ones, in case you are thinking of creating a mod with new terrain type that player won't be able to walk on.) https://cdn.factorio.com/assets/img/blog/fff-346-character-movement-no-transitions.mp4 Character movement when not considering tile transitions My goal was to make player movement not be frustrating around water, and intended the rest of the collisions to work as they used to, despite for example enemies not being able to always chase after player. The map generator didn't create maps on which this would happen often, and I didn't mind players using landfill to create passages that could not be crossed by enemies. It just didn't seem to be worth further fuelling this chain reaction of solution to previous problem creating more new problem, because changing player collision was not without it's own issues either (have you noticed anything unusual about walls placed next to water? hint hint). Anyhow, what I wanted to do, was to make a special collision function for the player character, but I soon learned, we have several collision functions for different situations, and I didn't want to make special version of each of them, so I decided to add a flag to character's collision mask, that would modify the collision detection method. Naturally, I wanted to make it is possible for modders to change the collision mask of the character entity, so I exposed the flag to prototype definitions. Mods ended up using the flag on non-character entities, and after Oxyd reworked the pathfinder, the flag started to cause crashes... Oxyd fixed it, but he changed my special logic to consider the entire bounding box again, instead of just the entity position, which made the feeling of player movement worse. This time I decided to solve it by adding optional parameter to the collision functions (instead of yet-another flag), that would indicate that the collision is being calculated for a player controllable entity, to determine if the old behavior should be used or not. And that's how the bug was introduced. Remember that landfill bug with tile correction creating water under player? Well, the fix for that was to add a piece of code to the end of "build terrain" routine that would check the player who built the tiles is not colliding with water, and if they do, just place the ground underneath them to correct the result of tile correction. The special player collision logic allows characters to get so close to water tile that its bounding box collides with the water, and when I added the extra parameter to the collision functions, I didn't adjust this code, so it was using "consider the entire bounding box" collision behavior and falsely detected the character entity as colliding with the tiles and tried to save the character by placing ground under its feet. https://cdn.factorio.com/assets/img/blog/fff-346-bug-reveal.mp4 Landfill bug And here comes the revelation. The big confession. When the first post reporting this bug came in, I immediately knew what the problem was. It wasn't the first time I've seen it. The same issue happened to me when I was making the special player collision logic the first time around. Back than I caught it and fixed it even before the entire tile transition rework was merged to the main code base. But I didn't make a test. I did not... make a... test. So that's how bug like that happens. The short version would have been something like... the bug was the result of long forgotten pieces of code, that are supposed to solve an edge case problems that were usually created by solutions to other edge case problems, interacting in an unintended way after changes that were made to solve yet another edge case problem. In Czech we have a saying for which I have not found English equivalent. "He who does nothing, breaks nothing." It is a kind of reassurance when something unintentionally breaks during an activity, resulting in inconvenience. The only way to make it a certainty that nothing would have broke would have been to do nothing. At times the proverb sounds like an advice... if I can't figure out all the problems a new feature, change, or bug fix will cause, or just the number of potential issues that will need to be solve to do the change seems overwhelming, doing nothing starts to feel like an option with the best possible outcome. But, that's just analysis paralysis creeping in, and what I need to do is to remind myself the intended meaning of the proverb, and stop worrying about potential problems that may not even be real in the end, and if they are, they will be just inconveniences that will be eventually solved too.

Character and vehicle movement effects (Klonan)

This week we're happy to show the latest in visual effects that Dom has been working on. Carrying on the topic of improving the way the terrain and environment feels and reacts to the player, Dom and posila have spent quite some time working on movement effects for the character and vehicles. As you walk around, on certain terrains, the character will kick up some dust and dirt. https://cdn.factorio.com/assets/img/blog/fff-346-character-walk.mp4 The effect actually makes a really big difference to how it 'feels' to walk around, which the GIF might not show that well. Especially with some exoskeletons equipped, you really feel like your zooming around in a real place. Waking around will also leave some subtle footprints in the ground, which helps connect the character to the terrain. https://cdn.factorio.com/assets/img/blog/fff-346-vehicle-trails.mp4 The vehicles also kick up the dust and dirt as you drive around. This feature actually is not simple as it would first seem from the result, but there are quite a few new features under the hood to make it possible.

[ 2020-05-08 13:50:43 CET ] [ Original post ]

Read this post on our website.

Unit group collision mask

Last weekend, a bug report came in on our forum. The issue was that the groups of biters were trying to path over the water, but the bugs can't swim.
It seemed like something quite typical of a mod being funky. I looked into it, and it seems the Hovercraft mod was playing monkey business with water collision masks to make his vehicles ride over water. One thing involved setting water tiles to be walkable, and then adding an additional collision layer to all players and biters. What this modder didn't realise though, is that unit groups have a fixed collision mask. It used to be hardcoded, but a while ago it was added to the utility constants. So we just say "hey its a mod problem, here's a quarter, call someone who cares"... right? Well it didn't sit right with me, because deep inside I knew that the unit groups shouldn't have a fixed collision mask, it doesn't make sense really. Lets say you add flying units to the game. If you give individual commands to the flyers to go attack the base, they will happily fly over the water and attack without issue. However if you put them in a group together, a group of flying units, the group will path around the water, because the unit group still has a fixed ground collision mask. So this week I decided to fix it once and for all. It turns out it wasn't so hard in the end. As we mentioned somewhat in FFF-340, unit groups already have logic in place to recalculate their properties based on their members. I hooked into that logic to also make them recalculate their collision mask. The way that made sense to me, is that they should add the masks together, so that they only path where all of the units can path. https://cdn.factorio.com/assets/img/blog/fff-345-small-biters.mp4 A group of only small biters, they can't walk on water, so they walk around it. https://cdn.factorio.com/assets/img/blog/fff-345-water-biters.mp4 A group of 'water biters'. They can walk right over water, so they go straight through. https://cdn.factorio.com/assets/img/blog/fff-345-mixed-biters.mp4 A mixed group of small biters and water biters. They add their masks together, so only go where all the units can go. You can imagine it quite intuitively I think, the group will try to stick together, and that will mean the group can only path to places that all the members can reach. It feels quite nice to make fixes like this, as they are relatively small in scope and risk, but cleanup a lot of potential problems, and open a lot of interesting possibilities.

Artillery shell particle effect

Another nice small finishing touch for you all this week. Adding a shell being ejected from the Artillery cannons was suggested back when we showed the new sounds integrated into the game (FFF-341). While we can't get too fancy with it, we think the relatively straightforward effect that we've added fills in the detail nicely. https://cdn.factorio.com/assets/img/blog/fff-345-artillery-shell.mp4 It is just a particle with a nice spritesheet that Dom rendered from the original shell models. With a bit of engine tweaking here and there, we had it ready in quite short order. Just another small bit of polishing that characterises this stage of development.

[ 2020-05-01 10:48:51 CET ] [ Original post ]

Graphics

• Added shell particle effect for the artillery shooting.
• Added tinted scorch marks for explosion effects. Explosions on different tile types will result in scorch marks of different colors.

Changes

• Pressing escape/close GUI when a search field is focused only closes the search field instead of the entire GUI.
• Updated GUI styles for PvP configuration GUI.
• Unit groups will determine their collision mask based on the collision masks of their members. more

Bugfixes

• Fixed landfill spawning under player when building landfill elsewhere. more
• Fixed a crash when a train recalculating path during movement is unable to reserve rail signal within movement distance. more
• Fixed production statistics corruption when recipe returns some but not all catalyst. more
• Fixed a pathfinding crash related to changing tiles in a way that affected neighbouring tiles' transitions. more
• Fixed that malformed data in data.raw wouldn't show the minimal-mode failure GUI. more

Modding

• Fixed that writing to mod settings would silently ignore bad values.
• Added "allowed_effects" support to the lab.
• Added "creation_distance_orientation", "use_source_position", "height" and "vertical_speed" to particle creation parameters (related to shooting effect shell particles).
• Added "scorch_mark_color" to TilePrototype.
• Added util.remove_tile_references for easier compatibility maintenance with future game updates when removing base game tiles.
• Removed migration for CustomInputPrototype consuming types that were removed in 0.15.24.

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

[ 2020-04-30 12:14:34 CET ] [ Original post ]

Read this post on our website.

Tile transition collisions (Klonan)

We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better. In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look.
Tile transitions on.
Tile transitions off. So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where. https://cdn.factorio.com/assets/img/blog/fff-344-stepping-stones.mp4 Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does). However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game. Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring. https://cdn.factorio.com/assets/img/blog/fff-344-drone-zig-before.mp4 By not considering the tile transitions, the drone takes an awkward path along the diagonal road. This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example. https://cdn.factorio.com/assets/img/blog/fff-344-drone-zig-after.mp4 By considering the tile transitions, the drones path much more naturally. With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration. As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.

This game is too short, I want my money back! (Bilka)

This Wednesday, Team Steelaxe set a new Any% multiplayer speedrun world record at 1 hour, 15 minutes and 21 seconds. This is the fastest anyone has ever launched a rocket in an unmodded Factorio game. [previewyoutube=X7LH9EvjQV0;full][/previewyoutube] I am part of Team Steelaxe, so I want to take the opportunity to explain how we managed to beat the game this quickly. In general, it is all about planning and preparation, we estimate that we have put a combined 200 hours into planning just for this speedrun. The Any% speedrunning category allows to change all map generation settings, including disabling enemies. Multiplayer subcategories allow for up to eight players. Planning begins with picking a map seed. Since there are many possible maps to choose from, we let a script generate maps and automatically filter out the ones without enough ore in the starting area, and then handpick from there. With the map picked, it is possible to start planning the base. This begins with setting a target time to finish the game and calculating the amount of science and number of assemblers required from there. We then come together and arrange a base on the chosen map, which will serve as a reference for the factory built in the actual run. It should be noted that the category rules do not allow blueprint imports, so instead we usually have the planning save file open in another window or use screenshots during the run.
Part of the spreadsheet that contains every players responsibilities. Another big part of the planning is also to create a spreadsheet of everyones tasks and when they should be done. We distribute the tasks so that two players build smelting, two build mining, one player builds the power plant and only three people build the factory itself. This strict divide means people only ever take and craft the material that they need, so ideally we dont have to fight over resources. Furthermore, the task list allows us to optimize by shuffling tasks around, so that no time is wasted by anyone. One example of this is that only two people ever chop wood for power poles, the rest get the wood from them and do not have to waste time on finding trees. The task distribution also means that every player has a very different perspective of the speedrun, so here are some more:

• Zulan is doing mining.
• I (Bilka) am doing smelting.
• AntiElitz is another base builder.

With the complete plan prepared, we do runs and iterate on the planning, taking into account what worked well and what did not. The speedrun above is the result of a few of those planning iterations combined with some improvisation to compensate for mistakes in execution. It may not always sound like it during the run, but we are all friends and when someone makes a mistake, others jump in to help out, so the linked run is the result of good teamwork. Without everyone working together like that, we would not have been able to reach our target time of 1 hour and 15 minutes. In the future, we hope to be able to launch a rocket in less than an hour, you can watch our next attempts on Sunday at 20:30 CEST on Twitch. You can find over 20 active speedrunners, resources such as save games and replays, or even try running yourself, at Speedrun.com/Factorio.

[ 2020-04-24 17:37:20 CET ] [ Original post ]

Features

• Added new environmental trigger effects for grenade, artillery and nuke explosions. more
• Added 3 level 'First steps' tutorial Campaign. more
• Mini-tutorial improvements.

Changes

• Moved Compilatron and Compilatron speech-bubble entities from demo to base game files.
• Removed Introduction Campaign.
• Removed Compilatron chest, Compilatron roboport, Compilatron logistic chest.
• Removed Tutorial/Campaign Lualib (base/lualib).
• Removed other campaign-only prototypes, such as styles, sprites, sounds.

Bugfixes

• Fixed that thumbnails wouldn't show in the update-mods tab of the mods GUI. more
• Fixed that LuaSurface::spill_item_stacks return value didn't work correctly. more
• Fixed that the research progress of the current tier showed for next queued tier in the technology GUI. more
• Fixed that the game didn't validate modded rail-planner item type values and would crash in some cases. more
• Fixed that modded units with consider-tile-transitions in their collision mask would cause the pathfinder to crash. more

Modding

• Empty layers in sprite or animation definition will yield an error now. more
• Added support for playing a sound when using smart-pipette.
• Added support for playing activate/deactivate sounds for night vision.
• Added support for playing a sound while an resource-style is being mined through mining_sound.
• Added mod-setting value "hidden" to hide mod settings from the GUI.
• Added 'invoke-tile-trigger' and 'destroy-decoratives' trigger effects.
• Added 'rotate-offsets' to the create-particle trigger effect.
• Added 'trigger_effect' to tiles. It is called with the 'invoke-tile-trigger' trigger effect.
• Added 'trigger_effect' to decoratives. It is called when the decorative is destroyed with the 'destroy-decorative' trigger effect.

Scripting

• Added on_pre_script_inventory_resized and on_script_inventory_resized events.
• Added 'allow_paths_through_own_entities' and 'no_break' path finding flags.
• Added LuaModSettingPrototype::hidden read.
• Added 'to_be_deconstructed' to the options for LuaSurface::find_entities_filtered. more
• Added LuaGuiElement::badge_text read/write.

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

[ 2020-04-24 06:53:57 CET ] [ Original post ]

Bugfixes

• Fixed a crash when loading saves from 0.18.12 and older while re-spawning and having personal logistics researched. more
• Fixed offshore pump selection box to match the new graphics. more
• Fixed possible performance issue related to animated trees in OpenGL rendering backend. more
• Fixed opening the character GUI through hotkey when the logistic tab isn't visible. more
• Fixed that curved rail ghosts selection didn't work quite right. more
• Fixed that the offshore pump would play sounds even when it wasn't doing anything. more
• Fixed wrong Lua docs for LuaCommandProcessor::add_command. more
• Fixed a desync when personal logistics is researched while a player is disconnected from the server with personal logistics disabled. more
• Fixed a crash when moving armors around in other players inventories in multiplayer. more
• Fixed a regression issue with the select-a-signal GUI related to group ordering. more
• Fixed that trying to load a save created from a scenario in a now disabled/removed mod would crash the game. more
• Fixed a crash when trying to join games through Steam when the Steam API fails to initialize.
• Fixed that the character corpse wasn't included in the post-player-died event 'corpses' parameter. more
• Fixed that trains pathfinder could create non contiguous path in case of single segment cycle with a single train stop. more

Modding

• Added warning for empty layers in sprite or animation definition. In next release, this will become an error. more
• Added a check to make sure placeable_by.count isn't larger than the placeable_by.item.stack_size. more
• Added support to play sounds when left clicking radio buttons and checkboxes.
• Added ParticlePrototype::fade_away_duration and vertical_acceleration.
• Rolling stock entities can no longer have next_upgrade set.
• Added support for rotated_sound on entity prototypes.

Scripting

• Fixed that LuaEntityPrototype::fluidbox_prototypes didn't include fluid energy source fluidbox prototypes.
• Added LuaEntity::productivity_bonus, pollution_bonus, speed_bonus, and consumption_bonus read.
• Added LuaGameScript::create_inventory() and get_script_inventories().
• Added LuaInventory::destroy() and resize().
• Added LuaInventory::mod_owner read.
• Added LuaEntityPrototype::adjacent_tile_collision_box, adjacent_tile_collision_mask, adjacent_tile_collision_test, center_collision_mask read to access new offshore pump prototype properties.
• Added "final-health" to the entity-damaged event.
• Added "final-health" to the entity-damaged event filter.
• Added LuaGameScript::max_force_distraction_distance, max_force_distraction_chunk_distance, max_electric_pole_supply_area_distance, max_electric_pole_connection_distance, max_beacon_supply_area_distance, max_gate_activation_distance, max_inserter_reach_distance, max_pipe_to_ground_distance, max_underground_belt_distance read.
• Added LuaEntity::deplete().

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

[ 2020-04-20 12:00:10 CET ] [ Original post ]

Read this post on our website.

Environmental particle effects (Dom)

Since the particle optimization we did for 0.18 (FFF-322) and the introduction of new explosions (FFF-325), we were able to push our vision even more. It always bothered me that the grenade and other explosions would emit the same type of particles regardless of the context. In most cases it isn't that bad, and somewhat okay, but when you throw a grenade into water, it will still emit stone particles, which breaks the illusion. Another problem is that we have the nice decoratives on the ground, but they don't really 'interact' with anything that goes on, and can feel like fake flat stickers instead of something 'real'. You would expect that when there is a massive explosion 2ft away, the bushes might have some reaction to that. https://cdn.factorio.com/assets/img/blog/fff-343-grenade-old.mp4 The explosion effect currently in 0.18

Specific tile effects

One thing we wanted was some way for tiles to respond to the explosions in different ways. The way Posila decided to add this capability, is through the 'Invoke tile effect trigger'. Tiles can define an effect that happens, and the explosion will tell the tile to create that action. After the implementation of this feature, it was smooth sailing from there. I was able to design the explosions like I wanted them, to be emitting specific particles based on their tiles. For example besides the visual improvement of the stone emissions in water, I was able to make the hazard concrete emit dark grey and yellow particles. https://cdn.factorio.com/assets/img/blog/fff-343-mosaic.mp4 We kept in mind that people might want to tint all the new particles for mods, so we kept everything as tint-able as possible. So a modder can just use our particle definitions and tweak the tints, for instance, if they want to add purple terrain. It's worth mentioning that the same goes for almost all the new particles (metal/stone/vegetation/blood/glass etc). Using the same sprites with different tints also helps us save some VRAM, as the game applies the tint during the render phase.

Decoratives

Posila also added the engine changes required to remove decoratives on impact, and for the decoratives themselves to create some particles on their destruction. This makes it feel much better when you see the explosion, because you see the decoratives reacting as if they were real, and it does not break the immersion in the game. It also helps to make the explosions feel a bit more powerful, at least powerful enough to blow over a bush. https://cdn.factorio.com/assets/img/blog/fff-343-grenade-new.mp4 The new grenade explosion, showing the new tile effect and decorative effects. The reactions are also based on the individual decoratives. So each individual decorative will emit a different set of particles, bushes will emit grassy vegetation particles, stones will emit stone particles, etc. We also use the same tinting system here, so a brown bush and green bush will have the same particle sprites, just tinted accordingly. There is of course the nice benefit of this to a lot of players, now that grenades can clear the decoratives, you can do some explosive cleaning of your precious prestine factory floors. https://cdn.factorio.com/assets/img/blog/fff-343-clearing-decoratives.mp4 A player clearing decoratives off their precious pathway

Minimal 'No base mod' (Klonan)

Bilka has spent quite some time in the last month working on a new 'mod' for the game. Well its more of a mod that allows the removal of the 'Base' mod. It has always been technically possible to run Factorio without the Base mod enabled, but anytime you would try you'd be hit by a bunch of missing prototype messages. Basically the game needs to have some minimum amount of prototypes defined to be able to launch properly. So Bilka's work will act as a foundation for other mods to build on, to help modders make true 'total conversion' mods, or just have fun with the raw Factorio engine. Of course enabling this mod and starting the game isn't very fun on its own.
Factorio, but there is no content For more details, please check out the detailed forum post by Bilka, and you can find the project repository here.

[ 2020-04-17 15:11:43 CET ] [ Original post ]

Read this post on our website. As stated in previous FFF's we will be making some changes to the demo and tutorial content in the game. I wanted to clarify exactly what is being removed and what it is being replaced with, as this content is almost ready for release. If you would like to catch up on the topic, you can read Kovarex's piece in FFF-327, but I will also summarize it here. Right now the NPE/Introduction is the scenario that is used as the demo (0.17) and as the tutorial in the full game (0.17 stable, 0.18 experimental). If anyone has played the tutorial in the last 12 months, this is probably what you have played. The First steps campaign was a series of three levels which used to make up the demo and tutorial in 0.16 and earlier. They were introduced in 2014. We have been working on revamping these levels to bring them up to 0.18 standards. Very soon the NPE/Introduction will be removed and the First Steps campaign will be reinstated, both as the full game tutorial and the demo.

What has been changed in the levels?

The plan was to change these levels as little as possible while updating them to modern Factorio standards. That is harder than it sounds given these levels were created in 2014. As stated in FFF-241, there were many things we felt were inconsistent in the First Steps campaign. One of the largest ones was that there were many different and confused channels of information. The newer version has given each channel a purpose and a format. The most distracting, and the most popular was the character monologues. Some of the messages in each channel were written in the first person, as if the character is talking to themselves. All the instances of this occurring in the Yellow speech bubbles and objective panel are gone or moved to the console. The rule here is that nothing that is actually necessary should come via this channel. To communicate to the player that this is story text, I added a speaker prefix.
The most necessary and most annoying channel was the Yellow speech bubbles. There are situations where it is absolutely necessary to pause the game and tell the player something. Since we have no other technology designed for this purpose, I just resorted to removing as many of them as possible. They only appear where necessary, although I would still like to get rid of more of them. The final channel is the Objective window. The rule here is, if the player tabbed through all the speech bubbles without looking, and did not read the story text, they should still be able to finish the level. The text should not be in the first person, and we can speak directly to the player. Due to much more rigorous and dedicated internal testing (Boskid), we caught a lot of corner cases where players can become stuck. The tutorials also now take into account new and updated game features. For example, previously the pickaxe was used to demonstrate crafting, so some extra attention had to be paid to when the player crafts the stone furnace for the first time. The maps have been updated to look much more like what the random generator creates in freeplay. The new remnants make a great impression here.
Now that the quickbar does not automatically populate, we had to be more careful about when the player has their inventory open. The new standard for new players is: open inventory, take item, close inventory, place item, open inventory, place remaining items, close inventory. Giving new players the option to add quickbar links as early as possible is a challenge because every time you add a new concept, the player must expend some of their attention keeping it in mind. Not only that, but using the quickbar actually removes a perfect opportunity for the new player to practice interacting with the inventory.

Why are we changing it?

Kovarex discussed his reasoning in FFF-327, but a lot of people asked me for more information to help them understand. Post mortems are uncomfortable but necessary so I will try to summarize his point and add one of my own. The NPE/Introduction was created to widen the audience of Factorio. It takes new players a long time to get into the game and many stop playing before 'getting it'. The strategy was to show new players (both in the demo and tutorial) more of the mid game. After finishing the scenario Kovarex realised that the experience was not in line with his vision for the game. When he told me how he felt, I think he was surprised that I agreed with his decision to remove it. Vision alignment is very important, especially in a demonstrator product. It isn't something you can just 'fix' when the project is almost finished. This is not to say that the NPE/Introduction failed in its goals. It did appeal to a wider audience and player feedback at the end of development was overwhelmingly positive. I received a lot of feedback from genuine first time demo players pledging to buy the game immediately and also from story focused, non-sandbox players who were craving more. But as Kovarex said in his FFF, the cost of this was too high. In light of the full length campaign being cancelled (see V453000s part in FFF-331), this is the biggest reason why I think the NPE/Introduction would have failed as a demo. We would have been offering an experience in the demo which was targeted to a wide audience, but the quest loving players were not going to get any extra content if they buy the game. A literal "It isn't what it says on the tin" situation. A full post mortem would be much longer than this, and I would have liked to discuss much more about the things that went right. On the up side, a lot was learned from this project and that can only make the game better in the future.

When is it coming?

The new old First steps tutorial is almost ready for release, we are still doing some general polishing and internal testing, and if all goes to plan, it will be released within the next few weeks. However that doesn't mean the work is necessarily finished, as no doubt we will need to tweak, polish and fix a lot more things as player feedback starts rolling in. Alongside this addition, we will also be removing the NPE, and doing a general cleanup of the now unneeded data changes. This may affect some mods which have dependencies on some new campaign assets. We might leave some assets in if they are significant enough (for instance the Compilatron), so if you are a modder and something in the NPE is of special interest to you, please let us know.

[ 2020-04-10 13:55:32 CET ] [ Original post ]

Changes

• Adjusted steam engine and turbine collision boxes so player can walk between two steam engines.
• Roboports allow exporting both logistics and robot stats at the same time. more

Graphics

• Added offshore pump remnants.
• Added new dying effects for biters, spitters, worms, and spawners.

Gui

• Added confirmation box for deleting blueprint book.

Sounds

• New or updated sound effects include:
• Transport belts - new concept for these sounds.
• Turrets rotation sounds and fold/unfold.
• Weapons improved and made more powerful, e.g. submachine gun, shotgun, gun turret, vehicle machine gun, Laser and electric beam.
• Particles: Water splashes, Tree debris.
• Various mix level tweaks including the train, enemies.
• Attenuations (audible distance) adjusted for entities such as Pipe, Substation and Offshore Pump.
• New sound when walking over ore patches.
• Default Sound Settings Updated:
• Music, Game Effects and Walking sound lowered, Environment sounds and Master Level raised.
• Zoom audible distance and volume levels adjusted.
• Maximum Environment Sounds increased (edited).

Bugfixes

• Fixed mining entity with randomized mining result amount would never return the largest defined amount. more
• Fixed crash when loading replay. more
• Fixed reading LuaPlayer::entity_copy_source when the player is dead. more
• Fixed that upgrading and delivering modules at the same time didn't work right. more
• Fixed a crash when closing the game while some GUIs are shown. more
• Fixed crash when setting max_group_gathering_time and min_group_gathering_time to the same value. more
• Fixed discharge defense equipment had the wrong sprite in the equipment grid. more
• Fixed that artillery wagons wouldn't show out of ammo icons. more
• Fixed that modded cargo wagon colors wouldn't copy correctly through blueprints. more
• Fixed furnaces with recipes using fluid ingredients could cause crash. more
• Fixed a crash when removing a player that has modded associated character entities. more

Modding

• Furnaces now ignore off_when_no_fluid_recipe property of their fluid box definition. Fluid boxes will not be disabled based on enabled recipes. more
• Changed colored concrete tiles to be non-mineable.

Scripting

• Added LuaEquipmentPrototype::automatic.
• Added "include_entities", "include_trains", "include_station_names", and "include_modules" fields to LuaItemStack::create_blueprint.
• Added LuaRoboportControlBehaviour::read_logistics and read_robot_stats
• Removed LuaRoboportControlBehaviour::mode_of_operations

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

[ 2020-04-08 15:26:02 CET ] [ Original post ]

Read this post on our website.

Sound design update (Ian)

One advantage of switching to home working during the COVID-19 crisis is the ability to listen to the game using speakers rather than headphones, and this has proved useful in balancing the relative levels of the game. Val has also been getting to grips with Lua, and this has led him to working on attenuations, which have been proving problematic. For instance, we noticed that sounds such as the radar were getting cut off when you walked away from them, rather than fading out cleanly. I investigated and discovered we had a maximum environment sound limit of 15, by raising this to 50 we have eliminated many of these problems. But then the downside is that there are now more sounds playing and therefore more clutter to mix and balance. Pink squares indicate which sounds are active.=
Limit of 15 nearby sounds.
Limit of 50 nearby sounds. Rseding has been working through the list of sound design programming tasks, for instance we finally have the sound for the artillery turret rotation integrated into the game (which was featured in FFF-252 quite a while ago). https://cdn.factorio.com/assets/img/blog/fff-341-artillery.mp4 Real in-game footage of the new artillery sounds In other news, we have an updated concept for the transport belts. We listened to feedback from the community that they were still a bit too present and annoying. The idea of the new sounds is that they will drift into the distance a bit more and become unnoticed (until you try to fall asleep). More fun sounds include water splashes, electric and laser beams, more powerful weapons such as the gun turret and vehicle machine gun. And our old robot sounds have come back as additions. If all goes to plan, we will merge the sound changes into master very soon, and once we've done all our pre-release checks, release it to the 0.18 experimental. After that, I plan to spend time on UI sounds, and also balancing the overall levels to get them more in line with other games, which is trickier than normal given the lack of audio middleware. However we have also made some changes to the default sound settings that move us in the right direction.

Attenuation (Val)

Lately Ian and I were occupied with mixing and sound attenuation of the game. Attenuation of the sounds is a great tool for mixing a game. Using it you can make all sounds more located, take a certain place, you can clearly hear what object you are passing by, and sounds dont overlap each other as much. Another bonus is that reaching an object wont shock you with the full volume of its sound, as it is audible at a distance and ramps up in volume. All that brings you a clearer mix of everything you hear in the game. While checking the offshore pump and I noticed that pipes produced a small part of their loop when I walked near them, even if there was no water flow inside. https://cdn.factorio.com/assets/img/blog/fff-341-fluid-sound.mp4 The pipe is making a sound, even though no fluid is flowing Rseding told me that it must be a conflict of the entity working_sound in combination with the max_sounds_per_type we use to limit the number of certain types of sounds playing at the same time. After thinking a while, I decided to remove the max_sounds_per_type and added a audible_distance_modifier with a very small value for pipes. I tested that, and for my happiness it worked well in this case. There are probably another 100 little issues like this in the sound design, it is not as simple as replacing all the audio samples, and we are getting there. This is also why your feedback and bug reports on the sound changes are extremely useful to us, as we need to take care of as many areas as we can before 1.0 arrives.

[ 2020-04-03 18:35:30 CET ] [ Original post ]

Read this post on our website.

Not mentioning it would be weird

I really think everybody has heard all about this and nothing else over the last few weeks, but yes, the Coronavirus. For now, with Factorio, everything seems okay. We are all working from home, the team is still going, and so far we are following our plan quite well. We released the Character GUI and Statistics GUI last week, and some improvements such as new water splashes and leaf animations this week. Things are still moving along. However it is still early days, we haven't really had any experience having the whole team work remotely, so there may be some challenges we need to tackle as time goes on. At the moment we don't know whether this will affect our 1.0 release date, I guess it will one way or the other, but for now we aren't announcing any changes.

Business as usual

Apart from the development side still running, our e-shop is also remaining operational, and we have just restocked on all variants of our t-shirts. While we can't guarantee anything, if you order from us at this time, we should still be able to get your t-shirts to you.

Deep desyncs

Last week there we had quite a few more players than usual, and Krastorio 2 was released, which meant a lot more hours into a lot more areas of the game. During the week, Boskid and I received quite a few desync reports with mods. Generally we believe, that it is probably the mods causing the problem, as it is quite easy to cause a desync with the control scripting if you don't know some very important gotchas. But still, we decided to investigate to help the players find out which mod is causing the problems.

Serpent cyclic references

One quite tricky desync we found, is related to cyclic references, and the way serpent serialises the global Lua data. Take the example here of the Construction Drones mod. You have a player which dispatches the drones to go do work; the player needs to keep track of what drones he owns, and the drones need to remember which player they belong to.
Now this works fine during runtime, you can access the drone from the player object, and access the player from the drone object. When the game is saved, Serpent goes through all the data in 'global' and serialises it for later. To handle the cyclic references, if serpent detects that it has 'seen' an object already, it writes a placeholder value, and comes back to fix it later. The problem, is that serpent chose nil as the placeholder value. In Lua, writing a table value as nil is the same as deleting the key, and the key won't be seen when looping the table in the future. When serpent then goes back to 'fix-up' the placeholder values, it ends up with each peer saving a different table ordering (because of some even deeper technicalities with our custom version of Lua). So the problem is deep and was quite hard to find, but the fix is quite simple. Boskid simply changed the placeholder value from nil to 0, and now the iteration order is saved and loaded correctly every time.

Unit group max speed

Another report came in from a player using Krastorio 2 and Rampant mods. This one on the surface really seemed like the mods fault, since all the diffs in the desync reports were related to unit positions, and the Rampant mod is all about units. The desync was extremely fragile, and was very hard to reproduce, but eventually Boskid managed to narrow it down. This is a screenshot taken on the exact tick that the desync occurred.
What jumped out to me as immediately suspicious, is that the biter is only just moving onto the creep. This is because the creep (from Krastorio 2) gives the units a speed bonus when walking on it. I did a quick experiment by commenting out the tile bonus code in the engine, and the desync did not occur again. But of course removing the code here would only treat the symptom, and the cause will be something deeper (FFF-296). So with lots of patience, Boskid narrowed it down further and further, deep into the movement and unit behaviour logic. What we found, is that the unit is part of a unit group, and this group was caching the value of its 'max speed' based on the fastest unit in the group. However this value was not saved with the save game, but was recalculated each time the game was loaded. Since the unit was walking on creep, it has a higher max speed, so the group calculated a higher max speed when the game was loaded. Now this logic has been in the game since unit groups began, but it only became a problem more recently. In versions of Factorio 0.16 and before, a units max speed was always going to be based on its prototype, which does not change after the game is loaded. With version 0.17 we added 2 (really nice) mod capabilities:

• Allowing units to be affected by tiles;
• Allowing scripts to change unit speeds directly.

It didn't come up as a problem initially, as the freeplay base game doesn't really use these capabilities. Well every change has the potential to break things. Since we know the only 2 cases where the units speed can change, Oxyd made it so that the unit will notify the group to recalculate its max speed when it is necessary.

[ 2020-03-27 13:14:13 CET ] [ Original post ]

Graphics

• New water splash effects using water particles instead of an animation.
• New animations for leaf particles.

Bugfixes

• Fixed the tank not being properly centered to its bounding box (graphical issue).
• Fixed GUI windows not drawing properly when they can't fit the screen width. more
• Fixed glowing Heat pipe ending sprites. more
• Fixed some character bonuses in bonus GUI not being printed correctly. more
• Fixed character GUI player color sliders not changing chat colors more
• Fixed that hotkeys wouldn't work while using the character logistics GUI in some cases. more
• Fixed a desync related to unit speed changing while part of a unit group. more
• Fixed some Trigger Effects not showing correct repeat count in tooltips. more

Scripting

• Added LuaEntity::effective_speed
• Added LuaControl::is_flashlight_enabled
• The 'on_ai_command_completed' event will now fire for distraction commands.
• Added 'was_distracted' to the 'on_ai_command_completed' event. If true, it means the completed command was a distraction command.

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

[ 2020-03-25 17:19:10 CET ] [ Original post ]

Read this post on our website. The beacon is one of the last entities left to convert to HR. As always, before 'just re-rendering' we take the chance to re-think the concept and modernize it. This post will try to go a bit deeper in the process of redesigning such an entity.

The old beacon

At the beginning of the project, the style of the game was less or more clear: nothing looks brand new. Everything looks dirty and DIY. The machines need to be full of details, if possible trying to explain its mechanics. The colors are provided by the raw materials. The bounding box is everything. And some other rules that I don't even remember now. The main handicap at that time was that we didn't have the experience of how the average player is composing the factories. So we produce a nice looking model but once it is placed in the factory, it doesn't look that nice due to the lack of context.

The process for the new beacon

The beacon is a very advanced late game entity. Usually placed very close to each other in long rows, horizontal or vertical. Its function is to provide extra power to other entities in its surroundings through the air. One of the main objectives for the redesign is not only a better coverage of the most common needs of the entity (shape recognition, working good in its context, and total integration in the world of the game) but also its expressivity. It would be really good to understand the use of the machine just by looking at it.
In this early sketch the main concepts are already defined. It needs to be a tower in order to transmit the effect. But the tower has to be transparent, otherwise it will occlude the other entities behind, creating a problem of readability. It has to look modern. That's why the conical shape with rounded windows. It reminds of a soviet space capsule. The blinking lights inside will help not only to look more technological, but also will help for visibility. Due to its normal usage in long rows, the plan was to create an extra tileset of cables connecting the beacons to each other. So the composition would look much more interesting and organic with the player moving under this network of beacons. The idea is cool and it works on paper, but once we get to work, we realise that it's needed to fill a square of 3x3 tiles. Once in the 3D viewport, this concept changes too much to not think of different solutions. Connecting the entities with cables. It looks like the beacons are interacting with each other creating a more powerful net of beacons, and this is sending the wrong message.

Save the good stuff and solve the problems in a new version

The main problem was the need of stuffing the tower in a squared area. This rule of the collision box forces every entity to be some sort of a blocky box on top of the ground, always, and for this entity we really needed the tower.
To solve this issue a new concept appears: Let's create a hole in the ground that covers the collision box area, and build the tower inside. It looks higher than what it really is, and the occlusion with the tiles behind is in the acceptable limits. [table] [tr] [th]
[/th] [th]
[/th] [/tr][/table] The beacon looks modern, colorful, tall, high tech, and integrated in the world of Factorio. It even solves the collision box issue and is easy to recognize from afar. But it has something wrong: it doesn't work fine in an array, and the center of the entity is too complicated. It creates a chaos of pixels that is hard to see, especially when overlapping with another beacon vertically.

A better beacon

To solve the ultimate complication for the array situation, a few changes are relevant to do. Cleaning up the center of the entity in a way that works as a background with himself when overlapping in vertical (or any other tall entity, like a pole).
In the so common array situation, it's going to be really nice seeing the beacon with some variations. This will make it look more natural, and pleasant to the eye. We would like to use this sort of variations for every entity, but the amount of work and VRAM needed would be just insane.
This is still a work in progress. Right now Im working on the animation of the beams. Im trying to make it much more subtle, because the way it is here it calls too much attention and saturates the screen very easily. [table] [tr] [th]
[/th] [th]
[/th] [/tr] [/table] The layer of the beams and the light will be separated and tintable in a single spritesheet. Probably the yellow rounded light also. It will be available for any modder to make a modified beacon just by changing the RGB values. There are many things I didn't say about this process of redesign, but I had to keep them out because this post is already very long. I hope it was interesting to you.In future releases, very soon, youll be able to play with it.

[ 2020-03-20 13:06:57 CET ] [ Original post ]

Gui

• The production statistics and electric network GUIs now have a new look.
• The kills GUI (K keyboard shortcut) has been removed. Kills statistics are now accessible as a tab in the production statistics GUI.

Bugfixes

• Fixed an issue with nested items in items. more
• Fixed Character GUI missing logistics tab due to missing technology migration. more
• Fixed Character GUI recipes constantly scrolling up when crafting or when inventory changes. more
• Fixed that simple mouse click on double slider button would not set a slider as active. more
• Fixed that tabbing out of empty high value textfield of double slider would reset it to 0. more

Scripting

• Removed the defines.gui_type.kills value from defines.gui_type.

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

[ 2020-03-18 17:37:26 CET ] [ Original post ]

Gui

• The character GUI now has a new look.
• Personal logistics has been moved to a separate tab. Logistic requests and auto trash have been merged into one panel.
• Using quick inventory transfers in the player inventory of the character gui will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.
• Updated the look of filter, item and circuit signal selection GUIs.

Changes

• Personal logistics are now unlocked by a single research. This unlocks personal logistic requests and auto trash(unlimited count), plus 30 character trash slots.
• Removed the restriction of not allowing to have two identical blueprints in the blueprint library or blueprint book.
• Allowed to delete blueprint/books/upgrade planners/deconstruction planners also when opened in other inventory.
• Removed the utility slots (to create blueprint, book etc) from blueprint library as it is now available directly through quick tools menu.
• Allowed to edit blueprints in the blueprint library the same way as when it is an item.
• Allowed to export blueprint books in blueprint library (it was only possible in inventory before).
• Allowed to choose whether train fuel should be included in a blueprint.

Bugfixes

• Fixed that 3rd last row of 4th sheet of gun turret shooting had duplicate frame. more
• Fixed desync when changing recipe that was outputting large amount of fluid per crafting cycle to recipe that outputs low amount of fluid. more
• Fixed sprite button would not respect draw_shadow_under_picture style property. more

Modding

• Added main_menu_background_image_location to utility constants.

Scripting

• Removed LuaStyle::extra_padding_when_activated read/write.
• Added LuaStyle::extra_top_padding_when_activated, extra_bottom_padding_when_activated, extra_left_padding_when_activated and extra_right_padding_when_activated read/write.

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

[ 2020-03-17 16:24:46 CET ] [ Original post ]

Read this post on our website.

The Character GUI (Twinsen)

It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type. https://cdn.factorio.com/assets/img/blog/fff-338-tabs.mp4 Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request. https://cdn.factorio.com/assets/img/blog/fff-338-setting-filters.mp4 With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science. Searching now not only searches the recipe GUI, but also the inventory and logistic requests. https://cdn.factorio.com/assets/img/blog/fff-338-search.mp4 By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots. https://cdn.factorio.com/assets/img/blog/fff-338-toggle.mp4 Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released. Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be focusing obsessing that much on the GUI in the future. We will 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. This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.

Community spotlight - Krastorio 2 (Bilka)

Over the past two weeks, an overhaul mod called Krastorio 2 has been going through closed alpha and beta testing. Krastorio 2 is an overhaul mod that aims to provide a vanilla-style experience with an expanded post-rocket game and updated recipes. The mod will be released later today, so I wanted to take the opportunity to spotlight it.
My factory, grown over the two weeks of testing, showing off the custom mod graphics. Click to view full resolution The mod changes almost all recipes without introducing many intermediates, making it close to vanilla while still being a new experience. One of the bigger changes is that late-game technologies do not require the starting tech cards (science packs). Combined with the tech cards mostly needing intermediate products, you can reroute the ingredients of the tech cards into other production as the tech cards become obsolete.
Post-rocket tech cards are consumed in the lab area on the left in the image, the pre-rocket tech labs stand disused in the bottom right. The biggest feature of Krastorio 2 is that it adds a significant amount of content beyond the rocket launch, including a new win condition. After automating rocket launches there are three more tech cards waiting to be researched, two new resources waiting to be harvested, and many more useful items to be crafted. All that production and the win condition take a significant amount of power but thankfully the mod adds an effective power generation option to fulfill the factory's needs.
Fusion power All in all, the mod can be described as a great mix of updated recipes and fresh mechanics that are kept in line with vanilla. This means that the mod is not as overwhelming as overhauls that really focus on certain mechanics such as many additional resources, fluids or intermediates. Instead Krastorio 2 strikes a great balance between old and new. The mod has many more features that I did not mention here; so if I made you curious, check out the mod for yourself and have fun playing!

[ 2020-03-13 13:40:50 CET ] [ Original post ]

Graphics

• Fixed player character shadow didn't animate in idle state when not facing north.

Bugfixes

• Fixed that LuaEntity::splitter_filter would reject a LuaItemPrototype. more
• Fixed smart entity collision mode in tile editor did not work with offshore pump. more
• Fixed that modded shortcuts that spawned items not visible in the blueprint library didn't work. more
• Fixed that technology tooltips didn't show debug tooltip data the same as other tooltips. more
• Fixed that crafting machines would report as supporting backer names through the Lua API. more
• Fixed that un-researched recipes couldn't be used while in the map editor. more
• Fixed that the removed-content GUI didn't include some translations. more
• Fixed a desync related to invalid rail signal requested to be closed by circuit network. more

Modding

• Added InserterPrototype::chases_belt_items. more

Scripting

• Added LuaEntityPrototype::inserter_chases_belt_items read.
• Added surface to the selected-area events.
• Changed LuaSurface::spill_item_stack() to return the created entities if any.

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

[ 2020-03-10 18:22:45 CET ] [ Original post ]

Read this post on our website.

Statistics GUI (Klonan, Oxyd)

The statistics GUI (electric network stats, production stats, etc.) is one of the GUIs that has been in the game for a very long time, and has had its functionality fleshed out reasonably over the years. It was not long ago when Twinsen added hovering and highlighting to the graphs. Given that, and the relatively short timeframe for 1.0 release, the update of the statistics GUI has really just been a style update, no new features or heavy logic rewriting. Oxyd has most of the work done, so we are happy to show some real in-game screenshots of how it looks:
A notable change with the electric stats is that the Satisfaction/Production/Accumulator charge are next to each other in a single row, as opposed to each in a separate row. The label for the exact amount has also been moved to inside of the progress bar, which itself is much thicker.

The production stats are pretty much the same functionality wise. One new button you might spot is the search button.
However there are some problems with the search feature. As you can see, production and consumption frames have a different search box independent from each other. The main problem is when pressing CTRL+F to perform a regular search: How do we know which frame to open? Of course this could lead to different solutions like the use of a cycle for the focus of the search, in which the second time you press CTRL+F the other frame gets the focus. Or both of the search boxes open at the same time but only one gets the focus. Or only one frame gets the focus and the other one works only by pressing the button. But let's face it, these "solutions" are not solid at all and create inconsistency in the main design. To solve this issue we decided that the simplest way to go is the use of just one search box on the header of the panel. This new location works as a general feature for the entire panel. One single search gives you 2 results, one on each frame. This solution is used in the new character window -to come soon- making it consistent with the whole design of the GUI.
You can also see we took this opportunity to integrate the Kill statistics in with the rest, instead of being its own window with its own hotkey. The Statistics GUIs will need a few tweaks and polishings here and there before it is ready for release, but unless something unexpected happens you can expect it coming out in a release soon.

Community spotlight - Mod Debugging and Instrument Mode (justarandomgeek)

This topic is a guest post by our community member and mod maker justarandomgeek. Historically, while developing Factorio mods, you just had to write some code and try it, until you get one of these:
Then you go back and find that spot in your code and try to figure out what went wrong. If the error is particularly confusing, you start sprinkling log() or game.print() around to try and figure out what the heck is going on. And, of course, when you find the problem, you inevitably forget to clean all of these up, and now you're spamming the log or chat forever.
Well there's your problem! Perhaps a bit constructed... For the last few months I've been working on a debugger to improve this experience. The first step was to spend some time with the Lua debug library and VSCode's Debug Adapter Protocol making introductions to get them talking to each other. Factorio doesn't give me many options, but Lua's debug.debug() and print() functions are enough to interact with the (normally invisible) console. VSCode can launch Factorio and attach itself to this console to inject commands as needed to read and manipulate the state of the running code. This gets us VSCode's debugger interface, with all the pre-built tools for displaying variables, setting breakpoints and stepping through code. Wrapping some of the game's APIs like remote.call() and most of script to add a little extra special handling, we get nice labels on event handlers in the call stack and a first version of break-on-exception for when things go wrong. I even built some nice detailed variable views for the most common LuaObjects:
But there's a catch, and it's a big one: because of the way Factorio sandboxes mods, the debugger (which is itself a mod, in part) can't actually get to your mod to install all these hooks! The first solution to this is to simply add a line to load the debugger, but this puts us right back where we started with log() - you put something in for debugging and forget to remove it. To solve this problem we need a little help from the API, a way for a mod to hook every other mod. Unfortunately, this level of hooks is too powerful of a capability to be generally available to mods, so it can't really be added to the normal mod API (it allows you to fairly trivially break nearly all assumptions about data lifecycle and mod sandboxing). After some discussion with Rseding, we eventually arrived at Instrument Mode (released with 0.18.10), a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once. This also provides a hook for a better version of break-on-exception. This gets us all the way to the rich debugger experience: When you run under the debugger, all loaded mods automatically get debug hooks installed for the session (but not permanently), and you can step through the code and examine all your variables! While I was building tools, I also added some highlighters for locale and changelog files, and validation for changelogs:

And of course, it's a game about automation, so we need some modding workflow automation too:
Modders, please give it a try and let me know what you think!

[ 2020-03-06 16:22:02 CET ] [ Original post ]

Graphics

• New offshore pump graphics.

Changes

• Removed the sound effect from the console-only electric-energy-interface.
• Item localised name takes priority over place-result localised name when showing item's tooltip. more
• Offshore pump is now buildable on ground tile adjacent to water instead of water tile adjacent to ground.

Bugfixes

• Fixed that the map generator GUI didn't reset to the correct defaults when changing presets. more
• Fixed blueprint window sizing for wide blueprints.
• Fixed some cases of not considering dark background icon when drawing alt mode overlay. more
• Fixed that burner generator idle_animation and animation could have different frame counts.
• Fixed icons with overlays were drawn incorrectly when used in sprite widget. more
• Fixed crash when loading map after removing fluid recipes with indexes. more
• Fixed spitters would not break from attacking an obstacle when the obstacle moved away. more

Modding

• Added Instrument Mode to support mod development tools.
• Added optional burner generator prototype properties always_draw_idle_animation, performance_to_sound_speedup and min_perceived_performance.
• Added optional offshore pump prototype properties min_perceived_performance, adjacent_tile_collision_box, adjacent_tile_collision_mask and center_collision_mask.
• Changed offshore pump graphics definition. Old definition will still be accepted, but is deprecated.

Scripting

• Added optional parameters daytime and water_tick to LuaGameScript::take_screenshot() function.

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

[ 2020-03-03 14:50:19 CET ] [ Original post ]

Read this post on our website.

Offshore pump redesign (V453000, Albert)

As one of the last entities which do not have high resolution graphics, the time has come for the offshore pump. The offshore pump is practically a 1-tile entity, but they must have a 1 tile gap between each other. It is also the only entity placed on a water tile at the moment. When we changed the way how terrain to water transitions work, we moved the offshore pump to be placed on the water tile. This can result in the pump drawing over terrain in ugly ways.
With the redesign, we took the oppourtunity to move the offshore back onto land, and additionally the pump checks a 2x3 tile water area in order to be buildable.
The new placement rules only applies to newly built pumps. Offshore pumps on existing maps will keep functioning, theyll just be shifted out from the shore. There is no blue colour for water integration at the tip of the offshore pump, so the offshore pump will look correct even with unexpected water types (not a big problem in vanilla). The water integration is split to an underwater layer which does not show when the pump gets landfilled over.
In the basic concept, the offshore pump is another type of a pump, so it should be similar to the other pump entity Albert made a few years ago, including the animation and visible fluid in it. The obvious difference is the connection to water. However we felt that is not different enough and needs more visual balance, so we added a pair of supportive legs. https://cdn.factorio.com/assets/img/blog/fff-336-offshore-pump.mp4 We are planning to release the new offshore pump graphics with the next release, likely next week.

Mod spotlight - Built in beacons (V453000)

Beacons strongly motivate building in rectangular repeatable patterns. The results generally look clean, but also very predictable and boring. Furthermore, the differences between different recipe builds are only minimal, so the visual difference between builds is minimal.
The issue is, I like to build the opposite of clean and predictable. The factory looking increasingly complicated and harder to expand over time is what keeps me engaged to continue playing a map. When it starts looking easy, I lose interest. Ive been trying to solve this for myself by either restricting myself from using Beacons (which is a massive sacrifice of productivity and speed), or by putting the sub-factories with high Beacon counts outside of the starting area, as keeping the organic starting area is key for me.
Eventually I thought about creating a mod that makes machines behave as if they had the maximum possible amount of beacons around them - allowing me to upgrade the starting base, but that also causes higher demand on the throughput of logistics, which the most interesting part - snaking more belts, fitting in more rails.
The mod defines 3 tiers for every producer to simulate beacons with tier 1, 2 or 3 of Speed modules in them. These machines cannot be further affected by normal Beacons and only accept special productivity modules defined by the mod.
Creating the mod was a ton of fun. I rewrote it about 3 times as I was learning how to do it better. I hacked together some basic graphics for it from some special passes (height and Ambient Occlusion) that we use for postproduction in our gfx workflow. I played with the mod and got some interesting results (imgur album) as I was able to continue building in the starting area instead of refactoring it for Beacons. [url=https://cdn.factorio.com/assets/img/blog/fff-336-base-preview-alt-smaller.png]
Click to view full resolution Lastly, I wrote a timelapse-screenshot tool. It can either be used by taking a screenshot each N ticks automatically, or in my case I give it a folder with savegames and it takes X number of screenshots, then moves to the next savegame. It's quite crude so I won't release it on the mod portal for now. [previewyoutube=AoxfGev36ms;full][/previewyoutube] Making Beacons disappear into producer machines to allow for more organic bases fits my perverted playstyle, but Beacons actually do bring a lot of interesting motivations to the base game, and it can be a lot of fun to mess with the building rules that Beacons force. You can find the mod on the mod portal if you are interested.

[ 2020-02-28 10:00:39 CET ] [ Original post ]

Features

• Added Rocket rush scenario. more

Changes

• Changed Team production team joining system and cleaned up the map sets.
• Changed Wave defense bounty system and refactored unit spawning logic.
• Changed fire sticker to deal damage only once per 10 ticks.

Graphics

• Added big scorch mark which is now used by atomic rocket and nuclear reactor meltdown.

Bugfixes

• Fixed that fluid energy source effectivity was not shown in the tooltip. more
• Fixed that the default column ordering in the update-mods GUI didn't match the visual ordering. more
• Fixed that train could accelerate for one tick into wrong direction when train stop is disabled. more
• Fixed that minimap would not allow setting temporary train stop when train would have to change movement direction. more
• Fixed damage value in sticker tooltip was 60 times too small.
• Fixed icons with overlays were drawn incorrectly when used in rich text. more
• Fixed PvP error when DEFCON was active alongside normal labs. more
• Fixed that modded recipes with no products or no ingredients still showed those sections in the recipe tooltip. more
• Fixed that modded burner generator equipment didn't show pollution in the tooltip. more
• Fixed teleporting or changing the force of an entity with a control behavior that was connected to the logistic network. more
• Reverted optimisation that caused inserters picking up items from belts to be slower.

Modding

• Added support to filter on-damaged trigger effects through the trigger prototype definition.
• Added secondary_draw_order property to simple-entity prototypes.
• Added StickerPrototype::damage_interval, defaults to 1.

Gui

• Updated the window of creating/editing blueprint.

Scripting

• Added LuaTile::surface read.
• Added event filtering support to on_sector_scanned and on_entity_cloned.
• Added "original-damage-amount", "final-damage-amount" and "damage-type" filters to the on_entity_damaged event filters.
• Added LuaGameScript::is_valid_sprite_path().
• Removed the required argument from LuaEnity::to_be_deconstructed() because it did nothing.

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

[ 2020-02-25 12:39:58 CET ] [ Original post ]

Read this post on our website.

Team production changes

Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love. So after 4 years of accruing wisdom, I started making some general improvements.

Choose your teams

I think this is one of the main suggestions people had for team production. The scenario just shuffled the players and assigned people randomly, and you could end up all alone playing against your two best friends. Now I believe anybodies first choice would be to add a GUI to handle this. I will go on about GUIs later, but short story is, I didn't want to add a GUI. They add a lot of complexity, and my development mood these days is to keep things simple and small in scope. So I added little colored launchpads!
I think it is quite intuitive, you will instantly be able to see which team has which players, you will see what map position you will be in when the round starts, etc. Another benefit is that if you want to spectate, you can simply just not walk onto a launchpad, and use the map view to see what's going on (before, there was a button you would press to join the spectators team). The idea to use tinted concrete came from Albert, as originally it was just a tinted square rendering over the tiles (which didn't need any new prototypes defined) and it looked very janky. A consequence of this is that we now have colored concrete tiles in the game. There is no item available to place color concrete, but players will be able to access them in the editor mode.

General cleanup

This is the not so glamorous but still important polishing we need to make. Things such as fixing GUI styles, switching the loaders to stack inserters, making sure the map sets are making sense, etc. I also spent some time making the challenges more predictable, the logic before could give a lot of variance to the difficulty of the production objectives, and make things hard to balance. One problem I see in the future, is that the production challenges are 'hardcoded' for the base game. If I find some more time later I might work on a system to more procedurally create the objectives.

Wave defense changes

I was inspired by some comments a few weeks ago, saying that the Wave defense scenario was a bit of a pushover, especially with a couple of players working together. So I thought an easy adjustment would be to scale the 'wave power' somehow to the number of players. It was a simple change and we released it with 0.18.4 a few weeks ago. Jobs a good'un right? Well after play-testing it more extensively over the weekend, I realised it wasn't quite so simple...

More biters; more money

A major problem is that the players earn bounty for every biter that it killed. So if I make the waves bigger, then the players earn so much more money, and can buy so many more upgrades, that the scenario is even less challenging than before. The solution to this is quite abrupt, I just remove the bounty from the units, and this makes the design work better in my eyes:

• Bounty is only earned from spawners and worms.
• You can't sit inside your walls and earn money for upgrades; You need to actively go out of your base to earn upgrades.
• Players could set up infinite money farms by spawn camping the biters; This is no longer possible.

A consequence of this is that the upgrade prices and bounties needed to be rebalanced, which was actually a little bit easier since the number of spawners and worms is way more predictable.

Predictable attack locations

I also noticed that biters spawning would always hit the base defences at the same places very reliably. This is great if you are the player and only want to invest 1 flamethrower turret to repel all the attacks. https://cdn.factorio.com/assets/img/blog/fff-335-waves-before.mp4 So I added an extra command to the biters orders, that tells them to first go to a random point within the base, and from there go and attack the silo. This means that the positions where biters intersect your defences will be less predictable. https://cdn.factorio.com/assets/img/blog/fff-335-waves-after.mp4

More wave power; same wave size

Another observation I made is that even though I increased the 'wave power', the number of biters was still being limited by the number of nearby spawners. This was due in part to a mix of me being clever with optimization and wanting to not make the groups too big. In short the spawning would work something like this:

• Determine the wave power, bases on factors such as wave number, player count, difficulty.
• Determine how many spawners we spawn from, something between 4 and 15 typically.
• For each spawner, pick a random number of biters to spawn, between 20 and 30.
• Spawn the biters, and remove their 'cost' from the wave power. If we have no more wave power we stop.
• Once we have gone through all spawners, we are done (even if there is a lot of wave power left).

The problem here, is that we are constrained by the spawner count and unit count. Even if wave power was 10x higher, the logic could still just decide to spawn 50 small biters from 4 bases and call it done. Well okay I was a clever boy, and now lets remove all this complicated logic and keep it simple:

• Determine the wave power, bases on factors such as wave number, player count, difficulty.
• Determine how many spawners we spawn from, something between 5 and 20 typically.
• Divide the wave power by how many spawners we have.
• Keep spawning units at the spawners until all the wave power is used up.

This way, if we have 10x more wave power, no matter how many bases we spawn from, the wave will be 10x more powerful.

Infinite map option

I had a few requests for this, and it wasn't so hard to add. If enabled, the Wave defense map will be infinite instead of an island, and the only way to win will be to launch a rocket.

New scenario - Rocket rush

Adding a new scenario at this point of development is a surprise to be sure, but hopefully a welcome one. The concept for this is that you are on the 'space platform', and you are preparing to land on the surface, and once on the planet you need to launch a rocket as fast as possible. You start with all technologies unlocked, and some money to buy starting equipment.
Once you and your friends are prepped, you head down to the launchpad to start.
And then that is pretty much it, you get teleported to the surface, and play the game as usual. We can afford to add this scenario because it is so small in scope and so simple, and it took less time to make this new scenario from scratch than updating what we already have. Maybe it is not the best thing since sliced bread, but I am hoping that my small investment of a few weekends will at least give some players a few more hours of enjoyment. I would be interested in adding more 'small scope simple scenarios' in the coming months, if we have enough time. If you have ideas that might fit this definition, please let me know (but no promises).

Damage effect filtering

It is the classic problem, we optimise a system so its 5x faster, and then we use it 5x more. This time it is the case of flamethrowers and particles again. With 0.18 we added the damage effects for entities, and we generally like the way it works. However when this is combined with flamethrowers, we encounter some problems. https://cdn.factorio.com/assets/img/blog/fff-335-biter-damage.mp4 First you might say, "It doesn't make sense that a burning biter will spurt blood", and I would agree. Second you might say "That is a lot of blood", and I would agree with that too. In fact it is 1,416 damage events worth of blood particles. The way flamethrowers currently work means they do a small amount of damage very frequently, in contrast to say a grenade which does a high amount of damage in a single action. Even with all the particle optimizations, the performance would once again suffer due to the sheer quantity of particles being created. So Rseding has gone ahead and killed 2/3 birds with 1 stone, and added damage type filtering to the entity damaged and entity died trigger effects. This means for our immediate problem of bloody burning biters, we can just filter the damage effect to not occur if the damage type is fire, which solves it perfectly. In the longer term the benefits are even greater, as we now have the capability to for instance, make custom dying effects for being run over, or damaged by laser, or dying by poison etc. Well that solves half the problem, but still, 1,400 damage events is still going to cause problems in other cases. A big part of this comes from the 'fire sticker', which applies damage every single tick. Since it lives for 30 seconds, that is 1,800 damage events. So a nice easy change posila has done, is to add a 'damage interval' to the sticker, so that damage is only applied every n ticks. For now we have set the fire sticker to do 10x the damage, but only every 10 ticks, reducing the number of total events for the sticker from 1,800 to 180, a lot more reasonable. (Note, changing this frequency can affect the damage balancing, as the resistances system in Factorio has an absolute reduction and a percentage reduction. In our case, the entities affected by the fire sticker had no absolute fire resistance, so the result is the same.) All the changes you see here should be released soon, we are in a rhythm now of doing 1 release every week (typically on a Tuesday), and everything you see here is pretty much done (but anything can change!).

[ 2020-02-21 14:54:27 CET ] [ Original post ]

Graphics

• New visuals for poison capsule effect.
• New dying effect and remnants for flying robots.

Sounds

• Entity destroyed alert - Sound softened and lowered in volume.
• Weapon sounds (WIP) - new Pistol, Submachine gun, Gun turret, Laser turret.
• Logistic chests open sound (WIP).
• Poison capsule cloud (WIP).

Bugfixes

• Fixed that reordering heat buffers during the same tick a different heat buffer was built would leave the heat buffer state corrupted. more
• Fixed that entity sounds with probabilities would loop forever once they started playing. more
• Fixed rocket silo tooltip did not include contents of the rocket result inventory. more
• Fixed that styles were applied to wrong slot in a filtered train view. more
• Fixed that server authentication would fail if both the token and username and password were provided. more
• Fixed that changing inserter pickup/dropoff through mods didn't work correctly. more
• Fixed that combat robots had their fire resistance overwritten. more
• Fixed that rolling stocks were not pulled correctly when train was moving through curved rails. more
• Fixed that LuaEntityPrototype::burner_prototype didn't work for the burner-generator entity type. more
• Fixed janky construction robot flying animation during repair work. more

Scripting

• Added optional LuaItemStack::build_blueprint raise_built.
• Added LuaInventory::find_empty_stack(), count_empty_stacks(), and get_insertable_count().
• Added LuaEntityPrototype::heat_energy_source_prototype, fluid_energy_source_prototype, and void_energy_source_prototype read.
• Added LuaGameScript::encode_string() and decode_string().
• Added on_player_set_quick_bar_slot.
• Added on_pre_player_toggled_map_editor.
• Removed LuaPlayer::name write. more
• Removed core lualib util.encode() and util.decode().

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

[ 2020-02-18 16:16:31 CET ] [ Original post ]

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.

[ 2020-02-14 17:07:37 CET ] [ Original post ]

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.

[ 2020-02-12 15:53:36 CET ] [ Original post ]

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.

[ 2020-02-07 17:17:17 CET ] [ Original post ]

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.

[ 2020-02-06 15:22:32 CET ] [ Original post ]

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 :).

KoS 500 player MP server

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.

New 0.18 Any% speedrun record

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=JA9ccg5tIlY;full][/previewyoutube]

The Biggest and most Useless Rail Network Ever...

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.

[ 2020-01-31 14:12:29 CET ] [ Original post ]

Graphics

• Improved map colors by adding specific colors to beacons, pipes, heat pipes, roboports and steam engines.

Sounds

• New or updated sound effects include:
• Pump, pumpjack, boiler, heat pipe, offshore pump, substation.
• Logistic and construction robots, roboport.
• Train.
• Rocket takeoff sequence.
• Car and tank (pitch scaling adjusted to sound more natural).
• All transport belts, splitters, inserters, assembling machines, power switch.
• Added some UI sounds that were missing.
• Shotgun, small explosions.
• Entity destroyed alert.
• New sound tech includes:
• Listener position set to centre of screen by default. This will allow you to hear what you see even when in map mode.
• The ability to turn off the Doppler effect in Lua, used for the Substation so far.
• environment-audible-distance setting increased to 30 so you can hear entities a bit further away.
• zoom-volume-coefficient changed so you can hear more of the world when you zoom out. This will help with combat and give a greater sense of the overall factory.

Bugfixes

• Fixed that pressing escape in some log-in screens lead to blank screen or incorrect states. more
• Fixed enemy walls should not render as connected to ghosts, since enemy ghosts are not visible. more
• Fixed undo on self-looped combinator ghosts not restoring wires. more
• Fixed achievement cards not showing description when descriptions are turned off in interface settings.
• Fixed that inserters from 0.17 save files could end up teleporting items into/from trains. more
• Fixed that the sync mods with save GUI wouldn't size correctly. more
• Fixed that thrown capsules could end up broken forever if thrown at exactly the right tick. more
• Fixed crash when using "create-entity" trigger effect item to create an artillery flare. more
• Fixed map view night LUT. more
• Fixed a crash that would sometimes happen when a biter, who was in previous versions of the game aggroed by a player in a car or tank, was aggroed again. more
• Fixed crash when joining a game through Steam without having previously logged in.

Modding

• Migrating loaders between loader and loader-1x1 will maintain the loader type (input/output). more

Scripting

• Added LuaSurface::create_particle().
• Added LuaEntityPrototype::inserter_pickup_position and inserter_drop_position read.

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

[ 2020-01-28 15:28:35 CET ] [ Original post ]

Read this post on our website

0.18.0 release (Klonan)

Early this week we pushed the deploy button on 0.18.0. This was quite a surprise to many of our players, as more typically the time between major releases and the scope of the release is greater. However this isn't like the old days, we are trying to keep the size of releases as small as possible (FFF-314). What this means, is that what is currently in 0.18 is only really a small part of the work needed to be done on 0.18, and releases in the coming months will continue finishing off our 0.18 task list. Once everything on the 0.18 list is completed and the time is right, we will turn 0.18 into 1.0. What we have accomplished with 0.18.0:

• GUI
  • Main menu redesign
• GFX
  • Water animation
  • Tree animation
  • Color correction (LUTs)
  • New explosions and damage effects
• Other
  • Optimizations
  • New Particle system
  • First work on new sound design
  • Steam login

What we have left to do in 0.18:

• GUI
  • Character GUI
  • Blueprint library
  • Statistics GUIs (production, electric network stats, etc.)
  • Entity GUIs (Inserter, Assembling machine, chests, etc.)
  • Main screen GUIs (Chat, minimap, etc.)
  • Many more...
• GFX
  • Offshore pump redesign
  • Assembling machine redesign
  • Beacon redesign
  • High-res icons
  • Final tweaks and polish
• Other
  • Further sound design improvements
  • Mini-tutorials
  • Replace NPE with old tutorial
  • Final game balancing and tweaks
  • Finalised locale and proofreading

With this in mind, it wouldn't make sense to mark 0.18 stable before most of the above is finished. We made 0.18 a major version because it will break mods with all the changes we are making, and while initially it hasn't broken that much, many things to come will have a bigger impact, such as the Character GUI.

Character GUI?

Initially we planned for the Character GUI to be in the first 0.18 release. However the task was proving quite difficult the way it was written, and when the release date came it was not ready, so we delayed the entire 0.18.0 release (twice). After a tough and thorough review, we decided to discard most of the work, and start fresh with a different team member. With programming, you've got to know when to hold 'em, know when to fold 'em. With this change, we decided to release 0.18 without the Character GUI, the alternative was an additional 4-6 week delay, which with only 8 months left, is a big chunk of time. We also don't want to get back into the old habit of always delaying the release for another and another reason, and the things we present in Friday Facts not being seen in-game for months and months. After this decision, Dominik, who was working on the Character GUI, decided to leave the Factorio team.

Campaign cancelled (V453000)

In the recent FFF-329 we have mentioned two different approaches to the campaign. In this FFF, we are announcing that the campaign has been cancelled, and Ill try to explain why. After the Tutorial/NPE was cancelled, I realized several things and it made me re-evaluate what the campaign is trying to be, asking questions like:

• Is the campaign meant to be 'The Way' how to play the game or just 'extra content'?
• Should the campaign try to mimic Freeplay?
• Is losing progress and starting from scratch that much of a problem?
• ...

In my mind, if we would be trying to create 'The Way' how Factorio is intended to be played, it would make sense to try to stay very close to how Freeplay works, since that has been 'The Way' for many years now. However trying to mimic Freeplay inherently means it's never going to be identical to Freeplay, while certainly adding some new problems (and hopefully benefits). Trying to be similar to Freeplay and create a representation of how Factorio 'should be played' was the mindset behind the work-in-progress expanding campaign. The main benefit compared to Freeplay would be that the content is segmented into smaller chunks (which is already kind of the case due to the science pack production/technology progression - the player can't build everything from the start). However, having a short-term quest, being in a limited area of the map, interacting with existing factory ruins that prevent the player from going to the next area, etc. brings a lot of unexpected problems. It was just not fun to play in comparison. With that, the Freeplay with all its freedom will probably always be the best way how Factorio is experienced. It would make a lot of sense (to me) to rather strive to create a set of smaller scenarios as side content to give a fresh experience after 2,000 hours of Freeplay. To extend Factorio with separate scenarios, instead of trying to re-invent Factorio with the expanding campaign. Being side content, I believe it'd be much more acceptable if progress is lost between levels if it creates fresh gameplay or an interesting challenge. The reason we chose the expanding map concept was to never force the player to lose progress and rebuild their base. If this restriction is lifted, we could split the scenarios over many levels. Over the Christmas break, I tried to recycle the work-in-progress expanding map into a set of separate levels, and we even implemented a playable but very crude version of them in the first week of January. We sat down last week to reconsider what to do with the campaign out of the two options from FFF-329. The expanding campaign felt too risky due to all its problems, and we were not sure enough about it. The separate levels would be a safer option, but if they are not the main way to play the game, then they are not as important as the core of the game for the 1.0 release. It is still possible we will add a campaign after the 1.0 launch, but for now we believe that abandoning the idea of a campaign gives us the focus we will need on the core of the game for the upcoming months.

Trains Pathfinder changes (boskid)

Today I would like to talk about changes in the Train Pathfinder I made for 0.18. They are subtle changes to fix weird corner cases, but first a short glossary:

• Rail - a single entity over which trains can ride. The basic unit of building.
• Segment - a series of rails that are not split in between by junctions, signals or stations. The basic unit for pathfinder.
• Block - a group of segments that are colliding or connected without signals in between. The basic unit for train reservations.

in 0.17 and prior, the pathfinder used classic Dijkstra to find the path with the smallest penalty. The nodes are related to segments with extra information about travel direction. Edges are related to segment connections (transitions).

Issue 1: the last segment distance is not counted into penalty

This was the issue that made me look into the pathfinder code. Train stops are always at the end of a segment. Segments can have at most 2 train stops, one for each direction of travel. Any more is not possible, since the train stop inside would split the segment into 2. This means that a train entering the last segment on its path, must travel the whole distance of it to reach its destination. As it was implemented, the total cost on nodes was computed as cost of all previous segments and transitions. That means the node with the requested train stop would be picked from a priority queue before the cost of the last segment distance was added. Since the node has the requested train stop on its end, the path would be returned even if there are other nodes with a higher current cost but would be better since the cost of the last segment would be lower. The cost of the current segment would be added to the new nodes during expansion but it was already too late - the path was returned.
0.17 - Pathfinder chooses the bottom path which is longer The fix was quite simple: include the node's segment length into the node's total cost from the start. This changed the node expansion code as it was not adding the cost of the current node's segment, but the next node's segment. This would lead to cases where the first segment distance would not be counted, so I added code that when creating starting nodes, creates them with the penalty of the whole starting segment.
0.18 - Fixed Pathfinder chooses upper path that is shorter

Issue 2: the opposite station in the last segment is not counted into the penalty

The second issue is also related to the last segment and has a similar explanation as the issue above. The cost of the train stop in the current segment was added only when expanding node to the next segments.
0.17 - The pathfinder chooses the bottom path because it does not contain the penalty of the opposite station The simple fix of shifting the train stop penalty by 1 segment (when expanding, add the cost of the train stops to the next segment, not the current segment) and including both train stops inside the start segment fixed the issue (this is not the final solution as it will be explained in issue 5).
0.18 - The fixed pathfinder chooses the upper path that is shorter. Both paths have a penalty of 1 station.

Issue 3: the first segment distance would not consider train position

Now after the fix for issue 1 I noticed that adding the penalty of the whole starting segment has a flaw - if a train can go in both directions and both train ends are in the same segment, the cost of the first segment would be same in both directions and would cancel out.
0.17 - The pathfinder chooses to go left. Path to the right has a cost higher by 2. The fix here was simple: since the pathfinder is only given the start rail in the first segment, it has to go by all the rails in a given direction to find the end rail in a given segment. I have added the distance measurement during that search and used it as the initial cost. That way the position of train will affect the initial cost when looking at paths for both directions.
0.18 - the fixed pathfinder chooses to go to the right. The train position is considered.

Issue 4: a single segment path had priority over multi-segment paths

Now that issue 3 was fixed, there happened to be extra code to handle single segment paths. It covers weird cases such as cyclic segment, or station in the same segment. This code is computing the path cost based on rails (not segments) and if it finds any path, it will choose the path of lowest cost and skip the main pathfinder logic for multi-segment paths.
0.17 - The pathfinder chooses the single segment path. The solution for this - if there exists a single segment path, create marker node with cost of shortest single segment path and throw it into pathfinder priority queue. If this single segment path is truly the shortest, then this marker node will be picked up during expansion meaning all the multi-segment paths have a higher cost. If there would be a shorter multi-segment path, this marker node will not be picked up in time and so will be ignored.
0.18 - The fixed pathfinder chooses the multi-segment path because it has a lower cost.

Issue 5: the opposite station in the first segment was added into the penalty

After the fix for issue 2, every segment on the path with train stops would add the penalty of the train stops, not counting if it was on an entrance or exit of the segment. This means that a double-sided train for which one end is inside the segment with a train stop that is under the train, would still consider that train stop in the penalty.
0.17 - The pathfinder chooses the left path since the right path has the penalty of the train stop Based on this, I decided to discard the penalty of opposite train stops in the first segment. Doing performance measurements here showed another issue: the fix for issue 2 was flawed. The penalty of the goal train stop in the last segment should not be added, because this forced the pathfinder to over-expand nodes up to the train stop cost looking for other paths that maybe would not have that last station penalty (when in fact, it was unavoidable). So now I saw: the opposite train stop in the first segment and the goal train stop in the last segment must not add a penalty. This gave the final solution for the train stop penalty: when expanding a node, the exit train stop in the current segment adds a penalty and opposite train stop in the next segment entrance adds a penalty.
0.18 - The fixed pathfinder chooses the right path. Train stop under the train is not counted.

Issue 6: the block distance from the start was not updated properly

This is quite subtle issue. It is related to this penalty rule: "When the rail block is occupied by a train -> Add a penalty of 2 * length of the block divided by block distance from the start, so the far away occupied paths don't matter much." This means that looking for path, not only the cost from the start is counted, but also the number of blocks from the start - every time a node expands to another segment that is from a different block than the previous node's segment, increase the total block count from start by 1. That was working fine as long node expansion would create a new node. In the case of updating a node, the total block count was not updated the leaving old value in the node. That means the updated node would have the cost of new, lower cost path, but would have the block distance from the start of the previous path.
0.17 - The pathfinder chooses the bottom path because blockDistanceFromStart is not properly updated in the upper contraption. In this contraption, the issue happens in the upper part. The segment under the upper middle locomotive is expanded first when going from the straight segment on its left - it was of lower cost. Now this segment has the cost of the straight path and the block distance from start of 1, since there was only 1 transition to a different block. There was also the penalty of the block being occupied by another train. When expansion goes through the upper siderail, it hits 4 rail signals and so the block distance from start is increased up to 4. This path has a higher cost up until the left rail signal near the upper middle locomotive. Here, however, the cost of the block occupied by another train is lower since we are entering the 5th block from start when going through the upper path. The side-rail path is chosen to update the node cost related to the segment with the upper middle locomotive, but the block distance from start was not updated. Because of this, the penalty on the next rail signal that goes to another occupied block, was equal to the last segment distance divided by 2 instead of 6. This difference would make the path through the bottom contraption of lower cost since the straight path here is cut and the node for the segment under the middle locomotive is created with the proper block distance from the start. The fix was simple: when changing the cost from the start on an existing node, also change the block distance from start.
0.18 - Fixed pathfinder chooses upper path

Issue 7: repathing would clear a train's counter of ticks waiting on signal.

This is not exactly a pathfinder issue but it lead to trains being stuck. If a train is waiting on a signal, it will repath periodicaly to find another possible path that may now be unblocked. The repath however clears the counter of how long the train is waiting on the signal. Periodic repath logic was aware of this so it would restore the previous waiting on signal tick counter when the train entered arriving-to-signal state. However some fix ago changed train behavior, and the train no longer goes through the arriving-to-signal state and so the tick counter was cleared. This broke the following rule: "When the path includes a train currently waiting at a rail signal -> Add a penalty of 100 + 0.1 for every tick the train has already waited."
0.17 - The right train is stuck because the time-dependent penalty of the left train is reset every time the left train repaths. Universal fix here: clear this counter only if the train changes state to anything other than waiting-on-signal.
0.18 - The fixed ticks waiting on signal logic, after 3 repaths the penalty of left train increases to a point where right train chooses the long path.

Train Pathfinder optimisation - priority queue

In the heart of the pathfinder there is a priority queue that collects open nodes. As it was implemented up until now, the priority queue was based on a double-linked list. Finding the node with the lowest cost (highest priority) was fast (constant), but inserting new nodes or updating existing nodes would be, in worst case, linear (O(n)). After a quick prototyping phase, I decided to implement a binary heap with min-property over array. This change alone gave around a 20% speedup to the pathfinder.

Train Pathfinder optimisation - heuristic (conversion from Dijkstra to A*)

The second optimisation applied was the addition of a heuristic function that gives the minimum cost to any end. This means that node expansion is now guided into the goal by the heuristic function, and so less nodes should be required to visit before finding the goal. This gave another performance increase. The rough guess as to impact of the train pathfinder changes, is that its about 2x faster, and should have fewer weird edge-cases. As always, lets us know what you think on our forum.

[ 2020-01-24 14:24:16 CET ] [ Original post ]

Changes

• Train stop at train's starting segment exit is no longer counted into penalty. more
• Inventory transfers mini-tutorial has been updated to feature the quickbar.
• Split the map editor sub-menu into more options so it's more clear when scenarios are copied and when they are edited directly.

Bugfixes

• Fixed replay gui covering tooltips. more
• Fixed tooltips in statistics window not showing force modifiers. more
• Fixed electric mining drill was missing dying explosion. more
• Fixed when using OpenGL backed turret range overlay was rendered incorrectly when zoomed in. more
• Fixed a crash when using script.get_event_order during control.lua init. more
• Fixed that LuaForce::reset_technology_effects() could change the enabled/visible when disabled state. more
• Fixed wrong lua docs about what event(s) could be filtered. more
• Fixed a wrong error message related to multiplayer and migration scripts. more
• Fixed crash when rail with temporary train stop is removed. more
• Fixed crash if you attempted to ping a train wagon immediately after placing it on a multiplayer server with high latency. more
• Fixed that clicking the drop-down widget in the map editor script section would stop the mouse from working. more
• Fixed nightvision effect was applied to zoomed-to-world view sometimes. more
• Fixed that enemies would attack rails. more

Modding

• Changed default value of LoaderPrototype::structure_render_layer from "transport-belt-circuit-connector" to "object", in order to be consistent with other on-belt structure sprites. more

Scripting

• Added LuaEntity::get_damage_to_be_taken().
• Added LuaSurface::brightness_visual_weights to add back ability to control darkness of the night runtime per-surface. more

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

[ 2020-01-23 14:01:30 CET ] [ Original post ]

Features

• Steam users can now log in automatically through Steam without needing their Factorio account password.
• Steam users without a Factorio account can create one by providing only a username.
• Reworked main menu structure.
• Added a "Continue" button which quickly loads the latest save game.
• Added a "New Game" GUI that shows all the ways to play the game
• Added a setting to the map editor to show/hide the extra entity settings.
• Added a map editor GUI to edit force data modifiers.
• Added a PvP team option to create a moat around the starting area.

Graphics

• Added animation to water.
• Added animation to trees.
• Added LUTs and color corrected the game sprites.
• Added sliders to the graphics settings to adjust brightness, contrast, and saturation.
• Added on damaged effects for most entities.
• Added specific dying explosions for most entities.

Sounds

• New or updated sound effects include:
• Nuclear reactor, chemical plant, furnace, fire, burner mining drill.
• Tank.
• Mining by hand, chopping wood
• Roboport door, Combat robots
• Player footsteps.
• Biter and Spitter footsteps.
• Worm breathing, Spitters and Biters, idling and attacking.
• New sound features include:
• The ability to fade out sounds instead of a sudden stop, e.g. for the furnace.
• Varying the pitch of sounds to a min/max level, to add more variety.
• A 'Random, no repeat' feature to reduce repetition, especially on sounds that happen frequently, such as player steps.
• The sound for the game has also been rebalanced to highlight certain sounds and make others fade into the distance.
• The default sound settings have also been updated to improve this mix.

Optimizations

• Optimized particle logic.
• Improved performance when side-loading transport belts.
• Improved performance of inserters interacting with assembling machines and furnaces.
• Improved performance of inserters when the circuit network turns them off.
• Improved performance of mining drills and inserters in general.
• Improved performance of burner entities.
• Improved performance polluting entities.
• Improved performance of smoke producing entities.
• Improved performance logistic and construction robot performance when they're flying towards their target.
• Improved performance of furnaces and assembling machines that use fluids.
• Improved heat pipe performance by 3x.
• Improved item request proxy performance by turning them off in 99%+ of the cases.
• Improved locomotive, cargo wagon, and fluid wagon performance by turning them off in 99%+ of the cases.
• Electric networks, fluids, and heat pipes are updated in parallel if you have enough cores.
• Improved script rendering performance for text and lines.
• Improved performance of rotated bounding boxes.

Bugfixes

• Fixed the recipe tooltip showing negative values for some complex recipes. more
• Fixed graphical glitch when GUI element with blurred background got out of bounds of the screen. more
• Fixed hard coded English string in NPE. more
• Fixed potential crash in NPE when Compilatron is pointing at something that gets deleted. more
• Fixed issue where sometimes you couldn't move to the second area in NPE. more
• Fixed issue where Compilatron would sometimes tell you to build more boilers when that was not the problem. more
• Fixed issue where Compilatron's speech bubbles could block you from interacting with the world behind him. more
• Fixed items with excessively long names squashing the count label in the recipe tooltips. more
• Fixed accumulator charge text in statistics bouncing around because of inconsistent number of digits. more
• Fixed train path finding penalty when there are 2 or more trains in block. more
• Fixed a crash when creating trains during the player moved event that was caused by the player getting ejected from a vehicle because the vehicle died. more
• Fixed a crash when removing mods that had custom GUI elements. more
• Fixed a crash when using Lua event filters when the thing to be filtered becomes invalid. more
• Fixed that some turret sounds could be heard on other surfaces. more
• Fixed that the tooltip for the generator would not show its efficiency correctly. more
• Fixed a crash related to building tiles in multiplayer with some mods. more
• Fixed that turrets would sometimes fail to attack things that are in range. more
• Fixed follower robot lifetime tooltip property not taking into account following_robots_lifetime_modifier. more
• Fixed cliffs sometimes getting marked for deconstruction when they shouldn't have been. more
• Fixed inconsistent rounding in the statistics window. more
• Fixed a desync when setting .active=false on beacons through script. more
• The map will be re-charted when the mod configuration changes. more
• Fixed inserters sometimes not being highlighted when selecting a large modded vehicle. more
• Fixed a crash when entity grid would destroy itself during update. more
• Fixed a crash with rich text tags and dynamic images. more
• Fixed setting the held stack of an inserter didn't update the inserter state correctly. more
• Fixed tooltip alignment in some specific cases. more
• Fixed a crash when lua removes pipe-to-ground between entity revive and deferred pipe connection fix. more
• Fixed a crash when setting infinity chest filters to legacy items. more
• Fixed that splitters could be set to have invalid bounding boxes that would lead to corrupt saves. more
• Fixed word wrapping of rich text containing tag that doesn't fit given width would duplicate the tag on multiple lines. more
• Fixed if migrating old achievement data to Steam Cloud failed, the old file would not be deleted resulting in the same error on every startup. more
• Fixed train pathfinding penalty for circuit network closed rail signal was not applied in some cases. more
• Fixed a crash when mods would define construction robots without some sprites. more
• Fixed that trying to do 0 damage would still trigger the entity-damaged event. more
• Fixed a save corruption issue related to modded loaders with different belt_distance values. more
• Fixed that train would forget amount of ticks waiting at signal when doing repath. more
• Fixed that train pathfinder was not counting penalty of last segment length in path cost. more
• Fixed PvP error on configuration changed. more
• Fixed pump tooltip showing double pumped amount when pumping to fluid wagon. more
• Fixed manual ghost revive of a loader in unload mode would not work in visually matching direction. more
• Fixed calling LuaEntity::order_deconstruction() on item-request-proxy would corrupt the game state leading to crash. more
• Landfill can be placed over shallow water.
• Fixed that LuaEntity::color wouldn't accept "nil" to reset the color. more
• Fixed that train pathfinder was not counting penalty of opposite train stop at last segment.
• Fixed that train pathfinder was counting penalty of whole starting segment instead of only part in front of locomotive. more
• Fixed that train pathfinder would return single segment path even if there are shorter, multi segment ones. more
• Fixed technology screen not showing modifier tooltips when tooltip descriptions are disabled. more
• Fixed belt tooltips sometimes showing their speed in exponent format. more

Modding

• Added UnitPrototype::light.
• Removed the "particle" prototype type.
• Added the "optimized-particle" prototype type.
• Added the "burner-generator" prototype type.
• Removed GeneratorPrototype::burner.
• Added the "pass_through_mouse" option to speech bubble styles. This lets mouse interactions fall through to interact with the world behind.
• Added optional "radius_color" property to capsule prototype.
• Removed EntityPrototype::emissions_per_tick, it is replaced by emissions_per_second.
• Removed EnergySourcePrototype::emissions_per_second_per_watt and emissions, they are replaced by emissions_per_minute.
• Removed TilePrototype::ageing, it is replaced by pollution_absorption_per_second.
• Removed ItemPrototype::stackable, primary_place_result_item and can_be_mod_opened, they were replaced by ItemPrototypeFlags "not-stackable", "primary-place-result" and "mod-openable".
• Added "probability" to trigger items and trigger effect items.
• Added "script" trigger effect item. It will call the "on_script_trigger_effect" when triggered.
• Added AttackParameters::rotate_penalty and AttackParameters::health_penalty.
• Added generic support for rendering radius visualisations on entities through radius_visualisation_specification.
• Changed construction robots and logistic robots sprites to be optional.
• Changed the loader prototype type so it has a fixed belt_distance of 0.5.
• Added the prototype type "loader-1x1" that has a fixed belt_distance of 0.
• Changed render layer of belt structures (underground belt, splitter, circuit connector) to object layer. They now have special sorting logic, so they are not rendered over player or cars.
• Horizontal directions of splitter sprites were separated to two sprites (for purposes of the special sorting logic).
• Added AttackParameters::ammo_categories.
• Added optional artillery projectile property "rotatable".
• Scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game gui; "multiplayer-compatible" determines weather the scenario is shown for multiplayer games.
• Added "multiplayer-compatible" to description.json file of campaigns also.

Scripting

• Added on_unit_group_finished_gathering and on_build_base_arrived events.
• Added LuaRendering::bring_to_front().
• Changed LuaGameScript::particle_prototypes to reference the optimized-particle type.
• Added LuaGuiElement::scroll_to_item() function.
• Renamed LuaInventory::hasbar(), getbar() and setbar() to supports_bar(), get_bar() and set_bar().
• Added LuaEquipmentPrototype::attack_parameters read.
• Added on_script_trigger_effect event.
• Set lower limit of zoom parameter of LuaGameScript::take_screenshot to be 0.0315 (1 pixel per tile) instead of allowing any value greater than 0.
• Added LuaPlayer::get_infinity_inventory_filter(), set_infinity_inventory_filter() functions.
• Added LuaPlayer::remove_unfiltered_items, infinity_inventory_filters read/write.
• Added LuaSurface::get_entities_with_force().
• Added optional "dealer" parameter to LuaEntity::damage().
• Added "force" filters to the on_built_entity and on_robot_built_entity event filters.
• LuaSurface::min_brightness doesn't have any effect on rendering as brightness of night depends only on color LUT of night.

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

[ 2020-01-21 15:06:24 CET ] [ Original post ]

Join our community hosted Massive multiplayer test Find it in the Matching server with the name: Big Community Games Test. You can also connect directly with the address: bigcommunitygames.uk.to

[ 2020-01-19 17:59:15 CET ] [ Original post ]

Read this post on our website.

The main menu rework (Twinsen)

Up until I looked at the source code, I was always confused about the differences between "Start campaign", "New game" and "Scenarios". New game seems like the same thing as "Scenarios"->"Freeplay", but are there any differences? We then later added a few more bonus scenarios, but they are hidden in the scenarios menu, with no explanation about what each is, what to expect or if it works in multiplayer. I believe it's very important to communicate to new players information about the game's content. It's also important to show that freeplay is the intended way to play. So all this prompted me to rework the main menu a bit. I started with the structure. The structure always seemed odd to me, compared to what I'm used to from other games. Important options like "Load game" are lost among options that are never used (like "Replay game"). So I came up with a new structure. It looks like this:

• Continue
• Single player
  • New game
  • Load game
• Multiplayer
  • Host new game
  • Host saved game
  • Browse public games
  • Browse LAN games
  • Connect to address
• Map Editor
  • New scenario
  • Convert save
• Settings
  • ...
• Mods
• About

The first new thing to notice is the "Continue" button. Since "start the game and continue my last save" is probably the most common thing players will do, it makes sense that there is an option for this right at the top of the main menu. The button will contain the name of your latest save. Pressing it will immediately load the game and get you in game. Due to implementation complications, for now it only handles save games and it will NOT connect you to the last server you played on if your last play session was multiplayer, but I might implement that if it's highly requested. Next, everything was grouped into either Single player or Multiplayer. There are much fewer options, since "Replay game" was moved as a small button in "Load Game", and every way to start playing the game was moved to the new "New Game" GUI. The "New game" GUI shows all the ways to play the game. It also groups them nicely, places freeplay on top, shows a description and even a nice image. This GUI is used for new game, multiplayer hosting and map editor, thus simplifying the menu quite a bit.
For modders, scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game GUI; "multiplayer-compatible" determines whether the scenario is shown when trying to host multiplayer games. "multiplayer-compatible" was added to description.json file of campaigns also.

Steam log-in and "mini-accounts" (Twinsen)

While working on the main menu, another thing I changed quite a bit is how logging in is handled. With Sanqui's help, we did some small improvements, such as better error handling and error localization, but a more important feature is being able to log in using Steam only. I found it annoying that even though you bought the game on Steam, if you want to play online, you need to make yet another account, whose email and password you are probably going to forget. For the Steam version of the game, when you try to use any online feature, the game will try to authenticate using Steam.

• If you have an account and that account is linked to your Steam account, you will be automatically logged in without having to remember your password.
• If you don't have an account, the game will ask you to choose a username (your nickname in multiplayer games) and then log you in. No password or email or email confirmation required. We call these "mini-accounts"

"Mini-accounts" can be upgraded to normal accounts by going on the website, logging in using Steam, and then adding an email and password. They can be used for the non-steam version of the game. These changes are ready to be released, so you should see them as soon as we release 0.18, soon.

File Share Shenanigans (wheybags)

A few years back, we were using a collection of hard drives stuffed into a leftover workstation as an office shared drive. This drive had all sorts of stuff on it, from unfinished art assets, to a collection of pictures of developers in a wind tunnel, we had it all. The inevitable day came, and we ran out of space on the disks. A decision was made at the time, to buy some new, high density drives, and put them in a QNAP enclosure. This is basically a little computer, with 4 front mounted hard drive bays, and some special software for file shares and management. We figured this should be less hassle since its designed to be used by normal people. This was supposed to make our lives easier, as it should be an easy-to-use setup for normal people. It even had a friendly GUI with a little clippy guy!
"It looks like you're trying to setup replicated live snapshots"

Shenanigan #1

After only three months, unfortunately the little guy died. Doesnt power on, just dead. Of course, we start the return process, but its going to take about a month to get the replacement sorted, during which time we will be without access to our files. So, we did what any reasonable capitalists would do, and we bought our way out of the problem once again, by just buying another QNAP NAS to use while we waited. When the warranty replacement arrived, we would use it as a backup target. Side note: we couldnt actually read our data off the drives we took out of the broken QNAP. The QNAP OS is just Linux with a custom GUI on top, so youd expect we could get our files by plugging them into another Linux machine, but no! QNAP have customised their Linux kernel in a way that makes it impossible to read on a normal install (for those interested, they modified LVM to add some more efficient form of snapshotting, from what I can tell). Mmm... delicious vendor lock-in!

Shenanagain!

All was well with the world of large file storage in Wube software, until one day disaster struck again! After a solid 14 months this time, the replacement NAS that we had bought also died. At this point, we begin to question our decisions.

ZFS to the rescue

With our original setup, we had a normal PC running the ZFS filesystem. We have decided to just return to this approach. The final lesson is, that sometimes the "buy the solution" easier option is not actually easier at all. Sometimes its just best to invest the time and effort to do it right yourself. If you're a technically inclined person who's not afraid of a command line, you should really check out ZFS. Despite some recent misinformed statements by highly influential figures, it is a really great filesystem with advanced features not really available in any other production quality filesystems, like snapshotting, checksumming, and live replication. Oh, and you should probably avoid QNAP NASes... As always, let us know what you think on our forum.

[ 2020-01-17 16:24:46 CET ] [ Original post ]

Read this post on our website.

Merch store open again (Klonan)

Our e-shop is now open again after taking a break over the holidays and new year. We have also restocked our new Factorio sew-on patches, so if you didn't manage to pick one up over the last weeks, now is your chance to order one.

Campaign reassessment (Abregado, V453000, Wheybags)

Learnings from the Introduction/NPE

After deciding to cancel the Introduction/NPE (Tutorial/Demo) we took some time to assess what we learnt. Here are just a few of the points that we took away from the experience:

• Players dislike being told that they must restart.
• Players (ironically) don't have regrets after they restart.
• It is valuable for new players (< 30 hours) to rebuild 1-3 times.
• Lowering player constraints increases design difficulty.
• People like Compilatron to be there.
• People don't like it when Compilatron does anything for them.

In addition to those, self-motivated discovery of new mechanics (FFF-327) is a more important part of Factorio than actually using the new mechanics. This means letting the player do things the hard way, and not rushing them to the realization that there is a better way. For example, veteran players know not to handcraft science packs for 30 minutes while standing still, but forcing a player to discover this by artificially not allowing them to handcraft, lessens the Factorio experience.

The Campaign Conundrum

While we were working on the Introduction/NPE we were also researching and designing what we wanted from a full featured Campaign. The game already had a Campaign which took the player up until Advanced circuits, but there was a feeling that we could do better. For the last year we have been working on and off to implement the design we came up with (from here on called the Expanding campaign), as talked about in FFF-245, FFF-257, FFF-291. More specifically the design was trying to remove the feeling of lost progression that comes from starting a new level and being forced to build a new factory from scratch. After the Introduction/NPE was cancelled, we took the holiday period to reassess if this goal was worth pursuing, and thought we should at least prototype some alternate solutions before committing completely to "the one design". The prototype came together very quickly this week because we were able to reuse a lot of work from the Expanding campaign prototype. Now we have two prototypes and wanted to present the ideas behind them:

1. The Expanding Campaign

This is the main prototype that we have been working on so far. A single map which starts small but grows after each objective is complete. This would emulate Freeplay gameplay in that the player can build very large bases and expand in the directions they want, but with quest objectives to steer the player towards building the rocket. Technology and progression are preserved perfectly, since we never ask the player to start again. As a result, the player can build a really big factory. This prototype focuses more on the long term problem solving that Freeplay requires, such as deciding where your next outpost will be. Main Problem: At the end of each 'chapter' the number of different situations the player could have gotten themselves into is near infinite. This makes it very difficult to predict the state the player is in, and construct an appropriate challenge. Clever objective and map design should be able to mitigate this issue.

2. The Separate level Campaign

Consisting of approximately five separate missions, each with an interesting starting condition. At the start of the level, all the technologies available in the last mission are pre-researched, and the player is given a new subset of the remaining technologies to be researched. Every level the player needs to build a new factory. They will have some starting items, and the gameplay is about short term problem solving. This would be very different from Freeplay and similar to what people expect from traditional campaign content. If the player fails, or wants to try a different strategy, they can restart the level and not lose a lot of progress. Main Problem: Players need to rebuild their factory each level, repeating things they have already done. This is especially problematic in a game like Factorio. We imagine that this issue can be mitigated by making the starting conditions interesting.

Conclusion

While these two prototypes have some large differences, there are many aspects they share:

• Freeplay will stay the same regardless of the choice here.
• No story.
• No exploration gameplay.
• Same tech tree as Freeplay.
• All content of Freeplay available at some point.
• Complex concepts (oil/logistics/trains) are broken down into smaller pieces.
• Almost identical quest structure.

These two approaches are actually very similar in their core quests, this is more of a decision on how we present the progression. Internally we are still discussing which approach is more appropriate for Factorio.

Community spotlight - 500 player 'speedrun' (Klonan)

Over the last weekend the Youtuber The Spiffing Brit hosted a server with the goal of completing a speedrun with 500 players online at the same time. There were 2 streams in total, one on Friday evening, and another on Sunday. Things went a lot more smoothly on Sunday, and we managed to reach a peak player count of 462. Spiff has edited down the stream from Sunday into a much shorter video, so those who could not attend can enjoy the spectacle. [previewyoutube=2hgvIhMkgKU;full][/previewyoutube] There will be some further attempts to set a new record soon, with some upgraded hardware. Just recently one of the organizers of the server on Sunday has confirmed the order of a i9-9900k with 10 gigabit networking. If you are interested in more info on the servers, you can join the discord here. As always, let us know what you think on our forum.

[ 2020-01-10 16:41:57 CET ] [ Original post ]

Read this post on our website. Hello, The office here in Prague is still 'closed' until next week, so not much is happening (so our team can rightfully rest). Things will get cracking again on Monday, and our first task is to get 0.18 done! For that reason, the FFF today is a little on the short side.

2019 recap

2019 was quite a 'typical' year for us. We released 0.17 early in the year, did some bug-fixing for about 6 months, and then we went back to development work. Saying that, we hit some major milestones this year:

• There was the all time concurrent player peak of over 22,500 with the 0.17 launch.
• The historically low count of bug reports on the forum.
• 2 million sales which we reached just last week.

You can see some correlations between this timeline and the commit frequency graph below.
Please note, the number of commits does not reflect the value and quality of an individual :). It seems like we are somewhat 'in-sync' with each other, which I suppose has good and bad effects. This year was also pretty good for the FFF blog itself. I would even say, this was the best year yet, with the highest quality and most well received posts we have ever produced. In terms of readership (on our website), here are the top 5 FFF posts of this year:

• Friday Facts #283 - Prepare to Launch
• Friday Facts #282 - 0.17 in sight
• Friday Facts #317 - New pathfinding algorithm
• Friday Facts #303 - Under 100 bugs (but still not stable)
• Friday Facts #278 - The new quickbar

No surprise that our 0.17 launch announcement ones are the most popular. And here is a graph showing the total website viewership statistics, because I also find them super interesting. You can really see the spikes every Friday :D. It is also funny, this year we started getting a lot of spam emails asking about posting 'sponsored articles' on our website. We would never accept any such proposals.
We really have a tough journey ahead of us this year, we are getting ready for the game to come out on September the 25th... Do or die, come what may. There are 9 months remaining now, and we have our work cut out. We'll keep you up to date on our progress, and we hope you will keep us up to date on your thoughts, at the usual place.

[ 2020-01-03 20:08:17 CET ] [ Original post ]

Read this post on our website.

2020 Vision (Albert, Klonan)

2020 is going to be quite an exciting year for us. We have our 1.0 date set to the 25th of September, and there is a lot of preparation to do. It is no doubt to any of us that we would not be able to have any success without the great community that has developed for the game over the last years, and the support of all our players and fans. As is almost tradition, Albert has prepared a commemorative postcard/wallpaper to celebrate the last FFF of the year.
Here's to a great year to come!

The local maximum - The tutorials swap (kovarex)

I had few months of "vacation" from work by playing world of warcraft classic and generally getting some distance to be able to help with the finishing of Factorio with some perspective and a clear head. Now I have returned from the lands of Azeroth, back to work with fresh mind to finish what is needed - hopefully. In this time, I was thinking about games in a bigger perspective. I have seen and admired videos related to game creation subject like A Love Letter to GOTHIC's Open World Design, Bethesda's game design is insulting, The decline of Gaming and the unbelievable story of the Fallout 76 fails that goes way further than I thought it can. And then I played our new tutorial again and realized what we did. We found something very close to a local maximum. To start from the beginning: The whole goal of the new tutorial introduced in 0.17 was to explain Factorio to the wider audience. To make sure, that even someone who wouldn't normally play the game would understand the concept and would automate. The motivation was partially due to the fear of someone playing the tutorial who just doesn't automate on their own. That someone would miss the idea of the game and would had completely wrong perception about the game. For example, that someone would play it only for 30 minutes and would think it is just about endless grinding and manual crafting, and they would never experience the automation midgame which is where the game starts to shine. This was a noble goal, but we didn't realize all the costs we had to pay for it. To make sure that the players know how to research and use assembling machines, and they get to experience that part of the game fast enough, we had to force them to do it early on. Firstly, this breaks the progression, which is one of the cornerstones of Factorio game design. The progression in the beginning is roughly this: Manual Mining -> Automated mining -> Automated logistics -> Automated production & science. The order of the progression is very important, as in every step you start doing something new that you had to do manually before, so you appreciate the upgrade. Also, when you are starting, you are exploring the game mechanics in the logical order and understand the motivation for those. This is in clear contradiction with forcing players to use assembling machines in the first 5 minutes of the game. Long story short, there was no way of just tweaking the new tutorials, the fundament on which it was built was wrong. Luckily, I wasn't the only one feeling that way. So I had to do the very hard thing, and telling the people that worked on it, that we are scrapping it, and in 0.18 we will switch to using the old tutorials again. They are way less polished with lower production value, but these things are much less important than the core gameplay mechanics as far as I can tell. We plan to tweak several things in the old tutorials, but the structure is planned to be kept the same. This is definitely a lesson for the future.

Two million sales (Klonan)

It has long been on the horizon, and the Christmas gift giving has given us that last push, for us to reach 2,000,000 sales. I would say its quite an achievement for a Indie game that has never been on sale. We first hit one million sales in May of 2017 (FFF-192), so its been about two and a half years to sell another 1,000,000 copies. I wonder how long till three million... Any bets? I find it quite interesting (and not surprising) to look at the proportion of the sales that come from each of our distribution channels. As you can expect, Steam accounts for the majority of all copies of the game sold.
What is also interesting, is that we had a lot more sales on our site before we launched on Steam. Either this is Steam cannibalising our website sales, or just everybody who wanted to buy it on our site did so before launching on Steam. Another data point for speculating on, is that 81.3% of people who purchased the game on our website, redeemed and activated their Steam key. Factoring that into the above numbers, about 96.7% of all players own the game on Steam. When we reached one million sales, we threw a party to celebrate. We're not going to do the same this with this milestone, but we are thinking of having a party to celebrate the 1.0 launch next year. Any news of that will of course be communicated in the usual way. As always, let us know what you think on our forum.

[ 2019-12-28 00:26:25 CET ] [ Original post ]

Read this post on our website.

More particle optimisations (Allaizn)

Rseding's recent optimisations of the particle system (FFF-322) made particles much more lightweight thanthey were before, but it still left particles as rather complex beasts. A quick summary of the possible actions a particle can make during it's update:

• Move their own position.
• Advance their animation to another frame.
• Land in water and apply a trigger.
• Apply another trigger with a certain frequency.
• Remove themselves from the game world once their life time ends.

What makes this complex is that triggers are general purpose systems that can do all kinds of things,including creating and destroying entities, fire, smoke and other particles as well as playing sounds or recursively applying even more triggers. In other words:applying a trigger is an "anything can happen" situation and thus totally unpredictable, which in turn makes optimisations extremely hard.

The particle emitter

The base game and most mods don't use particularly crazy triggers when creating particles - the goal is usually to just spawn in a bunch of small animated texturesand make them fly around on screen (which is somewhat ironically what is usually called "particle"). An idea for further optimisations of particles was hence to createa kind of "simple" particle, which couldn't apply all kinds of triggers to allow handling them in bulk, which is usually faster than handling them individually.This bulk handling would be done by a thing called a "particle emitter", whose whole job is to create, update, draw and finally destroy the simple particles it manages,with the idea being that a biter dying wouldn't have to spawn hundreds of particles, but only a single/few emitters. But this is not all: simple particles are not able to change any other game state, and would thus only get updated to maintain their own internal values - mainly theirposition and velocity. A small physics exercise later the idea was born to not update the particles at all - you can compute their current position from their startingone after all! Even better: if the particles aren't ever rendered, then there's no point in creating them in the first place, so there's no reason to do that until theemitter comes into draw distance - millions of biters dying in gigantic blood fountains offscreen would thus basically not matter at all for your frame and update time! https://cdn.factorio.com/assets/img/blog/fff-326-emitter.mp4 A visualisation of the emitter in action: the red box represents the actual screen. Particles managed by emitters outside the screen region simply don't exist at all. The particles themselves not being allowed to affect gamestate has another benefit: in a multiplayer game, each player only has to generate the particles theysee themselves, instead of those that are visible by anyone. This also suggests not using the emitter's update function, but it's draw one instead, which yields even morebenefits due to the draw function being called during the render prepare phase, which runs on as many threads as you allow it to have. However, all of this doesn't just magically work correctly, and there are edge cases that need handling. For example: what happens if an emitter is created offscreen andthen comes into view distance? What happens if you save and reload? What happens if you save and reload with a mod set that doesn't have the particles defined any more? It would be very odd to see your rocket silo explode in uncountable bits, see how they fly and crash into the ground - then save and reload and see everything again because the particle effect restarted. Handling these kinds of issues took some time and thankfully only increased the systems internal complexity marginally, allowing me to focus on expanding it's features.Currently, the following things are supported to be present on an emitter:

• Handling simple particles with individual random starting positions and velocities.
• Handling simple particle streams via normal and instant tails as shown in FFF-325.
• Handling simple particles with a smoke trail behind them (FFF-325 has some examples of this, but the effect already existed beforehand).
• Handling simple particles impacting the ground by potentially being replaced with a water splash when hitting water.

Particle emitters have two main restrictions:

• They only handle a single particle type (and technically associated smoke and water splashes). Making an assembling machine burst into metallic blobs and oil splashes would thus require two emitters.
• The particles managed by an emitter cannot fly too far away from the emitter (which itself will never move), because we need to know how far outside the draw distance to search for emitters that may want to render their particles.

https://cdn.factorio.com/assets/img/blog/fff-326-all-effects.mp4 A demo particle animation showing off all effects at once - all of these are managed by a single emitter.

Startup time - Data Cache (Rseding)

Game startup time (time to reach the main menu) is just as important to us as compile time (see FFF-206). With how frequently we compile and launch the game to test things, every extra bit of time spent waiting for the game to load is wasted time. There are 2 main parts of the Factorio startup process:

• Go over each enabled mod and collect the prototype data it defines/generates (the 'data stage').
• Load and process the sprites that the game needs to run.

https://cdn.factorio.com/assets/img/blog/fff-326-mod-loading.mp4 This is a familiar sight to those who play with a lot of mods. In the past we made an experimental setting which would cache the loading and processing of the sprites, so we never need to wait for it when nothing around them has changed. However, the game still had the process all of the 'data stage' every time the game would start. During normal development that wasn't really an issue - it would happen in a fraction of a second in most cases. However, as the game has grown, so has the amount of stuff that gets processed during the data stage. Additionally, for every mod enabled that has anything in this stage, the time would roughly double. Recently I started to wonder what it would take to make the same kind of caching system we have for the sprite loading for the data stage. Since mostly the results are the same between restarts, it would mean it didn't need to do most of the work - and should be faster. After working on it for about day I had a working prototype; but it wasn't actually any faster with just the base game. Not wanting to quit just yet I spent some time with the profiler and managed to find a few areas that I could optimize and reduced the time the caching logic was spending by about half. So, it finally had some benefit for the base game (although quite small). What I didn't expect was just how much of an improvement it was going to have for the modded case. What used to take 25 seconds in my testing took only 4 with the new cache setting enabled. The time savings gets even better as the number of enabled mods increases. The setting is still disabled by default because it's highly experimental, but if it ends up stable enough, we might turn it on by default.

Christmas mods (Klonan)

This is the last FFF before Christmas, so I thought we would celebrate some of the mods which aim to create some holiday spirit in the game.

Alien biomes

Alien biomes snowy terrain is just beautiful. In the map gen settings you can crank up the 'Cold Climates' option, so your whole world is just a cozy winter wonderland.

Holiday artillery

We must also remember to share the love to our biter friends, this mod will lets you deliver gifts far and wide, and embellishes the Artillery Gift delivery turret/wagon with a lovely red and green paint job.

Christmas tree

And of course, no winter factory is complete without a lovely Christmas tree. [previewyoutube=dljJijRJ6vQ;full][/previewyoutube] We wish you a merry Christmas, and as always, let us know what you think on our forum.

[ 2019-12-20 14:27:50 CET ] [ Original post ]

Read this post on our website. Hello, The year is wrapping up, and we have been hard at work finishing off some topics before we take our Christmas break. As you can imagine, releasing any new version of the game without a few weeks to do bugfixing wouldn't be wise, so you can rest easy this holiday period without the worry of a surprise 0.18 release.

New explosions and particles (Albert, Dom, Klonan)

One of the motivations behind the new optimized particle system (FFF-322) was to give our GFX team more flexibility to create special effects in the game, and specifically new explosions, without a major concern for any performance impact. With the new system as the foundation, we have been working on adding new features into the trigger items and particle trigger effects. One such feature was to have particles spawn a 'tail' behind them. This tail looked good for some particles, but not really for others, so then we added an option to spread that tail out in a natural way. This 'Instant tail' gives the particle effect a more explosive feel, with the particles really bursting out dramatically from the source, rather than in a somewhat comical single-file stream. https://cdn.factorio.com/assets/img/blog/fff-325-no-tail.mp4 https://cdn.factorio.com/assets/img/blog/fff-325-instant-tail.mp4 Instant tail off vs. Instant tail on. Albert spent some time adding new specific explosions for the enemies dying. This is still a work-in-progress, but so far we are happy with the initial results. https://cdn.factorio.com/assets/img/blog/fff-325-enemies.mp4 A nice feature we added back in 0.17 is the 'damaged_trigger_effect' on all entities. This lets each entity have a customised effect it creates whenever it is damaged. For instance with the biter, we made it create a blood particle hit effect, which gives the player some visual feedback about hurting the poor critter. https://cdn.factorio.com/assets/img/blog/fff-325-biter.mp4 Another bit of refinement we can make is setting the effect to 'hit' at a random position inside a specified box. In the case of the Roboport, which is quite a big entity, the effect is very noticeable. We can make the random offset box any size and position we like, it isn't tied to any other property of the entity, so we can precisely tweak the effect. https://cdn.factorio.com/assets/img/blog/fff-325-roboport.mp4 With these two in place, we can start to get a bit more specific. Dom has been hard at work the last few months creating specialized damaged effects with custom particles for every entity in the game. One example is the stone wall creating stone particles when damaged and when dying. https://cdn.factorio.com/assets/img/blog/fff-325-walls.mp4 We can also mix and match the different particles, to better reflect the composition of the entity in the resulting rubble. For instance the rail has a mix of stone, metal rail, and wood particles. https://cdn.factorio.com/assets/img/blog/fff-325-rails.mp4 These new effects and explosions are very much work-in-progress, and are already providing a much better feeling to the destruction in the game. Please let us know what you think, and if you have any suggestions to share. We are mindful of potential performance impacts a lot of particles could create (even with the new optimized system), so we are still looking into some even more performant ideas for the most brutal effects.

Steam review milestone (Klonan)

A Reddit post surprised us yesterday afternoon with the news that Factorio has reached 50,000 reviews on Steam (not including those who purchased the game from our website).
This is an absolutely huge number, and we never had any idea we would reach such a milestone when the game started as a small project just 7 years ago. Many thanks to all those who have reviewed the game. In regards to other milestones... we might have something else to announce in the weeks to come :) . As always, let us know what you think on our forum.

[ 2019-12-13 16:58:12 CET ] [ Original post ]

Read this post on our website,

Factorio logo patches (Jitka)

We would like to introduce our new fabric Factorio logo patches, which are now available at our e-shop. These sew-on embroidered patches are ideal for clothing, hats, backpacks, etc. The dimensions are 2.5 x 12 cm.
As we are uncertain how large the demand for these patches is going to be, we have only limited stock available at the moment. Please note that our online store ships only once a week every Wednesday, and it is highly possible that the orders placed now will not be delivered before the 25th or December, this applies especially for orders shipped outside of Europe.

Sound design (Ian)

I have been brought on to Factorio to finish the sound for the game for version 1.0. It was felt that a sound designer was needed to work at the Prague office to help implement the sounds and improve the audio vision. With a desire to make some quick wins, one of my first tasks was to add the sounds of the enemies footsteps, which we felt would really make them come alive. Unfortunately it transpired that the tech we wanted to use for this (each step being connected to the correct terrain, as per the player's footsteps), was going to be too expensive for the game in terms of CPU. After all, some of these creatures have 12 legs. Remembering a similar nightmare with giant spider's footsteps on a Harry Potter game years ago, I decided to make a simpler solution. So what we now do is to play a one shot sound for each cycle of the walk animation. First of all I started sourcing sounds from a library so I could rapidly prototype something. By taking some eggshells crackling sounds and adding them to a video of the walk animations, I managed to create something pretty good for the biters steps or movements. I plan to record some extra sounds for these later on, but for now these work fine. The sounds are different for each enemy however, the biters have more crackle and the spitters have more of a set of thuds. The bigger the enemy, the bigger the footsteps. These sounds should give you a greater feeling of immersion into their world, as you hear them scurrying towards you just before you see them. [previewyoutube=4EgG8Shq7Tk;full][/previewyoutube] Regarding the other enemy sounds, it seemed to me that the spitters and biters sounded too similar and this is something I wanted to change. If we can distinguish between the sounds made by the enemies, this adds to the variety and also the fun factor. The other sound designer Val has made new sounds for spitters idles, in order to bring out their squishiness and make them more disgusting. In the meantime I've been adding these sounds to the game, playtesting and tweaking them. For example, I chose better sounds for the enemies dying, in order to give clearer feedback to the player when making a kill. In other news, I've been busy working on mixing the whole game and improving sounds as I see fit, but I'll leave that for another time!

Animated trees. Of course (Albert)

In last week's FFF we presented animated water as a mini-series of "small" additions on the feeling of the environment. A lot of the feedback came saying that now the trees look pretty dead in comparison with water. We knew that in advance, and it seems like you were reading our minds because during the preparation of water we were working also on the trees. Today finally we can present this work finished. The always running sound of wind in the game feels much better with these new animations, plus the sounds to come. The shadows cast by the trees are also animated, and it makes the effect on top of the water somehow much better. https://cdn.factorio.com/assets/img/blog/fff-324-animated-trees.mp4 The idea of animating tree leaves is old as Factorio, but we never had the time due to obvious other priorities. One day Tom (wheybags) came with a very nice prototype, and I got very engaged -again- with the idea. Some time after, Ernestas made a new prototype based on different techniques. That was also really interesting. The subject was moving pretty solidly but it wasn't good enough. Next, Viktor (Allaizn), had the idea of using the normal maps of the trees instead of a generic noise to move the leafs, and the result of this experiment was fantastic. The rest will be explained by Allaizn himself.

Tree shader integration - you probably forgot something if it works on the first try (Allaizn)

My first "big" task was to integrate the shader Ernestas made into the game engine, which was exciting due to its looks, but also somewhat stressful considering I only rarely looked at that part of the game's code until then. The first step in doing this is usually to understand how the shader itself works, so allow me to give you a small explanation of what is happening. The GPU renders a texture pixel by pixel, and each pixel (roughly speaking) initially only knows where on the screen it is. A shader is then necessary to give it the extra information needed to arrive at the color it's ultimately supposed to have, where it acts a little bit like a "color by numbers" game - we ready a texture as the colors to use, and also pass in some numbers that tell it which part of the texture to use (their technical name is UV coordinates). When rendering sprites we almost always want to pass in these numbers in a way that results in the texture being copied onto the screen (see the image below) - but there is nothing preventing us from messing with those numbers beforehand ;) .
Left: you see the numbers that are chosen to result in an onscreen copy of the supplied texture. Right: the scrambled result if you just supply random numbers. Passing in random UV coordinates will usually result in an completely unrecognizable image, but we can be more crafty than that: we can pass the number passing to the pixel below the usual one, or to the one above - and if we do that strategically, the image looks like it shifted a bit. Vary this shifting in time, and the result is the appearance of slight movement across your image! This offsetting by a pixel or two is called distortion, and it's usually supplied to the shader by a second texture (whose color values we just reinterpret as the shifting values we need) called the "distortion map". Back to to the implementation side of things, it was surprisingly easy to arrive at a working version since I could copy the hardest part (the shader itself) straight from Ernestas prototype - only to then realize that the title of this paragraph is almost always true! Trees can be drawn in surprisingly many ways:

• High vs normal resolution textures.
• No, high, or low quality compression.
• Full or half color depth.
• Leaves decrease in amount due to pollution damage and have a total of 4 stages.
• Leaves desaturate with rising amounts of pollution.
• Trees can be rendered as part of the game world, or as part of the GUI.

If you disregard counting the desaturation, there are thus 48 different ways to render the same tree sprite, and we of course want all of them to work, leading to me being stuck hunting for the missing cases for a few days. During that time not everything went smoothly: sometimes everything seemed right with the code, but the trees seemed to refuse to move. There was thus always the question whether the effect was active at all, or if it was, then how much it actually did. This lead me to write a debug visualization into the shader: https://cdn.factorio.com/assets/img/blog/fff-324-tree-debug.mp4 The three color channels encode the three main properties the shader has to work with:

• The red channel reports the displacement in the horizontal direction - no red means displaced in one direction, full red in the other.
• The green channel reports the same for the vertical displacement.
• The blue channel reports how much the distortion has to be scaled by in order to account for different texture resolutions - full blue results in no scaling, half blue in a scaling of 0.5, no blue results in no distortion at all since it's scaled by 0.

The title theme also struck me in another way: the effect depends heavily on the provided distortion map, and our first version resulted in a look that was best described as "it looks fine if you turn it down until it's nearly invisible" - even the best implementation in the world just doesn't matter if the final effect doesn't look great, too. Given that the initial distortion map was mostly noise, I instead tried the very opposite approach: find a texture that is highly correlated with the tree leaf texture and use that instead - ultimately settling on the normal map of the tree leafs. The shader itself uses only the red and green channels of the normal maps, which made them a fine target for BC5 compression that we haven't had use so far in the game (see FFF-281 for more info on compression). After an astonishingly short time, the compression was up and running - or so I thought, since I was once more struck by "did you think of this?". The culprit this time was mipmapping, which wasn't aware of the compression and thus downscaled the compressed image instead of decompressing, downscaling, and recompressing again.
Normal maps as seen in the sprite atlas When the project was nearly done, I was hit one last time by the realization that I forgot something: moving tree leaves should result in their shadows moving too, right? I thus spent a little bit more time to implement a special shader for them that does just that by using generated noise instead of a distortion map.

Optimizations (Rseding)

There are a few key parts of the codebase that end up being "slow" relative to everything else and the reason why almost always simplifies down to edge cases. "Why is ... so slow?" -> "Because it has to check for A, B, C and D each time it does any logic". "Why? Those almost never happen" -> "Because without the checks, the logic is simply wrong". About 3 years ago I had my version of this with inserters. Inserters end up being one of the more common entities for the simple fact of: you have to have them if you want anything to run. However, inserters are also one of these "slower" entities where the basic idea of what they do seems so simple; "how can moving items from A to B in an arc end up so slow?" (relative to everything else of course). And so I looked at the profiling results and the code it pointed at:

• Each tick; check if the inserter has a burner energy source. If it does:
  • Check if the energy source is completely empty and go to sleep if so (no fuel, can't move fuel into itself since it can never move).
  • Check if the item in the inserter hand can be used as fuel for this inserter. If it can:
  • Move the hand towards the inserter itself.
• Each tick; check if the destination has moved away (teleported/vehicle drove away).
• Each tick; check if the source has moved away (teleported/vehicle drove away).
• Each tick; check if the target or source is marked for deconstruction.
• Each tick; check if the source has changed force.
• Each tick; check if the enabled condition exists and if the inserter is disabled by it.

If all of that passes, then move the hand towards the source/destination position. It's not surprising that ends up being "slow". But you can't just not do any of that and say "it's okay". The obvious answer to all of that stuff is "that doesn't happen frequently/those are edge cases; they should all be done through events". But then - how? To put it simply; there was no event that the inserter could use to know when these things happen so it had to check each tick if any of them happened. I ended up leaving it alone and went back to working on other things. But it always stayed in the back of my mind; cooking - trying to find a solution. 3 years later I found it: Targeters. Targeter driven events Targeters are a thing we created and have refined over the years for 2 main reasons:

• They're disappear-aware pointers; when the thing you "target" is deleted, your pointer is cleared (set to nullptr).
• They're saveable/loadable pointers; you can persist a pointer through save -> quit -> load.

Most things in the game that need to "point" at something else will use these (with a few exceptions of course). Inserters use these. My idea was fairly simple: anything which can be "targeted" can go over anything "targeting" it and let it know when some rare event happens (everything the inserter had to check for and some others). The events aren't free - but because these cases don't happen commonly the inserter not having to do these checks makes the cost of the events when they do happen meaningless in the overall performance charts. Snowballing With the Inserter update logic drastically simplified and with the new Targeter driven events at my disposal I started to notice things:

• Mining Drills share most of the same checks that Inserters do - so they got the same treatment.
• Locomotives, Cargo Wagons, and Fluid Wagons had the same kind of checks; so now they don't need to be active in 99%+ cases.
• The blue triangle module-requesters had the same kind of checks; so now they don't need to be active in 99%+ cases.
• Logistic and Construction robots had the same kind of checks for (did the target move?) so now they don't need to check that.

After finishing with those I re-profiled and with those entities taking far less time different interesting things started showing up:

• Burner energy source logic was doing several slow checks for the edge-case behavior.
• Transport belts were doing a O(N) check every time they would move items when it could be done in O(1) time.
• Anything which made smoke from consuming energy was doing several slow checks to try to make smoke when they didn't need to in most cases.

And finally one last thing showed up: heat pipes. Every time I make something run faster something else takes its place in the "what is time spent on each tick" (this is expected), but it also means it reveals new things I might not have noticed before. Heat Pipes The first thing I noticed with heat pipes is: all of the actual logic for heat pipe flow isn't even in the heat pipe entity itself. The entity just defer the logic to the "Heat Buffer" class. It got me wondering: why even have the "update" logic go through the entity at all if it doesn't do anything? Several days later and a lot more code than I set out to write; I moved all of the update logic for heat flow into its own dedicated manager class (almost identical to how fluids and electric flow have a manager class). It looked too good to be true; what was 0.55 ms/tick was showing 0.17 ms/tick (a little over 3x faster) by just not going through the entity each tick to do heat flow. A lot of testing later and the results were correct; it was just that much faster. The underlying algorithm didn't change but it just ran > 3x faster now by touching less memory. This is another nice example of "Factorio is not CPU bound, it's memory latency bound". More cores wasn't going to make this faster - because it was never limited by how fast the CPU ran. Conclusion Electric networks... Fluid networks... Heat pipe networks... none of these interact with each other or anything outside of themselves. What happens if I just update all 3 in parallel? Not surprisingly; each of them got slightly slower (because they are competing for memory access) but overall it was still measurably faster. The interesting part about this though: 1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done. Every save file I've tested ended up running measurably faster in the end. The most extreme one (lots of steel furnace based smelting) showed a 2.3x speed-up. As always, let us know what you think on our forum.

[ 2019-12-06 12:13:31 CET ] [ Original post ]

Read this post on our website

Water animation - Concept (Albert)

Since the very beginning of the project, we have focused a lot in the side of the factory, providing better designs for the machines, and expressive animations that give a sense of life and credibility in this area. We put a lot of effort also in the environmental side, adding different tile sizes, improving textures, adding doodads, cliffs, trees, decals, and constantly improving the map generation for a better feeling. But apart from biters and the factory, nothing else moves in this Factorio planet. So the environment is nice looking but it feels somehow unreal due this lack of motion. Today we proudly present the first experiment in this area: Animated water. This animation doesn't try to grab your attention, it's just there. Slowly moving. I personally bet that this animation, with the proper sound design, will provide the natural feeling that the planet needs. https://cdn.factorio.com/assets/img/blog/fff-323-animated-water.mp4

Water animation - Technical Art (Ernestas)

Animation was always one of the most powerful creative tools we have. Animation is how we communicate with our audience about functionality, it creates interest and emotions people like. So let us talk about water and how the current representation might be missing something. Some of you with an eye for detail might have noticed that water in Factorio is static. It has foam, which is static. There are also some static reflections. Due to the fact that making animated water was considered polishing, we never took the time to make an actual solution. But now we are polishing Factorio, trying to make it as beautiful as we possibly can given our constraints. I am glad to talk to you a bit about us solving animated water! Christmas of 2018, I decided to gift myself with solving water animation in secret. Based on past conversations with Albert the goal for it was clear:

• It had to look similar to the current water.
• Photorealism was a no no.
• It had to be super cheap for the GPU.

In the past I was experimenting with this cheap clouds shader. It used fractal Brownian Motion and only sampled a noise texture, instead of the usual approach of calculating Perlin noise. With a low iteration count, it was almost as cheap as drawing a sprite. So I started MonoGame (lovely framework) and implemented a tile-based world using the same technique for the shader, the only difference being I clamped noise values to simulate brighter and darker areas. For the noise I used our water sprite.
Original - Noise - Clamped To save GPU power, water was drawn the same as tiles, one after another. The position was easy to solve also, I simply used UV coordinates to represent the game world position. With some trial and error, water was recreated with a moving effect. https://cdn.factorio.com/assets/img/blog/fff-323-pitch.mp4 At the beginning of 2019, I pitched the prototype to the team. Sadly it was not really accepted mostly because of the movement. However, I sat down with Albert and talked and tweaked values to more appealing ones. After that, we basically forgot about it. Half a year passed and that solution was back on the table, I only had to solve reflections, foam, transparency, out of map transitions, and some other stuff. Solving reflections, transparency and foam resulted in using a render target to save information for water shader. A render target is just a texture on which you can draw. Using three channels RGB, I am able to save three kinds of information. Red for reflections, green for transparency, and blue for foam. All drawing is additive to account for multiple tiles drawing on top of each other. This way we are able to add information not only for shore, but also for entities. https://cdn.factorio.com/assets/img/blog/fff-323-layers.mp4 For out of map we updated our jelly feeling with waves on top. Basically we left the old graphics on the bottom and added animated water on top. For cutting/masking out water where we want, I used another shader that generated green waves in the water render target. Now some of you might ask why we did not use a waterfall. I mean it would look nice having a waterfall to this pitch-black hole of nothing. The reason is waterfall was the first thing we tried, and concluded that the jelly looks better and cleaner. https://cdn.factorio.com/assets/img/blog/fff-323-out-of-map.mp4

Water animation - Game integration (posila)

For a long time, in order to make terrain rendering fast, we would keep an offscreen buffer with terrain that was rendered in the previous frame, and reuse it to render terrain in the current frame. If the players view didnt change at all, we would use the offscreen buffer as is, if the player moved, we would shift the buffer accordingly, and render just the bits that were not visible before. Zooming or changing tiles in the view would invalidate the content of the offscreen buffer, and the terrain would have to be re-rendered for the entire view. But that happens only in a fraction of frames, so its not a big problem. You may have noticed this optimization is incompatible with rendering animated tiles, so for the initial integration of Ernestas water effect, I had to force a full redraw every frame. This created a performance issue, as the tile render prepare step would take up 3ms (almost 1/5 of total frame time) when zoomed out. Why does that matter? The games main loop runs in 3 major stages:

• Update - progresses the game state one tick forward.
• Prepare render - collects the data that is needed to render the current view.
• Render - uses this collected data to issue commands to the GPU.

While game update and render are executed in parallel, neither of them can run while prepare render does (more on this in FFF-70). So 3ms of additional prepare time means 3ms less can be spent in update before the update rate drops below 60 (and I dont even want to mention how much time it would take in debug build, Ill just say that Id expect a lot of nasty looks from coworkers). Luckily, I already had an idea how to solve this. The water animation depends only on global time, and the vertex data of water tiles doesn't change in between the frames, so instead of caching the finished terrain render in a texture, we can cache the data resulting from prepare render, which we call draw orders. To make it work, we cache draw orders per-chunk, and we only run prepare render on chunks that have just entered the player view (and werent in the cache already). That pretty much solves the problem of the render prepare and has some nice side benefits. First of all, changing render scale doesnt need to invalidate the new cache, so zooming doesnt cause prepare render to run for all tiles in the entire view. Secondly, it creates opportunities for other future optimizations - for example, we can start caching tile draw orders that are likely to enter into the view in advance and spread this work over multiple ticks, or we can generate tile draw orders for each chunk in parallel as they are independent of each other now. Even though the water effect is relatively cheap, some of our players play the game on really weak hardware, which already struggles with the current state of the game, so we needed to add an option to turn the effect off and essentially revert back to the old behavior. Initially I thought we would even use the old water sprites, but because we had to change the tile transition definitions, the old water would look really bad. I have decided to always render water using the new effect, but if you disable the animation, it will render frozen in time and will be cached to the offscreen buffer. Since we were keeping the offscreen buffer logic around, we could utilize it for everyone if possible. I added a flag to cached per-chunk tile draw orders, that determines if the chunk contains a dynamic effect (and therefore needs to be rerendered each frame - if the animation is enabled) or if it can reuse pixels from the previous frame. This means when rendering chunks without any water (E.G, the middle of your factory), the new water effect will have no impact on performance. Modding When seeing this you might get excited about the possibilities for modding. Well, dont just yet. The system has been setup for making it possible to define different tile effects, but at the moment it is limited to allow just 1, which is used to define the water effect. I plan to lift this restriction in the near future, but in the end youll be limited to only changing the properties of the effect we made. But that still might be interesting enough, due to ability to change the noise texture. There is still no plan to support custom shader definitions before 1.0. As always, let us know what you think on our forum.

[ 2019-11-29 14:53:19 CET ] [ Original post ]

Read this post on our website

Release plans (Klonan)

This week we released version 0.17.79, and marked it stable. Internally we have been calling this 'Stable 3', and the main feature was the new tooltips we showed in FFF-318. There is one constraint we put on ourselves when we started this more swift feature release schedule: We want to avoid breaking mods. This is easy enough in principle, don't start renaming things, don't remove API features, etc. However as we develop further, there are certain features and improvements that we can't realistically do in a way that won't break mods, such as the new Character GUI (FFF-289) and color correction (FFF-320). It is for this reason that we are going to accumulate some of these mod breaking changes, and release them all at once. Since it will definitely be breaking mods, we will bump the major version number, so it will be 0.18.0. We have already internally started merging in these 0.18 features into our master branch, so we will not be doing any more 0.17 releases (unless something absolutely catastrophic is discovered).

The problem with particles (Klonan)

Particles have been in the game for as long as anyone can remember, and they are pretty simple all things considered. They are a small mostly decorative entity, that we use to add a bit of visual gratuity to the death and dying of bugs and machines. For instance, Biters are full of blood, so when they die, they make quite a splash. Lets try to count how many particles we spawn in a typical dying explosion. https://cdn.factorio.com/assets/img/blog/fff-322-biter-die.mp4 In this clip, the blood particle sprite has been replaced with a debug visualisation, to make counting easier So it's quite a few. The Biter spawned 427 particles, and the Spawner 749. Well they don't persist very long, and they're only decorative, so it's all fine right? One key word I would like to highlight in the previous description, is that they are an entity. When kovarex and slpwnd started making Factorio, they made a robust system for managing game objects and their interactions - the entity system - and everything that has a physical representation in the game world was built on top of this system. As the game grew bigger, it became obvious, the entity system is too heavy weight for some things, and we can get better performance by creating more specialized systems. This led to removing items on belts from the entity system in 0.12, and doing the same for smoke and terrain decoratives in later versions. Despite most other games or game engines having very efficient particle systems from the early stages of development, particles in Factorio are still piggybacking off the entity system in 0.17. This means that particles are registered on the game surface in the same generic way as everything else. This also means, that they are iterated through when doing entity searches. So what sort of engine actions do entity searches?

• Area trigger effects - such as grenade, flamethrower stream damage, atomic bomb, poison capsule.
• Pathfinding - To check if a path can traverse a given tile.
• Movement collision checks - such as Characters, Units, Projectiles.
• And many others...

As you can imagine, having thousands of extra entities to iterate through every tick, can start slowing down the simulation. The worst case these days is defending your walls with flamethrowers. In the image below, all entities are highlighted with a debug visualization.

If you lost count, this scene contains 15,689 entities Flamethrowers vs Biters are pretty much the perfect example of the problem:

• The biters need to check every tick when they move if they collide with anything.
• When the flamethrower streams land, they do splash damage, which is an area trigger effect.
• The flamethrower stream also creates the fire on the ground, which does a collision check.
• Every 10 ticks, the Fire on the ground do damage with an area trigger effect.
• The flamethrowers kill biters very efficiently, so a lot of particles spawn in a very short amount of time.

This combination leads to some significant slowdowns later in the game when big groups come knocking. Also, since we improved the pathfinding, the problem is even worse in the latest versions of 0.17. So how do we solve it?

Particle Optimization - Technical (Rseding)

When Posila first talked to me about doing a re-work of how Particles function in the game I had a lot of ideas. Not all of them worked out in the end but they sounded nice:

• They wouldn't be entities.
• They would work like smoke does (stored in contiguous blocks of memory).
• They wouldn't need to be updated each tick if they didn't effect the game state.

In the end I found that it wasn't worth the added complexity to make #3 work. The process Particles needed to not be entities. Something being an entity has a lot of memory and performance overhead that particles just didn't need. Unfortunately when I implemented artillery I made the manual-targeting marker a particle. The reasons why don't matter any more, but it meant I had to add migrations to handle that and then migrations to handle removing all of the entity particles. I stripped out all of the extra data/logic from particles that they no longer needed - reducing the size of each particle in memory from 224 bytes to 64 bytes. As a side effect of making them not entities it also reduces the amount of information that has to be saved in the save file. However, in most cases particles don't exist long enough to end up in the save file so that didn't really matter. I needed some place to store/work with the particles runtime as they are created, exist for some short amount of time, and go away. Most stuff in the game ends up being stored on a given chunk (a 32x32 area of the world). In the case of particles I didn't care at all about any of the other stuff on a given chunk so I didn't want to stick them there. Instead, I made a separate thing that functions very closely to chunks and called it "particle chunk". The key differences being: they only exist when there are particles to update on them and the only data they hold are particles. That meant when the game needs to go over each particle to update them, all it has to do is go over all of the "particle chunks" that exist and run update. Additionally since I had full control of these new particle chunks I can recycle them in memory as needed to avoid spending extra time allocating and de-allocating memory as particles come and go. The end result is a nice performance boost, reduced memory usage, and simplification of the logic around how particles work. A simple unscientific test we performed was nuking the same biter base in the old system and the new system, and recording what the max update tick time was.

The circular ring of entities around the edge are the 'Atomic bomb wave' projectiles. Old system:

• Max Entity update = 7ms.
• Entity count (Excluding projectiles) = 7769

New system:

• Max Entity update = 2.4ms.
• Max Particle update = 1.7ms
• Entity count (Excluding projectiles) = 786

This is not very scientific or highly controlled, but just to give an idea of the scale of the improvement. A 10x reduction in the number of created entities, and about a 40% reduction in max update time. Having the new optimized particle system also means the GFX team can go a bit more crazy with particle effects in the future... As always, let us know what you think on our forum.

[ 2019-11-22 12:44:52 CET ] [ Original post ]

Bugfixes

• Fixed that the infinity pipe mode could sometimes reset when changing other infinity pipe settings. more
• Fixed that electric energy interfaces didn't consume power correctly. more
• Fixed market GUI not showing price in the tooltips of modifiers. more
• Fixed market GUI showing empty price property in the tooltips when no price is set.
• Fixed lights render quality slider in graphics settings missing tooltip. more

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

[ 2019-11-19 16:25:30 CET ] [ Original post ]

Changes

• When a team loses in PvP, all their characters will die.
• Technology GUI shows saved progress of partially-researched technologies.

Bugfixes

• Fixed a crash when when loading modded saves that had construction robots working on modded entities.
• Fixed that 'corpses' and 'dying_explosion' wouldn't be created on the correct force. more
• Fixed that LuaEntity::get_fuel_inventory() didn't work on burner pumps. more
• Fixed ammo turret tooltip not showing the damage bonus correctly. more
• Fixed fluid name and amount not being shown when the tooltip is on the side. more
• Show how module energy consumption is applied more clearly in the tooltips. more
• Fixed several issues related to modded reactors set to use electric energy. more
• Fixed spitters were not able to destroy trees and rocks. more
• Fixed that shift+click recipes in cheat mode wasn't able to handle recipes that included fluids but still only produced 1 item result. more
• Fixed a difference in map editor paused vs unpaused game ticking related to enabled/disabled train stops. more
• Fixed that produce item per hour achievements could not be progressed. more
• Fixed an issue with reading localised strings in Lua. more
• Fixed that right clicking to add 1 item to assembling machines had no limit. more
• Fixed that teleporting players/cars between surfaces would invalidate lua references to them.
• Fixed a crash with trains that had wheels.direction_count = 0. more
• Fixed statistics not counting items correctly on large intervals when a large number of items are produced/consumed. more
• Fixed Beacon ghost tooltip missing some information. more
• Fixed ghost tooltips not showing correct max energy consumption.
• Fixed tooltips for tile creating items showing wrong title. more
• Fixed blueprint strings not saving empty values for some circuit network settings. more
• Fixed PvP config import would always append the default item and equipment lists. more
• Fixed that creating infinity chests with logistic_mode set would ignore request filters. more

Scripting

• Added LuaEntity::command, LuaEntity::distraction_command, LuaUnitGroup::command, and LuaUnitGroup::distraction_command reads.
• Added LuaUnitGroup::is_script_driven read.

Modding

• Changed RollingStockPrototype::wheels to be optional.

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

[ 2019-11-15 18:16:35 CET ] [ Original post ]

Read this post on our website.

1.0 date (kovarex)

Hello, we feel that the Factorio development is taking way too long. The approach "It is done when it is done" was serving us well to deliver a high quality product, but if we continued this way, we would be doing it basically forever. A lot of us don't have any problem working on Factorio for some more time, but the main problem is, that we would like to introduce new features and content instead of just polishing parts that are already present in the game. We also considered, that the game is quite polished now, and if we just pushed the button to release 1.0, it wouldn't be a catastrophe. From our perspective, a lot of things wouldn't be finished, but from the perspective of a new player, the things we are working on now are mainly nitpicks. With this in mind, we decided to just specify a 1.0 release date publicly, so we have to stick with it. We will just focus on the most important aspects as we approach the date, and we just do whatever we have time to do. Once the 1.0 happens, we can have some rest and after that, we can finally focus on the content and features again. The date is 25th September 2020. Version 1.0 does not mean that development on the game will end, or that Factorio is 100% finished. When we have a better idea of what we will be working on after the 1.0 release, we will let you know.

GDS 2019 (Klonan)

Game Developers Session 2019 is happening in a few weeks, Friday 29th and Saturday 30th of November. This year, like last, we are silver sponsors of the event, so you will see our banners around the venue if you attend. This year we are happy to have two of our team doing talks at the conference:

• Albert - "Developing the Visual Style of Factorio".
• Vaclav - "Technical Side of Creating Factorio Graphics".

You can read a bit more about our talks and others on the speakers page. Other than our two speakers, a lot of the team will be attending the conference, so if you see anybody sporting a Factorio t-shirt, it could be one of us (don't be afraid to come talk to us). We also took the opportunity to do some updates to our cover art.

The Factorio team must grow (Klonan)

We have been on a bit of a hiring spree lately, trying to fill gaps in the team where we can identify them. We are happy to say, we have continued our team growth, with two new additions to the team. Ian is a sound designer from the UK, who has moved to Prague quite recently. He will be working with us full-time here in the office, and with the help of Rseding for engine features, will be developing the soundscape of the game as we narrow in on the 1.0 release. Next up is Allaizn. You might remember a few of our team mentioned him in past Friday Facts, and he is infamous for his experiments with cars on belts. He has had source access to the game for a long time, and in the past has made some good contributions through the program, so he has been able to get up to speed with us very quickly. For now he is reinforcing Posila in the Graphics backend department. For some more details on our new colleagues and the rest of the team, we have short bios for everyone on our Team page. As always, let us know what you think on our forum.

[ 2019-11-15 15:54:55 CET ] [ Original post ]

Changes

• When a team loses in PvP, all their characters will die.
• Technology GUI shows saved progress of partially-researched technologies.

Bugfixes

• Fixed a crash when when loading modded saves that had construction robots working on modded entities.
• Fixed that 'corpses' and 'dying_explosion' wouldn't be created on the correct force. more
• Fixed that LuaEntity::get_fuel_inventory() didn't work on burner pumps. more
• Fixed ammo turret tooltip not showing the damage bonus correctly. more
• Fixed fluid name and amount not being shown when the tooltip is on the side. more
• Show how module energy consumption is applied more clearly in the tooltips. more
• Fixed several issues related to modded reactors set to use electric energy. more
• Fixed spitters were not able to destroy trees and rocks. more
• Fixed that shift+click recipes in cheat mode wasn't able to handle recipes that included fluids but still only produced 1 item result. more
• Fixed a difference in map editor paused vs unpaused game ticking related to enabled/disabled train stops. more
• Fixed that produce item per hour achievements could not be progressed. more
• Fixed an issue with reading localised strings in Lua. more
• Fixed that right clicking to add 1 item to assembling machines had no limit. more
• Fixed that teleporting players/cars between surfaces would invalidate lua references to them.
• Fixed a crash with trains that had wheels.direction_count = 0. more
• Fixed statistics not counting items correctly on large intervals when a large number of items are produced/consumed. more
• Fixed Beacon ghost tooltip missing some information. more
• Fixed ghost tooltips not showing correct max energy consumption.
• Fixed tooltips for tile creating items showing wrong title. more
• Fixed blueprint strings not saving empty values for some circuit network settings. more
• Fixed PvP config import would always append the default item and equipment lists. more
• Fixed that creating infinity chests with logistic_mode set would ignore request filters. more

Scripting

• Added LuaEntity::command, LuaEntity::distraction_command, LuaUnitGroup::command, and LuaUnitGroup::distraction_command reads.
• Added LuaUnitGroup::is_script_driven read.

Modding

• Changed RollingStockPrototype::wheels to be optional.

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

[ 2019-11-14 19:34:40 CET ] [ Original post ]

Read this post on our website.

Color correction (Albert, V453000)

Factorio is in a state that even though is not yet finished, it is very close to it's 1.0 version. That means that most of the work is done and we are polishing the game in order to make it bright. That's what we've been doing for the past 2 weeks. Literally making it bright. Since years I wanted to do this post-production work. But I didn't dare to do it until most of the graphics were finished. I was afraid of breaking the consistency of the look and our production pipeline. Now it's different. There's only a couple of entities to re-design and some other stuff to do, but in general this missing details are not affecting the possibility of working in the post-production. Factorio is a dark game. I mean conceptually. All these things about industrializing a planet, polluting an entire world just for the sake of the factory, and killing all its inhabitants are not precisely happy concepts full of light. This old article could explain better my thoughts regarding this concept. But the look of the game was dark, too dark. So we cleaned it up without betraying its spirit. Like restoring an old painting.
The difference can be subtle, but very effective. We added more light, and a little bit of color saturation. Adding these general changes to the entire sprites collection is not an easy task. Many sprites were badly affected by this general correction. V453000 was fixing individually the broken sprites and icons in order to keep the consistency with the new context. We took the chance to work on the terrain a bit further. Not only this color correction was applied, but the contrast and integration with other terrains was also improved. Also experimenting with the color of the trees, trying to achieve a more colorful feeling with the excuse of an alien planet. I have to say the Alien Biomes mod was opening my mind - a little - to experiment with the color a bit further.
In order to break this general brown feeling, we added a more orange tonality to the sand biome. Here is were you can the difference more. Going further to too saturated colors is dangerous, after all, the terrain is a background that should provide a good and comfortable contrast with the entities and the icons.
Touching terrain colours means touching map colors also. We were very keen to keep the visibility of the map information and the similarity with the terrain. The result is a more vibrant look in the entire game.
We tweaked the night also. Thanks to posila and Wheybags, we can use LUTs (Look up tables) to dynamically modify the colors. Instead of playing with the alpha channel of a solid black layer on top of the game. Now we can gradually move to a different color palette for night with more control. So the colors are losing their saturation and becoming more blue and cold. This is important, because part of the annoying darkness of the game comes from this black layer.
We are still experimenting with this LUT, and the transitions of day/night cycles. I'm pretty sure also that I will have to touch the map colors for some missing details and fine tuning. Possibly there is some entity that is not in its best shape with these new color palettes, and maybe we keep tweaking the terrain. But I feel very confident with these additions and I'm very sure that these changes will improve the experience of playing Factorio. After playing with these colors, the feeling is good. I hope you see it the same way.

Updating mods (V453000)

By changing the colors of all game graphics, most mods are going to look out of place. Weve used scripts to apply LUTs to most of the images, and one such script is ready for mod authors to clone or download here, together with the information of which LUT was used for which spritesheet in the game data, with the exception of terrain tiles, electric wires and combinators which were adjusted manually. For technical support dont hesitate to contact me directly, youll get quickest reply by messaging me (V453000#1894) on the Factorio Discord. We still have some work to do on the LUTs, so they aren't going to be ready for release for another short while. As always, let us know what you think on our forum.

[ 2019-11-08 15:36:54 CET ] [ Original post ]

Changes

• Energy consumption is no longer shown in the tooltip for void energy sources.

Bugfixes

• Fixed a bug in NPE where Compilatron would sometimes loop around smashing things. more
• Fixed possibility of dying just before a cutscene in NPE, which would lead to a crash. more
• Fixed game crashing in NPE if it can't find anywhere to spawn a biter. more
• Fixed using dark coal icon on dark speech bubble background. more
• Fixed a crash when loading modded saves without the mod when you had entities marked to be upgraded to the now removed modded items but the entity is still valid.
• Fixed incorrect string for "Fuel Pollution" in tooltip. more
• Fixed tooltip not showing max consumption correctly when using modules. more
• Fixed battery equipment and accumulator tooltips showing wrong input flow limit when it's unlimited. more
• Fixed item tooltips not showing custom_description. more
• Fixed some item tooltips having incorrect title or description.
• Fixed that hovering over a logistic request didn't highlight inventory items. more
• Fixed pump tooltip not showing pumped amount when pumping from a fluid wagon. more
• Show the products of a recipe more clearly when the product has a probability and/or an interval defined. more
• Fixed a crash when restarting the game after it failed to load modded fluidboxes. more
• Fixed tech tree quantity icon being shown incorrectly. more
• Fixed an exploit related to upgrading ghosts while a robot is trying to work on them. more
• Fixed target leading logic would cause turret to shoot outside of its range sometimes. more

Modding

• Added AmmoTurretPrototype::entity_info_icon_shift.

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

[ 2019-11-07 15:56:37 CET ] [ Original post ]

Features

• Construction robots will attempt to batch build tiles.

Changes

• Tooltips reworked. They now have a new structure and look.
• Properties in tooltips have been reorganized and reworked. Common properties have been added to categories.
• Added more information to tooltips, for example to be able to calculate steam power and nuclear ratios.
• Recipe and item tooltips are now separate. Item tooltips will be shown for each product in the recipe, if relevant.
• Descriptions and Total Raw can be hidden using the interface setting.
• Reorganized the interface settings menu.

Bugfixes

• Fixed a crash when switching between the map editor and the ghost controller type. more
• Fixed car movement animation played forwards when reversing. more
• Fixed a crash related to using LuaCustomTables incorrectly. more
• Fixed that accumulators wouldn't copy circuit signals correctly in some cases. more
• Fixed a crash related to removing all collision masks from rails. more

Modding

• Added ProductPrototype::show_details_in_recipe_tooltip. It determines if a product tooltip should be shown when hovering a recipe.

Scripting

• Added filtering support for several common Lua events.
• Added LuaEntity::logistic_network write for construction and logistic robots.
• Added "lifetime" optional entity creation parameter for speech-bubble entities.
• Added LuaEntityPrototype::max_distance_of_sector_revealed and max_distance_of_nearby_sector_revealed read.
• Changed RecipePrototype so it calculates catalyst from ingredients and products automatically if not manually defined.

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

[ 2019-11-04 16:14:23 CET ] [ Original post ]

Read this post on our website. Hello, There is a bit of a cold/flu going around the office, but it isn't severe enough to dampen our spirits (I don't like the daylight savings though).

New T-shirts (Jitka, Albert, Ale, Klonan)

Ever since we launched the classic Grey T-shirt back in November 2017, we've been asked when we're going to have more designs. Over the last few months Jitka, Albert, and Ale, have been working on our new collection, which is now available.
Check out our store page for full product details. We chose the Inserter and the Electronic circuit, as we feel that they are some of the items that best represent the game.

Once again, its the small details of which we are really proud. This time we are incorporating the new Wube logo into the print, as well as continuing our Factorio Dude printed label. We have also updated our classic Factorio logo on grey with the new T-shirt design, which means that all the T-shirts are available in 3XL (Triple-XL), including the older design which previously only went up to 2XL. We have also printed a small batch of the Factorio logo T-shirts in a Ladies cut. Several weeks ago, we mentioned that we bought a new rack for the server room (FFF-315). The secret we have been keeping is that we didn't just buy new racks for the server room, but also for the merchandise room. Now that we have the new T-shirt collection, the shelves are filled quite nicely.
The new T-shirt collection is available on our website from today. Please bear in mind that we are packaging and shipping all the T-shirts ourselves in the office, we aren't handling things through any 3rd party distributor. What this means is that shipping isn't super fast and we can't really guarantee any shipment dates. Generally the T-shirts reach European addresses within 1 week, and reach North America within 2. With Christmas approaching, shipping times may be longer, so if you are looking to gift a Factorio T-shirt this upcoming holiday season, we would recommend ordering as soon as possible. Please note we still impose a 3 T-shirt limit on all orders.

Lua event filters (Rseding)

Every so often someone makes a mod interface request that grabs my attention - not because of the actual benefits the request will give (although that helps) but from a pure challenge perspective: I start thinking "that sounds difficult (and fun) - but I think I can do it - so how I can do that in an efficient/expandable way?...". Several weeks ago someone requested a way to filter the different prototypes from the game on the C++ side instead of having to do it all Lua side:

• Grab all of them.
• Iterate through them one by one.
• Store only the ones I care about.

Their reasons made sense to me and it was one of those challenging things that grabbed my attention. I finished it - and it has been out for several weeks. Shortly after that someone asked for the same system for Lua events; mentioning that most mods don't actually want most events when they subscribe to one - but only a small subset of what would trigger a given event. It also made sense to me and it was even more of a challenge to take the already working filtering system I had and make it work for something I didn't intend. The end result though works quite nicely and can be expanded as we find different events needing different filters.
What this means overall, is that modders will be able to write cleaner and more efficient Lua scripts, and everybody will benefit from less UPS spent filtering the events on the script side.

/r/Factorio Extra Life charity stream (Klonan)

This weekend the moderators over at the Factorio subreddit are taking part in the Extra Life charity event. They will be streaming Factorio to help raise money for Children's hospitals in the US and Canada. There are some more details on the Reddit post. As always, let us know what you think on our forum.

[ 2019-11-01 14:12:35 CET ] [ Original post ]

Read this post on our website. Hello, we just released 0.17.73, with 0.17.74 coming very soon. This is just some bug fixes and further pathfinding improvements, and we hope to be able to mark the release as Stable next week.

The new tooltips (Twinsen)

As part of our big GUI update, I've been working on one particular part: the tooltips. We worked not only on updating the style, but also how the information is structured and sorted, added missing information, removed irrelevant information. This concerns entity, item and recipe tooltips, but almost all tooltips were touched one way or another. Many things were changed. I will go through some of the more important changes. The new look
First thing to see is the new style Albert has worked on. They now have the same general style as the technology tooltips. We tried to keep them as compact as possible, as sometimes there is quite a lot of information to show. For the screenshots in this blog post, I set the background to be non-transparent. Unfortunately they don't blend very well with our blog background, but in game you will notice that they are slightly transparent and the also have a blurring effect. Together with the shadows, they integrate nicely in the game. Categorization
As you may have noticed already, some common properties like electricity consumption are grouped into categories. Most of the work was defining these categories and trying to figure out what makes sense. These categories help grouping the information but also gives more context to some entity properties. Properties that are directly related to the selected entity type are placed in the "root" category that has no name. This is to avoid having pointless categories like "Inserter" and "Transport belt". New information The place where the categorization really shines is in the tooltips of power generating entities. Now it's much clearer what each entity does and what the ratios are. Entities related to nuclear power were especially confusing. Creating an optimal nuclear setup was almost impossible without the help of the wiki. Now all the important information is there.

Entity tooltips and item tooltips generally show the same properties, but I tried to make the entity tooltips show state information when possible. For example, here's how the item tooltips above look when the entities are placed in the game. Categories are even more useful now, since properties like the fuel inside the machine or the state of the fluid output pipe can now be grouped inside the relevant categories.
Other entities have more properties added to them, such as inserter rotation speed, rolling stock weight, laser turret energy use per shot, flamethrower turret burning and slowdown effect, and many more. Tooltip separation
The recipe tooltip was kind of a Frankenstein's monster of recipe information and item information mashed together. We also had the problem with what properties to show when a recipe has multiple output products. The solution was to split the tooltips and show a "multi-tooltip" when hovering a recipe, Now, when hovering over a recipe in the crafting menu the recipe tooltip will be shown. An additional item tooltip will be shown for every product, as a separate tooltip, if the item tooltip has a description and/or properties to show. While this improves things quite a bit in vanilla, complex mods will benefit from it even more. Recipes can now have their own textual description and each separate product can be explained independently if necessary.
The same mechanism is used for the tooltip shown when hovering a logistic request in the character window. This means that an item tooltip will look the same regardless if it's shown while hovering a recipe, an item in the player inventory or a logistic request. No more mixing of information. Most of the implementation is done, just a few tweaks and bugfixes left to do, plus any changes based on your feedback. If all goes well, the new tooltips will be part of one of the next experimental feature releases, which we hope to release in the next couple of weeks. After that, more GUIs to come.

Construction robot tile batching (Rseding)

One of the things I've wanted to tinker with for some time is having a construction robot build multiple things at the same time. Construction robots spend the vast majority of their time just flying around doing very little work and can technically use the cargo capacity research but only ever use it for logistic related things. https://cdn.factorio.com/assets/img/blog/fff-318-not-batched.mp4 One of the main things which stopped me from looking into this in the past was performance concerns: figuring out which thing(s) a robot can work on in a batch gets expensive very quickly and with robots existing in the 10s of thousands range I can't just make each one 5 times as expensive. A few weeks ago I thought I finally figured out a way to at least make robots able to batch build tiles without loosing too much performance. The thing is: when tiles are built they are built in large square patterns so I can safely assume there will be other tiles to be built directly next to a given tile that hasn't already been assigned a robot to work on. After some experiments and then several re-works to optimize what was already quite fast I was satisfied with the result. https://cdn.factorio.com/assets/img/blog/fff-318-batched.mp4 Of course, the next question people ask is: what about doing it for entities? I could, but it doesn't make as much sense for them because they aren't always 1x1 (performance drops off quickly as the size grows - tiles are always 1x1), aren't typically built in tightly packed squares like tiles are, and in the common case it would just make robots more expensive to run while rarely making them build faster. So, for now they just batch build tiles. https://cdn.factorio.com/assets/img/blog/fff-318-batched-comparison.mp4 As a more direct comparison, Boskid made this nice setup using two forces with different cargo bonuses. As with the tooltips, the tile job batching will be released as part of our next experimental feature release, which we're calling internally 'Stable 3' (0.17.69 is Stable 1, 0.17.74 will be Stable 2). As always, let us know what you think on our forum.

[ 2019-10-25 13:34:04 CET ] [ Original post ]

Graphics

• Extended transport belt sprites a little bit to avoid rendering glitches at some zoom levels.

Bugfixes

• Added missing max_work_done_per_tick in map-settings.example.json. more
• Fixed that accumulator settings could not be copy-pasted. more
• Fixed that generators could rotate and render incorrectly. more
• Fixed bad quest GUI in NPE. more
• Fixed a crash related to the map editor "recipe locked" setting for assembling machines. more
• Fixed that Military science pack was sorted after Chemical science pack in the Lab GUI.
• Fixed low quality texture compression would create major artifacts on some sprites. more
• Fixed a crash when reading storage_filter on infinity chests. more
• Fixed a crash when reading LuaEntity::tree_stage_index_max in some cases. more
• Changed blueprinting selection previews to include both tile ghosts and tiles when only tile ghost entities are being selected. more
• Fixed a crash that could happen when path_resolution_modifier was set to very low values. more

Modding

• Changed input_flow_limit and output_flow_limit so 0 means 0 instead of unlimited (no value still means unlimited).

Scripting

• Added LuaEntity::driver_is_gunner read/write.

Balancing

• Changed: Amount of copper-cable in Introduction scenario crash site.
• Changed: Increased minimum size of a resource deposit to 100 in the Introduction scenario.

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

[ 2019-10-24 18:45:52 CET ] [ Original post ]

Bugfixes

• Fixed another biter-related crash. more

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

[ 2019-10-18 13:30:08 CET ] [ Original post ]

Read this post on our website.

New pathfinding algorithm - Oxyd

Last week we mentioned the change to make biters not collide with each other, but that wasnt the only biter-related update we released this past week. Somewhat coincidentally, this weeks updates have included something Id been working on for a few weeks before an upgrade to the enemy pathfinding system. Pathfinding When a unit wants to go somewhere, it first needs to figure out how to get there. That could be as simple as going straight to its goal, but there can be obstacles such as cliffs, trees, spawners, player entities in the way. To do that, it will tell the pathfinder its current position and the goal position, and the pathfinder will possibly after many ticks reply with a path, which is simply a series of waypoints for the unit to follow in order to get to its destination. To do its job, the pathfinder uses an algorithm called A* (pronounced 'A star'). A simple example of A* pathfinding is shown in the video below: A biter wants to go around some cliffs. The pathfinder starts exploring the map around the biter (shown as white dots). First it tries to go straight toward the goal, but as soon as it reaches the cliffs, it 'spills' both ways, trying to find a position from which it can again go toward the goal. https://cdn.factorio.com/assets/img/blog/fff-317-basic-pf.mp4 In this video, the algorithm is slowed down to better show how it works. Each dot in the animation represents a node. Each node remembers its distance from the start of the search, and an estimate of the distance from that node toward the goal this estimate is provided by what's called a heuristic function. Heuristic functions are what make A* work it's what steers the algorithm in the correct direction. A simple choice for this function is simply the straight-line distance from the node to the goal position this is what we have been using in Factorio since forever, and its what makes the algorithm initially go straight. Its not the only choice, however if the heuristic function knew about some of the obstacles, it could steer the algorithm around them, which would result in a faster search, since it wouldnt have to explore extra nodes. Obviously, the smarter the heuristic, the more difficult it is to implement. The simple straight-line heuristic function is fine for pathfinding over relatively short distances. This was okay in past versions of Factorio about the only long distance pathfinding was done by biters made angry by pollution, and that doesnt happen very often, relatively speaking. These days, however, we have artillery. Artillery can easily shoot and aggro massive numbers of biters on the far end of a large lake, who will then all try to pathfind around the lake. The video below shows what it looks like when the simple A* algorithm we've been using until now tries to go around a lake. https://cdn.factorio.com/assets/img/blog/fff-317-long-pf-before.mp4 This video shows how fast the algorithm works in reality; it hasnt been slowed down. Contracting Chunks Pathfinding is an old problem, and so there are many techniques for improving pathfinding. Some of these techniques fall into the category of hierarchical pathfinding where the map is first simplified, a path is found in the simplified map, and this is then used to help find the real path. Again, there are several techniques for how exactly to do this, but all of them require a simplification of the search space. So how can we simplify a Factorio world? Our maps are randomly generated, and also constantly changing placing and removing entities (such as assemblers, walls or turrets) is probably the most core mechanic of the entire game. We dont want to recalculate the simplification each time an entity is added or removed. At the same time, resimplifying the map from scratch every time we want to find a path could quite easily negate any performance gains made. It was one of our source access people, Allaizn, who came up with the idea that I ended up implementing. In retrospect, the idea is obvious. The game is based around 32x32 chunks of tiles. The simplification process will replace each chunk with one or more abstract nodes. Since our goal is to improve pathfinding around lakes, we can ignore all entities and consider the tiles only water is impassable, land is passable. We split each chunk into separate components a component is an area of tiles where a unit can go from any tile within the component to any other within the same component. The image below shows a chunk split into two distinct components, red and green. Each of these components will become a single abstract node basically, the entire chunk is reduced into two 'points'.
Allaizns key insight was that we dont need to store the component for every tile on the map it is enough to remember the components for the tiles on the perimeter of each chunk. This is because what we really care about is what other components (in neighbouring chunks) each component is connected to that can only depend on the tiles that are on the very edge of the chunk. Hierarchical Pathfinding We have figured out how to simplify the map, so how do we use that for finding paths? As I said earlier, there are multiple techniques for hierarchical pathfinding. The most straightforward idea would be to simply find a path using abstract nodes from start to goal that is, the path would be a list of chunk components that we have to visit and then use a series plain old A* searches to figure out how exactly to go from one chunk's component to another. The problem here is that we simplified the map a bit too much: What if it isnt possible to go from one chunk to another because of some entities (such as cliffs) blocking the path? When contracting chunks we ignore all entities, so we merely know that the tiles between the chunks are somehow connected, but know nothing about whether it actually is possible to go from one to the other or not. The solution is to use the simplification merely as a 'suggestion' for the real search. Specifically, we will use it to provide a smart version of the heuristic function for the search. So what we end up with is this: We have two pathfinders, called the base pathfinder, which finds the actual path, and the abstract pathfinder, which provides the heuristic function for the base pathfinder. Whenever the base pathfinder creates a new base node, it calls the abstract pathfinder to get the estimate on the distance to the goal. The abstract pathfinder works backwards it starts at the goal of the search, and works its way toward the start, jumping from one chunks component to another. Once the abstract search finds the chunk and the component in which the new base node is created, it uses the distance from the start of the abstract search (which, again, is the goal position of the overall search) to calculate the estimated distance from the new base node to the overall goal. Running an entire pathfinder for every single base node would, however, be anything but fast, even if the abstract pathfinder leaps from one chunk to the next. Instead we use whats called Reverse Resumable A*. Reverse means simply it goes from goal to start, as I already said. Resumable means that after it finds the chunk the base pathfinder is interested in, we keep all its nodes in memory. The next time the base pathfinder creates a new node and needs to know its distance estimate, we simply look at the abstract nodes we kept from the previous search, with a good chance the required abstract node will still be there (after all, one abstract node covers a large part of a chunk, often the entire chunk). Even if the base pathfinder creates a node that is in a chunk not covered by any abstract node, we dont need to do an entire abstract search all over again. A nice property of the A* algorithm is that even after it 'finishes' and finds a path, it can keep going, exploring nodes around the nodes it already explored. And that's exactly what we do if we need a distance estimate for a base node located in a chunk not yet covered by the abstract search: We resume the abstract search from the nodes we kept in memory, until it expands to the node that we need. The video below shows the new pathfinding system in action. Blue circles are the abstract nodes; white dots are the base search. The pathfinder was slowed down significantly to make this video, to show how it works. At normal speed, the entire search takes only a few ticks. Notice how the base search, which is still using the same old algorithm we've always used, just 'knows' where to go around the lake, as if by magic. https://cdn.factorio.com/assets/img/blog/fff-317-long-pf-after.mp4 Since the abstract pathfinder is only used to provide the heuristic distance estimates, the base search can quite easily digress from the path suggested by the abstract search. This means that even though our chunk contraction scheme ignores all entities, the base pathfinder can still go around them with little trouble. Ignoring entities in the map simplification process means we don't have to redo it every time an entity is placed or removed, and only need to cover tiles being changed (such as with landfill) which happens way less often than entity placements. It also means that we are still essentially using the same old pathfinder we've been using for years now, only with an upgraded heuristic function. That means this change shouldnt affect too many things, other than the speed of the search.

Bye bye TOGoS - TOGoS

Hi everybody! I'm going to be resigning from official Factorio staff after today to start a new job closer to home. The main reason for this switch is that working entirely remotely turned out to be something that I wasn't able to handle all that well. But also, my primary contribution to the project, the programmable map generator, is complete, stable, and pretty well understood by at least one other person, so timing-wise this seemed a good point for me to move on. To working in a cube farm writing Android applications for treadmills, apparently. We'll see how that goes! It's been an honor to be part of this awesome project and to leave my imprint on it. And working on a large and pretty well-managed C++ codebase, full of things done just a bit different than I had ever thought to, has been mind-opening. I also want to thank the community for your continual patience, honest feedback, and the occasional bit of pressure that you put on us to make the game as good as it can be. I'll continue to read the Friday Facts every week, lurk on the forums, and probably update documentation here and there. Hopefully I'll find time to crank out some terrain-altering mods of my own. And I'm looking forward to seeing what else y'all do with it, too. (Which includes working through a backlog of mods -- I have yet to get to the space exploration part of Space Exploration!) Peace out for now.

Community spotlight - 13x9 Micro Factory - Klonan

Over 100 Friday Facts ago we covered DaveMcW's 9x14 Micro Factory (FFF-197). While it may have taken over 2 years, he has improved his design even further, and the result is just as impressive as before. https://youtu.be/9dzQge6pe2o He offers some more explanation of his Micro Factory in this forum post. As always, let us know what you think on our forum.

[ 2019-10-18 11:05:32 CET ] [ Original post ]

Bugfixes

• Fixed a crash that would happen on loading certain saves made in previous versions. more
• Fixed entity selection could desync from mouse cursor when switching to cutscene controller in multiplayer. more

[ 2019-10-16 15:14:09 CET ] [ Original post ]

Features

• Added interface option to adjust the number of shortcut bar rows that are visible on the screen.
• Added ability to shift click a research in the technology screen to start that research.
• Allowed setting filters with the ghost cursor.

Changes

• Biters and Spitters will no longer collide with other biters/spitters. more

Graphics

• Added new remnants for several entities. They are still work-in-progress and subject to further change.

Bugfixes

• Excluding runtime fluid mixing check from assembler migration that caused some crashes when loading a save with mixing in it.
• Fixed landfill map color on old saves. more
• Added migration to recalculate tile transitions when tile layer definition changes in tile prototype. more
• Fixed that artillery remote failure sounds could be duplicated in some cases. more
• Fixed that the game would still process mod dependencies for disabled mods. more
• Fixed that underground pipes with different length could sometimes connect one tile further.
• Fixed that the cursor would appear in the wrong position after textbox alignment was changed by scripting. more
• Fixed placement of scrollbars around textboxes. more
• Fixed a crash related to teleporting biters during the ai-completed events. more
• Fixed that non-square crafting machines without fluid boxes didn't rotate correctly. more
• Fixed that the game would freeze when trying to find automatic artillery targets with very high levels of artillery range. more
• Fixed tile ghosts sometimes overlapped on edges which created visible lines. more
• Fixed that the on_gui_switch_state_changed event would fire twice in some cases. more
• Fixed wrong damage bonus values in tooltips of combat robots and units in a different force. more
• Fixed that the research screen would show a technology as "available" when it was queued. more
• Fixed that LuaEntity::last_user didn't support writing `nil`. more
• Fixed that mod GUIs could show on top of the technology screen after loading a save. more
• Fixed a crash when using the /screenshot command. more
• Fixed that the --disable-migration-window command line option didn't always work. more
• Fixed that pumps had a drain when using a non-electric energy source. more
• Fixed a bug in fluid system splitting.
• Changed order of pipe connections to avoid previous cases of fluid mixing. A.k.a Boskid's deferred pipes.
• Offshore pumps now set fluid filter automatically based on produced fluid. more
• Fixed crash when closing shortcut selection list while dragging. more
• Fixed that biters could get overloaded by artillery and stop moving. more
• Fixed that biters could get stuck during attacks. more
• Fixed that biter pathfinding could cause unreasonably large save files. more
• Fixed that biters would attack in a single file due to their colliding with each other. more
• Fixed that personal roboports would function with literally no power.
• Fixed migrating pre-0.17 maps with detached characters that had a grid armor in quick bar would corrupt game state. more

Modding

• Added optional flying robot prototype property "max_speed".
• Added light_renderer_search_distance_limit to utility constants.

Scripting

• Changed LuaEntity::color to also work for cars.
• Changed LuaStyle::padding, margin to also accept arrays of padding values.
• Added optional "unit_number" to on_post_entity_died event.
• Added support to teleport car entity types between surfaces.
• Added LuaEntityPrototype::call_for_help_radius, max_count_of_owned_units, max_friends_around_to_spawn, spawning_radius and spawning_spacing read.
• Added LuaForce::research_enabled read.

[ 2019-10-15 20:36:26 CET ] [ Original post ]

Read this post on our website.

Map editor Lua snippets

In the last few weeks, we've really accelerated our work on the campaign. We've been pushing ahead a lot with both the scripting and blocking out the physical level design.One of the problems we've come up against a lot, is that we often need to perform custom edits to the map, which are quite tedious, but not common enough to add a new tool to the map editor for them. For example, something like "disable all the spawners in this region". This kind of problem is easily solved with a little bit of custom Lua code, but getting the specification of the area we want to edit into Lua is a painful process of noting down and typing out location coordinates. It is also easy to lose track of these Lua snippets, as there is no good place to save them. To solve this problem, we decided to add a Lua snippet tool to the map editor. This tool will let you drag your cursor over an area, and it will then run your custom Lua code on that area. The snippets are named, and saved in your player-data.json, so you can keep them around for later. https://cdn.factorio.com/assets/img/blog/fff-316-snippet.mp4 For example, this simple snippet replaces trees with biters. Currently, there doesn't seem to be a very big scene for community made custom maps/scenarios with custom maps, and we're hoping that the example from the campaign once released, as well as the much improved editor we have in 0.17 will encourage more people to give this a go.

Apple signing woes

As some of you may have heard, Apple is introducing a new system called notarizing to their MacOS apps. This is a system where you sign you packages and upload them to apple so they can run something akin to a virus scan, and mark it as approved. As of the new MacOS Catalina version, this will be mandatory. Our friends at Valve were nice enough to send us a warning with some info about the process. Up until now, our MacOS binaries haven't even been signed at all, so this seemed like a good time to get on that. To be clear, you could, and can play unsigned factorio binaries on MacOS, but you need to change your security settings to do so (or so I thought). To test, I grabbed the .app of 0.17.69, signed it, uploaded it to apples notarization server, and got the notarization process to succeed (eventually). I then copied it onto a completely fresh, default settings install of macOS Catalina, double clicked it, and it ran, with no security prompt. Problem solved, right? Well, after that I decided to do a sanity check, and copied over the completely unsigned binary of 0.17.68, and it ran just fine as well, also with no security prompt. So, at this point, it seems like we don't really have a way to test this process, so all we can do is set things up correctly to the best of our abilities, and see if it works for people. The next Factorio release should include signed and notarised macOS binaries, so if anyone has problems with 0.17.70 security warning on macOS, please let us know.This whole process has been rather slow and painful (just getting the notarizing tool working was a bit of a saga in itself), and doesn't inspire much confidence in Apple's developer ecosystem, so if anyone at Apple is reading this, please, please, make this process better. Also to make it known again, we are still looking for a macOS developer to join our team, so if you are interested or know someone who is, please checkout the job listing.

Non-colliding Biters

For a long time we have been improving the biter pathing, with many iterative changes and tweaks. However we have long had a problem in the moment where a group of biters encounters the players base. I am sure the scene below is familiar to all Factorio players: https://cdn.factorio.com/assets/img/blog/fff-316-biters-collide.mp4 This mating dance or whatever it is, has long been a thorn in our side. The reason behind it is quite logical. When moving, the biters are in a group, and everything goes smoothly. However when they see an enemy, they are 'distracted' by it, and individually try to attack it. Since the biters are now moving and pathing as individuals, things start to get messy. The biters find a path, but then there is another biter in the way, so he tries to move and turn around, but there are biters in the way there too, and each of those biters are trying the same thing, so it all goes gets clogged up for a while. The solution we have decided, which some might consider a 'hack' is that we simply don't make biters collide with other biters. In the engine this was a rather simple change, and was already possible just using normal mods. The result speaks for itself: https://cdn.factorio.com/assets/img/blog/fff-316-biters-no-collide.mp4 There is already some 'separation' logic in the engine to keep biters from getting too close to each other, so in the end we get away with a lot of the benefit of no collisions, without the immediate/obvious problem of biters infinitely stacking. There might be some smaller issues to pop-up with this change, and maybe some balancing tweaks to be made, but we are happy with the outcome so far.

Twinsen is going to Poznan Game Arena, Poland

Next week I'll be in Poland for 3 events:

• I'll be visiting the consumer expo and indie areas of Poznan Game Arena (18-20th Oct).
• I'll be going to the talks and parties of Game Industry Conference (17-20th Oct).
• I'll be attending some workshops during Game Design Summit (16-18th Oct).

If you are in the area and see a guy with a Factorio hoodie, it will most probably be me. I am looking forward to meet any fellow developers or fans attending.

Ludum Dare entry

Over the weekend, two of us (wheybags + Abregado) entered the Ludum Dare game jam. A game jam is an event where people make a game as completely as can be in a fixed time-frame (in this case 48 hours). We ended up making a rather Factorio-appropriate gear puzzle game. Check it out if you're interested.
As always, let us know what you think on our forum.

[ 2019-10-11 15:36:39 CET ] [ Original post ]

Read this post on our website.

New test servers

We recently bought and assembled some high-end PCs, with the hope to gauge the performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core.
We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63. As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better! As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start. So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make. So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.

Server room organization

Alongside building the new servers, we also had some new storage shelves installed in the server room. So this week I spent some time moving the servers from their old home (of the floor) onto the new racks, and moving a lot of the 'PC junk' (cables, mice, fans, spidertron, keyboards, SSDs, headphones etc.) that had accumulated around the office into the server room.
We now have 10 servers, some run tests, some do the deployments, etc. We are hoping to reduce this number in the future, as we can have 1 beefy PC do the work that is currently handled by multiple older/slower ones.

Community Spotlight - Nauvis Invasion

This week I spotted a Reddit post by /u/Bladjomir. It is a video of this modded base after he had respawned all the biter bases. I was really in awe at just how different the game can 'feel' once you started adding and combining mods (especially when it is coupled with the classic Red Alert 2 soundtrack). So I messaged Bladjomir asking if I could include his video in this Friday facts, and he took the time to create a brand new video for us to showcase: https://youtu.be/Qekvxw9t7zo As someone who grew up playing the old school RTS games, these videos really hit on some nostalgia for me. What I am really proud of, on behalf of the team here, is just how well the game supports mods. It really is just so amazing to me that we have a engine now that can be extended and overhauled by mods and just works. There will be a time when Factorio base game is finished, when we have made the game we set out to make. Yet even though our vision is complete, anybody can come along and implement their own ideas, rework what we have done, and even (theoretically) turn off the base mod and make essentially their own new game in the engine. So in the (super) long run, I believe that mod support will be critical to keep the game and community alive, and continuing to improve the modding capabilities of the game is a strong possibility for post 1.0 support/updates. As always, let us know what you think on our forum.

[ 2019-10-04 12:53:34 CET ] [ Original post ]

Read this post on our website. Hello, technically this post is the Pi Friday Facts, but unfortunately we can't think of anything special to do... maybe someone can make a combinator cake... that can calculate Pi?

0.17 stable

We released 0.17.69 as stable this Tuesday. It seems it all went very smoothly, no avalanche of crashes, and only a handful of technical support emails about updating video drivers.
Apart from stable, essentially no development work has happened this week; nearly everyone is on vacation (I am even writing this as I sit in the airport waiting to fly to London for a wedding). We're hoping that at the start of next week, with all the relaxation over, and the pressure of stable off our shoulders, we will get cracking on the next updates with renewed energy. In fact I might be a little optimistic in saying this, but I think we are in for some exciting times here in the team. Before now, we have always done a cycle of having the whole team on development for a few months, then the whole team bug fixing for a few months. This binary approach is what gives us the traditional 'stable' and 'experimental' labels. This is not to say that all bug-fixing would stop once stable it out, quite the contrary, but this has been the general strategy. What we are planning, if the logistics of it turn out okay, is to have significantly smaller feature releases, containing only a handful of new features. This is to have a sort of mixed cycle, and a mixed cycle in two similar ways:

• Some developers will be on bug-fixing while others are on development.
• The individual weekly/monthly work of a developer will have a more balanced mix of development and bug-fixing.

For example, while one developer works on a feature for the next feature release, another will be bug-fixing the features in the current release. This is only practically possible if the feature release frequency is relatively high. This new structure has been a long time brewing in our minds, and we think now is the right time to try it out. With the GUIs we really need to do quick iterations and receive fast feedback to the changes. The traditional release flow meant that we could add a new feature to the game, and players wouldn't get their hands on it for months. Then once it is released and we start getting feedback on it, extra time is spent just re-orienting ourselves to the code and how it was written. If the feedback is given expediently, the rework and improvement is much more efficient. Furthermore, I think it is more psychologically effective to work on a mix of bug-fixing and development. This is just theory now, but grounded in some observations I have made over time. Development work, a new feature, new GUI, etc. is generally a long-form creative process. New systems have to be created out of pure thought-matter, ideas for implementation have to be evaluated and determined, and it also involves a lot of 'background processing'. Feature development always has more room for extension, and it is very hard to say 'It is finished'. It is also quite a subjective result, so sometimes it is hard to know if you 'did a good job'. Bug-fixing on the other hand is very short form and challenge oriented. It is like investigating a murder mystery, and really feels like a complete story. Tracking down a problem inside the game engine engages a logical part of your brain, trying to piece together and backtrace where the fault is occurring. Generally the bug has a very clear 'win-condition', and you can close the game and let your mind rest peacefully. The result of a bug-fix is grounded strictly in objective measurements, so you can be reasonably sure if you 'did a good job'. So these two parts of the job are in a way, quite distinct and separate: Development is a long-form creative process; Bug-fixing is a short-term logical process. From all this, my reasoning is that focusing on only one for a long period of time leads to quicker mental fatigue, and that a balanced workload will keep us happier and more productive. In essence, doing development lets our bug-fix circuits rest, and doing bugs lets our development battery recharge. There are also some pragmatic reasons I think the smaller/quicker releases will make things move along more smoothly:

• Bug-fixes after stable will be released within a short time-frame.
• The flow of bugs coming in will be less extreme, no more massive waves with each major release.
• There will be less 'blocking', where unfinished features delay a release. They will just be scheduled for a different release.
• Feedback will be more focused, so it is easier for us to evaluate.

At the start of the year, I read a book called "Rolling Rocks Downhill" by Clarke Ching. It is a book about software project management, it was quite an enjoyable read, and gave me a lot of inspiration to try and optimize our development effort. At that time we were just wrapping up 0.17, so there wasn't a whole lot of room to make changes to the way we do things. Now that we have stabilized 0.17, and with it, completed the 'traditional' cycle, there is opportunity for a fresh approach. I guess I will give the book another read next week... Anyway, thanks to all of you for such a great year so far, thanks to all our friends on the forum and throughout the community who have helped us in the great bug war of 0.17, and as always, let us know what you think on our forum.

[ 2019-09-27 10:30:11 CET ] [ Original post ]

Read this post on our website.
It has been 6 months and nearly 70 releases since we first launched 0.17 to the world. Now is the time to let is be enjoyed by all the players of the game. We are going to be continuing our work on 0.17 over the next few months, with small experimental releases of new features, and finishing all the GUI reworks.

New map editor

The new map editor can be accessed directly in-game with the /editor command. Packed with new features and improvements, such as cloning tools, multiple surface support, and time control. The new editor also allows collaborative map editing in multiplayer. More details: FFF-252.

Redesigned enemies

The enemies in the game, the native inhabitants of the planet, have received a major facelift in this update. As well as a graphical overhaul, the attacks and balancing of the spitters and worms has been revised, incorporating skill-based elements and some tactical decision making. More details: FFF-268, FFF-279.

Automatic mod downloads

Now when trying to join your favorite server, you can directly sync your mods with the server from in-game, and automatically join once they are all installed. This massively reduces the friction for joining modded servers. The in-game mod browser has also been redone to help find new mods and manage your installations.

Optimized fluid system

We have massively optimised (and parallelized) the fluid update in 0.17. In effect each section of pipe can be updated independently of other pipe sections. This comes as welcome news for any megabase planners out there. Furthermore we have limited each pipe section to only a single fluid, and will actively block any placement that could mix fluids, to prevent the catastrophe of mixing water into your oil system and bricking the whole system. More details: FFF-271.

Rewritten rendering backend

This release has a completely new rendering backend, written almost from scratch to our exact requirements. The new engine takes advantage of more modern GPU features and is highly optimized. What this means is that the game can now work with much less VRAM and allow players with older videos cards to still enjoy the game in high resolution at 60 FPS. More details: FFF-251, FFF-264, FFF-281. Due to the more modern architecture, some issues may be present with certain hardware configurations, please see this forum thread if you experience any graphical problems.

New introduction scenario

We have added a completely new introduction scenario on a hand crafted map. It gives new players some simple goals and provides a place for them to experiment with a smaller toolset than Freeplay allows. The scenario is open ended, so that players may experiment with larger bases. A separate techtree is provided for this purpose which includes some infinite research. Our companion robot, Compilatron, is also present to help guide the player. More details: FFF-262, FFF-306.

Construction shortcuts

We have added some powerful shortcut keys, which use the intuitive layout we are all used to. Now you can undo your last action by pressing CTRL + Z, quick equip a cut tool with CTRL + X, do quick copy/paste actions with CTRL + C/CTRL + V, and assign robots to upgrade your factory with the new Upgrade planner. More details: FFF-255.

New GUI

We added a new GUI skin, along with the first batch of GUI reworks. The new GUI aims to unify the look and feel of the game, and provide a consistent visual basis for the players interactions with the world. More details: FFF-243.

Much more

As always there are a ton of smaller features and changes to discover in this latest major update. You can read the changelog in game for a full rundown, or checkout the release notes here. We have our plan moving forward for the next version of the game, which you can check out here.

[ 2019-09-24 12:33:48 CET ] [ Original post ]

Read this post on our website. Hello, We have had quite a peaceful week here in the office. Last night we went out for a burger and a beer as a last meal with Ernestas before he flys back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.

Light at the end of the bug tunnel

It seems our 'news' of some programmers taking a break made headlines this last week: Work slows on Factorio while a dev levels his priest in WoW Classic. Even though he is still not level 60, Kovarex found some time to fix a few more bugs, which seemed to go very smoothly, as he is feeling super recharged. We also had Boskid come to visit the office, and he helped us do some intensive testing and test writing. Working together with Dominik, the two managed to find and fix a lot of bugs related to the fluid mixing system. It was certainly more efficient having someone doing QA inside of the office, so it seems our team might be getting a bit bigger. With the last 'blocking bugs' resolved, the bug war is almost at a close. The count on the forum is down to only 16, and the automatic crash reports are looking okay:
We have released version 0.17.69, we are optimistic that this version may be able to be called stable. While this is almost over 1 month after our first 'stable candidate', we are confident now that this version is more stable than 0.16.

Landfill update

In last week's FFF we presented the new landfill terrain. We felt relieved by having another task done in GFX. One of the first reactions in our forums was the idea by eradicator of rotating the grid to 45. It followed a fast mockup made by ThreePounds. The idea was good, and apart from us, some people on the forums agreed. The modification of our sources to get this rotation done was very affordable to us, so we decided to make it official and here we are now presenting it:
This solution is nicer than the 90's one because basically it doesn't interfere with the tile grid of the game, and provides a nice loose space feeling in the general composition. I just felt a bit guilty for not coming with the best approach from the beginning, but luckily our community is very keen to give us feedback on any aspect of the game. Thanks guys for the feedback. As always, let us know what you think on our forum.

[ 2019-09-20 12:27:06 CET ] [ Original post ]

Read this post on our website.

Fluid mixing saga

Hello Factorians, Today I would like to talk to you about my favourite subject - fluid mixing and its prevention. It is a new mechanic introduced in 0.17 that seemed quite simple at first, but has been giving me nightmares ever since. A while ago I took on the task of updating the fluid system (FFF-260). The way it works in 0.16 is that the fluid boxes (the thing that holds the fluid and is contained in entities like pipes or refineries) had no organisation whatsoever except their connections. They would sit there and do nothing and then once per update send fluid somewhere. It had it's issues especially with symmetry, and when you happened to put some fluid where it did not belong, you could end up requiring major demolition works. My task was to develop a better algorithm to move the fluids, and a very very optional side task I had in mind was to do something about the fluids getting to wrong places and mixing. We started by organizing the fluid boxes into systems (connected FBs make a system) managed by a special fluid manager, and optimizing the heck out of it (FFF-271). Soon after, I started working on the new algorithm and anti fluid-mixing. Until then nobody really considered preventing the fluid mixing seriously as it did not seem possible. But when I thought about it, it did not seem that hard. The idea is to simply not allow any action that would lead to fluids getting where they are not supposed to go. When you build a steam pipeline, you should not need nor want it to touch another fluid. In principle, it would only require a few quite realistic mechanisms:

• A connected block of fluid boxes would either be fluid-free, or it would be locked to one fluid.
• Two such blocks can connect only if they are compatible - either one has no fluid lock, or they have the same fluid.
• An assembler can only set a recipe if it is compatible with the fluid locks on its fluid boxes.
• Have a migration from old saves that can contain mixing.

By creating the fluid systems right before, number 1 was almost finished and we only needed to assign the lock. It would be set either by a fluid, or by a 'filter', which is a fluidbox that is set to use a fluid - such as a water pump using water, or assembler having some inputs/outputs given by a recipe. After a while I had both the fluid algorithm and the mixing done (FFF-274). The mixing was not that easy (like 5x more complicated) but it worked pretty well. As for the fluid algorithm, V453000 and Twinsen found some issues with waves on a macro scale, and because it was right before releasing the 0.17 experimental, we decided to hold it off on it for the time being (we have a new version now that seems okay, but has to wait for 0.17 becoming stable first). The mixing made it through though and seemed quite finished. It turned out that the work on it was at most one tenth complete.
Some difficulties appeared already before the initial release, but that was only a hint of what would come later. One by one, then ten by ten, bugs started coming. The problem is that as often as not, they were not just little issues with simple fixes. Instead, over and over, they turned the current solution on its head and the code had to be completely rewritten in order to account for the new case. As of now, almost exactly half a year and many rewrites later, it is still not fully bug free. The number one issue was with Assembling machines. It turned out that their code was pretty messy and does not simply allow the checks I needed, so it had to be refactored. The next problem was that the check was not only required when setting a recipe on an existing assembler - as I naively thought - but in about one million different situations I would not dream existed. Building a fixed recipe assembler. Reviving an assembler. Rotating. Blueprint of an assembler. Blueprint with a recipe and a rotation placed over a ghost with a non-default rotation during a full moon. Teleport. Script building. Copy-paste settings. Any combination of these. Pretty much every case would go through different paths in the code and behave entirely differently. Fixing one would break another and so tons of tests had to be written. When these cases finally worked, it turned out that doing these operations when they fail (e.g. cant rotate because it would cause mixing) brings another wave of issues. And then mods come and the complexity multiplies. All this, although in a more simple form, had to be done for all other entities that can use fluid too, such as inserters (mods...). Another number one issue are underground connections. When playing, you would not think twice about them but on a closer look they are all but simple. They have this (cough) uncomfortable feature (want to shoot myself) that you can build another underground pipe between them (or take it out) and a complex reconnection logic jumps in. It means that based on building order, connections are established and reestablished differently. This is a big thing when building a blueprint with many pipes, or loading a save game. But the largest issue is one tiny corner case with huge implications. Have two underground pipes that have different fluids, but are split by a third, and it gets removed. Until now mixing was theoretically completely avoidable, but here it was and there was nothing to stop it.
As a result, a new concept is introduced - a blocked connection. An underground connection that would normally connect but cant. Establishing it is the easier part. But when does it get fixed? An entity miles away gets rotated, that splits a fluid system, disconnecting the blocked connection from a fluid filter on the other side, and the connection should unblock. But even something as simple as a rotation contains fluid fixes and re-establishing of fluid boxes and if it fails, it still fixes the blocked connection in the process and it cant be undone... You get the picture. And we are still talking about underground pipes, while anything can have underground connections, including said assemblers, which the previous code did not consider at all. The complexity just goes deeper and deeper, and Rseding is probably right that we should have never gone this way at all. So the bug fixing has been basically running in circles - clearing one batch of bugs, thinking that those were the last ones and the ordeal is finally over, only to find another batch (ideally from some bizzare modder idea) a few days later. Many times I wished that mods never existed. Nor multiplayer, or any players at all for that matter. About two months ago all seemed really fine, with basically no reports and just a few crashes in the automated crash reports. At that moment another nightmare materialized in the form of a talented volunteer bug tester named boskid, who took on a personal crusade to break the fluids to dust (I actually imagine him sitting in his dark room with evil laughter, dreaming about making my next day worse than the previous). In all seriousness, he has done a great deal of work with his bug testing, creating bizzare modded cases and testing scripts, and deserves a big thanks. He is actually coming to our offices next week, so follow the news for reports of developers falling out of windows.
An example of a nice configuration he found (and I cant fix). The whole time we were taking the offensive approach to mixing - crash the game when it happens - so that we know about bugs to fix them. Recently we have decided to put a stop to it and have the mixing automatically fix itself once it is detected, eyeing the end of this episode. Right now I have 3 mixing bugs on the list and I am sure those are the last, and mixing will be done (lying to myself is a way to cope with it) and the new fluid algorithm can come soon after :).
(And of course, boskid found a way to use the automatic mixing fixing as an evil PVP tactic.)

Landfill terrain

This week Ernestas came physically to the Wube office to spend some time with us (he is normally working remotely), so we are taking the chance to finish things that we had in the drawer that needed closer communication. One of those things is a specific terrain for landfill. As you know we were using grass for it. Not anymore.
In Factorio we have a clash of two worlds:

• The natural and organic planet. Off-grid with multiple terrain types, trees and doodads.
• The world of the factory, which is mathematical, regular, modular, and totally attached to the grid.

This new terrain represents a boundary in between those two worlds. The grid on its surface tries to express the artificiality of it, like mechanically pressed with some sort of industrial stamp. The imperfections of the grid and its irregularities are holding this man made terrain into the realm of the natural environment. For now the sound of the landfill action is not solved, 'soon' well take care of it. As always, let us know what you think on our forum.

[ 2019-09-13 11:37:14 CET ] [ Original post ]

Read this post on our website. Hello, Another week has elapsed, which brings us another week deeper into the declining weather of autumn.

Even more Remnants

In FFF-288 we proposed that we are considering multiple approaches to remnants, and in FFF-293, we described that we are choosing the balanced solution which does not obstruct the movement of a player if an entity is destroyed. We have recently finished quite a few which we would like to show you.
Compared to some of the early versions of remnants, you can now really recognize which entity got destroyed.

General

If you have been following the progress of remnants in 0.17 experimental versions, you have probably noticed that a lot of them have been changed quite drastically. In general we are trying to hit the balance between having the remnant look destroyed enough, yet still very well recognizable which entity it was. This is especially difficult for tall entities as the player has to be able to walk over their remnant, the extreme case being train stop for which we are also implementing a special solution...

Train stop

Train stops are recognizable because of the top coloured part, and the tall scaffold that holds it. Giving the station a colour mask was trivial graphically, but our dear posila needed to add a bit of code to support remnants to have colour masks. Keeping the tall tower is a bigger problem as if the tower is a part of the remnant sprite, the player would be able to just walk over it, and trains would always show on top of it as well. We chose to split the train stop remnant into two layers so the illusion of height is kept.

Remnants with colour masks

We also used the colour masks for basically everything the player has the ability to change the primary colours of. It includes the Locomotive, Turrets, Car and the Tank. Once the entity dies, the colour of the given entity stays with the remnant.

Walls

We have updated the wall sprites as well, as we wanted to make the walls more like broken walls instead of random rubble, to break their line less. The walls are by far the most destroyed entities besides turrets so they can look repetitive quickly. To improve this, wall remnants have several sprite variations. Compared to 0.16, whenever any entity gets destroyed, the player can tell which entity it was. We believe this makes rebuilding your factory much more fun, and seeing your things get eaten less frustrating. On top of that, we plan to utilize the remnants to a large degree in the campaign for 1.0 for half-destroyed factories to be found and explored. We will be adding more remnants and improving some further to make this effect even greater than it is currently in 0.17.

Community spotlight - Industrial revolution

In the past month I had the opportunity to balance test an overhaul mod called Industrial Revolution. Now, after around 1,000 hours of development, Deadlock has finally released the mod to the public today. In the around 65 hours I have spent playing the mod, I fell in love with it and I want to present it to you here.
Click to see full resolution My current base, machines from all ages forming one big factory. The mod gives more depth and length to the vanilla experience by changing the progression throughout the entire game. You work through ages of technology, always chasing the milestone of the next material. Just like in vanilla, you start out with the stone age and classic burner machinery. Automation is key, even in the stone age; the mod adds new intermediate products to all crafting steps. To allow automation at this stage, the mod provides burner assembling machines and labs.
However, instead of getting to power as soon as possible, the next goal is bronze, an alloy made from the two starting resources, tin and copper. After improving the factory with bronze machines and automating logistics science packs, the iron age is not far away. With it come steam power, oil processing and trains, allowing rapid expansion of the factory. The steel age unlocks better ore refining techniques and powerful machinery, paving the way to the rocket. Beyond the ages, the mod introduces new types of turrets, each with their advantages and disadvantages. On top of all these gameplay differences, the mod boasts incredible graphics and good sounds.
When I started testing the mod, I was expecting a long-ish casual playthrough with some different recipes. What I got instead was an addiction and a huge appreciation for the concepts the mod adds and changes: Different challenges, more logistic puzzles and completely new recipes refreshing the whole experience. The extended burner phase in the mod introduced an unconventional problem to me: Fueling burner inserters and assemblers. Combined with my spaghetti approach and limited space due to the enemies lurking in the desert around me, fueling inserters became a challenge that I spent hours on. My proudest creation is an electric motor assembler, it needs four inputs, all supplied by burner inserters that need to be fueled by other inserters. The assembler stands to this day:
Another great change by the mod is how it deals with ore processing. Ore processing allows the player to improve how many ingots can be produced from ore, up to producing twice as many ingots. This happens in steps, every age introduces a new technology to refine ore. So, getting more iron means building an extra ore processing step and simply connecting it between the last processing step and smelting. Each refining setup has its own challenges such as multiple outputs or needing a catalyst, so it becomes an interesting puzzle to get more ingots. The new ore processing flows well with the rest of the game; often times I found that I needed an ore refining byproduct and more ore refining at the same time. This is a big improvement compared to the vanilla way of getting more plates: Mine yet another ore patch and smelt it in the same old boring way.
Click to see full resolution Gold being mined, crushed and purified to increase its yield before smelting it, all in the same area. Of course, adding more intermediates also means that you run the risk of only ever needing a product for one other recipe. The mod manages to avoid this pitfall, I find myself routing belts and pipes through half the factory because an item is needed in multiple different places. Another possible problem is the long burner phase, it could delay automatic construction. This is prevented by the addition of very early personal construction robots. The clockwork punkbots can be used with an automatically refuelling burner generator that fits into heavy armor, all available in the bronze age. Vanillas boring defenses become more varied with the new turret types. The first turret you unlock is a bronze scattergun turret, it works similarly to a shotgun. These turrets are great at taking out groups and still make up a large part of my defenses. However, their range is lower than that of medium spitters, therefore minigun turrets and laser turrets guard my more commonly attacked areas.
All in all, the mod overhauls vanilla to provide fresh challenges, is well balanced and on top of that nice to look at. I hope you will have as much fun playing the mod as I did, so try it out now that it is released (Mod portal page). As always, let us know what you think on our [url=https://forums.factorio.com/viewtopic.php?f=38]forum.

[ 2019-09-06 19:29:49 CET ] [ Original post ]

Changes

• Pressing ESC while catching up to a multiplayer game will open the menu with most options disabled. more

Bugfixes

• Fixed migration bug that doubles up to one sample worth of statistics when a save is loaded from before 0.17.44.
• Fixed production statistics not calculating the totals correctly. more
• Fixed that on_built_entity wouldn't be fired for built blueprint entities. more
• Fixed a crash when right clicking with the map editor tile area tool. more
• Fluid mixing does not crash the game anymore and is fixed the same way as on migration.
• Fixed some Lua tables would be incorrectly interpreted as Lua arrays. more

Modding

• Changed pipe_covers to be drawn with secondary sprite draw order 64 resp. -64 to prevent "z-fighting" issues. more

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

[ 2019-09-04 18:10:20 CET ] [ Original post ]

Graphics

• New chemical plant graphics.
• Heat pipes (also in reactors and heat exchangers) glow with high temperatures.

Changes

• Pressing ESC while catching up to a multiplayer game will disconnect instead of opening the menu. more
• An entity can't be teleported into a position where pipe connections would overlap. more
• The camera will zoom to center instead of zooming to cursor in God controller, Ghost controller and Spectator controller.

Features

• Added an area tool to the map editor tile editor.
• Added highlighting of the source entities when selecting areas to clone in the map editor.
• Added a setting in the map editor to hide entity health bars.
• Added a setting in the map editor surface editor to generate new chunks using lab tiles.
• Added support to manipulate items on the stored character while in the map editor.
• Added infinity settings for automatically controlling items in the map editor.
• Changed the infinity chest so it can also spawn hidden items.

Gui

• Rearranged key-bindings in Control Settings to different categories. Improved and added more descriptions of key-bindings.

Bugfixes

• Fixed cloning ghost entities with rotation didn't work correctly. more
• Fixed that the lab GUI wouldn't update when the technology being researched changed. more
• Fixed loader front patch and back patch were not sorted correctly when drawing. more
• Fixed wire connection distance sometimes being inconsistent. more
• Fixed a rotation of modded pump with regard to blocked pipe connections. more
• Prevented a crash resulting from teleporting a pipe to a fluid system with blocked connection. more
• Fixed that the filter GUI tooltip would flicker when changing tabs. more
• Fixed fluid mixing from creating an underground pipe by script into a blocked fluid system. more
• Fixed fluid mixing from copy/pasting an infinite pipe next to a different fluid. more
• Prevented playing Jesus and changing water into other fluids. more
• Fixed assembler ghost fluid filters disappearing through loading. more
• Cliffs sections which are fully marked as indestructible can't be exploded. more
• Fixed interaction of underground pipes with modded length. more
• Fixed fluid mixing caused by fluid producing furnace. more
• Fixed that opening the technology GUI in the same tick as the entity tooltip being shown didn't work correctly. more
• Prevented rotation of a modded assembler with a blocked pipe connection that results in fluid mixing. more
• Fixed train condition button indentation not being properly updated under special circumstances. more
• Fixed that train schedule waypoint was considered to be passed when train departed the related rail rather when it entered it. more
• Fixed that storage tank entities ignored pipe_picture property in their fluid box definition. more
• Fixed improper action selection for UI actions for key bindings differentiated by modifiers only. more
• Fixed a crash related to a modded assembler and fluid mixing. more
• Applied the cannon shadow to the artillery wagon, fixing some unintended highlights. more
• Fixed crash when removing electric pole. more
• Fixed event handler could try to register events twice in some cases. more
• Fixed blueprinted locomotives would preview as snapped to train stop. more
• Fixed items spilling on the ground when using fast entity transfer while robots are trying to insert into the player. more
• Fixed hand reserving a non-empty slot in some situations when player inventory auto-sorting is disabled.
• Fixed custom lua slider sometimes initializing with the marker in the wrong position. more
• Fixed "list-box" and "drop-down" custom GUI elements would not update selected index when changing its items programmatically. more
• Fixed that the map editor 'instant blueprint building' would fail to place trains correctly.
• Rail signal that is to be reserved by circuit network doesn't allow train to go through even when the block is already occupied by the given train. more
• Rail signal will change from reserved by circuit network state to closed state when train is manually placed into the block it guards. more
• Fixed train stop name in map not being positioned properly. more

Modding

• Changed default value of LoaderPrototype::structure_render_layer from "lower-object" to "transport-belt-circuit-connector", in order to be consistent with other on-belt structure sprites.
• Different wall types will connect visually by default. If this behavior is not desired for a wall prototype, set it unique "visual_merge_group". more
• Added optional random_variation_on_create to all simple entity prototypes.
• Pump was changed to not expand its bounding box when connected to pipe. Collision box for vanilla pump was adjusted to reflect this change.

Scripting

• Added additional filtering to LuaGameScript::get_filtered_..._prototypes() functions.
• Added optional "tags" to entities in blueprints and entity ghosts.
• Added optional "tags" to script_raised_revive, on_built_entity and on_robot_built_entity events when reviving ghosts.
• Added LuaEntity::tags read/write for entity ghosts.
• Added LuaItemStack::get_blueprint_entity_count(), get_blueprint_entity_tags(), set_blueprint_entity_tags(), get_blueprint_entity_tag(), and set_blueprint_entity_tag().
• Added on_force_friends_changed and on_force_cease_fire_changed events.
• Added "area" to on_chunk_charted and on_sector_scanned events.
• Added "position" to on_chunk_generated event.
• Added area to the LuaChunkIterator operator() return value.
• Added LuaPlayer::toggle_map_editor().
• The script_destroyed_entity event is raised for map editor instant deconstruction.
• Added LuaEntity::tick_of_last_attack and LuaEntity::tick_of_last_damage write.

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

[ 2019-09-03 12:55:23 CET ] [ Original post ]

Read this post on our website.

A few bugs left...

WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth. This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest... We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs. Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.

Glowing Heat pipes

Heat pipes were released with 0.15, since then, we (the GFX department) contracted a debt with this feature. The original plan was to be able to visualize the amount of heat by using a glow on the pipes. Due to the tight schedule of the 0.15 release we decided to postpone the feature. Finally Ernestas took care of it, and we can proudly present it integrated in the game.
As you can see, the pipes emit light due to the red hot metal. The fact that they are connected to the reactor and the heat exchanger, made us make some extra patches. It would look wrong if the heat pipes were glowing, but the pipes on the reactor were not. The final result apart from beautiful is also very readable for the player, which is the main point of the entire design.
The glow intensity is proportional to the heat. Now the visualisation should be crystal clear. The new graphics are already merged into master, so will be included with the next experimental release. As always, let us know what you think on our forum.

[ 2019-08-30 10:53:28 CET ] [ Original post ]

Read this post on our website. The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server). So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team. In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies. Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.

Inserters should not chase items

What I always liked about Factorio is that it's a very precise game. Ratios, throughputs, crafting times are all well explained and even if it gets complicated, everything can be calculated to the last item. Miners mine resources at a precise rate, smelters and assemblers craft items at a precise speed, belts move the items at a precise throughput. But inserters... due to their behavior where they track items on the belt before grabbing them, they don't have a precise throughput. This really grinds my Iron gear wheels, as it's hard to even know if an inserter will be fast enough to load a simple assembler. There are Wiki Tables and References, but they are ridiculously complex since it depends on the inserter type, source, destination, belt type, belt orientation and inserter capacity bonus. Even after accounting for all that, the numbers are still not precise since it depends on timings and how items are placed on the belt. My proposition is to remove this complex movement of item chasing and have inserters move to their predefined pickup location and immediately pick up the closest item (in the case of a belt).This will:

• Make inserters have a constant throughput. It will still depend on some factors like stack size (e.g. stack inserter will pick up faster from chest than from belt), but it should simplify things significantly and allow us to have a calculated throughput for chests and belts that we can show in inserter tooltips.
• Prevent all the issues with inserters getting stuck (e.g. burner inserters running out of fuel because they chase items they can not grab). We often argue if this is a bug or not and if it should be fixed.
• Improve performance (maybe significantly). Inserters currently chase items throughout it's entire swing, tracking the items on the belt each tick and searching for a new item each time one goes outside the belt (which happens quite often for blue belts). Removing this requirement would mean less memory access to other entities and much simpler mathematical calculations. Since inserters are the second most common built entity, these improvements could lead to a big UPS boost.

But on the other hand, this will mean:

• It will graphically look much worse. While I believe we can do many things to make this look good enough (by separating drawing animation logic from game logic), it will probably not look as nice as it does now.
• It will remove some of the nice organic feel of the game. And it will remove some (arguably) fun emergent situations.

Combine this with the fact that changing something so core to Factorio in such a significant way would have big implications. So we decided this wont be done.

Blueprint import/export should be a modded feature

The blueprint library has always been a controversial topic. We argued about how it should work technically, in multiplayer or if it should exist at all. But one thing that I particularly don't like is blueprint import/export. It's obvious that it's more fun to make your own setups and it's probably universally agreed within the team that importing large sections of factories is not what players should do. This promotes "instant gratification", it eliminates the satisfaction you feel after finishing your creation you spent hours tinkering and planning. And could easily make a 100-hour game into an 10-hour game. It's sad when we release an update and the first comment is "does anyone have the blueprint string for the nuclear reactors" or someone immediately asks for an artillery shell production blueprint. It's our job as developers to incentivise the player to play the game properly. If importing blueprints is obviously so bad, why are we providing this tool as a vanilla tool? Not only that but we also place it in the "tools" section, as a shortcut in the main screen, as if you are expected to use it often. So my proposition is that this tool should only be modded in. By making it a mod it's clearly not a an intended way to play.The very common counter argument is "since it's obviously not fun, players won't use it. Put it in and let the players decide". That's like putting a "level up" button in an RPG and saying "well it's obviously not fun, it skips content, players won't use it, but let them decide". Yes they will, as soon as they encounter a problem a player will evaluate his options. A tempting "skip-ahead" button is irresistible in such situations. It's hard to remove such a powerful tool now, since it's oh-so-tempting to import that nice blueprint book with belt balancers, so you don't have to deal with designing those complex things yourself. Until a different consensus is reached, the tool will stay in game. But I urge players to restrain themselves from adding too many blueprints to their library that are not their own (or their friend's).

Combat/Biters

Weapons shouldn't lock on

Weapon lock on and the distinction between shooting with spacebar and C is a constant source of confusion for new players. Also, it is just weird and not even fun. Weapons should all work like the shotgun, you point and shoot, and the bullets hit whatever is in that direction. There's only one button to shoot, and that can be spacebar. We could take inspiration from the huge number of top down shooters out there to figure out satisfying weapon mechanics that would work with this new style. Even if you don't like this style, we already have it for some weapons (shotgun), and using it for some weapons but not all is inconsistent and confusing. (Klonan made a mod a while ago which does something like this).

Biters should be more aggressive, and probe your defenses

Currently, you can get by with only walling off part of your base, responding to attacks as they come, and leaving the rest fairly open. This runs opposite to what "most new players" [citation needed] would expect. For example, I always started off by walling and turreting my entire base, presuming that if the biters noticed a part of my perimeter that was uncovered, they would just go through there. The counter-argument is that it makes the game less fun, because you spend way too long building massive defensive walls instead of making your factory. My counter to that is that for a lot of people, making defenses is very fun, everyone loves turtling in RTS games. Maybe it's just my play style, but this is what I was doing anyway even when it's not necessary, and leaving big holes in my walls just feel wrong. IMO if you don't enjoy that, you should just turn off biters. Also related is the way that biters will sometimes ignore your structures, if they are not polluting or military. For the same reasons, I think you should have to defend your railway lines, power poles, etc.

Clearing bases should not leave you safe

Related to the point above, I think that clearing the bases inside your pollution cloud should provide only a very temporary respite from attacks. Biters should very regularly expand back into your pollution cloud, meaning you always have to defend. Alternatively, the whole pollution cloud mechanic could be removed, and replaced with a worldwide pollution count.

Miners shouldn't output directly to belts

Every other interaction between a belt and a building uses an inserter to move the items to/from the belt. Why are miners any different? From a pure consistency point of view, I think this should be removed. As far as I know, the reason it has been left this way so far is just convenience. (Bonus fact: I used to put inserters in front of my miners for an unspecified-but-way-too-long time when I was new to the game).

Boilers shouldn't have a water output

During our in-house testing, one of the things we did was invite people who had never played the game before into the office to try the new introduction campaign, while we observed them. One stumbling block that almost every person hit, was connecting their steam engine to the water output of their boiler, instead of the steam output. I understand that the current setup allows for some interesting layouts, but IMO it is not worth the usability cost.

Pipes should work like electricity

Pipes and fluid have been a constant annoyance for a long time. Thanks to the labours of another of our developers (Dominik), this has improved greatly, and is due to improve even more. However, if I had the choice, I would just remove the headaches outright, by making pipes function like magic liquid teleporters. Each "pipe network" (a block of connected pipes) would have a set of inputs and outputs. The load would be drawn equally from all inputs, and distributed equally to all outputs. Of course, this would mean that there would be no flow limits for pipes. So you could, for example, have a massive array of offshore pumps connected via a single pipe to a large nuclear plant, and it would work just fine. There would also be no way to visualise the flow, so the windows would have to be removed. IMO, the cost is worth the gain.

Adventure mode

I can't get my wife to play Factorio with me because she's not really that into Factory building.But she and I have been playing Satisfactory because it gives herreasons to explore the map and discover new places and collect items. The obvious change that could be made to Factorioto accomodate that play style would be to scatter useful itemsaround the map.I imagine things like an abandoned railyardthat would give one early access to a few prebuilt enginesand rails, totally changing the way an early factory is designed. But there is a second aspect leads to Factorio not being very exploration-driven,and that is that you can see ridiculously far and nothing obstructs your line of sight.Who needs to explore when you can just plop down a few radar towers?Forests would be much more meaningful if you couldn't see through them,and had to actually poke around and through them to know what was there.(I personally take inspiration from Ultima 3for line-of-sight calculations in 2D games). And speaking of line-of-sight-blocking terrain features, we also need mountains.Not just rows of cliffs, but large and impassiblemountain ranges that compliment the impassible (but non-sight-blocking and land-fillable)bodies of water. Games with a first-person perspective automatically give you the line-of-sight effect.Another thing that true 3D game engines give you out of the box that 2D onesusually don't is the possibility of non-planar worlds.Bridges and tunnels can provide alternate (or secret) routes and interesting loops.But it is possible to get some of the same effects out of a 2D engine.Since Factorio already supports multiple surfaces, it wouldn't be too much of a stretchto add a cave system (preferrably with an odd topology) underneath the surface surface,with entrances in mountain sides. I'm not sure that making vanilla Factorio more fun for peoplewho want to focus more on exploration is itself controversial,but all these features take time and energy to build and maintain,and "Factorio isn't supposed to be about exploration",so it hasn't been a priority.

Robots should take up space and time

In my estimation, the main cause of bots becomingoverpowered in late-stage factoriesis that they take up zero space(large amounts of logistic or construction bots can occupy a single point on the map)and take zero time to pick up or drop items or to deconstruct things.This leads to the following:

• Laser-turret-creeping enemy bases is trivial because construction bots can instantaneously place enough turrets to completely overwhelm all the biters.
• There is no reason to mess with belts at all when bots can 'teleport' unlimited resources between storage chests.

Buildings taking time to construct (such as they do in games like Total Annihilation)would to some degree solve the first problem,since an already dug-in force would have a chanceto defend itself while turrets are being built. Bots taking up space (so that they have to queue up to pick up and drop off items)would solve the problem of bots completely obsoleting belts;to transport large numbers of items quickly you wouldneed to spread out the pickup and load boxesto give the many robots space to work. The main reason we're not doing this is that bot movement logicis currently written such that calculations are needed only when something changes(a robot completes its task, its target is moved, etc).Having to keep bots separated would add a lot more calculationsthat need to be done while a bot is en route,which would probably result in a lot of complaintsfrom people with huge bot-based factoriesthat the game got all slow.

Items should have volume and mass

Similar to the overpowerdness-of-bots problem,being able to carry multiple locomotives (or rocket silos)around in a backpack or in a train car feels silly.Big things should require time and space to move around. Solving that would require completely changing how construction workslarge things would have to be built on-site a la Total Annihilation or Satisfactoryinstead of being preassembled.But that could lead to its own interesting situations.Some objects would require more resources than can fit in a standard stack,so special assembly buildings would be needed. There are mods(such as Rocket Silo Construction)that try to do this with certain buildings already.

Power-user hotkeys

I believe it is alright for a game to have power-user controls that are not bound to any keys by default. For example "Toggle exoskeleton" introduced with a 0.17's toolbar is a feature that most people probably will never need, and lot of people won't even realize it exists. It is probably useful for some people, and it also useful that it can be toggled by a hotkey, but it doesn't need to be bound to any keys by default. People just get confused why they run slow when they press the hotkey by accident, even if they knew about the feature, but don't actively consider its existence. I think if we changed our attitude towards default keybindings we could go nuts with adding new shortcuts and there would be little bit for everyone. I mean, how many people use hotkeys for connecting or disconnecting trains, and how many people would use a shortcut for toggling manual driving in trains.

Mining furnaces and assembling machines should return the ingredients for the in-progress recipe

In Factorio the game makes a large effort to not punish the player for experimenting: you can mine up anything you build and move it somewhere else or just try different setups. The game doesn't punish the player for this (or so most people think). You can hand craft things and if you change your mind just stop crafting to get the ingredients back. When it comes to furnaces and assembling machines this is different. Anything which is in-progress when you mine a furnace or assembling machine is lost. If you had a Kovarex enrichment process running with 40 Uranium 235 and you mine the centrifuge the game deletes all 40 of the Uranium 235 and you're left with nothing. In a previous version of the game it would just give back everything it had consumed when the recipe started. However, because of a possible incredibly tiny exploit related to productivity modules and being able to get an extra % of items back if you time it correctly this was removed (bug report). We continue to get bug reports about deleted items and all of them get filed under "not a bug". There have even been mods created to address this specific shortcoming in the game. Remember that since we are focusing on 1.0, these ideas are currently nothing more than a cause for heated discussions in our office. But let us know what you think (on our forum) and maybe we will change our mind based on the feedback. (maybe after 1.0...)

[ 2019-08-23 13:28:59 CET ] [ Original post ]

Read this post on our website. Hello, we had a party last night in the office to celebrate the work we have done over the last 6 months on 0.17 stablisation. It was nice to have most of the team together to share some beers and pizza.

Not stable quite yet

Unfortunately a couple of nasty bugs appeared this week, in no small part due to forum member boskid and his crusade to find bugs. In the last month alone boskid has reported over 20 bugs, so very special thanks are due. Saying that, we have been efficient in our fixing, and are now down to 32 open bug reports on the forum. While there are issues being reported, the number of crashes is at an all time low. Below is a comparison between 0.16 and 0.17.
We compared the current number of 0.17 crashes to the number of crashes in 0.16 before we released 0.17. From what we can tell, comparing the number of crashes against average player counts, about two thirds of players are playing on 0.17. Factoring the player counts into the data, we can determine that 0.17 is close to being as stable as 0.16. A lot of the crashes are from older 0.17 experimental releases, which might be skewing the data. Additionally about 1 in 20 of the bug reports are due to Cheat Engine, and not something we can fix. What this means for the stable release, the plan is the same as last week. We have just release 0.17.66 with a bunch of fixes, and if it weathers the weekend player base and nothing critical arises, we will mark it as stable next week.

Community spotlight - Nauvis Post Collapse

Forum member lilstrip has spent over 8 months working on a map, based on the idea of an Abandoned Colony/City, first talking about his baby in this thread. After long last he has a version ready for publishing, and a little bit of a backstory to go with it.
Click to view full size

In the years before the gates shut Nauvis used to be a promising colony. Equipped with a massive orbital ring the planet was an absolute power house when it came to building ships for the Tyrador Safeguard Coalition.

Sadly the colony was lost in the first AI war long after the collapse. In reality things weren't going too well in the first place after the gates closed, famine and unrest were a common occurrence for the colony of Nauvis. To this day [REDACTED] of the AI war still roam the system in massive numbers and eventually a few decades later the location of the colony was lost..

Xterminator has made a video showcasing the map too, if you want a more hands-on preview. https://youtu.be/kBlFp9FF81k You can find the download link and the information on the scenario in the forum post. The scenario itself requires a pretty beefy PC to run, a map this large is stretching the limits of the engine a little. As always, let us know what you think on our forum.

[ 2019-08-16 15:51:13 CET ] [ Original post ]

Changes

• Blocked underground pipe connections (see e.g. https://forums.factorio.com/73840) are always highlighted.

Bugfixes

• Fixed crash when using the close button while the client is saving the map for desync report. more
• Fixed a crash related to settings copy/paste of some modded assemblers. more
• Correctly highlighting blocked connections of modded underground pipes. more
• Fixed a case of disappearing fluid in a special fluid furnace configuration. more
• Fixed programmable speaker caused crash when using --disable-audio command line option. more
• Fixed that an underground pipe ghost did not split fluid systems. more
• Fixed that an underground pipe ghost did not split blocked connection. more
• Fixed that fluids in assembling machines and furnaces would get voided any time mods changed. more
• Prevented construction of underground pipe that could crash the game due to blocked pipe connection. more

Scripting

• Added LuaEntityPrototype::terrain_friction_modifier read.

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

[ 2019-08-16 14:27:41 CET ] [ Original post ]

Changes

• Modded achievements and their progress are now stored even when the mods adding extra achievements are temporarily removed. Up to 5000 modded achievements are stored indefinitely. more
• Programmable Speaker sounds now change volume accordingly as player moves. more
• Rocket Silo sounds now change volume accordingly as player moves.

Bugfixes

• Fixed tightspot level 5 expecting old chemical science recipe. more
• Fixed Transport belt madness inserter exploit. more
• Fixed that filling energy of entities in map editor didn't work for accumulators in electric network.
• Fixed a crash or desync that could happen after assigning a build_base command to a single unit. more
• Fixed that mining drill covering more than 1 infinite resource showed the mining speed as sum instead of average. more
• Fixed that infinite item based resources with yield of more then 100% didn't actually mine more. So yield of 260% for example means that it mines 2 resources and 60% probability of 1 extra.
• Fixed cloning of accumulators in the map editor not setting available energy correctly.
• Fixed a desync related to cloning accumulators. more
• Fixed 2 crashes related to custom-switch. more
• Fixed that train could consider itself being parked in station when in fact being misaligned. more
• Fixed that activating deconstruction planner/blueprint/blueprint tool from the shortcut by pressing the buttons didn't clear the cursor if it wasn't empty. more
• Fixed condition operator button visibility when dragging conditions in the train schedule GUI. more
• Fixed few layouting issues with scroll panes.
• Fixed that biters could get stuck in narrow passages between water tiles. more
• Fixed that members of unit groups could sometimes get far ahead of the group. more

Modding

• Added CraftingMachinePrototype::match_animation_speed_to_activity.
• Added LoaderPrototype::structure.back_patch and front_patch.

Scripting

• Added ability to clear a sprite or sprite-button by writing nil or empty string to LuaGuiElement::sprite. more

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

[ 2019-08-14 12:14:06 CET ] [ Original post ]

Changes

• Range modifier and shooting speed modifier are now shown in ammo tooltip and ammo turret tooltip.
• Allow pressing ESC to cancel saving or downloading the map while desynced. more
• Added copy paste from assemblers to infinity chests, similar to requester chests.

Bugfixes

• Fixed crash when loading a save containing modded crafting machines with fluid boxes, with mods disabled. more
• Fixed turret range drawing not accounting for ammo range modifier in world and in map view. Fixed turret unfolding and animation not accounting for ammo range modifier. more
• Fixed case of swapping left and right lane of underground belts. more
• Fixed desync related to marking and then un-marking combinators for deconstruction. more
• Fixed Infinity Chest GUI showing wrong label when modded as a storage chest. more
• Fixed when target of combat robot changed force to an allied force, the combat robot wouldn't stop attacking it. more
• Fixed silo script error using generic on_event function. more
• Fixed a desync related to using multiple custom fluid indexes in a recipe. more
• Fixed some labels getting cut of in the statistics GUI, on some translations. more
• Fixed a crash that could sometimes happen when fighting large groups of biters. more
• Fixed a special corner case of signal internal state consistency. more
• Fixed that the circuit and logistic network buttons in the train stop GUI were swapped. more

Scripting

• Combinators can now be activated or deactivated through LuaEntity::active.
• Added LuaEntity::upgrade_target read.
• Removed the ability to convert a table address into a string.

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

[ 2019-08-09 19:35:13 CET ] [ Original post ]

Read this post on our website. Hello, We had a lovely surprise waiting us this Monday, one of our fans had sent us a delicious cake:
It didn't last very long...
Thank you very much Conn! It certainly helped with the bug fixing push this week.

0.17 Stable candidate

This last week we have made a big push to fix as many remaining bugs as we can, and we are down to only 36 reports on the forum. Since these remaining bugs aren't really hard crashes, save corruptions, or desyncs, we are looking to consider 0.17.64 (releasing today) as our 'Stable candidate'. What this means is that, if all goes well over the weekend and nothing too serious comes up, we will mark it as the 0.17 stable next week. We will continue to fix bugs and issues after the stable, and we will also start our work on the features of the 'next stable', so the GUI improvements and all the rest we have mentioned in the past. In the next few weeks a lot of the team is going to be on vacation, so things won't get up and running with the new feature work for a while. This experimental period has been quite a long one, we had a lot of new things to fix and debug, and a lot of technical debt from the year of development. There won't be another release quite so large, we only have a few major things left to cross off the list before we can call Factorio finished:

• All new GUI's implemented.
• New Campaign and mini-tutorials.
• Completed high-res graphics.
• Maybe some small surprises along the way.

By no means are any of these easy, but each day brings us closer to concluding this chapter of Factorio history.

Prototype documentation overhaul

Just in time for the stable version, the prototype documentation for mods has received a major overhaul. The backend has been converted to use semantic mediawiki to store the prototype documentation data in a machine readable format. Using the new ability to query the stored data, prototype pages now display all their base classes at the top for easy navigation. Furthermore, each prototype page now provides a compact overview of not only its own properties and their types, but also the properties it inherits from other prototypes. The documentation also boasts a new overview page that lists all 199 prototypes and their 1943 fields. As always, let us know what you think on our forum.

[ 2019-08-09 14:15:32 CET ] [ Original post ]

Changes

• Inventory filters tooltip now shows they are inventory filters to avoid confusion. more
• The quickbar tooltip now shows what shortcut to use in order to clear it.
• Quickbar filters can now be set from the ghost cursor.
• In Introduction, changed some places Compilatron stands at to be less in the way. (https://forums.factorio.com/74138, https://forums.factorio.com/74018)

Bugfixes

• Fixed some combination of graphics options could cause infinite loop at 95% of sprite loading in the demo. more
• Fixed assigning empty table to sprite definition would not cause loading error but crash in-game instead. more
• Fixed a desync related to accumulators in multiple networks. more
• Fixed transitions on tiles where landfill, grass and water meet. more
• Fixed logistic network technology description did not mention buffer chests. more
• Fixed "use-version-filter-in-browse-games-gui" config option didn't work. more
• Fixed possible crash in introduction scenario if player builds turrets too far to either side. (https://forums.factorio.com/74133, https://forums.factorio.com/74060)
• Fixed electric coverage visualization was not shown when hovering mouse over invisible widgets. more
• Fixed a crash when using a path_resolution_modifier of 8. more
• Fixed introduction leftover invisible entity after cutscene. more
• Fixed introduction bug where sometimes Compilatron wouldn't build things properly. more
• Fixed "toggle filter" control setting would not work if bound to modifier key and left or right click. more
• Fixed introduction bug where poles could still connect to the generator after it was destroyed. more
• Fixed introduction possible crash when removing power consumers. more
• Fixed missing laser-beam entity from demo. more
• Fixed issue with walls in hidden smelter section in introduction. more
• Fixed that biters could form too many attack groups when aggroed by artillery. more
• Fixed that clicking and dragging electric poles in multiplayer latency didn't work correctly.
• Fixed that fast-replacing assembling machines with fixed recipes didn't work correctly. more
• Fixed a crash when deleting surfaces during the same tick as auto-save running. more
• Moved integration patches of crash site entities to decals render layer. more
• Fixed that inserters would pick up from the left lane of a loader even when positioned closer to the right side.

Scripting

• Added LuaEntity::request_from_buffers read/write.

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

[ 2019-08-06 12:26:39 CET ] [ Original post ]

Read this post on our website. Warning this Friday facts is about the Introduction scenario, not about anything that will be in Freeplay Factorio. You may want to read previous FFFs (FFF-257, FFF-284) about the Introduction. TLDR: the Stable candidate of the Introduction scenario is now in Experimental please play it and send me your screenshots. Feedback especially on the freeform endgame would be greatly appreciated. We have also released a Experimental version of the Demo, be sure to send this link to your friends ASAP SPOILER WARNING: If you have not yet played the Introduction Scenario, go play it before you read this.

Introduction scenario as Tutorial

The tutorial components of the Introduction are working very well now. There is still more polish to do, but I feel confident it is ready for new players of all kinds.

Introduction scenario as Demo

The rest of this article will discuss the Introduction, but from the point of view of a player who has not payed for the game yet. Once 0.17 Stable comes out, the Free Demo will be replaced with just the Introduction Scenario.

What we wanted from a new version of the Demo

The old demo has a very limited amount of content, and only about 2 hours of playtime. The content it does present is very dated, and hardly could be called representative of contemporary Freeplay Factorio, it did not even include Research! We had some design constraints for the new demo, some of which were:

• The player can fail during the demo
• Difficulty is respectful, Fake danger is disrespectful

Whatever happened, we hoped that the new demo would demonstrate a wider range of Factorios concepts, including a small taste of deathworld difficulty. I would say we were too successful. We decided to do this with a final quest where the player has to quickly complete a long research while the biter attacks increase in strength. The player needs to be completely attentive, otherwise their defense will fall over.
An invisible, dynamic difficulty curve meant that everyone was challenged to the breaking point, veterans and new players alike. See FFF-284. For the goal of being a challenge, I would say it was working well.

What other people were thinking

People loved it or hated it. I received many elated emails saying how intense the final battle was and how sweet the victory felt. I also received pseudo-hatemail about 1,000 hour players rage quitting. The reason a lot of vets were failing was because they were pretending to be new players. This generally meant playing as a vet (using shortcut keys, and high APM, heavy pollution) but placing few turrets, generally in sub-optimal locations, and being lazy with ammunition delivery. Newer players felt pressured and were generally able to pull off a close victory. Many said they were overrun at the end, but still were victorious, giving an interesting moment to leave the game and start freeplay with a high heartrate. Feedback was far more positive than negative, but from the negative feedback there were two recurring themes.

• The most common negative feedback was that such intense combat is not representative of Factorio.
• The second most common feedback was that the player did not expect such a difficulty in a 'tutorial' level.

Failed Solution 1: Sending less biters

This removes the chance that the player can lose, but introduces new problems with the design. It removes ammunition as a production pressure, and makes Turret placement irrelevant.

Failed Solution 2: Ramp up the attacks slower

This sounds like it could work and for the second problem listed above, it does. The player has more time to react. However this means that only new players experience the challenge, as they most likely have built the fewest Labs, and take the longest to finish the quest. Vets will finish before the attacks built up to any meaningful level. Just making it easier for the players who are able to overcome the challenge the most seems odd.

Failed Solution 3: Add more time between waves

In order to have a decent number of biters so the production challenge is not lost, the waves need to be very large. For the player to have enough notice between waves, there is a chance they will be able to finish the research before the first one comes. Also the most common failure state was when a Turret with 200 rounds is destroyed, meaning the player cannot craft enough new ammo to keep up with the waves. This happens more often with bigger, less frequent waves. All three of these solutions have one thing in common: we would need to implement them in a way that removed the challenge almost completely. So I suggested an alternative solution.

New Solution: Remove the Challenge quest completely

Now there is no timed research and defence quest at the end of the Introduction. Instead the player is told to destroy Biter spawners to reduce the attack frequency, and then they are left to deal with Freeplay style attacks. The structure of the final quest is similar to Freeplay itself "Research a technology at the bottom of the tech tree". The player now needs to automate Logistic Science packs to win the Introduction.
If the player cannot survive here, they will not survive a Freeplay game, but realistically the biter challenge in Default settings Freeplay is not particularly worrisome.

Other new Demo goodies

Having a great Demo is important to us. We dont want someone to pay for the game, just to see if they like it. It is also fits well with our no sales policy. We already offer an extended refund period to players who buy on our website, if they gave the game a red-hot go but discovered it was not for them. Demos are in general a super cool thing from the 90s that most people here wish still existed. So we will increase the amount of content in the demo. You can continue playing at the end of the Introduction, and I suspect there is about 10 hours of stuff to do. We are also adding more recipes and technologies to the Demo. The new list of what is available:
A complete and unique demo techtree that uses Automation and Logistics science packs, Mining Productivity infinite tech, Shooting speed infinite tech, Grenades, Steel, Piercing rounds, Car, Medium power poles, Heavy armor, Submachine gun, Assembling machine 2, Turrets, Lamps, Long handed inserters, Gates, Walls, and more to discover.
The size of the final play area is also much larger.
Click to view full size We have released the changes today, and also released an experimental version of the demo. Please let us know if you have any feedback or suggestions in the usual places.

[ 2019-08-02 17:16:04 CET ] [ Original post ]

Changes

• Combat robotics 2 technology now require Laser. more

Bugfixes

• Fixed fluid mixing checks for some setups when setting an assembler recipe. more
• Fixed flying notifications showing player's inventory updates were visible to all forces. more
• Fixed error during PNG decompression would cause crash on Linux. more
• Fixed that save files could become very large. more
• Fixed that cloning furnaces wouldn't preserve the crafting progress. more
• Fixed inserters being slower and rotationally asymmetrical after the previous version.
• Fixed that wandering units could be activated for longer than necessary. more
• Fixed a crash when trying to check if 'game' is equal to anything using the Lua API. more
• Added a check for overlapping crafter fluidboxes to detect wrong mod configuration. more
• Fixed desync related to inserter ghosts and belts. more
• Fixed setting health of item stack of item-with-entity-data to 1 would do nothing. more
• Fixed a desync with the map editor resource editor. more
• Fixed a desync with the map editor decorative editor. more
• Prevented some rare cases of fluid mixing tied to underground connections. more
• Fixed placing entities that consume type of energy other than electric would still show electric coverage visualization. more

Modding

• Added InserterPrototype::draw_inserter_arrow.

Scripting

• Added LuaGuiElement::choose-elem-button elem_types "decorative", "item-group", "achievement", "equipment", and "technology".

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

[ 2019-08-02 17:11:02 CET ] [ Original post ]

Balancing

• Basic oil processing produces only Petroleum gas, for more streamlined oil setup in the beginning.
• Basic oil processing keeps some of the refinery input/output slots unused, so it is more clear which ones will be used by Advanced oil processing.
• Chemical science pack requires Sulfur instead of Solid fuel.
• Flamethrower ammo requires crude oil instead of heavy and Light oil.
• Rocket fuel requires light oil.
• Laser Turrets, Lubricant, and Worker robots technologies need Chemical science pack.
• Deathworld marathon preset was made a little bit easier.

Bugfixes

• Fixed a crash when trying to show invalid thumbnails for mods. more
• Fixed that up/down keyboard navigation of the load/save game GUIs and manage mods GUI didn't work in some cases. more
• Fixed that cloning belts with items didn't preserve the item positions correctly. more
• Fixed a script error in train stations mini-tutorial. more
• Fixed a script error in the NPE. more
• Fixed car turret shadow would rotate in opposite direction to the turret. more
• Fixed that changing sound settings didn't persist through game restart. more
• Fixed that the migrated-content GUI wouldn't show in some cases. more
• Fixed that right-click-and-drag didn't work in the blueprint GUI to remove things. more
• Fixed that unit groups would use paths going through cliffs. more
• Fixed some cases of entity rotation with blocked underground pipes. more
• Fixed inserters sometimes getting stuck when picking up from a non-backed-up underground belt. more

Modding

• Added CraftingMachinePrototype::default_recipe_tint.

Scripting

• Added LuaEntityPrototype::supports_direction read.
• Fixed that LuaGuiElement::force_auto_center() didn't work. more
• Added LuaGameScript::get_filtered_entity_prototypes(), get_filtered_item_prototypes(), get_filtered_equipment_prototypes(), get_filtered_mod_setting_prototypes(), and get_filtered_achievement_prototypes().
• Added workaround for a driver crash when calling D3D11CreateDeviceAndSwapChain. more

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

[ 2019-07-30 14:54:07 CET ] [ Original post ]

Read this post on our website.

Lua Mod GUI additions

Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game.
When someone new to Factorio modding is introduced to how they function, they almost always have the same questions:

• Why is mod GUI part of the game state?
• Why do mod GUIs need to be deterministic?
• How can I edit the base game GUIs?

And then comes the explanation:

The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event.

Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to:

• Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort).
• Not break with simple refactoring.
• Not cause other programmers trouble by existing.
• Not prevent base game GUIs from working how they need to work.

So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.

The Oil Changes

In the last FFF, we presented changes to how Basic oil processing works along with some other changes (mainly moving Worker robots behind Chemical science pack), which resulted in a lot of discussion as it is a very sensitive topic. We have discussed with as many of you as we could, and in this FFF we would like to present to you what conclusions we came to, and try to explain our ideas in more detail.

Basic oil processing changes

A significant portion of you has voiced concerns about removing Light and Heavy oil from the outputs of Basic oil processing, be it about the change itself, or that it does not fit because of some other factors... Automating Chemical science packs is generally considered to be a huge step by many, mostly because even for veteran players, setting up oil processing consists of many steps, and for newer players theres many new things to learn very quickly. This change is trying to address both of these issues.
As for the complexity, the most confusing factor is the specific mechanic of the Oil refinery, that all products need to be used or stored in order to keep it working. This is made worse by the common situation that the player can be very far ahead with what they have unlocked with technologies, while being very far behind with what they have already automated.
This can lead to a new player having every Logistic science technology researched before setting up the refinery, and just the sheer number of new unknown items and recipes can get very confusing, especially when some are not really useful at the moment.
One of the ways we can look at the Chemical science pack is "the proof that the player has managed to set up a functional refinery". With this in mind, it fits very well to have them set up a rather basic refinery, and get to know most of the new entities/items/recipes that are necessary to progress, first.
After 'proving' that Basic oil processing is working, the player can proceed to a more advanced version with more outputs and more recipes - but as the player is already familiar with the basics and has their infrastructure already in place (Pumpjacks, oil transport, how pipes work, Chemical plants, ...), its not nearly as confusing and daunting to unlock and orient themselves in the Advanced oil processing, yet it still has new concepts to grasp (multiple outputs, cracking, more recipes).
A lot of people have voiced their concern about simplifying the game, but setting up Advanced oil processing (or Coal liquefaction which also has the same challenge of multiple outputs and using cracking) is still mandatory in order to launch the rocket. The learning curve is just smoother.
All in all, we would like to keep this change as we believe it has a positive impact on the game both for newer and veteran players, however when discussing the changes, we realized there are things that would make this change fit in the game much better...

The use of Light oil

Many of you pointed out that Light oil has very few uses in the game - mainly producing Solid fuel efficiently, but its possible to ignore Light oil altogether and just produce Solid fuel from Petroleum gas, sacrificing some Crude oil efficiency for simplicity.
One of the topics repeated many times was that with the proposed changes, suddenly the player is incapable of producing Solid fuel "the right way" (from Light oil) from the start. While this alone is not a big problem and can be justified by "at least the player will appreciate Advanced oil processing more", the efficiency of Solid fuel from Light oil is fairly unobvious, and the player has so many more critical problems to focus on that its easy to miss.

Rocket fuel behind chemical science pack, requires light oil

We are adding Light oil to the Rocket fuel recipe, and therefore moving Rocket fuel behind Advanced oil processing, with Rocketry taking the pre-requisite of Flammables instead. This should help as a slight hint to produce Solid fuel out of Light oil and to make the recipe a little more interesting - we dont have many assembling machine recipes with fluid input and a refinery-related fuel recipe is a good fit. One of the obscure details was that the only motivation that made Advanced oil processing mandatory was just Lubricant - which does not feel like a high-tech product - now there is Rocket fuel as well.
The more important question many of you have asked would be "why even make Solid fuel with the changes". This applies even more now that Rocket fuel is behind Advanced oil processing.
One of the great things about the idea of adding Solid fuel to a science pack was that it could be created from the excess Light oil that the player has no use for until unlocking Advanced oil processing. Then it could easily be burned to get rid of it to keep the refinery working, but since Basic oil processing has no excess byproducts anymore, every bit of Petroleum gas is valuable - therefore producing Solid fuel feels like a waste, unless the player has a desperate lack of coal to burn.

Chemical science pack change - Sulfur

There is however an item that is much more useful than Solid fuel, and is also created from Petroleum gas - Sulfur.
It opens the path towards Sulfuric acid (for Batteries both for Modular armor and for Accumulators), and more interestingly Explosives. Unlocking the Rocket launcher often feels like a big side step mainly because it requires setting up Explosives production. With Sulfur set up for the science pack, this is one step more convenient. A similar case occurs with Tank and Cannon shells later.
Therefore we find it fitting to replace Solid fuel with Sulfur in the Chemical science pack recipe, as there are multiple uses for it even with Logistic and Military science packs, and Solid fuel has lost a lot of its charm with the new changes.

Robots behind chemical science pack

One of the obviously controversial changes from the last FFF, was that Worker robots would become gated behind Chemical science pack. Our thought process behind this change was that you need to set up pretty much all of the oil refining recipes anyway, so it is not as much of a big jump as it seems. In fact, we believe it has been a confusing trap - it has appeared as a Logistic science pack tier technology, but in reality requires all the items that the next technological tier would expect you to have. On top of that, worker robots are a good motivation and reward for unlocking Chemical science pack which does not have that many big shiny technologies behind it.
With the change of putting Sulfur into the Chemical science pack recipe, worker robots are even closer to it as all the items in the science pack directly contribute to getting robots.

Flamethrower ammo change - Crude oil

With Heavy and Light oil behind Chemical science pack, Flamethrower ammo needed to be moved as well or have its recipe changed. Rather hastily we chose to change the recipe for Petroleum gas instead of the oils which does not make much sense, especially as the Flamethrower turret cant take Petroleum gas. After some of you pointed this out, it shall be Crude oil instead. Technically you can already use the turret with Crude oil barrels on the offensive, so making Flamethrower ammo simpler is not a problem.

Adjusting the numbers

We made slight changes to the numbers in the recipes - specifically, Basic oil processing results in a bit more Petroleum gas (45 instead of 40), and Advanced oil processing results in more Heavy oil (25 instead of 10) than before. This is because it was common to use Basic oil processing over Advanced oil processing when you needed a lot of lubricant for Express transport belts.
We are confident about these changes but nothing is set in stone, so let us know what you think about them. We actually found a bug with the new 'block water input fluidbox' feature we added, so we won't release the changes until we have that sorted. You can test these changes (except the reserved fluid inputs) with this mod.

[ 2019-07-26 14:00:52 CET ] [ Original post ]

Balancing

• Changed expensive variant of electronic circuit to require 8 copper cables instead of 10.

Changes

• User verification must be enabled for public multiplayer games. LAN games, direct-connect, and Steam still don't require user verification.
• Network message segment size can be configured in server-settings.json, for server providers with large enough upload bandwidth.
• Added "Build with obstacle avoidance" into controls settings with CONTROL + Left mouse click as default. It re-introduces the possibility to build rails in ghost mode that avoid trees rocks and cliffs.
• Decreased base damage of Personal laser defense from 40 to 30.
• Decreased base shooting speed of Laser turret and Personal laser defense equipment from 3 shots per second to 1.5 shots per second.
• Reverted combat latency behavior to do latency hiding while in combat. more

Bugfixes

• Fixed that extra fast (modded) splitters didn't work properly. more
• Fixed an inconsistency between area selection and logistic network highlight. more
• Fixed that probabilistic recipe result that is also a catalyst didn't put itself into consumed statistics when the probability check failed and the item wasn't produced. more
• Fixed visual errors when dragging train schedule conditions. more
• Fixed that locale settings didn't save when changed. more
• Solved that pressing ALT while walking right (D being pressed) stopped the character as it interfered with ALT + D. more
• Fixed connection preview of underground belt in blueprint in a specific case. more
• Changed accumulator/wall/underground belt map color to be more contrast against certain tiles. more
• Fixed laser turrets were shooting beams that would last until target was destroyed even if it got out of range and turret stopped shooting. more
• Fixed Laser turret shooting speed research didn't increase damage of laser turret. more
• Fixed Laser turret shooting speed research didn't increase damage of Personal laser defense equipment. more
• Fixed that biters sometimes couldn't get past other biters. more
• Fixed that migration scripts couldn't use "require". more
• Fixed a crash related to fast-replacing modded generator entities without fluidboxes.
• Fixed loaders would not wake up sometimes after picking up items from them manually. more
• Fixed that space science pack technology did not have accumulators and solar panels in prerequisites. more
• Fixed that switching to another window while dragging a widget (slider) with a tooltip didn't clear the tooltip. more
• Fixed that rails would report bounding box sizes of zero when read through the LuaEntityPrototype API. more
• Fixed that unit groups could get stuck at the end of their assigned path. more
• Fixed a desync related to changing forces in the map editor. more
• Fixed a crash related to fluid connection changes in mods. more
• Fixed that creating character corpses using player_index was off by 1. more
• Added extra check to prevent infinite cycle in fast belt building. more
• Fixed a crash when building train stations when the backers.json file is empty. more
• Fixed that entities could have their light rendered twice. more
• Fixed that biters had difficulty pathfinding around crescent-shaped lakes. more
• Fixed that the "not enough rails" error didn't work correctly in the map editor. more
• Fixed train would not stop exactly in the station preventing pumps to connect to fluid wagons when a mod was changing speed of breaking train. more
• Fixed that trains would try to path to train stops on different surfaces. more
• Fixed pump would not disconnect from fluid wagon when rail besides pump was mined or destroyed. more
• Fixed a crash related to the rail planner. more
• Fixed that the mod info label in the technology tooltip didn't line wrap. more
• Fixed a crash near the start of the NPE. more

Modding

• Changed how beams are drawn to improve seamless tiling of beam segments. Head and tail segments are now stretched to fill space from source/target position to next segment.
• Changed how beams apply damage. By default, they no longer trigger their action every damage_interval, instead the action is triggered when its owner triggers shooting. The old behavior can be turned on by setting BeamPrototype::action_triggered_automatically to true.
• It is possible to specify fluid product or ingredient with a fluidbox_index so they use exactly one slot corresponding to the specified fluidbox of the machine.
• Changed the "market" entity from entity-with-health to entity-with-owner so it now has a force and unit_number.
• Changed fluid energy source prototypes to error when no consumption limits are set instead of logging a warning.
• Added util.parse_energy().

Scripting

• Added LuaGui::screen.
• Added on_gui_location_changed, on_gui_selected_tab_changed, and on_gui_switch_state_changed events.
• Added LuaGuiElement type "empty-widget", "tabbed-pane", "tab", and "switch".
• Added LuaGuiElement::add_tab(), remove_tab(), and force_auto_center().
• Added LuaGuiElement::location, auto_center, drag_target, selected_tab_index, tabs read/write.
• Added LuaGuiElement::switch_state, allow_none_state, left_label_caption, left_label_tooltip, right_label_caption, right_label_tooltip read/write.
• Added LuaStyle::badge_font, badge_horizontal_spacing, default_badge_font_color, selected_badge_font_color, disabled_badge_font_color, selected_font_color, selected_hovered_font_color, selected_clicked_font_color, strikethrough_color read/write.
• Added clear_and_focus_on_right_click to LuaGuiElement text-box.
• Added LuaGuiElement::get_slider_value_step(), get_slider_discrete_slider(), get_slider_discrete_values(), set_slider_value_step(), set_slider_discrete_slider(), set_slider_discrete_values().
• Added LuaGuiElement::get_mod().
• Added LuaEntity::loader_container read.
• Added LuaEntity::belt_neighbours read.

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

[ 2019-07-25 14:47:17 CET ] [ Original post ]