old LTN discussion thread

[Optera]

Er macht auch schon fast das was er soll.
Habe im mein Lager eine Kiste mit Eisen und Kupferplatten er gibt die Meldung raus das er 2 Stacks holen soll aber er lädt nur die Eisenplatte ein und der Filter wird nicht auf Kupferplatten umgeschaltet.
Im Kombinator habe ich je 1 Eisen- und Kupferplatte eingestellt.

Wenn du mehrere Gegenstände laden willst mußt du zählen wieviel die inserter laden und das von der ladeliste die LTN stops ausgeben abziehn.
Braucht maximal 3 Kombinatoren. Viel Spaß beim Tüfteln.

2017-02-22-22-08-37-4084801.jpg (100.75 KiB) Viewed 8576 times

[ssilk]

Please avoid discussions in other language than English.
See Forum Rules.

Phobos, Du kannst auf Deutsch schreiben, aber bitte liefere eine Englische Übersetzung mit (Google Translate zum Beispiel).
Phobos, you can write in German, but please provide an English translation (Google Translate for example).

Thanks.

[Iakhovas]

I, for the past 3 hours, cannot get this to work. I've reread every word on the mod website, and everything in the forums and i still cant get it to work. Initially i tried to integrate it to my preexisting oil rail network, (using RailTanker_1.4). I set up the depot, connected my storage tank to the constant combinator, set the negative value and waited in eager anticipation for the oil to start rolling in. Eventually, my other trains started going to this station with their previous route erased, and would just sit at the depot doing noting. I would manually send the intended train to the desired station, wait for it to fill, and it would just sit with the blue light. Never would go on it own. After hour 2, i thought maybe it was an incompatibility with the RailTanker mod so i set up a little test area using iron plate. My initial train in the depot would never leave and the ones with the plates would stay in the station with the blue light. I was using trains with one engine, one cargo trailer. Every combination i tried wouldn't work, and i have a strong suspicion its user error on my part. Any advice/help would be greatly appreciated. Sorry for the novel.

[Optera]

I, for the past 3 hours, cannot get this to work. I've reread every word on the mod website, and everything in the forums and i still cant get it to work. Initially i tried to integrate it to my preexisting oil rail network, (using RailTanker_1.4). I set up the depot, connected my storage tank to the constant combinator, set the negative value and waited in eager anticipation for the oil to start rolling in. Eventually, my other trains started going to this station with their previous route erased, and would just sit at the depot doing noting. I would manually send the intended train to the desired station, wait for it to fill, and it would just sit with the blue light. Never would go on it own. After hour 2, i thought maybe it was an incompatibility with the RailTanker mod so i set up a little test area using iron plate. My initial train in the depot would never leave and the ones with the plates would stay in the station with the blue light. I was using trains with one engine, one cargo trailer. Every combination i tried wouldn't work, and i have a strong suspicion its user error on my part. Any advice/help would be greatly appreciated. Sorry for the novel.

There's 2 possible parameter combinations that will prevent any delivery:
1) minimum Delivery Size must be equal or less than requested amount (this is exactly why older versions had best effort enabled by default)
2) train length must be between minimum length and maximum length

[Iakhovas]

Thanks for the quick reply! It turns out that i had selected the "oil in tanker" instead of the "oil". I changed the values to the correct icon and the whole thing sprung to life. This mod is amazing, thank you!!

[steinio]

I would like to have a option to set for example the train max size for the whole save so i just need to change train stops which needs other train sizes.
Maybe a global setting train stop or for simple implementation a config option - but this get lost on mod update.

Greetings steinio

[Optera]

I would like to have a option to set for example the train max size for the whole save so i just need to change train stops which needs other train sizes.
Maybe a global setting train stop or for simple implementation a config option - but this get lost on mod update.

Greetings steinio

What keeps you from using blueprints including combinators with set parameters?

[thelordodin]

