[Implemented] Space Exploration Space Elevator Compatibility? (IE LTN between surfaces)

[Sloppyjosh]

Earendel is releasing a space elevator that allows transmission of power, circuit network, and Physical Trains between game surfaces. My question to you, is it possible for different surfaces to interact in LTN?

[ssilk]

Currently comparisons between different surfaces are excluded to avoid calculating routes between surfaces.

[Optera]

Let's talk about this when SE also automatically adds intermediate trains stops required to teleport trains between surfaces.
I certainly won't add that to LTN.

[S_gamez]

Maybe not related but as SE is mentioned will it work to use the same binary on 2 diffrent surfaces without interference ?

[robot256]

Yes, scheduling checks between surfaces are excluded even if the network ids match.

[DrParanoia]

So, now that the Space Elevator is out, is there a way to make LTN work between surfaces?

[Neocult]

As this is the first information to find with a search engine and people still looking for this compatibility, I could add some of my findings to save some time and hazzle for people interested.

### Some Explanation for Vanilla ###
The Space Elevator is working as a train station Up and train station Down and can be added in a normal schedule (Factorio Vanilla) and that works well. As a downside you will see stations on other surfaces in the train schedule as unreachable, but they will be reachable if they are after the space elevator station in the schedule (Which brings them to the right surface and if they are actually reachable by track then it becomes visible in the schedule and the train operates correctly).

### LTNs well working defaults + How much effort for extension ###
LTN separates Surfaces from each other, as it is a very useful and expected default behavior (Separate Planets, Enclosed Entities etc., which will not interact by train), because there is no useful train transition between surfaces under most circumstances. (Planet to Planet (Space Exploration) or Surface to Factory Hall (Factorissimo)) ---> (Several surfaces is modded Factorio already and LTN supports that well)

There is a couple issues to solve to create compatibility which needs several checks in place to influence train routing depending on mods installed and behavior wanted. That needs additional configuration options and/or signals + MOD specific extensions and quite a work to integrate with complex procedures already in place.

### A self-made workaround (To utilize it still somehow) ###
STEP 1
You could wire all your stations in orbit (Use *1 Arithmetic to not pollute your individual stations signal) und create the request for materials (If you use the mod LTN Content Reader, they have combinator giving out the LTN requests as a signal already). These signals you can request at a LTN Train Station near the Space Elevator deliver all the materials to the elevator.

STEP 2
Just build a Circle Track around the Elevator on the ground and in orbit. Create VANILLA train stations (Ground Station (Load) / Orbital Station (Unload)). Now transfer all the requested materials at the ltn station to the ground vanilla station. Program one train by hand (vanilla style) to bring all possible goods to orbit and unload them there.

STEP 3
Now having the requested Goods in Orbit, you build another LTN Station there, transferring all the unloaded materials into the station. They are now available for pickup and in the LTN Network in the Orbit. (Wire the arrived Materials in the train station back to the request on the ground to avoid too much over delivery while the material is waiting to be picked up in Orbit to the final destination)

STEP 4
Use signaling to Extend to more space elevators if you need higher throughput.

[DrParanoia]

Maybe it is possible to have something like "Surface group id" that could be provided to LTN stops? And then, the pathing could check if there is a space elevator or not (or maybe some sort of manual way to provide a "proxy station" which in this case would be the Space Elevator).

[robot256]

Maybe it is possible to have something like "Surface group id" that could be provided to LTN stops? And then, the pathing could check if there is a space elevator or not (or maybe some sort of manual way to provide a "proxy station" which in this case would be the Space Elevator).

I made a working proof of concept last year that does this. Add hooks to LTN somehow to tell it certain cross-surface routing is allowed, and make LTN listen to the "train used elevator" event to update the train ID (just like on_train_created). It creates the jobs and dispatches trains like normal, except it checks stops on surfaces marked as connected, and doesn't add temporary rail schedule records for another surface (causes a Lua crash otherwise).

