LTN 1.4.0 creating incorrect deliveries

[TheTom]

Just updated and now I am getting TONS of merged delivery. Many of them.

Point is that with some very few exceptions I run single good supply stations. So there should ot be merged delivery.

Creating merged delivery from LT-TinnedWire.....? What is merged there? There is only tinned wire supplied.

[Optera]

Just updated and now I am getting TONS of merged delivery. Many of them.

Point is that with some very few exceptions I run single good supply stations. So there should ot be merged delivery.

Creating merged delivery from LT-TinnedWire.....? What is merged there? There is only tinned wire supplied.

Look in the train schedule or enable debug logging to see what it merged.
If it's wrong send me a logfile with debug logging enabled while this delivery was created.

[TheTom]

Will do. Do you mix up loading and unloading schedules?

I have one train stuck on loading. it's conditions wait for more than 5000 iron gear, but the station outputs desired load as 2200 (which are loaded).

The condition looks mangled:

Cago: Iron gear wheel > 5652 AND cargo iron gear wheel > 2199

Log attached

[Optera]

Will do. Do you mix up loading and unloading schedules?

I have one train stuck on loading. it's conditions wait for more than 5000 iron gear, but the station outputs desired load as 2200 (which are loaded).

The condition looks mangled:

Cago: Iron gear wheel > 5652 AND cargo iron gear wheel > 2199

Log attached

I can't find this specific delivery being generated in the logfile. Without seeing the loading list I can't say what happened during the schedule generation.

Going through your log I noticed I forgot to remove items from providers when creating orders. Resulting in it trying to deliver items multiple times.
fixed in 1.4.1

I also found some potential configuration errors:
LT-IronGear provides over 9k yet the Dispatcher can't match the provider to your requester.
Check if LT-IronGear and your iron gear requester have train size settings allowing for a train to enter both stations.

Code: Select all

 605.878 Script control.lua:723: (GetProviders): found 6718(1000)/1110 item,iron-gear-wheel at LT-EngineUnit-In priority: 0, used in nil orders, minTraincars: 2 maxTraincars: 2 locked Slots: 0
 605.878 Script control.lua:800: Provider[1] LT-EngineUnit-In: Priority 0, 3 deliveries, 1110 item,iron-gear-wheel available.
605.878 Script control.lua:847: added new order 3 LT-EngineUnit-In >> LT-InsY-In: 1110 in 12 stacks item,iron-gear-wheel min length: 2 max length: 2

The name suggests this is an request only station. Here it had enough gear wheels stored to go above the default 1k provide threshold.
Generally you seem to run most of your stations with only global 1k thresholds. It's more efficient and less error prone if you use set thresholds at every station to a trains load. For requester only set provide to more than it can possible hold.

[TheTom]

IronGears are definitely delivered to anything that wants them (all my goods are being produced). I do have some seriouss problems with supply on that end (nnot generating enough), but that is not an LT problem.

Before updating this morning (some hours ago) the network was ticking along nicely.

I can reload that savefile (pre upgrade) and check again, then let it run some time.

THe double load amounts, thugh, are new - that was not in the system yesterday.

[TheTom]

Will do. Do you mix up loading and unloading schedules?

I have one train stuck on loading. it's conditions wait for more than 5000 iron gear, but the station outputs desired load as 2200 (which are loaded).

The condition looks mangled:

Cago: Iron gear wheel > 5652 AND cargo iron gear wheel > 2199

Log attached

I can't find this specific delivery being generated in the logfile. Without seeing the loading list I can't say what happened during the schedule generation.

Going through your log I noticed I forgot to remove items from providers when creating orders. Resulting in it trying to deliver items multiple times.
fixed in 1.4.1

I also found some potential configuration errors:
LT-IronGear provides over 9k yet the Dispatcher can't match the provider to your requester.
Check if LT-IronGear and your iron gear requester have train size settings allowing for a train to enter both stations.

Code: Select all

 605.878 Script control.lua:723: (GetProviders): found 6718(1000)/1110 item,iron-gear-wheel at LT-EngineUnit-In priority: 0, used in nil orders, minTraincars: 2 maxTraincars: 2 locked Slots: 0
 605.878 Script control.lua:800: Provider[1] LT-EngineUnit-In: Priority 0, 3 deliveries, 1110 item,iron-gear-wheel available.
605.878 Script control.lua:847: added new order 3 LT-EngineUnit-In >> LT-InsY-In: 1110 in 12 stacks item,iron-gear-wheel min length: 2 max length: 2

The name suggests this is an request only station. Here it had enough gear wheels stored to go above the default 1k provide threshold.
Generally you seem to run most of your stations with only global 1k thresholds. It's more efficient and less error prone if you use set thresholds at every station to a trains load. For requester only set provide to more than it can possible hold.

It is request only. LT-EngineUnit-In is the supply for my engine unit production. Something is odd here - as this station only gets suplies delivered it should never go over +1000 (because I actually run the request from constnat to storage). I did not see this yesterday. This station was NOT attempted o be used as provider.

[Optera]

1.4.0 Bug hunting update:
So far I managed to find and fix 2 major bugs.
I probably will have to limit Dispatcher to 1 delivery /update cycle again. Removing that limitation reintroduced some annoying issues like trains not running at maximum capacity and a lot of edge cases where it doesn't exactly do what is expected.

[adamcirillo]

i'm getting a issue with 1.4.0 where the train is going to 1 stop and have 5 requests of the same resource in the train and it stuffed up the arithmetic combaintor setup I had the provider stations.

[TheTom]

Went back to my laste pre mess file and 1.4.1 is working nicely. No more excessive "stacks" loading, nice separate orders.