old LTN discussion thread

[Pontiac]

The train encoding is an output only. It doesn't use it to filter which kinds of trains can go to the station. (there's lots of discussion of this in the thread and it's currently listed as a "will not implement" in the main post).

Somehow I missed the output functionality. Alright, so I'll have to do my 'custom' trains in a different way. Most of my bulk trains are just the ores. My fluids I'll have to handle on my own.

That said, whats the point of the binary out on the trains? What use would that be to decision making outside of LTN?

[Optera]

Hi, love the mod. Finally got a requester/provider station working as detailed in the first post.


My question: I should be able to shuttle back and forth small quantities of items, right? I can't seem to request anything < 1000. I have "Ignore minimum delivery size" set on both provider and receiver's stations, but I still can't get it to deliver anything unless I request at least 1000. It will deliver less than 1000 (ie 20 or 50) but I can't trigger a delivery until I request at least 1k.

Minimum deliver size is the threshold above which a requester is considered in need of a shipment.
You can use the global 1k in settings and override it for requesters with the minimum delivery size signal.

The train encoding is an output only. It doesn't use it to filter which kinds of trains can go to the station. (there's lots of discussion of this in the thread and it's currently listed as a "will not implement" in the main post).

Somehow I missed the output functionality. Alright, so I'll have to do my 'custom' trains in a different way. Most of my bulk trains are just the ores. My fluids I'll have to handle on my own.

That said, whats the point of the binary out on the trains? What use would that be to decision making outside of LTN?

Train composition can be used to service different train sizes and configurations in one station.
Why is it not a input?
Train composition is directional with the LSB facing the stop. When leaving a station trains change their front and back depending on track layout (RoRo vsTerminus) and the signal would become ambiguous.

[realm174]

"Delivery from A to B running for 18060 ticks removed after time out".

So as I expand, the mines get further away from the main base, hence, the main reason I use trains. This is the first one (mine) I get this message consistently. So a pickup job gets dispatched there, trains head out in that direction, and after some time, I get that message in the log, for every train that was dispatched to that destination. The trains do make it there, and get loaded and are typically on their way back by the time that message pops up. My question is, however, what does that actually imply? Or how do I prevent that if it implies anything negative going on? I am just about to setup more mining area at equal or longer distances from the main base, I'm just concerned that somehow that's too far for LTN to handle?

Edit: Expanding on the above: The station in question has a combination of Iron and Copper, mixed in within the chests. The train shows up, with the expectation of >7799 Copper. However, because of the random nature of the chests loaded with the 2 ores, the train filled up 3 out of 4 cars with copper and sat there for 2 minutes, then headed back. I just checked, and the train ride is 2.5 minutes each way.

[Mobius1]

"Delivery from A to B running for 18060 ticks removed after time out".

So as I expand, the mines get further away from the main base, hence, the main reason I use trains. This is the first one (mine) I get this message consistently. So a pickup job gets dispatched there, trains head out in that direction, and after some time, I get that message in the log, for every train that was dispatched to that destination. The trains do make it there, and get loaded and are typically on their way back by the time that message pops up. My question is, however, what does that actually imply? Or how do I prevent that if it implies anything negative going on? I am just about to setup more mining area at equal or longer distances from the main base, I'm just concerned that somehow that's too far for LTN to handle?

Edit: Expanding on the above: The station in question has a combination of Iron and Copper, mixed in within the chests. The train shows up, with the expectation of >7799 Copper. However, because of the random nature of the chests loaded with the 2 ores, the train filled up 3 out of 4 cars with copper and sat there for 2 minutes, then headed back. I just checked, and the train ride is 2.5 minutes each way.

You could increase the timeout limit of your trains on the settings part on main menu > options > mods before you load your save, so that message wouldn't pop out if your bases are too far away.
Just remember tho, the values are in gameticks, so if you want 5 minutes of timeout (meaning after 5 minutes the LTN system will show that message), you need to do:
5x60 = 300 (convert to seconds)
300x60 = 18000 (convert to gameticks)

[realm174]

Thanks for that info, I'll adjust that. What does usually happen when the timer expires? I know the schedule is already on the train, so the train will eventually make it to the unloading area and then the depot. But does it have any negative repercussions other than displaying that message?

[Mobius1]

Thanks for that info, I'll adjust that. What does usually happen when the timer expires? I know the schedule is already on the train, so the train will eventually make it to the unloading area and then the depot. But does it have any negative repercussions other than displaying that message?

Once the timeout is triggered, that work order of the train is re-evaluated on the system and a new train is dispatched with that work order.
Lets say you have a station requesting 4000 iron ore, the train leaves the station to go to the provider mining outpost with a work order of 4000 iron ore, that train hits timeout then the LTN check again if the station is still requesting iron ore, since it'll be requesting still, it'll pick another train from the depot and give him the 4000 iron ore work order, not necessarily on the same mine, it'll pick the closest station with 4000 available iron ore unless you provide some priority signal on another station that has 4000 available iron ore, then he'll go to this latter one instead.

[realm174]

