Hello,
Nice to see you all again so soon.
Imagine you are setting up your first space platform. You start building tiles, a full rocket-load is sent. When you need belts, assembling machines or furnaces, again, a full stack is sent. A small platform could request 10-20 automated rockets and leave plenty of unused items in the inventory. The advantage is that you don't have to wait for more when you decide to rebuild it or add machines. This is how we envisioned space platform building - as making incremental progress.
But not all players do it this way, some like to plan more in advance. These players view sending full stacks of items as a waste of rockets, especially in the early game. We noticed the discussions on our forums, on Reddit, and on the community Discord.
We didn't attempt it during 2.0 development because mixing multiple item types in one rocket seemed too complicated, it had lots of edge cases which we didn't have a good answer for.
However, it was also something I missed in my own playthrough, so much so that I started working on a proof-of-concept mod abusing our Lua API.
It was functional but wasn't polished enough to make it available, and no, none of my co-workers ever saw it.
Then the feature popped up independently on our internal 2.1 wishlist, and I volunteered to implement it.
Handling the edge cases, thinking about our options and discussing what we wanted to achieve took quite some time and wasn't without compromises.
In the end, I think we reached a good place, so let me present our results:
A typical 'full build' platform construction request.
One of the mixed rocket payloads to build the platform.
The important part of supporting mixed payloads was to make it fully automatic. That is, you request something on your space platform and if you have automatic requests turned on in your rocket silo, the logic should pick the right batch of items and have robots deliver them to the silo. At the same time we had to keep performance in mind and not try to find the most optimal solution, just something good enough.
We process requests sequentially and start with the lowest request count. These represent one-off construction requests or important items, so we want to deliver them before bulk goods which platforms normally transport, like calcite from Vulcanus or planetary science packs.
Things get tricky if you have too few unsatisfied requests to fill a rocket. Sending the rocket half-empty would be wasteful, but we didn't know how to solve it nicely when making 2.0. In 2.1 we decided that we should select the most requested items and overdeliver them because you likely want more. Delaying the rocket until players request more items wouldn't be intuitive and wouldn't really work with the "all requests satisfied" condition.
Step-by-step demonstration of the logic.
Even when overdelivering some items, the algorithm can still fail to find a complete batch due to our sorting constraints. It usually happens when you don't have enough supply in your logistic network. The logic hopes that missing items will be produced eventually and wants to wait. Some co-workers were confused about it during our playtesting, so I opted to fall back to single-item rockets to keep things flowing.
I also made various other tweaks, so the fallback should be very rare and we can change it more based on players' feedback.
Another difficult case was dealing with space platform deadlocks. A few weeks after 2.0 release we got a bug report on our forum, the player pasted a large platform blueprint and their hub didn't have enough inventory space to fit all the requests. Before they could get enough tiles and cargo bays built, other items managed to fill the hub completely. The workaround required sending some items back down and making sure cargo bays would be able to get in this time.
Of course we had to fix it, so Rseding changed the code to not put unbuildable stuff into construction requests. This fix was fine when rockets sent full stacks but led to inefficient utilization of the new mixed payloads. Reintroducing this bug was not an option, so we had to find a different way to fix it.
The thread had suggested to prioritize space platform foundations, which became doable since item requests were sorted for batching logic anyway. Therefore I added a request priority API to item prototypes and enabled it for platform foundations and cargo bays. Cargo bays are prioritized to speed up the building of large platforms by adding more input hatches and increasing inventory size, but it means they can still deadlock the platform in an extremely rare case. We thought this was an acceptable tradeoff. This change adds all ghosts to construction requests again, even if the platform has enough supply, and also includes item requests of unbuilt entities.
During my rework I also found time to fix related long-standing bugs like the one with custom minimum payload. Using custom minimum payload shouldn't be as necessary anymore but now it works more as you would expect. The rocket will request as many items as possible, capped at the requested amount or the amount in your logistic network, whichever is lower. It will try to launch as soon as the minimum payload is satisfied and no robots are on the way to bring more items. I even fixed modded cases like auto-launching items to orbit if a mod enables it in Space age, which brings me to our next topic.
Since I was rewriting rocket delivery logic anyway, I wanted to consider modding interface requests on this subject. Quite a few modders were displeased that the rocket lift weight was a global utility constant but their request was marked as "won't implement" because it required a significant rework of the system. This was the perfect time to revisit it.
It surprised me how much moddable lift weight complicated the implementation and I believe Rseding was right about rejecting it. I am not really sure if difficulty increased with mixed rockets or not, but it adds another payload optimization parameter to automatic rocket deliveries, so it makes sense that things aren't easy. Nevertheless, I was determined to implement it.
Finding the optimal packing gets exponentially harder because now you not only have to pack items optimally into a rocket but also pick the right size to overdeliver as few items as possible. I started working towards the optimal solution hoping the code would stay simple enough but as soon as I solved one problem I found another edge case. I was worried about the performance impact of more complex approaches, so in the end I scrapped most of it and chose the simplest way. The logic now picks the smallest available rocket which can fit all requested items, whereas a better approach could involve splitting the load across multiple smaller rockets. It is a reasonable compromise and we can tweak it later if someone comes up with something smarter.
As for the rocket capacity mentioned in the item tooltip, which was another blocker for this feature, I decided to keep it referring to the default capacity in utility constants. Changing it to item weight and letting players calculate rocket capacity in their heads might have been better for mods with many custom rocket silos but not so much for Space Age. This way, Space Age is unaffected and mods can treat their custom lift weights as multipliers of this default value.
A tooltip of a modded rocket silo with increased lift weight.
As a last thing to make the automated delivery logic work nicely with mixed rockets, I changed the rocket silo inventory size to be dynamic. Inventory slots will automatically grow and shrink when new items are added or removed, either physically or through remote interaction. The old mode didn't go away. Modders can choose between a weight-restricted slot-unlimited inventory and a weight-unrestricted slot-limited inventory. This selection is tied to launch_to_space_platforms prototype parameter because automatic rocket delivery can only work with dynamic-size inventories.
Space platforms are the logistic back bone of the Space Age gameplay, and while they work okay, there are a few improvements we've made during 2.1 development.
Orbital requests can set a specific planet to import the items from. This is necessary for the platforms to actually move items between planets (E.G, pick up Tungsten from Vulcanus, drop it to Nauvis). If there was no filter on the pickup planet then the game would have no way to know where dropping the item makes sense.
But it turns out, there are some cases where we want to import items from basically all locations, or at the very least prevent dropping items at any planet.
The main example is items that the platforms themselves need (like Fuel cells, Repair packs, etc).
It is somewhat possible to achieve it with multiple logistic sections (each importing from a different location), but that is just tedious, instead we just implemented the common suggestion of "Leaving the [Import from] blank", which now means "Import from all locations":
A related problem, is that if you have a filter set to trash on a specific planet (E.G, dump Depleted uranium fuel cells at Nauvis), it was possible the platform would leave with the items still in the trash slots. This causes a little bit of an unwanted problem in some situations, essentially randomly deciding where the items would end up.
So we amended the platform logic, so that it will wait to clear its trash slots before leaving the current location (if there is a surface to trash to).
This also applies to any items manually trashed of course, so your expedition ships don't leave while you're waiting for your construction robots and such.
You can also notice in the screenshot the new Diode next to the 'Orbital drop slots' panel, hovering this will show the status of the drop logic, such as "Waiting for item drop cooldown" or "All surface stations are busy".
You might notice something a little bit suspicious in the last screenshot: "Why is the platform importing Ice/Carbon/Sulfur? Isn't that super inefficient and illegal?".
And yes! You would be absolutely right if we were playing 2.0. However with 2.1 we are adding the ability to let platforms send and receive items from other platforms:
In the orbital request, you can specify from which place the filter will request from:
To prevent unexpected item transfers and also help with the feature discoverability, platforms have a checkbox to specify if they provide to other platforms or not:
This of course opens up a whole new can of possibilities such as:
No Factorio feature is complete without the true automation with the circuit network. One reason we didn't add the circuit requests before, is that we did not have a way to specify which planet they would import from, and it seemed like an awkward system to implement.
But now, we have the 'Import from Any', so we can keep the design clean and intuitive by saying "Circuit requests import from all locations", and they also request from 'All' sources (from the planet and platforms).
It is also possible to use 'Set requests' at the same time as 'Read contents', due to a little bit of magic self-subtraction of the circuit network signals.
To make all the pieces come together, we need a way to transmit signals between platforms and planets, and it is only natural to have this feature as an extension of the Radar circuit connection:
You can specify a channel (SignalID), and all radars with the same Universe channel will send/receive from each other. On a platform you can filter the channels by current location to get missing planet materials or available cargo, and implement whatever logic you might like to control and command your fleet.
All these features combine to make the Space logistics in 2.1 much more capable, oh and there is one more thing...
As a part of 2.1 we are making our last pass over the graphics, so prepare your eyes for this treat and many more to come.
Graphics by Zsolti, Sounds by Ian.
It is now much more clear when the silo is crafting, and we added the little hatch in the top right for the robots to pickup/drop items.
As always, mix a payload of your thoughts at the usual places