Suggestion:
As I see mostly a train deliver one type of items.
So, why not set filter on all cargo wagons on delivery to requested item?
I mean if this mod https://github.com/SeaRyanC/fast-filter-fill can change cargo filter this should be possible to implement and it seems to be quite easy.

For merged requests it's much harder to implement, but is possible with some limitations: one way - don't merge different types, other way - set filters dynamically while loading on station.
Simplisity from filters is prior for me than merging.

This would allow:
- Make dual purpose stops easy without any combinators
- Avoid loading wrong type of material
- MUCH simplify multi delivery station setup

Can you make such an option for Depot or globally?

[thelordodin]

Suggestion 2:
Implement "Maximum trains going to this station" parameter (with default value 1 or 2 maybe in config file)
If there is more than this number of deliveries to or from this station don't make any new ones (continue as if this station have no requests and no sendings available).

[steinio]

I would like to have a option to set for example the train max size for the whole save so i just need to change train stops which needs other train sizes.
Maybe a global setting train stop or for simple implementation a config option - but this get lost on mod update.

Greetings steinio

What keeps you from using blueprints including combinators with set parameters?

Didn't know this works.
Will try it out, thanks for your insight.

Can I set up more then one ltn networks which are not connected by rail or would the mod create deliveries to no path stations?

Greetings steinio

[Optera]

Suggestion:
As I see mostly a train deliver one type of items.
So, why not set filter on all cargo wagons on delivery to requested item?
I mean if this mod https://github.com/SeaRyanC/fast-filter-fill can change cargo filter this should be possible to implement and it seems to be quite easy.

For merged requests it's much harder to implement, but is possible with some limitations: one way - don't merge different types, other way - set filters dynamically while loading on station.
Simplisity from filters is prior for me than merging.

This would allow:
- Make dual purpose stops easy without any combinators
- Avoid loading wrong type of material
- MUCH simplify multi delivery station setup

Can you make such an option for Depot or globally?

As I explained a few pages earlier it's next to impossible to calculate what stack goes where for merged deliveries.
I think LTN is as simplistic as such a complex system can get. Needing some combinators to control inserters is intended complexity.

For example (un-)loading a set amount of multiple items only takes 3 combinators, which hardly qualifies as complex to me.
0.15 will make circuit controlled inserters pick up only set amounts of items instead of full stacks and also have train stops report current train inventory making (un-)loading trains even more of a no-brainer.

Suggestion 2:
Implement "Maximum trains going to this station" parameter (with default value 1 or 2 maybe in config file)
If there is more than this number of deliveries to or from this station don't make any new ones (continue as if this station have no requests and no sendings available).

A similar system is already in place.
Requesters are serviced in round robin.
Providers with least active deliveries are preferred.

Can I set up more then one ltn networks which are not connected by rail or would the mod create deliveries to no path stations?

Short Answer:
not possible

Long Answer:
All I can do is order trains to go to stop with name xyz. If another stop with that name exists trains will pick the nearest reachable. That includes stops of other forces.
What I could do is a hack solution like constantly renaming stops.
Cons:
very confusing if stops kept changing at least part of their names
as it would have to change all stop it'd become incompatible with any mod adding or changing train stops
would add noticeable processing time

[steinio]

I'm fine with your answer. No hacks needed.

Greetings steinio

[thelordodin]

Suggestion:
As I see mostly a train deliver one type of items.
So, why not set filter on all cargo wagons on delivery to requested item?
I mean if this mod https://github.com/SeaRyanC/fast-filter-fill can change cargo filter this should be possible to implement and it seems to be quite easy.

For merged requests it's much harder to implement, but is possible with some limitations: one way - don't merge different types, other way - set filters dynamically while loading on station.
Simplisity from filters is prior for me than merging.
...

As I explained a few pages earlier it's next to impossible to calculate what stack goes where for merged deliveries.
I think LTN is as simplistic as such a complex system can get. Needing some combinators to control inserters is intended complexity.

