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.

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.

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.

• Blocked underground pipe connections (see e.g. https://forums.factorio.com/73840) are always highlighted.

• 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

• Added LuaEntityPrototype::terrain_friction_modifier read.

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

• 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.

• 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

• Added CraftingMachinePrototype::match_animation_speed_to_activity.
  
• Added LoaderPrototype::structure.back_patch and front_patch.

• 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.

• 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.
  

• 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
  

• 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.

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.

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.

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.

• 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)
  

• 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.
  

• Added LuaEntity::request_from_buffers read/write.
  

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

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.

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.

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

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

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.

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.

Having a great Demo is important to us. We don’t 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 90’s 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.

• Combat robotics 2 technology now require Laser. more
  

• 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
  

• Added InserterPrototype::draw_inserter_arrow.
  

• 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.

• 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.

• 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

• Added CraftingMachinePrototype::default_recipe_tint.

• 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.

Read this post on our website.

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.


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.



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 there’s 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, ...), it’s 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...

Many of you pointed out that Light oil has very few uses in the game - mainly producing Solid fuel efficiently, but it’s 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 it’s easy to miss.



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 don’t 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.
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.

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.

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 can’t 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.



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.