LTN Space Age - Rewrite

[Alzurana]

TL;DR
Rewrite efforts for 2.0 SA should be considered when talking about LTN continuation to respect Opteras wishes.

What ?
Going through the issues and Opteras replies it feels to me as if nobody is really hearing what the original author expects from a continuation of the LTN Mod. So I'll list what I gathered to hopefully guide the discussion into the right direction:

• A port with the old code is not desired as it would drag out old concepts that do not fit onto the new design of the game
• Pull requests that just "make it work for 2.0" are also not desired (I think)
• Optera mentioned that they have not been approached for a proper, formal takeover, yet. But I don't know if that is outdated by now.
• 2.0 LTN should ideally rebrand slightly to differentiate it from the original and make it clear that it is a rewrite. Suggestion: LTN 2.0 Space Age
• Performance considerations for a rewrite: Pathing is now the biggest cost. Trains that return to a depot are worse for performance, not better. The whole depot concept needs to be re imagined therefor. Trains could move to a provider station right away, waiting to be reloaded. I feel like this breaks LTNs feature that a single station could be both, provider and requester. I would propose that trains stay in their dropoff station either until another request is made or another train needs to enter it, only then going to a depot to make space. Maybe make this configurable so players have the ability to choose classic or new behavior.
• It would be beneficial if a rewrite for 2.0 could make use of icons and art that 1.1 already provides.
• An LTN combinator could be included or provided as a separate module.
• An LTN interface could be included or provided as a separate module.

-> When I first thought about this I had the idea of setting up all LTN activity as train interrupts. However, when I looked over the lua documentation I did not see sufficient ability to insert, create, manage or trigger interrupts via the lua interface. Meaning classic LTN dispatch might still be the only option.

Why ?
I hope this is more aligned with what Optera would agree with.

[0ptera]

That's a perfect summary.

[FoMaK]

A port with the old code is not desired as it would drag out old concepts that do not fit onto the new design of the game

LTN is already interrupt based, so “interrupts 2.0” uses old ltn concepts... I don't understand what exactly is obsolete here...

LTN for example is needed for my PY run with 600 hours spent (and I'm not the only one, other players have fallen into this trap too), why not fix the current version (considering the community is willing to help)? This would be version 1.19.0. Will there be an updated and shiny completely redesigned ltn? This is already version 2.0.0 of the mod

[Alzurana]

LTN modifies the train schedule with permanent stops that it clears after leaving the dropoff (or when entering the depot, it's configurable)

In general to me it seems like optera has certain wishes that should be respected as it is their former passion project. That we're not permitted to take the old code is a bummer but ultimately not a tragedy.

I've been in the process of working myself into factorio modding. I do have decent gamedev and coding experience as well as lua experience. Just none in factorio, yet. I haven't proposed to take over fully because I am not 100% sure of what LTN 2.0 could look like. Since this is a redo, it's possible to clean out some older concepts that are actually a bit hard to use.

One of them would be the network ID being a bitmask. It's equally performant to solve this with tags or groups, same as train groups and signal groups are now a thing in the game. To add a stop to a "network" you would just add it to a group that you define by name. This is much more comfortable. The default group for stops would be the surface they're on, naturally. This would also allow other mods like Space Exploration to combine surfaces with space elevators in a very easy fashion.

Another consideration is to align modern train stop functionality more to how requester and provider chests also work and provide an interface to configure stops directly without the need of complex circuitry but allowing circuit control if needed (same as existing logistic chests)

I am also not sure if this concept should be expanded to providing additional train stop functionality:
Active provider stops that always load a train preemtively?

Also, can the signals from and to the train network be improved? Should stops have 2 combinators for input and output, should they split these between green and red wires? The idea here is that it could make it easier to differentiate what's supposed to happen to a train based on a signal the stop itself provides. Example: Negative numbers for unload, positive numbers for load.

Something that always annoyed me about LTN was how it lost track of trains that took a little bit longer. It would be great to have a feature that does not just "forget" about the train but warns the player if a train takes suspiciously long (configurable).

Or if a train is being loaded with a product that is not requested. It would be great to get an error message if that happens on accident somewhere.

-> Should slots in wagons be filtered so inserters can not accidentally insert the wrong item? (configurable) How to clear the hand if it has something wrong grabbed?

-> Can LTN determine stack sizes itself and you never ever have to configure item counts anymore, doing math in your head based how big a stack is. How about making all thresholds stack based? This makes a lot more sense for trains and storage all being stack based anyways.

Yeah, lots of thoughts but not that much work in the actual project, yet. But I think I would be willing to try. (Ofc a redo like that would break compatibility and you'd have to redo stops if you want to update an old save. However, I believe that to be a good tradeoff for a more streamlined 2.0)