For example (un-)loading a set amount of multiple items only takes 3 combinators, which hardly qualifies as complex to me.
0.15 will make circuit controlled inserters pick up only set amounts of items instead of full stacks and also have train stops report current train inventory making (un-)loading trains even more of a no-brainer.

Will you accept my pull request to your mod? It implements filters as an option (in config.lua)
All done in control.lua, 4 small pieces of code changed.
I've tested it on one map (it works), not very deep tested...

[EoRaptor]

Hello Operta,

I recently added this mod to our mod-pack playing an angel-bob's mp-map.

I do really like the mod and you have done an excellent job making it! Thanks.


Unfortunately, eery time a train is dispatched, the joined ppl - not the server - get the message regarding the server not responding.
Another issue is the frequent desyncs we get. Most of the time those are occuring when a provider station is not providing requested items.

Hope you can have a look at the issues.

Regards,

[Optera]

Will you accept my pull request to your mod? It implements filters as an option (in config.lua)
All done in control.lua, 4 small pieces of code changed.
I've tested it on one map (it works), not very deep tested...

Apart from the fact that I will not disable a core feature of LTN here are some of the problems I came along when trying filters:

It drains resources mostly at the first wagon making balancing chests at stations a tedious chore requiring combinator (MadZuri's chest balancer) or belt based load balancing negating any increased simplicity you wanted to gain by adding filters.
(Un-)Loading such a filtered train is slower than loading a train randomly until both iron & copper are above requested amount.
e.g 100 iron a L-4C-L train will result in: wagon[1] = 48 stacks iron, wagon[2] = 48 stacks iron, wagon[3] = 4 stacks iron & 44 nil stacks, wagon[4] = 48 nil stacks

A better solution without disabling merged deliveries, albeit still with the same limitations, would be to iterate over wagons and set filters according to loadingList.stacks.
e.g 50 iron 50 copper with a L-4C-L train will result in: wagon[1] = 48 stacks iron, wagon[2] = 2 stacks iron & 46 stacks copper wagon[3] = 4 stacks copper & 44 nil stacks, wagon[4] = 48 nil stacks

For simple loading lists you could divide stacks by wagons and split stacks more evenly. With very diverse merged deliveries (e.g. requesting materials for building outposts) complexity of stack allocation will become a real pain, with many recursive loops utterly destroying performance.

Bottom line: adding filters doesn't provide enough improvement to warrant the added runtime cost and my hours of making it work.

[Optera]

Hello Operta,

I recently added this mod to our mod-pack playing an angel-bob's mp-map.

I do really like the mod and you have done an excellent job making it! Thanks.


Unfortunately, eery time a train is dispatched, the joined ppl - not the server - get the message regarding the server not responding.
Another issue is the frequent desyncs we get. Most of the time those are occuring when a provider station is not providing requested items.

Hope you can have a look at the issues.

Regards,

Thanks for the report. Sadly server desync logs are utterly useless for modders and client desync logs are not any better.

I was recently trying to find desyncs afther another report, but couldn't reproduce any desync with LTN running by itself. It might be an incompatibility with one of the mods in your modpack.

If you could provide me with information about the mod(s) that cause LTN to produce desyncs I might be able to hunt them down.

[thelordodin]

Will you accept my pull request to your mod? It implements filters as an option (in config.lua)
All done in control.lua, 4 small pieces of code changed.
I've tested it on one map (it works), not very deep tested...

Apart from the fact that I will not disable a core feature of LTN here are some of the problems I came along when trying filters:

It drains resources mostly at the first wagon making balancing chests at stations a tedious chore requiring combinator (MadZuri's chest balancer) or belt based load balancing negating any increased simplicity you wanted to gain by adding filters.
(Un-)Loading such a filtered train is slower than loading a train randomly until both iron & copper are above requested amount.
e.g 100 iron a L-4C-L train will result in: wagon[1] = 48 stacks iron, wagon[2] = 48 stacks iron, wagon[3] = 4 stacks iron & 44 nil stacks, wagon[4] = 48 nil stacks

A better solution without disabling merged deliveries, albeit still with the same limitations, would be to iterate over wagons and set filters according to loadingList.stacks.
e.g 50 iron 50 copper with a L-4C-L train will result in: wagon[1] = 48 stacks iron, wagon[2] = 2 stacks iron & 46 stacks copper wagon[3] = 4 stacks copper & 44 nil stacks, wagon[4] = 48 nil stacks

For simple loading lists you could divide stacks by wagons and split stacks more evenly. With very diverse merged deliveries (e.g. requesting materials for building outposts) complexity of stack allocation will become a real pain, with many recursive loops utterly destroying performance.

Bottom line: adding filters doesn't provide enough improvement to warrant the added runtime cost and my hours of making it work.

I see your point.

Ok. If I make it station parameter and only for stations where filtering is on if a train goes to or from it - it will have filters.
So (1) this won't disable merging for stations without filtering and (2) this won't affect stations where this param isn't set.

Then this will be ok?

[EoRaptor]

If you could provide me with information about the mod(s) that cause LTN to produce desyncs I might be able to hunt them down.

I have uploaded the used mod-pack to dropbox.
https://www.dropbox.com/s/hst6zncjzwgxm ... c.zip?dl=0

We started the map with smarter trains, but switched to logistic trains before we started on any of the train research.

[gridstop]

I'm really enjoying trying out this mod.

I had a question on how to handle a situation though. If my network is train limited, ie my provider station is always full, and my requester station is constantly requesting much more than the size of my trains, yet the trains can't catch up, it gets stuck in a pessimistic state where each train is carrying only slightly more than the minimum delivery, and won't fill up.

For instance, my requester is requesting 8k iron, I'm using little LCCL trains (4k capacity) and minimum delivery is 2k. There is a huge surplus of providers. I will always end up with 4 trains in flight, together they sum up to the 8k delivery. But each one only carries around 2100-2500. Maybe this won't be possible until 0.15, but in theory you could have the LTN observe the train contents, and have the train schedule trigger on a signal sent from the LTN instead of directly on cargo quantity, so that you could dynamically adjust load amounts even after the train is dispatched, instead of scheduling a new train.

I guess I could use my own circuit system to detect this condition somehow, and bump up the minimum delivery size dynamically, when it detects starvation? This is just me playing around on a test map, in a normal base usually for ore the train isn't the limiting factor. But I could see scenarios when using trains for intermediates in a megabase where you'd have problems.

Has anyone else tackled this or have any suggestions?

EDIT: Is it as obvious as my request size is too small? If my trains can't keep up it means the buffer I was requesting isn't big enough for my consumption rate. There must be some way to approximate that number so I can get deliveries in time without excessive buffering or train usage.

[Optera]

I see your point.

Ok. If I make it station parameter and only for stations where filtering is on if a train goes to or from it - it will have filters.
So (1) this won't disable merging for stations without filtering and (2) this won't affect stations where this param isn't set.

Then this will be ok?

Bottom line: adding filters doesn't provide enough improvement to warrant the added runtime cost and my hours of making it work.

Filters are more effort for me to develop, maintain, provide support and use more runtime while offering nothing in return 1-3 combinators cant do.
LTN was designed to be more versatile and easier to use than Siggboys combinator controlled masterpiece, while still promoting players to come up with creative solutions to train loading.
I'm also against anything that'd make building networks and designing stations with LTN into a no-brainer. If I wanted a place-and-forget transportation mod, I'd have made Portal Chests. (should probably reserve that name)

I have uploaded the used mod-pack to dropbox.
https://www.dropbox.com/s/hst6zncjzwgxm ... c.zip?dl=0

We started the map with smarter trains, but switched to logistic trains before we started on any of the train research.

According to Ssilk, smarter trains somehow conflicts with LTN.
I'll check the mod pack out when I find the time.