Thanks for that info, I'll adjust that. What does usually happen when the timer expires? I know the schedule is already on the train, so the train will eventually make it to the unloading area and then the depot. But does it have any negative repercussions other than displaying that message?

Once the timeout is triggered, that work order of the train is re-evaluated on the system and a new train is dispatched with that work order.
Lets say you have a station requesting 4000 iron ore, the train leaves the station to go to the provider mining outpost with a work order of 4000 iron ore, that train hits timeout then the LTN check again if the station is still requesting iron ore, since it'll be requesting still, it'll pick another train from the depot and give him the 4000 iron ore work order, not necessarily on the same mine, it'll pick the closest station with 4000 available iron ore unless you provide some priority signal on another station that has 4000 available iron ore, then he'll go to this latter one instead.

Oh ok.. not exactly the way I was thinking it would behave but that works nonetheless.. So the train that timed out, it comes back to the requesting station with its load. What happens then? I'm guessing it balances itself out? So taking that same scenario as above... Train 1 goes to mine A to pick up 4000 iron, then times out. So the requesting station asks for another 4000, so Train 2 goes to mine B to pick up that 4000 iron. In the meantime, Train 1 makes it back to the requesting station and unload its 4000... So that station is satisfied with its request. What happens when train 2 returns to that station with the 4000 ores? Is this why I sometimes have trains that don't seem to unload completely? In my case, it doesn't matter much since I have unloading mechanism at the depot anyway, but before having that, I'd often have trains that have multiple types of items in it (left overs from previous trips I guess).

[Mobius1]

Oh ok.. not exactly the way I was thinking it would behave but that works nonetheless.. So the train that timed out, it comes back to the requesting station with its load. What happens then? I'm guessing it balances itself out? So taking that same scenario as above... Train 1 goes to mine A to pick up 4000 iron, then times out. So the requesting station asks for another 4000, so Train 2 goes to mine B to pick up that 4000 iron. In the meantime, Train 1 makes it back to the requesting station and unload its 4000... So that station is satisfied with its request. What happens when train 2 returns to that station with the 4000 ores? Is this why I sometimes have trains that don't seem to unload completely? In my case, it doesn't matter much since I have unloading mechanism at the depot anyway, but before having that, I'd often have trains that have multiple types of items in it (left overs from previous trips I guess).

If there's slot to unload 4000 ores, then Train2 will unload its full cargo then head back to depot, the station will end up with 8000 iron ore assuming its not being consumed while unloading since the timed-out train is considered "lost" so to keep the factory going, LTN sends another train to fill that blank that the lost train made.
If your station have unloading system tied to inserters based on the constant work load signal, than yes, the train won't fully unload since the signal the inserters would receive would be 0 so the train would leave with 4000 iron ore, being unable to load on any station and also unloading his 4000 iron ore somewhere else if you have multiple bases.

[Alxandr]

The train encoding is an output only. It doesn't use it to filter which kinds of trains can go to the station. (there's lots of discussion of this in the thread and it's currently listed as a "will not implement" in the main post).

Somehow I missed the output functionality. Alright, so I'll have to do my 'custom' trains in a different way. Most of my bulk trains are just the ores. My fluids I'll have to handle on my own.

That said, whats the point of the binary out on the trains? What use would that be to decision making outside of LTN?

You could say that all fluid trains are one length, and all solid trains are another length, and just set both min and max train length I would think?

[Pontiac]

You could say that all fluid trains are one length, and all solid trains are another length, and just set both min and max train length I would think?

Theoretically, that would work, but still very limiting as your factor is against the train length, not what the train consists of. So for every unique job a train is supposed to have, I have to make the train a certain length in order for it to go to its destination.

With the addition of Uranium, I have an LCF train that goes to a specifically designed station that only loads uranium and unloads sulfuric acid. I also have a train that is an LFL that runs around and picks up oil. With the limiting factor of just the train length, I have no way to defer sending my uranium train to go pick up oil.

This leads me to think that maybe a feature request for the mod would be needed. Instead of relying on purely just train length, what if it were to be possible to set particular depots to use a particular signal color, letter, or number to a certain number, and out stations and unloading stations must have that exact same setting in order for the train to be called?

So for instance, if I setup a particular depot station to have C3, an outstation that is flagged with C=3, and an offloading station set with C=3. If any train that is scheduled to go to that particular depot, it only looks for stations that have C3. If I have another depot setup for U2, I build a depot and two stations with U2, and any train that comes into that new depot only goes to stations requesting U2. If the assignment is positive, that'd mean an exact match must be made. If the assignment value is negative, that means any depot that matches the color can send trains to the stations of the same color assignment.

So if X=+1, depots must send to stations matching X=+1. If X=-1, then a train can be sent to any station with X<0.

If no special assignment is given, then the trains are sent to whatever stations have no special assignment.

That would completely eliminate the binary identification. It would allow for much tighter control over what train goes where. It wouldn't affect whether I'm using double-headers or not, completely eliminates the problem with train length being the decision maker on what train to go.

[Optera]

