old LTN discussion thread

[Lezreth]

This sounds to me like the system is ignoring the minimum delivery size variable entirely. The purpose of setting it was to make the depot wait until a provider has the resources to fulfill the order requested. If minimum delivery is set to 16k, then a train should not be sent out until a provider can give it 16k. Instead its dispatching trains for orders of whatever is available. One order placed while writing this was for 12 copper ore! No train is worth running for a lousy 12 ore.

[Optera]

min Delivery size is a threshold for requests that's all.
Delivering with best effort is so you don't accidentally starve your whole base, which you seem to have managed anyways.
if you really want it to deliver more, build more mines or add a combinator to only send positive signals when >8k are in the mine.

[ssilk]

IMHO: the usage case is not clear.

And for me as player I don't want to think about that. It should just work and transport requested items from providers without "own logic". Aka: if there is a request and a matching provision -> transport it! but only that much that is in that moment of loading requested/provided (min()).

This would make the code also radically simpler and avoids a lot of hidden errors.

If the player wants a threshold he can simply place a decider combinator to forward the signal only if the threshold is high enough. That can becontrolled by the player and is not hidden in the logic of the system.

(This is my main-critique to the system from beginning )
(Which doesn't mean the current mod is bad )

[Optera]

but only that much that is in that moment of loading requested/provided (min()).

What is that supposed to mean?

[Optera]

Merging multiple items into one delivery is complete. While at it i also added a memory so requests are processed in order the came up.
Please note, fluids will not be merged, nor are mixed trains of cargo wagon and rail tanker supported.

I've had to make quite some changes for this so I'd welcome some testers.

[ssilk]

but only that much that is in that moment of loading requested/provided (min()).

What is that supposed to mean?

That means bad English. Indeed I typed that on IPhone.

I mean: When the train is loaded, it should not load the number of items, from the moment, when he was sent from the Depot to the providing station, but the number of items, that are - yet, in this moment - should/could be loaded.

That is calculated so:
CURRENT_REQUESTED = The number requested items minus the number of items already loaded for that requesting stop.

If the number of the provided items of this stop is then lower:
CURRENT_REQUESTED = number of provided items at this stop

WHAT_REALLY_SHOULD_BE_LOADED_AT_THIS_TICK = CURRENT_REQUESTED minus what you already have been loading into the wagons of this trains.

Maybe it can include also the number of all trains currently loaded for driving to the requesting stop, but that is not really important.

[Optera]

but only that much that is in that moment of loading requested/provided (min()).

What is that supposed to mean?

That means bad English. Indeed I typed that on IPhone.

I mean: When the train is loaded, it should not load the number of items, from the moment, when he was sent from the Depot to the providing station, but the number of items, that are - yet, in this moment - should/could be loaded.

That is calculated so:
CURRENT_REQUESTED = The number requested items minus the number of items already loaded for that requesting stop.

If the number of the provided items of this stop is then lower:
CURRENT_REQUESTED = number of provided items at this stop

WHAT_REALLY_SHOULD_BE_LOADED_AT_THIS_TICK = CURRENT_REQUESTED minus what you already have been loading into the wagons of this trains.

Maybe it can include also the number of all trains currently loaded for driving to the requesting stop, but that is not really important.

I already said no to updates once a delivery is created. I don't care if a train could load 100 ore more when it arrives. If configured properly, through your "beloved" min delivery size, it will load full or nearly full anyway.

[Lezreth]

min Delivery size is a threshold for requests that's all.
Delivering with best effort is so you don't accidentally starve your whole base, which you seem to have managed anyways.
if you really want it to deliver more, build more mines or add a combinator to only send positive signals when >8k are in the mine.

First off, my actual base is not really starved as its mostly not being used and not actually hooked up to the logistic train system yet. The Big Forge, Green Circuit Mass Producer, and a couple of the mines are being used as a testing ground for your mod. Production at the main base is for the most part halted except for whatever materials I need to expand/test mods. When materials are needed the main base also has its own forge.

When I downloaded the Logistic Train Network and analysed the way it sent trains to fulfill orders, I noticed that it was sending trains with very specific quantities to pickup via the circuit wait condition. As I wanted to transport only full train loads, I set the Minimum Delivery Size to force the system to wait until a full train load was available. Or so that's what I thought what was going to happen. As it turns out the depot is setting that circuit condition number to values like >207, >341, >12, etc. This makes sense if the mod's code is indeed following a "best effort" approach as you stated above. However this to me sounds contradictory to the name of the variable in question. If this behavior is what is intended, then I think the Minimum Delivery Size should be renamed to Max Delivery Size, or Delivery Goal or something along these lines. A Minimum Delivery Size of 8k tells me that the train should not be dispatched until there is at least 8k available to move. Also, I think that the best effort approach does not work well for trains. If I wanted to move 12 of something across my base, I would use the bot network.

I already said no to updates once a delivery is created. I don't care if a train could load 100 ore more when it arrives. If configured properly, through your "beloved" min delivery size, it will load full or nearly full anyway.

Then this tells me that my system is not configured correctly. If this is the case then please let me know where I went wrong.

EDIT: I did as you suggested and added a combinator to my provider stations to only output their contents when a full train load is available, and as soon as the station had over 8k resources, the depot dispatched all 6 trains to pickup 8k each. The second train to arrive is now sitting at the station and causing the remaining 4 to clog my main line preventing any other trains from going where they need to go.

[Optera]

Seems to me like the ultimate fix will be to rename "minimum delivery size" to "request threshold".

EDIT: I did as you suggested and added a combinator to my provider stations to only output their contents when a full train load is available, and as soon as the station had over 8k resources, the depot dispatched all 6 trains to pickup 8k each. The second train to arrive is now sitting at the station and causing the remaining 4 to clog my main line preventing any other trains from going where they need to go.

That was with 0.3.12? If so it's certainly a bug I'll have to fix for 0.4.
Could you download my 0.4 test version a few posts above, do the same thing with it to let me know what happens.

Edit: nevermind, i found the bug in 0.4.0 too, it should be fixed now.
I've also added a config option to turn off best effort.

[Optera]

EDIT: I did as you suggested and added a combinator to my provider stations to only output their contents when a full train load is available, and as soon as the station had over 8k resources, the depot dispatched all 6 trains to pickup 8k each. The second train to arrive is now sitting at the station and causing the remaining 4 to clog my main line preventing any other trains from going where they need to go.

With 0.4.1 this bug is now finally fixed.

When I downloaded the Logistic Train Network and analysed the way it sent trains to fulfill orders, I noticed that it was sending trains with very specific quantities to pickup via the circuit wait condition. As I wanted to transport only full train loads, I set the Minimum Delivery Size to force the system to wait until a full train load was available. Or so that's what I thought what was going to happen. As it turns out the depot is setting that circuit condition number to values like >207, >341, >12, etc. This makes sense if the mod's code is indeed following a "best effort" approach as you stated above. However this to me sounds contradictory to the name of the variable in question. If this behavior is what is intended, then I think the Minimum Delivery Size should be renamed to Max Delivery Size, or Delivery Goal or something along these lines. A Minimum Delivery Size of 8k tells me that the train should not be dispatched until there is at least 8k available to move. Also, I think that the best effort approach does not work well for trains. If I wanted to move 12 of something across my base, I would use the bot network.

Added use_Best_Effort to config.lua. If you set it to false, no deliveries smaller than Minimum Delivery Size will be created. (make sure you have outposts that are able to hold more)
If Depots have only trains able to load less than Minimum Delivery Size it will still use those.

[Lezreth]

I have downloaded and tested version 0.4.1 and it works great! I like having the option of weather or not to use best effort, as I can see some situations where it would be useful. For now though, it will be turned off for me. As a bonus, this mod has made one area easier that has always been a royal pain: liquid barreling!

[Optera]

I have downloaded and tested version 0.4.1 and it works great! I like having the option of weather or not to use best effort, as I can see some situations where it would be useful. For now though, it will be turned off for me. As a bonus, this mod has made one area easier that has always been a royal pain: liquid barreling!

That's great to hear.
Liquid barreling sadly is something i wont implement 100% the way I would like.
Ideally it'd send a train from depot to pick up as many empty barrels before going to the outpost and swap the full barrels with empty. The complexity needed for just this one scenario is too much. Especially considering rail tanker and with 0.15 base offer direct fluid transport.

[Lezreth]

IMO I think that the current implementation is sufficient. Attempting to add a special use case for barrels would go outside the scope of this mod's fundamental purpose. With a few combinators, the circuit network can make barrel management much easier. The problem I was always faced with was the fact that its difficult to manage the amount of barrels in a system with a train always parked at one or more of the stations, due to the problem that the contents of cargo wagons are not visible to neither the circuit nor logistic networks (without mods). What this mod does is remove the train from the station, making it much easier to count barrels and add to the system autonomously. (Or one could try dealing with Siggboy's combinator insanity which fulfills the same purpose, but that's much more complicated.)

Here are some screenshots of my oil drop-off facility at the main base:

Main Base Oil Barrel Management Overview

Full barrels are dropped off and emptied on the left. Empties are routed to the right side to be loaded onto the next train

Barrel Facility North End

Total barrel count is tracked on the northern side. If barrel count (full + empty) drops too low, new barrels are added via the logistic network. New barrel manufacture is handled at the main bus.

Barrel Facility South End

On the left, full barrels are requested when low. On the right, Empty barrels are provided to the system. Due to barrel management on the north end, barrel count will scale with the addition of new outposts and base expansion/oil consumption increases automatically.

The outposts are simpler. One station for empty barrel drop-off, another for full barrel pickup. Layouts are similar to ore pickup and drop-off stations. The only major difference would be the oil on hand is counted and empty barrels are requested only when enough oil is available to fill a whole train worth of barrels.

Yes I am aware that the addition of the oil tanker in 0.15 will make barrels obsolete, but for now this scheme works well.

[Optera]

Siggboy's combinator method is impressive but too inflexible for my liking.

Quite the effort circling the barrels around. I'd simply feed the output from unloading into the assemblers and take care of the logic at the inserter placing barrels on the belts.
You use a bad lane balancer design, it hurts my ocd.
here's a much better design that will work on clogged belts.

I wouldn't want to miss RailTanker anymore. It allows such simplistic and clean fluid (un)loading stations.

Oil Unloading + RT Depot

2016-11-12-14-07-19-1913823.jpg (488.1 KiB) Viewed 8217 times

[Lezreth]

The purpose of the barrel loop was to maximize parallel processing of the barrels. Due to funky fluid dynamics if I gave each assembler its own belt of barrels, some would finish unloading oil before others. During high demand I can't have oil sitting around in drums waiting on a single assembler.

As for the lane balancer, in this situation its primary purpose is less about balancing and more about getting all the oil on the belt. Though I did not realize that it did not actually balance the lanes as I originally thought until I read that post you linked. Even so, I also don't care for the design that post recommends. The fact that 48 items get stuck in the middle of the balancer never to be used hurts my OCD. Therein is the challenge, finding a balancer that does not waste resources by getting them stuck in the middle. For the most part, I have been making good use of this post for balancers. Some of them I had to tweak a little to get rid of resource waste though, which may or may not end up breaking the design. >_>

I've always thought barrels were an interesting concept because it allows one to use a general purpose train to move fluids around, whereas the rail tanker forces you to make specialized trains for a single purpose. I have wanted to incorporate the rail tanker at some point though. With the developers' decision to incorporate the design into 0.15 I will get the opportunity sooner or later. (so many mods, so little time )

[ransburger]

I have a non-delivery size related conundrum.

I have a few providers/requesters that want 4 cargo-wagon trains, and some that want 1 cargo wagon trains. The stops that want the longer trains I added the condition that says # cargo wagons = 4. When I introduced the smaller trains into the system the Depot started routing them to the 4 cargo wagon stops.

I understand how to prevent a longer train from going to a smaller stop by setting the max train length, but what about the reverse? How do I prevent a smaller train from going to a larger stop?

[Optera]

I have a non-delivery size related conundrum.

I have a few providers/requesters that want 4 cargo-wagon trains, and some that want 1 cargo wagon trains. The stops that want the longer trains I added the condition that says # cargo wagons = 4. When I introduced the smaller trains into the system the Depot started routing them to the 4 cargo wagon stops.

I understand how to prevent a longer train from going to a smaller stop by setting the max train length, but what about the reverse? How do I prevent a smaller train from going to a larger stop?

Depends on what you try to ship on the stations for large trains. If it's only 1 or 2 items/station you can set min delivery size > inventory size of the small train. This will force the 4 wagon trains to get used, unless the 1 wagon trains are the only ones parked in depot.

[ransburger]

Depends on what you try to ship on the stations for large trains. If it's only 1 or 2 items/station you can set min delivery size > inventory size of the small train. This will force the 4 wagon trains to get used, unless the 1 wagon trains are the only ones parked in depot.

Yep, that's the problem. The 1 wagon trains are the only ones in the depot.

The large stations in question are for the ore mines, min delivery size is 7k, which is 3.5 wagons.

So the easy solution is to add a few more large trains to the system, which sounds way better than delving back into the combinators or you doing coding.

Thanks!

[Exasperation]

You use a bad lane balancer design, it hurts my ocd.
here's a much better design that will work on clogged belts.

It's funny, the version you linked to hurts my OCD - I can't stand to see a balancer that strands materials so they can never be used, even if I know it's more efficient.

[Kormer]

This mod is awesome. I've been using it heavily the past few days and have two suggestions. First, I'd like to have a priority signal I could send to a station. There are a few recipes where an item is produced from multiple recipes. In that case when a secondary item is backed up causing the primary to not be produced, say copper plates from cobalt, then I'd want that secondary product to be picked up before another factory where the secondary is the only thing being produced.

The priority signal would override the normal order of determining jobs and assign the next available train to pick up from that station. In cases where multiple stations have a signal, assign the highest signal takes priority. A config option for allowing priority signals to override a station's minimum delivery setting, however no job should be created if there are no stations requesting the item.

The second suggestion would be to have a max trains at one time signal to pass to a station. Suppose I have a station with 32,000 items and 4 trains, each with 1 wagon with a capacity of 8,000. Currently the system will send all 4 trains to collect that 32,000 cargo. If my station has one loading bay and two waiting bays, I'd set the max trains to three, and then once three trains have been sent to a station no more jobs will be created until one of the trains has finished the loading process.