Space Elevator Testing (Patreon)

The space elevator is in closed testing (on discord) at the moment. I've been avoiding making too much noise about that because while the bugs are easy to find it doesn't help having lots of people testing, it just takes longer to read through all the same feedback. The problems and process is quite interesting though, so is worth talking about.

So how does it work?

The elevator links a planet or moon to the corresponding orbit. There is part of the elevator on each side and their positions match. When you place one the structure on one end, the structure on the other end is also placed. The elevator is not finished at this point, these 2 structures are more like construction sites. You need to build the tether that connects them by passing resources to one end, and once the tether is complete it needs those same resources as maintenance. 

Once the tether is finished the space elevator lets a train enter on one side and let it exit the other side on the other surface. It can also transfer power and signals from end to end.

What are the challenges?

Cross surface electrical network.

Having a direct electrical network link through the space elevator 'was' done and worked well for most things. The catch is the way that the game optimises solar power. All the solar panels on a network are treated like 1 entity for power production. They use surface's details for the time of day and solar multiplier. Usually this is fine, but if the electrical network bridges 2 surfaces it will choose one (with the lower surface id) for ALL solar panels connected, so that can really mess up your orbit solar production. Suddenly solar panels in orbit use the planet's settings, including day/night cycle. For now I'm having to transfer power using internal accumulators which have dual purpose of also being needed for the machine's energy buffer. It's not too bad but not quite what I wanted. 

Train issues. 

What Factorio considers a 'train' is a connection of carriages, but any change to that set destroys the train and makes a new one, at least as far as the code is concerned. Any change, addition or removal of a carriage, can result in reversal of the train direction, which end it thinks is front, loss of the schedule, loss of manual mode, etc. 

When a train goes through the elevator carriages are replicated on the opposite surface and deleted from the original surface. This causes problems for the train, so a lot is needed to keep all of the associated data carried across.

While the train is half way through the elevator it is 2 trains, a front and back part. Their speed needs to be synced, that's not too hard, but as 2 trains I also need to make sure that the 2 sides are not trying to do conflicting things. The back-end is set to manual mode so it can be passively drawn forward by the front of the train, but the front of the train really needs to be capable of drawing the train forwards. This is a problem for trains with a locomotive at the back, the front train part ends up as half a train with no power to pull itself forward. To work around this I've had to make an invisible "tug" locomotive, so that the front of the train can always move. It's also important that the train is not artificially "pushed" forward by the elevator otherwise it will force itself past rail signals, not steer properly, and fail at all of the things that you get automatically if trains are pulling themselves along using the proper train logic.

At this point most of the remaining problems are weirder situations, like a long train going through 2 elevators at once or a long train occasionally getting cut in half for a reason I haven't figured out yet.

It's getting pretty close to a working consistently, then I can focus more on costs, balance, and a larger group of testers.