Theoretically, that would work, but still very limiting as your factor is against the train length, not what the train consists of. So for every unique job a train is supposed to have, I have to make the train a certain length in order for it to go to its destination.

With the addition of Uranium, I have an LCF train that goes to a specifically designed station that only loads uranium and unloads sulfuric acid. I also have a train that is an LFL that runs around and picks up oil. With the limiting factor of just the train length, I have no way to defer sending my uranium train to go pick up oil.

Merging item and fluid deliveries isn't supported as it'd only work in very specific station configurations.
e.g. an L-CF-L will do a 180 at the end of a depot-provider-requester trip if 1 or 3 of those are terminus stations. I'm not going to listen to the complaints about how broken LTN is for not accounting for such cases.

In your case your train simply changing your train composition from LCL and LCF to LCL and LFF would make all trains capable of running every delivery.

This leads me to think that maybe a feature request for the mod would be needed. Instead of relying on purely just train length, what if it were to be possible to set particular depots to use a particular signal color, letter, or number to a certain number, and out stations and unloading stations must have that exact same setting in order for the train to be called?

So for instance, if I setup a particular depot station to have C3, an outstation that is flagged with C=3, and an offloading station set with C=3. If any train that is scheduled to go to that particular depot, it only looks for stations that have C3. If I have another depot setup for U2, I build a depot and two stations with U2, and any train that comes into that new depot only goes to stations requesting U2. If the assignment is positive, that'd mean an exact match must be made. If the assignment value is negative, that means any depot that matches the color can send trains to the stations of the same color assignment.

So if X=+1, depots must send to stations matching X=+1. If X=-1, then a train can be sent to any station with X<0.

If no special assignment is given, then the trains are sent to whatever stations have no special assignment.

That would completely eliminate the binary identification. It would allow for much tighter control over what train goes where. It wouldn't affect whether I'm using double-headers or not, completely eliminates the problem with train length being the decision maker on what train to go.

Trains always find back to their home depot by it's name.

There is no reason to segregate into subnetwork. LTN will always pick the train that's right for a job. Capacity closest to delivery size, linear distance closest to provider.

The goal of LTN is to utilize all eligible trains for all deliveries. If for some reason you want trains bound to a specific line use manual schedules for that.

[denadan]

mmm... for train limitations you have signals to use specific locomotion/wagon types, or i get it from other mods installed?
put on request station signal to use canister or cargo wagon and this is all

[nuhll]

Anyway to stop LTN from creating deliveries from stations (requester) to stations (requester)?

[Optera]

Anyway to stop LTN from creating deliveries from stations (requester) to stations (requester)?

Funny you ask that just as I'm done adding a the first feature of 1.3.0 dealing with how requests and providers are handled.
Minimum delivery size, ignore minimum delivery size and best effort will be removed. Instead request threshold and provide threshold are added as global setting and per stop override signals.
This change makes configuration a lot more versatile and eliminates legacy settings and signals like best effort and ignore min delivery size.
Setting the provide threshold way above what the station could hold would prevent it from ever turning provider. The opposite also will work.
To use Best Effort/Ignore min delivery size, setting provide threshold to 1 will effectively do that as well.

For current builds use a decider combinator set to each < 0 = each: input at requesters

[nuhll]

Anyway to stop LTN from creating deliveries from stations (requester) to stations (requester)?

Funny you ask that just as I'm done adding a the first feature of 1.3.0 dealing with how requests and providers are handled.
Minimum delivery size, ignore minimum delivery size and best effort will be removed. Instead request threshold and provide threshold are added as global setting and per stop override signals.
This change makes configuration a lot more versatile and eliminates legacy settings and signals like best effort and ignore min delivery size.
Setting the provide threshold way above what the station could hold would prevent it from ever turning provider. The opposite also will work.
To use Best Effort/Ignore min delivery size, setting provide threshold to 1 will effectively do that as well.

For current builds use a decider combinator set to each < 0 = each: input at requesters

Acutally i ask that now since 20 pages

Please provide a guide when its finished...

Thanks for adding.

Do you know why LTN sometimes creates to big deliverys? Vanilla Trains ... most time it happens when it combines deliverys

[Optera]

Do you know why LTN sometimes creates to big deliverys? Vanilla Trains ... most time it happens when it combines deliverys

I know some reported this, but I have not been able to reproduce it.
Unless you can provide information on how to reproduce it, have a level 4 log or save showing this I can't do anything about it.

[nuhll]

Here you can see what i can tell you about this bug

viewtopic.php?f=94&t=36976&p=274833#p274833

[Optera]

Here you can see what i can tell you about this bug

viewtopic.php?f=94&t=36976&p=274833#p274833

That tells me nothing useful.

[nuhll]

Here you can see what i can tell you about this bug

viewtopic.php?f=94&t=36976&p=274833#p274833

That tells me nothing useful.

The problem must have something to do with combining transports, but it also happens (not often) with single transfers.

[Optera]

The problem must have something to do with combining transports, but it also happens (not often) with single transfers.

That statement contradicts itself.