I always seem to come back to this game. As far as simulators go it's top notch, and the level of commitment one has to allocate to play one of the overhaul mods is quite the thing. In this case SE stands for "Space Exploration" (as opposed to Special Edition).
It's fascinating that these mods are even compatible, as they essentially attempt to achieve opposite goals. SE is all about colonizing other planets which creates a lot of decentralized logistical problems (probably why I like it), because you have to colonize multiple planets and there are only a couple ways to transport product between planets (all of which are expensive).
Krastorio 2 is more about scaling up and creating centralized "mega bases" where millions of items are being processed and output in the same location, so again it's weird that these two mods can even work together. The only reason why they can is that it's someone's 'job' just to make sure they work together because they are two of the most popular Factorio mods available. Normally two overhaul mods that complete change the game could never be compatible unless they are specifically made compatible like these two are. I'm still not sure how the creators of these mods get paid (if it's just tips or whatnot) because the amount of work that goes into them is downright astounding (from sprites to scripts to game balance). These enthusiasts spend thousands of hours creating this stuff. Pretty wild.
You end up finding an abandoned derelict vessel on the first asteroid field you discover using satellite rockets. It probably looks a bit rough considering this is just a mod for the game, but the way that it works is pretty interesting.
The first picture is what it looks like after you repair the damaged sections, but it's wise to make some modifications to it for it to be more useful.
astronomy to get there.Automating a spaceship like this is shockingly difficult in Factorio SE, and after playing this mod for literally hundreds of hours (cumulatively combined with my previous non-KR2 game) I finally figured it out.
Coincidentally enough the first asteroid field in which the ship is found also contains copious amounts of Beryllium which is the main resource for getting farther with astronomy tech (there are 4 advanced resources like this in total). So in this game I dared to be different and vowed to set up a mining operation in space for the first time ever; with the spaceship being used to automate transporting the beryllium to my main base (which I have thus dubbed Orbital Command).
One of the biggest sticking points with automating the spaceship is the console. In essence the console is the brain of the ship, and has various input/output signals needed for automation. The reason why this is so confusing is that it looks like a single entity but in reality there is a tiny console on the right (shown above) that's completely different from the rest of the display. These are where all the output signals are broadcast, whereas input signals are connected to the left side.
If we're just trying to do basic automation a lot of these signals are not needed, and the ones that are needed have to be executed in a very particular order for it to work properly. Also, some of the signals can come from outside of the ship (dock) while others must be calculated and broadcast from within the ship.
This ends up being a bit overwhelming at first because we can only put so much stuff inside of a ship before the integrity variable gets too high and the ship will no longer fly until something gets removed from the build. Max integrity gets upgraded as the game progresses, but again I haven't even researched the ability to create a ship, so I'm stuck at the minimum level (300 max).
This variable can be toggled from the outside. More importantly it can be set using a constant combinator as long as the destination is indeed a constant: meaning the logic dictates that we know for a fact that the ship can only be going in one place from the current dock. Any kind of "middle man" docking station would have to have the appropriate if/else logic set up to broadcast the correct variable, but in the easiest cases this is not a variable and remains constant (like in this example).
In this particular iteration the ship is docked at Orbital Command and I know the destination ID needs to be the beryllium asteroid mining colony I set up earlier. So I head into the universe explorer and see that the signal I'm looking for is asteroid field #43 and set the appropriate signal on the constant combinator.
Oh wait actually this part isn't even easy because it's a bit unclear that it can even be done in this manner. As a newbie I didn't even realize that signals could get to the console from the outside of the ship. If you try to connect a red/green wire to the console from the outside it will work for a single attempt... but when the ship launches these connections will be severed and the signal wires will be destroyed.
Apparently connecting a wire on one of the clamps will transmit to the other side without the two wires actually being physically attached. Of course for some god forsaken reason you're able to connect wires to two different locations on the clamp (on the bottom and on the top). Only the top connection is broadcast to the other side, so if we just happen to accidentally connect to the bottom (which seems to be easier to do) then it won't work and we'll have no idea wtf is going on.
The launch command is simple enough... or so I thought! This one definitely can't be set as a constant, otherwise the ship would takeoff the second it landed (which is something that happens over and over again when you have no idea wtf is going on). Because this ship is outfit as a beryllium hauler, I set the variable to launch at orbital command when beryllium = 0, while the ship will launch at the mining outpost when beryllium >= 1000. This ends up being a very efficient way of doing things as it takes quite some time for my outpost to actually mine 1000 beryllium. The ship spends most of its time waiting at the outpost and only spends a couple seconds unloading at Orbital Command.
In fact the ship unloads so fast that I had to make the Orbital Command circuit more complex. I noticed that there wasn't enough time for the ship to fully refuel before it took off again, so I created two custom signals: X & Y. Both have to be true before sending the launch signal. X signal returns true (1) if beryllium = 0, while Y signal returns true (1) if the fuel tank is near full. Then for good measure I added a manual override using another constant combinator that allows me to shut the whole thing off so I can keep the ship and drydock and make upgrades without it taking off (which it ended up doing like 10 times before I actually figured out how).
Once the ship has a destination set and has been launched into orbit it requires one last signal before it actually starts moving. The speed signal accomplishes this, while also setting the preferred speed of the vehicle. There are certain situations in which we want the ship to target a lower speed then the maximum:
Fortunately I didn't have to worry about any of that especially after removing one of the two engines from the ship. It easily flies at maximum speed out to the first asteroid belt (although this would certainly not be the case farther away from the sun as all the energy generated is solar). But again in this case the speed is simply set above the maximum onboard the ship with a constant combinator.
We can see that I've randomly set the speed to 130 even though the ship caps out around 70 with one engine. Signal 69 is a docking clamp output, which is perhaps the most complicated part of all of this.
According to Informatron, an in-game guide for factorio mods (a mod for mods; so meta), in order to land a ship automatically at a docking station the console requires two separate signals:
The documentation seems to be a bit better now as the mod has been around several years, but back in the day it was pretty damn confusing. That's because the clamp at the dock broadcasts a signal with a yellow arrow that is apparently not used by the player (and perhaps exists for some kind of script running in the background).
So if we want to connect ship clamp 69 to dock clamp 420 we need to broadcast a clamp signal with a yellow arrow (69) pointing right (because the ship clamp is on the right side of the ship and pointing right). However, we need to broadcast a blue clamp signal (420) also pointing to the right in order for it to actually work, even though that docking clamp is literally broadcasting a signal of the opposite color and pointing in the opposite direction. Fun stuff. I'm sure there's a reason why it's so confusing. Probably has something to do with more complex solutions.
Fortunately once I actually realized how this all works I figured out that the ship's docking signal (69) is a constant that can be broadcast 100% of the time. As long as it's not paired with the other signal the ship will not land. This is significant to prevent the ship from redocking immediately after taking off. Because I was already using a constant combinator the broadcast the ship's speed (130) I just used that same one to broadcast dock signal 69 to the right (shown higher up in the "speed" section).
God forbid you tried to have multiple docking clamps on the ship or multiple docking clamps on the surface which would trigger in different circumstances. Clearly this is possible but I'm still not sure why anyone would add this kind of complexity to the build. Then again ships are pretty damn expensive and programming one ship to do multiple things could prove useful. Still: I'd be interested to see if anyone has found a valid reason to have more than one clamp on the ship itself, as multiple clamps on the surface makes a lot more sense.
This is the correct signal to automate docking to the clamps I have set up. The problem is that a constant combinator is... constant. And I need to only broadcast the signal when the ship gets to where it's going, otherwise it will redock the second it launches. This is accomplished by feeding the constant signal into the back of an onboard decider combinator that will "decide" when it is time to broadcast the signal (if/else).
It looks like there's more than one way to do this, but in this particular case the combinator will broadcast the correct docking signal if destination = -1. A destination of -1 apparently means the ship has reached the destination that was set at the previous docking station. Another way to do this would be if speed was -1 (indicating the ship has stopped) but a destination of -1 seems more accurate and less prone to bugs given more complex operations.
So given this condition the combinator broadcasts the 420 signal, and when combined with the 69 signal the ship will automatically land... finally completing the automation process until it starts all over again with a new destination and launch condition provided by the current dock.
Notice that the bullet for "input count" is selected, which is required so that the combinator broadcasts the correct 420 signal. If I has just used the default docking signal (1) the constant combinator of 420 wouldn't be needed on the ship, so it's a bit extra, but I wanted to know exactly how it worked so I picked non-default numbers during testing. Totally random non-default numbers.
Again it's very expensive to transport product between planets in SE. The advantage of figuring out spaceship automation is that it's by far the cheapest avenue to move items around; The path of least resistance if you will.
The delivery cannon is by far the most expensive option, but the advantage is that product moves instantly within the solar system to any planet in small quantities as desired.
The cargo rocket is bulk transport that ends up being much cheaper than delivery cannons but is only 100% efficient if all 500 product slots are filled with items to transport. It can be difficult to acquire that much product at once within a timely manner. Launching these rockets also costs 100 cargo rocket sections which are relatively expensive but 20% of them are salvaged for reuse (+4% per research upgrade). Cargo rockets are also nearly instant travel no matter the distance (which doesn't make logical sense but is a great balancing mechanic). They also cost a lot of rocket fuel.
While a spaceship takes time to get where its going: the only physical resource it consumes is rocket fuel. This makes it highly efficient, especially when taking off from small planets (lower gravity & lower escape velocity requires less fuel for takeoff). Coincidentally enough the closest moon to my home planet (Nauvis) just happens to be a very small one with a main resource of oil, so eventually I plan to set up a mining operation there to create near-infinite rocket fuel with a refueling station in orbit (which is even easier to takeoff from). Once I have that up and running I should be able to transport a lot of product around basically for free using this newfound spaceship automation described above.
Another thing that is really hard to transport around is fluid (including rocket fuel). Barrels of fluid do not stack well inside of cargo rockets, with only 10 of them being able to stack per slot. Most other items can stack up to 100 (some 50 some 200), so only 10 makes it very difficult to transport things like water, oil, and other various chemicals around. On top of this inconvenience once barrels are emptied you're left with one empty barrel, which can then be recycled back into 1 steel (the cost of a barrel) but this leaves us with yet another logistics problem: a ton of steel or empty barrels sitting around in a place where they aren't needed and eventually need to be dealt with.
Spaceships can be outfitted with bigger and more efficient liquid tanks that can hold exponentially more while also not leaving behind a steel byproduct. So it will be interesting to see how much better this is since I've never actually done it before.
And to think I thought I could get this one finished in a timely manner.
My video game posts are always so atrociously long.
Yikes.
While this is just a silly video game or whatever: logistics, programming, and automation extend deeply into the real world as well. Hell, Amazon makes all their money basically 100% on logistics alone. Getting physical items from one place to another seems like it should be easy, but just like many other things in this world it's a mastered skill that we simply take for granted.