Hello, today we will go over some of the details of Space platforms we couldn't fit into the last FFF, as well as some new features that will tie the whole system together.
Without construction robots, do the things just magically appear on the platform?
Many things we show in FFFs these days are work in progress, including the space platform building visualizations.
Let me present the tiles building animation preview.
We will have something similar for entities too, so things won't magically appear, but it will be as though the platform is 'building' them by itself.
If blue science leads to rockets do we get advanced stuff like low density structure and rocket control unit earlier, or are rockets different?
Low density structure is blue science. Rocket control units were removed and processing units are used instead.
On top that, we lowered the cost of the rocket by 20 times. This is to lower the focus on rockets, because you will have to produce rockets on every planet eventually, send quite a lot of rockets to build your platforms, and to move stuff between planets.
This results in thousands of rockets being sent in the expansion at least.
We only see gun turrets on the platforms, are laser turrets ineffective against asteroids?
Each asteroid size has a different preferred weapon. Laser turrets are only efficient against the small asteroids, and the medium ones need at least a gun turret.
Since energy is quite scarce on the platform, it is usually a better strategy to just use gun turrets for both small and medium asteroids.
There are also going to be big and huge asteroids on some of the more dangerous routes, and these will need even heavier weapons, but more on that later.
With the cargo bay extenders, can't we use the one big inventory as a teleport?
We aren't noobs :) Why do you think cargo wagon can't be placed in space. Only the central hub can be used to access the items with inserters. It can be utilised on a small platforms, but it can't be abused in a scalable way.
Why can space platforms not have holes?
The reason is driven by a gameplay motivation. If you could have holes in the space platform, it would basically mean, that you can do a very comfortable spacious setup, and just remove all the unused tiles to reduce the platform weight.
We wanted to push the minigame of building a belt based mini factory in a limited space. So far, it seems to be doing its job as intended.
The first obvious question is how much can a rocket carry.
We surely wanted to make the transport from the surface to the orbit to be expensive.
This means that the rocket can carry only a small amount of items, which makes the relative cost of transporting different items quite important.
The obvious choice is to just set the rocket to carry some fixed amount of item stacks (it would be 1), but it just wouldn't be feasible because:
This is why we chose the capacity to be weight driven.
We decided the axiom to be that the rocket can carry 1000kgs of goods, and balanced the rest around it. We started by setting ore weight to be 2kg per item, so 500 items/10 stacks can fit in a rocket. Then we created an automated formula to derive the weights of items based on their recipes. Many items also have specific hand-picked weights defined in their prototypes.
This created some kind of rough base for testing, and we then modified many things a lot. Most non-intermediate utility stuff was cut to be at most 1 stack per rocket, many things were rounded up, etc. In some cases, we bent things a lot, science packs are expensive, but they can't be recycled, so we allowed 1,000 to fit in a rocket. Modules are expensive, but a whole stack can fit a rocket, because recycling modules is just silly.
There are 2 main ways to fill the rocket, manually and automatically.
In the manual mode, you can just put any mix of items you want as long as they fit the limit and press a button to send the rocket to a space platform.
Manually filled rocket ready to be launched.
In the automatic mode, the rocket silo will request just one type of item, based on the requests from orbiting platforms. By default it always waits until it has a full rockets worth before launching, so as to not waste any rocket capacity.
For special cases, we added the 'custom minimal payload' to set a lower launch threshold, which might be useful for very expensive, low throughput items.
You can select a non-default amount needed to send one rocket. The 'import from' selection allows the player to specify which planet is used to fulfill this request, it will be important later.
Launching yourself to space is done with the same rockets as normal cargo, in the GUI you just choose 'Travel to space' and pick your destination platform. Upon arrival the character will sit safely strapped into the platform hub.
However the weight system implies that the player can potentially hold tons of rockets worth of items in their inventory, so for traveling to space, you can only carry your armor and your guns, nothing else (not even ammo).
The last non-explained piece of the puzzle is the way items are transported from orbit back to the surface.
This is done with the cargo landing pad, which is a special building that can be extended with cargo bays like the space platform hub, and more importantly, you can have only one per planet!
The limitation of only one per planet might sound weird, but we just find it fitting, because otherwise (we tried that) it is too convenient to put them all over the place to have the imported items right where you need them, and in the late game, it is nice to have this one very busy logistic junction in your base.
The landing pad has logistic requests, which are satisfied by platforms in orbit. Inserters can pull items from it directly, and it also works as a provider chest when in a logistic network on the surface.
The interplanetary logistic system works nice, but playtesting uncovered one critical problem.
As you can see, this is a recurrent theme now, playtesting and iterative improvement is a required tool to uncover problems and develop something playable.
The problem we discovered is that the system has many points where you request the same set of items, and once you need to update it, it is a chore, and leads to chaos.
And this problem is not relevant only to space, as having a group of Spidertrons with logistic requests has the same issue, which leads to the annoying task of going through all the requesting entities one by one, using copy paste just to miss one in the group and introducing chaos.
This is why we developed a solution that solves all these problems and adds some nice benefits as well, which is the logistic groups.
The solution has three main parts:
This is similar to what I actually used during game. I was disabling/enabling different things based on what I
was planning to do.
The final GUI solution is also the result of quite a few iterations, the main goal was to make it reasonably simple to use if you don't care about groups at all. In that case, you just have the one unnamed group and use it the same way as in 1.1.
There was this annoying problem I had with Spidertrons. As I played, I had to add more and more trash requests for all the things they could pick up. For example wood, stone, ores, basically any kind of mess they encounter when deconstructing.
When I was adding around the 10th item to be trashed, I realized that there will be always that one extra item I forget about, and what I actually want to do is to trash everything that is not requested. At that point, the feature idea was obvious.
So we added the 'trash unrequested' checkbox, and when enabled anything that isn't explicitly requested is put straight to trash. This also has the secondary benefit, that when you change the requests of some group, outdated requests/items don't accumulate in the storage.
Using the 'trash unrequested' in personal logistic can have a few unexpected consequences at times, and it takes a while to become conscious about it. It happened to me many times that I crafted this new item into my inventory, it immediately disappeared into the trash slots, and before I realized what is going on, the robots were happily carrying it away from my reach... But once I got used to it, and turned it on or off based on what I was doing, it became one of the things I couldn't play without anymore.
Both the logistic groups and trash unrequested features are unified across player, requester chests, spidertrons, roboports, rocket silos, space platform hubs, and landing pads, and will be available in the 2.0 base game.
I would like to show you my favorite example of beginner/intermediate circuit network usage, to demonstrate a needed change related to the logistic groups.
If you know whats up in Factorio, you probably learned that it is not the best idea to spread your logistic network across all your expansions and defensive perimeters. It is generally better to have more smaller logistic networks, so the robot deliveries are faster. You also probably know, that it is a good idea to set up a way to keep your defensive perimeter in good shape automatically, so biters won't eventually grind it down. This becomes even more useful once you need to ensure that your base is able to survive long enough without your physical presence in the space age expansion before having spidertrons or artillery.
So its useful to set up the wall resupply system, which is basically a train which delivers all the needed materials to the separated smaller logistic networks around the defense perimeters. Just a few combinators are needed to make this work really.
Example of the automatic wall resupply setup.
The constant combinator defines what is needed at the remote outpost, and we subtract what we have from what we need to get the list of missing materials. This can be used to control the inserter unloading from the train and also to disable/enable the station to call the train only when necessary.
Everything is nice and easy, and doable in vanilla just fine, but the system has a problem related to change. You might decide that you want to add new item to your resupply stations, or change the item amounts.
As long, as you don't want to make a huge, whole-map circuit network, all the constant combinators (one in your main base, and one per remote station) have to be updated manually.
Manually... with no way to automate it... that is unacceptable!
Since we just finished the logistic group system, we were also looking for ways to read the contents of the logistic group with the circuit network, the solution felt obvious.
Constant combinators just use the exact same system for its configuration as the request entities, so different combinators in the world can be synced up automatically, and the constant combinator can be even synced up with requesting entities.
As you might guess, this is not the last time we will talk about circuit stuff. We have things which both make it more approachable and more powerful, but since this post is starting to be quite long, it will be discussed some other time :)
As always, let us know what you think at the usual places.