A "helper mod" listens to the LTN dispatcher update event and checks for trains scheduled to cross surfaces. Then it adds the elevator schedule records as temporary station entries, and adds the appropriate temporary rail stops when the train arrives on the destination surface.

The main thing I've been unsure of is how the user should tell LTN cross surface is allowed, and how to tell the helper mods which elevators should be used. The most versatile UI would be for a GUI attached to each elevator to accept a network ID mask for the LTN networks allowed to use that elevator. The simplest would be to automatically detect the presence of an elevator and just assume all rail networks on both surfaces are connected.

[Whias]

I don't suppose you got any further with this? I am just now reaching space elevators, and the thought of having to make interfaces between LTN and regular trains for each of my resources is pretty painful.

[DrParanoia]

Maybe it is possible to have something like "Surface group id" that could be provided to LTN stops? And then, the pathing could check if there is a space elevator or not (or maybe some sort of manual way to provide a "proxy station" which in this case would be the Space Elevator).

I made a working proof of concept last year that does this. Add hooks to LTN somehow to tell it certain cross-surface routing is allowed, and make LTN listen to the "train used elevator" event to update the train ID (just like on_train_created). It creates the jobs and dispatches trains like normal, except it checks stops on surfaces marked as connected, and doesn't add temporary rail schedule records for another surface (causes a Lua crash otherwise).

A "helper mod" listens to the LTN dispatcher update event and checks for trains scheduled to cross surfaces. Then it adds the elevator schedule records as temporary station entries, and adds the appropriate temporary rail stops when the train arrives on the destination surface.

The main thing I've been unsure of is how the user should tell LTN cross surface is allowed, and how to tell the helper mods which elevators should be used. The most versatile UI would be for a GUI attached to each elevator to accept a network ID mask for the LTN networks allowed to use that elevator. The simplest would be to automatically detect the presence of an elevator and just assume all rail networks on both surfaces are connected.

LTN recently added a couple of new events (on_delivery_created, on_delivery_pickup_complete, on_delivery_completed). Maybe these can somehow make your task simpler?

[ZenithStar]

Following a discussion at the Earendel/SE discord, I briefly looked through the two codebases and it's non-trivial but doesn't feel too difficult either.

From SE's side, it would be nice if the remote API directly listed all space elevator connections with the associated surface index and the station names. (Maybe add it as a zonelist flag and force asset while we're at it.) It would also be nice if SE would be aware that a train being teleported was an LTN train and to not invalidate its temporary stations.

From LTN's side, with the currently available APIs, it would have to scan through all stations across all surfaces and match by name. Conveniently, each space elevator station is prefixed by the space elevator icon and suffixed with an up or down arrow. Alot of the dispatcher code will have to be modified to count space-elevator-connected stations as valid providers and free trains and then schedule the space elevator stops. If SE doesn't support LTN back, LTN would probably need to reschedule any deleted temporary stations after on_train_teleport_finished_event. LTN would also need to schedule sending the train back across the elevator if there's no depot available on the requester side. (btw I don't actually know lua or the patterns/idioms of the factorio mod ecosystem)

[robot256]

Following a discussion at the Earendel/SE discord, I briefly looked through the two codebases and it's non-trivial but doesn't feel too difficult either.

Harag and I had a longer productive discussion in the SE Discord closed-testing-chat channel that answers some of your questions, and Harag is testing their own version of what an LTN interface would look like. I think they were planning to test more before bringing it up here.

From SE's side, it would be nice if the remote API directly listed all space elevator connections with the associated surface index and the station names. (Maybe add it as a zonelist flag and force asset while we're at it.) It would also be nice if SE would be aware that a train being teleported was an LTN train and to not invalidate its temporary stations.

An interface to expose elevator data would be useful. The temporary stop issue cannot be fixed, because Factorio will not allow you to make temporary rail stops on a different surface than the train currently is. For LTN to route to another surface, it must omit the temporary stop on the other surface.

From LTN's side, with the currently available APIs, it would have to scan through all stations across all surfaces and match by name. Conveniently, each space elevator station is prefixed by the space elevator icon and suffixed with an up or down arrow.

