According to the LTN API documentation, it says we don’t need to manually remove connection data when entities are destroyed.
I followed this guideline, but I want to double-check: Is it true that LTN will always clean up surface connection data automatically when relevant entities are removed, or are there any cases where manual cleanup is needed?
Thanks for any clarification

What are you trying to do? LTN creates a logic "we can somehow route a train from surface a to surface b" connection when some other mod puts that information into LTN using the remote API.

If you later destroy one of the surfaces, LTN will clean this up. If you have an entity that provides that connection (e.g. the SE space elevator) and you destroy that, then the entity should (in one of the handlers that will be called, e.g an on_mined_... handler, remove that connection.

What would not work is if you need that entity to move trains from surface a to surface b, that entity created the surface connection but then was deleted. LTN would in that case try to send trains to that entity and you most likely end up with "no path found" errors.

Is there a concrete reason you are asking / are you working on a mod that uses that API? I can help / try it out.

Thank you for your answer. I've roughly figured out the logic of the LTN API over this period of time, so the question is actually answered. Yes, I did try a train-teleport mod, and it's currently stable and compatible with LTN.

Furthermore, your API changes or some logic modifications might affect my compatibility with LTN. However, if you're interested, you can test my mod RIFTRAIL. I'm not sure what else I need to do or what can be combined with yours.

There are some patches for se-ltn here: https://github.com/harag-on-steam/se-ltn-glue/pulls. Those are specific to the space elevator but if you mod works similarly, the logic should apply for you as well. The most important thing is that your mod should use temp stops to route trains to your connection entities and that for advanced cross-surface delivery, LTN might schedule deliveries where the pickup is on a different surface, so there needs to be a surface change between leaving the depot and the provider; something that you might not have expected before.

Thanks, that makes sense.

I updated Rift Rail so the extra stops it inserts into the LTN schedule are now added as temporary stops, including the optional post-teleport cleanup stop. That seems to match your recommendation.

I also reviewed the advanced cross-surface scheduling case. In my current implementation I haven't run into the “wrong end” / reversed entry-exit situation, so I don't think I need an additional fix there right now.

As for cleanup when portals are removed: normal removal paths are already handled on my side. I am not planning to add extra complexity for extreme editor-forced deletion edge cases unless I see a real issue in practice.

Rift Rail already supports deliveries where the train needs a surface change between leaving the depot and reaching the provider. The main thing I changed after your feedback was making the injected routing stops temporary.

I put this mod together - https://mods.factorio.com/mod/ltn-space-exploration which uses the APIs "how they are supposed to work". It manages temp stops, elevator, advanced delivery and everything else LTN may throw at an integration. Feel free to pick the pieces that help your mod.

that was helpful.

I checked that logic more carefully on my side. RiftRail is now using temporary stops for the cross-surface routing, and I also handle the advanced cross-surface cases where LTN may require a surface change before reaching the provider, not just between provider and requester.

I also removed the optional post-teleport cleanup stop setting from my mod. That behavior made more sense for space-elevator-style infrastructure, but for RiftRail it was not really necessary, and I did not want it to interfere with LTN’s temp stop handling.

At this point the compatibility is stable on my side, so I think I have covered the important parts of the API. Thanks again for the clarification and for pointing me at the SE/LTN integration work.