The player can change the name of space elevators, so this is not actually a good solution. That's why SE or a "glue" mod needs to determine which surfaces are legitimately connected for a given force, and provide that information to LTN somehow.

Alot of the dispatcher code will have to be modified to count space-elevator-connected stations as valid providers and free trains and then schedule the space elevator stops.

There are actually only a few lines where LTN checks if two stations are on the same surface. Those checks can be modified to account for surfaces that are declared to be linked. The biggest issue with this change is how to make it the most computationally-efficient. That probably means caching a table of links, and keeping that cache properly updated will be the hardest part of the changes required.

If SE doesn't support LTN back, LTN would probably need to reschedule any deleted temporary stations after on_train_teleport_finished_event. LTN would also need to schedule sending the train back across the elevator if there's no depot available on the requester side. (btw I don't actually know lua or the patterns/idioms of the factorio mod ecosystem)

Someone has to recreate the temporary stops in on_train_teleport_finished_event, yes, because they cannot be made while on a different surface. This doesn't have to be LTN itself, if the "glue" mod remembers the train's destination as given in on_delivery_created.

My take from our discussion on discord:

The primary interface needed is a way to declare certain pairs of surfaces to be "linked" by another mod, for a specific force and perhaps a specific LTN network mask. When this is established, it gives an alternative matching criteria to the existing "provider surface == requester surface" check. The second interface needed is a way to call "UpdateDelivery" when the train ID changes after passing through the elevator.

The external mod using the interface can easily add the elevator stops in the handler for on_delivery_created (both up and down), and add temporary stops while the train is en route. The external mod can be responsible for letting the user specify whether an elevator is LTN-traversable or not, so that it does not affect existing separated systems unintentionally. LTN does not need to modify the schedule itself, and it works as long as it does not reset the schedule after delivery is complete.

The form that this interface takes is the subject of debate. Some complicating factors that we have discussed are:

• What to do when the external "glue" mod maintianing the connection is removed
• Whether the interface should accept a complete table of surface links, so that the "glue" mod is responsible for performing individual updates and sending a whole new table; or if LTN should accept individual requests to link and unlink surface pairs and perform validity checks itself.
• How to indicate that a particular elevator is LTN-enabled (GUI or circuit network).
• How to handle multiple mods providing different types of surface links, for hypothetical example Train Tunnels and Factorissimo.

[ZenithStar]

What limitations would a glue mod have from the license restrictions and mod sandboxing? AFAIK, we wouldn't be able to overload, say, the getFreeTrains inside Logistic-Train-Network/script/dispatcher.lua and have LTN run the glue mod's functions instead. IDK how the dependency hierarchy for factorio mods work, but I assume interfaces needs to be higher up on a dependency tree. It would make little sense to force SE and LTN depend on the glue mod. I checked and they have no common dependencies atm.

From LTN's side, with the currently available APIs, it would have to scan through all stations across all surfaces and match by name. Conveniently, each space elevator station is prefixed by the space elevator icon and suffixed with an up or down arrow.

The player can change the name of space elevators, so this is not actually a good solution. That's why SE or a "glue" mod needs to determine which surfaces are legitimately connected for a given force, and provide that information to LTN somehow.

I don't believe players are allow to change the elevator station names independently. The format will always be <elevator_icon><elevator_name><up|down> and <elevator_name> will always match between the two surfaces. This would be an O(N^2) search but N can be as small as any station with the <elevator_icon> prefix which would max out at 20-30 for any typical playthrough. This is no more complex than getting the distances between station pairs, which is already being computed and cached/memo'd. This search-and-match can be performed in one of the LTN ticks, probably under

Code: Select all

elseif global.tick_state == 3 then -- parse requests and dispatch trains

before the ProcessRequest calls.

I don't think we can get away with letting dispatcher.lua run as is, so regardless, we'll have to rewrite a bunch of it, or glue mod would have to disable most of it and run its own scripts.

[Harag]

LTN has received the necessary changes and this is now available as a separate integration mod.