old LTN discussion thread

[ssilk]

Very nice update, Optera. I played around with it for the last 3 hours and it works really well in this cases:

- Mass-transport.
- Provides one single item only.

In that case it works really well and most times as I would await it. I agree: Handling many trains at the provider is mainly the players problem. But perhaps some simple rules: It makes not much sense to send more than one train per 10 seconds to one provider stop. I would say the scheduler should wait about 10-60 seconds before he sends he next train.

Some ideas how that could be calculated:

- Amount to loaded items for one wagon (it takes much longer to load a wagon of green circuits vs. to load a wagon of iron-plates, because of the stack-sizes).
- Amount of items that could be loaded in all trains on the way.
- Length of train (the longer it takes to accelerate, enter and leave)
- How much trains are already on the way to this stop and their average distance to it. The more close the trains are, the longer it should wait, before sending the next.
- RollonRolloff or Terminus train stop (it doubles the time to enter/leave a stop).

Well, the last one is difficult.


The mod is in my eyes not really ready for "supply stations". That are stations, that provide up to 12 different items per wagon (you can place up to 12 inserters to an wagon). Like Repair-Pack, Lasers, Walls etc.

Issues (we had already discussed about them via PM, so this is a repetition for the other readers, so that they know, how to work with it):

- Only one item is loaded per train.
- The problem is then: From the previous load another inserter couldn't fill all the item in his hand (cause the wagon was full) and now waits with some items left in his hand for placing items. That is in general no problem, if you unload all items (no matter of the type) at the requesting stop. But I would say this is not intended. But I still have no idea how to fix this.
- You need to set up the min-delivery-size signal to 1 or so (on both sides). In my opinion the min-amount doesn't make sense, if the number of items that are requested (minus the already delivered) is more or less always up-to-date.
- The amount of items is not updated while loading. (*)
- Trains are ordered to transport items, that are already "on the way". See previous point.


(*) You wrote: as of 0.1.0 Output also includes count of all wagons and locomotives parked at this stop. Eventually that is a bug? Or I miss something? Cause the numbers currently don't change. (I can provide my save. I used 0.3.11 and reinitialized everything from scratch.)


PS: I will include the Radar like promised tonight.

[zebediah49]

Awesome, nice improvements. I still get an error (running 0.3.11) when using a battle trains cargo wagon though --

Code: Select all

Error while running event on_train_changed_state (ID 23)
Unknown virtual signal name: LTN-battle-cargo-1
stack traceback:
	__LogisticTrainNetwork__/control.lua:557: in function 'UpdateStopOutput'
	__LogisticTrainNetwork__/control.lua:133: in function <__LogisticTrainNetwork__/control.lua:106>

[Anson]

As promised here's 0.3.11 hopefully fixing your reported errors and a new demo map.

the new version seems to work for me, with the old as well as the new demo map. thanks.

since this post got "a bit long", i cut it in 4 segments, hidden in the following spoilers :

several shorter problems, questions and suggestions

Stops consist of 3 entities, the stop itself and the automatic placed lamp(input) and constant combinator(output).

it would be nice and avoid some confusion if you include that sentence somewhere in the first post (in the long description or somewhere else), before telling to check "connections of the output" when setting up a station.
The lamp and the combinator seem to be not clickable, but only connectable to the curcuit network. that probably is no bug, but intended. is that correct?

on the demo map, you probably have intended to check the length and components of a train to activate the correct inserters to refuel the backend engine, by computing something and giving a signal "A". nice idea and i might add something like that to my normal map. but on the demo map, you calculate only: <nothing> plus <nothing> gives signal "A". this causes the backend engine to never be refueled (the demo map works nonetheless since all trains reverse in the load/unload stations and thus all engines are in front sooner or later and then get refueled on the next visit to the depot).

all stops seem to have a "grey" signal with value 1, what is that used for ? to power the lamp no matter which color (or whether any color at all) is active, and thus result in the status display "white: not initialized" ? and if this is the case, why is the signal grey and not white to more easily show this fact?
or does the grey signal have some other meaning ?

as an alternative to the vanilla logistics network, i understand that this train stop might require blue science for research, but why does the vanilla logistics need blue science? because it first needs flying robots (to handle those requests), and thus people will have researched and built an oil industry anyway ?
should the same technology requirement also apply to this mod? or should this be a "simple" exension to trains and all other train related stuff and thus only require green science (instead of blue science), and also only green circuits (instead of red circuits) ?

BUG - always attempting full load even for few items and single-item requests

on the demo map, i changed the values for green circuits to 200 for request and for minimum delivery size. result: after some time a request was generated to deliver 200 circuits. the train went to the loading station with conditions "circuits>199 and inactivity 1 second". as a result, since the loading station had 120k available, there was no inactivity until the wagon was fully loaded with 8000 circuits (a multi-wagon train or a train with bigger modded wagons might easily have been loaded with 50k or more, instead of the intended order of only 200). at the unloading station it had conditions "circuits=0 and inactivity 1 second", and it waited a long time (several game days/months/years) to unload everything.

i understand that it is a difficult problem to do exact deliveries that change over time, maybe even on every tick, and thus i would accept a little surplus. but in no case should an order of one stack or less try to deliver a full train (48++ stacks) of goods.

with the above behavior, the existing description "To request items a simple constant combinator outputting the negative amount that should be available at the station is sufficient" should get an additional warning like "as soon as a negative amount is set, a transport is triggered that will pick up at least that amount, and if available also up to full train load"

why do you do the test for inactivity of 1 second at all?
i only find use in that behavior on the depot when the train should wait to finish refueling even when it gets a green light.

BUG - loading wrong types of items, or when nothing should be loaded at all

as ssilk already noted, trains on the demo map sometimes get stuck on loading because they arrive at a "multi type" station and some inserter still has items from a different type in its hand. then those items are inserted first even if that type is not requested, and the train can't load the desired amount. this problem also appears after quite some delay, eg on the demo map, an inserter can have a circuit in hand, a copper train arrives and unloads and thus has free space for those circuits. as a result it goes to the depot with those circuits and much later is sent to any station where it cant fully load the entire train.

this problem was also discussed in the thread Smart Train Deliveries with Combinator Magick [0.13/0.14] which tries to achieve something similar purely with vanilla combinators (which makes it more difficult to set up and maintain than this mod). AFAIRR (as far as i read and remember), they solved the problem in requesting only a few fewer items than would fit in a train (one handfull for each inserter), and thus at a station with 12 inserters, each with 11 bonus for a max handfull of 12, would abort loading 144 items before the wagon is full, so that the "last handfull" of all inserters still can be put into the train.

until that problem is solved, people should be warned of this problem and advised to use one separate station for each type of items, unless specific conditions are met, eg a station where trains are only unloaded.

two ideas how this problem could be eliminated or at least reduced :
- is it possible to set the wagon-filters by this mod? then those inserters with items in their hand would be blocked instead of loading the wrong items. in the worst case, this could stop the train from being loaded or make loading slower with fewer "free" inserters, but in no case would a train get the wrong cargo and later be blocked somewhere else from fully loading
- you could subtract those 144 items (max number of inserters times max stack bonus) automatically when determining the capacity of wagons. then no inserters would have items left in their hands. but to make this work, trains may not load until inactivity and have to leave when they have loaded the requested amount (or max a handful more).
- people also could do this themselves (if they know of this restriction) by never requesting a fully loaded train, but only a few items or maybe a stack less than a full train. but as above, that would require trains to abort loading when the requested amount is loaded and not continue until inactivity.

Handling many trains at the provider is mainly the players problem.

yes, and that might also apply to leaving enough space for inserters to empty their last hand, IF the mod allows stopping to load before the wagon is full.

opposing the suggestion of minimum wait time

But perhaps some simple rules: It makes not much sense to send more than one train per 10 seconds to one provider stop. I would say the scheduler should wait about 10-60 seconds before he sends he next train.

but what if i have several loading stations and several unloading stations, maybe a single loading station and a single unloading station, each with more than one track ?

Some ideas how that could be calculated:

nice ideas, but i can think of cases where the calculations should give the opposite result from what you think is "normal" ...

• >> Amount to loaded items for one wagon (eg stacksize of circuits vs ore)
  imho, other factors are much bigger, eg the number of buffer chests and one- or two-sided loading (1-12 chests), and the speed of inserters (slow, fast, stack, modded, or even direct insertion, etc)
• >> Length of train (the longer it takes to accelerate, enter and leave)
  length of entire train? the more wagons it has (including engines opposite the driving direction) the slower it is, and the more engines it has (in driving direction) the faster it is. eg 2-3 is longer but faster than 1-3, and 2-2 is as long as but still faster than 1-2-1, etc, and there are mods with different engines from strong and slow cargo to fast and weak passenger. you would have to calculate a lot and still not be able to find correct results for all circumstances.
• >> RollonRolloff or Terminus train stop (it doubles the time to enter/leave a stop). Well, the last one is difficult.
  my experience from OTTD says that there is no difference for RoRo and Terminus in the station itself (the block is blocked in both cases). the difference is in the size of the area in front of and/or behind the station: when one train can start entering after another has left, or whether the first train has to clear a large block (area of common entry/exit rail and crossings) first. the difference should be less than one train length, negligible in comparison to distance between depot, loading and unloading stations.

there are probably many more special cases than this mod could take care of, and thus the player should take responsibility.

at most, an additional signal could be added that adds some minimum distance between trains, but has 0 as default.

The amount of items is not updated while loading. (*)
(*) You wrote: as of 0.1.0 Output also includes count of all wagons and locomotives parked at this stop.
Eventually that is a bug? Or I miss something? Cause the numbers currently don't change.

that's also how i understood it at first, but probably something completely different is meant:
i saw that on that wire, not only the number of all items IN the train, but also the number of engines and wagons of the train itself are visible. and when reading this again, i noticed that he said "count of all wagons and locomotives" and NOT "count of all ITEMS IN wagons and locomotives"

[Optera]

That's a lot of feedback. I'll break it up in 3 posts so i dont time out while writing again.

Awesome, nice improvements. I still get an error (running 0.3.11) when using a battle trains cargo wagon though --

Code: Select all

Error while running event on_train_changed_state (ID 23)
Unknown virtual signal name: LTN-battle-cargo-1
stack traceback:
	__LogisticTrainNetwork__/control.lua:557: in function 'UpdateStopOutput'
	__LogisticTrainNetwork__/control.lua:133: in function <__LogisticTrainNetwork__/control.lua:106>

That looks like my data_final fixes is unable to generate the virtual signal for battle trains. do you have any other mod running data-final fixes that would change battle trains prototypes?

[Optera]

@ssilk.
Taking roro/terminus, train length, speed etc in account has little to no benefit for massive the effort needed to calculate every modded parameter so it's a definite no, i wont do that.

delivering only single items:
It's the last big task on my todo list before moving the mod out of alpha stage.
In the process i will also change how trains behave at stations (get rid of 1s inactivity for anything except depots)

inserters holding items feeding unwanted items into wagons:
It would be easy to point at my repeated request for making filter inserter stack sizes controllable which have not even been answered so far.

min delivery size:
Like i said in pm, trains are mass transports. The default min delivery size of 1000 is to prevent trains running wild when initializing the system. if you really want trains to rush at a delivery of 10 belts, set min delivery size < 10.

The amount of items is not updated while loading:
What you see at a provider station is the total order size while a requester station shows the total deliverd amount aka train inventory.

Trains are ordered to transport items, that are already "on the way":
I can't replicate that behavior in any of my tests. For example If on my demo map oil unload has less than 5k a delivery is created and the next would only be made at less than 10k.

[Optera]

@Ansen
several shorter problems, questions and suggestions:
I will update my description and the demo map to fix those errors.

The sole meaning of the grey signal is for short circuit detection. if output and input are connected input will see 2 color signals and lock down the station. While not the most elegant solution it's certainly one of the most runtime friendly.

Honestly I didn't think too deep about progression. Putting Train logistics at the same level as robot logistics seemed appropriate since players by then should know what behavior to roughly expect.


BUG - always attempting full load even for few items and single-item requests
I noticed that too. It's a unintended side effect of the 1s inactivity condition and will be removed once i rework it to merge shipments.
I'll release a version without the 1s rule today.

BUG - loading wrong types of items, or when nothing should be loaded at all
I could set filters and limit inventory size when generating the schedule, but ultimately decided against it because i can not know how players load the wagons.
Imagine a 4 wagon train sent to pick up copper and iron ore from a mine.
The player neatly set the first 2 wagons to be loaded with copper and the last 2 with iron. How would i set the filters?
It adds infinite complexity to the mod. In the end filters would only work well for single item trains.

If you want max efficiency having dedicated loading stations per item type is still the way to go.

If you don't care for loading speed, but want multiple items on one station you can build a smart loader with my inventory sensor.
This design requests x+stack bonus items and loads them into the wagon. When the train leaves it cleans out the request chest.

Smart loader overload

Code: Select all

H4sIAAAAAAAA/9VW246bMBD9lYinXnCFyWV3tXK/oG99XFWWF0+CtWBTY9KNEP9e45ALBBCstis1L0lk+3h8zpyZ4WqRqIglC0pKkEYYATkpS8lSIB7TwsQp
GBGhSKXPQjKjtOdnKrf7lCTlK0FL/0BQ8G1d+ZGSRquEPkPM9kJpUl7OU7vI3SGLvhU6NzQXO8kSUppDZq/aC20Klnj+8ebjIgIWxZ5Dzg2ThiDsqww0c7d7
XzxfFSYr5mBVDk1C1MTy5GHvFyl3GsC+50jBgQpOcFDvffLCelkDby2u/UjoqBDG7azqj99wthWJAY2EzEHbHx22cM0W7uPqBJgqDlRt6eWduD/kbkwYXwcV
toISBlKUg8xv5AubgLjQxwvIqie446PqxBhlmoOxIMDRH7ZT0glXWNWwLySH1/ohnfN1XKfDTmRduCCQVs/KnAHWQYMQjiJoyJjQKGPRy/loGJzOLoe0nyFu
onYid3aIITeIWaQ9oEyrveC9WgeXsxyietOwk2opnJHGtWhw5jqqR5vGVIH9mWZM1yER7/s8U+1BH0ws5M4hZgfqaKdbrVIqpIUhVlOYyPzSknWV0N18HnJj
O/PbitknRi8DbgycQFd0hyO+PNP9rmwTbyI13Te2iArfWI7wJPOPVKbzvRoYpzGTvObJ2NByp/t53S25TTXK1JL20MkA/7ZMP0w2q4bfhf3u4yD4NwU5HC7I
Ezpr+KGNNcSru9X9crO6v+6wX9+vw46zg3vFvRsx/V2Lz9NDxueUN/e5uX1qvNON96lwxowynPxTRjebXF1SNh+RbOF1iqF/l2KbVpVcT20ns52Kb3ns6yT/
zzQ8TuRNyR0i8r46MikiBz7iiOv5tJrkoX5ZqouHmn0/U2YWPxSzE9Niv1l8UnZgSezfz171qMEUWi7oI0j+Fxe4t64IDQAA

You are right in all points against calculating times. Not to mention the massive amount of work i'd have to put in a feature few would understand how and why it works.
roro in factorio is a lot more efficient than in OTTD. In OTTD you can't put signals in the middle of stations making long train stations highly inefficient. In Factorio you can put a signal every wagon making theoretical roro throughput much higher than terminus.

as of 0.1.0 Output also includes count of all wagons and locomotives parked at this stop.

Its the number of locomotives and wagons currently parked at the stop.
The signals are automatically generated from the entities to allow discerning between any modded locomotives and wagons as well

[jeffstan123]

I have one line loading and unloading iron ore. I am trying to move iron plate but when i have the same set up as the ore but with plate nothing happens. The iron ore route still runs, but not the plate route. how should i fix this?

[ssilk]

Sorry, ich kann manchmal nerven. Falls ich nerve ignoriere meine Posts einfach. Ich hab damit kein Problem.

min delivery size:
Like i said in pm, trains are mass transports. The default min delivery size of 1000 is to prevent trains running wild when initializing the system. if you really want trains to rush at a delivery of 10 belts, set min delivery size < 10.

Sorry, this min delivery makes no sense.

I repeat my argument: You cannot decide the importance of a transport by the amount, that might be transported. It's not the task of a logistic system.

Hm...

Why not adding a new signal "transport priority" instead? Default is "0" (or none), can be positive but also negative.
Transport priority of provider and requester is added. Say provider says "priority is -5" and requester says "priority is 10", then the resulting priority is 5. All transports with priority 5 are transported before transports with priority of 4 and before priority 6. In other words: the higher priorities are transported before the lower. If that goes wild: Well, that's the players problem, not yours. After some minutes, when the first transports have been made the system balances itself out.
The cool thing with this is: You can change the priority with circuits!
Say you have an iron furnace. If it has enough iron it can reduce it's request priority to zero. But when iron gets lower and lower the priority could be increased.

The amount of items is not updated while loading:
What you see at a provider station is the total order size while a requester station shows the total deliverd amount aka train inventory.

I know, but the order changes during movement and is in the moment of arrival at the provider eventually useless.

Example: I have an iron outpost that mines 4000 iron per minute. When the train starts his order is 1000. But he takes about 2 minutes to arrive. In that time there are 9000 iron. But it picks up only 1000.

Another example: An outpost needs lasers. A train is ordered. Before the train picks up lasers the player arrives adds some lasers from his inventory into the outpost inventory. The order is now obsolete, cause now the outpost has too much lasers. Train could return to the depot. Instead he insists on delivering.

[Optera]

I have one line loading and unloading iron ore. I am trying to move iron plate but when i have the same set up as the ore but with plate nothing happens. The iron ore route still runs, but not the plate route. how should i fix this?

I would need the save to know what's going on.

Sorry, ich kann manchmal nerven. Falls ich nerve ignoriere meine Posts einfach. Ich hab damit kein Problem.

Ich hab kein Problem mit "durchdachten" Verbesserungsvorschlägen. Wenn ich allerdings in nichtmal 5 Minuten einen Weg finde wie die Idee völlig an der Realität zerbricht war sie einfach nicht durchdacht.

I repeat my argument: You cannot decide the importance of a transport by the amount, that might be transported. It's not the task of a logistic system.

Hm...

Why not adding a new signal "transport priority" instead? Default is "0" (or none), can be positive but also negative.

Min_Delivery_Size is no priority system. It's exactly to achieve what you want with your "update delivery while train moves" idea for far less performance cost.

You contradict yourself when saying prioritizing is not the job of the transport system and one sentence later want a priority signal.
Deliveries will be handled by age of request, availability of items and trains.

I know, but the order changes during movement and is in the moment of arrival at the provider eventually useless.

Example: I have an iron outpost that mines 4000 iron per minute. When the train starts his order is 1000. But he takes about 2 minutes to arrive. In that time there are 9000 iron. But it picks up only 1000.

You don't give enough information about the whole transport system, so I assume you have this single train.
What will happen is the train picks up the 1k since that's what the available inventory of that outpost was when creating the delivery.
After finishing the delivery, the outpost will have more than the remaining 3k available so those will be shipped in the 2nd run.

In reality you have several ore outposts, each with more ore in storage than a full train load, so this is not a problem at all.

Another example: An outpost needs lasers. A train is ordered. Before the train picks up lasers the player arrives adds some lasers from his inventory into the outpost inventory. The order is now obsolete, cause now the outpost has too much lasers. Train could return to the depot. Instead he insists on delivering.

Do logistic bots turn around and put requested items back to provider? There's your answer.
Instead of having 2 logistic network behaving totally different I aim to make them behave as consistent as possible.

Unlike your other requests it would take very little addition to the logic, but players would be utterly confused if trains suddenly stop with "no path" on their network optimized for the Depot > Provider > Requester > Depot route.

[Anson]

Sorry, ich kann manchmal nerven. Falls ich nerve ignoriere meine Posts einfach. Ich hab damit kein Problem. :)

ich auch. desgleichen. ditto. :-)

The sole meaning of the grey signal is for short circuit detection. if output and input are connected input will see 2 color signals and lock down the station. While not the most elegant solution it's certainly one of the most runtime friendly.

does that mean that i can temporarily shut down a station by sending any color signal to the input?
that would be a nice and easy way to edit a station or its values without accidentally sending trains for unintended requests.

Honestly I didn't think too deep about progression. Putting Train logistics at the same level as robot logistics seemed appropriate since players by then should know what behavior to roughly expect.

by requiring blue science, oil industry and red circuits, you suggest (almost force) people to do robots first. i don't know whether a train based "small delivery system" late in the game would be used by many people (for doing only mass transport of ore and maybe plates in fast and long trains, i mostly don't need a logistics trains mod)

i thought of using your system together with the JunkRail mod for doing transports in the factory in the early game, or when resources (most important oil) are limited in the starting area and i have to expand in the early game while or before i do oil and robots.

one example for use might be using a logistic train network with junkrails eg replacing a big multi-lane master belt by those trains. this would also allow to have separate areas for producing specific items like plates/smelting, one green and one red circuits factory, later transport plastic and batteries all around in the factory, etc. and all that without the need to first research oil and robots, and without having to build a belt system first, then do the oil, and finally replace the entire factory by a new one that uses this mod. when adding also bio industries and bergius process (which currently have the same problem of needing a tiny bit of real oil to start the oil-less chain), i could almost do an entire factory based only on wood, with wood trains, and without the need for oil :-)

setting up a train network with multiple trains is already quite some task since trains require additional space and overhead in comparison to robots. whoever uses mods in general and this mod in particular to do logistics with trains should have played one or a few vanilla games already and thus "should know what behavior to roughly expect".

>> always attempting full load ...
It's a unintended side effect of the 1s inactivity condition ...
I'll release a version without the 1s rule today.

THANKS!
that will be a big help in general, and also allow users to setup solutions themselves for avoiding the second bug/problem of getting wrong items in wagons from having inserters with items left in their hands.

How would i set the filters?
It adds infinite complexity to the mod.
In the end filters would only work well for single item trains.

true. that suggestion was only one idea to (temporarily) avoid the problem of loading wrong items.
with the above (removal of the 1s inactivity) people can do better themselves now.

... smart loader with my inventory sensor. ... (blueprint) ...

I'll have a look at that later when i have more time. i love wired setups for loading, unloading, conditions, etc :-)

it would be so nice if we would get "dumb inserters" in vanilla, that always do only single items no matter what the stack bonus is. what would we need: maybe two pairs (slow and fast, each as normal and as filtered version) that are enabled together with the stack bonus research, or even as separate research after bonus research. or maybe add a new option to the circuit network besides enable/disable on inserters: a signal for the max quantity of items in hand, eg 0=off, any value = max items to take in hand

In Factorio you can put a signal every wagon making theoretical roro throughput much higher than terminus.

i noticed that too, but only a while after i had written the last post.
implementing such a station will still be some challenge if it should be avoided to load and unload those following trains at incorrect locations (hehe, i always am wondering why i have coal in ore-unloading chests after i stopped trains and/or drove them manually :-)

The default min delivery size of 1000 is to prevent trains running wild when initializing the system. if you really want trains to rush at a delivery of 10 belts, set min delivery size < 10.

Sorry, this min delivery makes no sense.
I repeat my argument: You cannot decide the importance of a transport by the amount, that might be transported. It's not the task of a logistic system.

what does the min delivery size have to do with importance ? nothing.
i find it nice that people can chose themselves whether and to what amount partial deliveries should be done, eg setting min delivery size for oil barrels to 20, for circuits to 2000, and for ore to 9500 on a 5-wagon train.
and whoever doesn't find it useful can simply leave that parameter as is, or set to a very low value that he desires as HIS default.

btw: can this value be set only at the provider or also only at the requester (and what happens with multiple providers and/or requesters), or both (and which value will then be used, which provider's or which requester's, or min or max of all of them) ? and similarly, does the same value apply to each item type separately or all of them together (eg when i request 10k ore and 30 barrels with min size 20 ? :-) i probably don't care much which of these variants you implement, but i want to know to do my setups accordingly.

the idea about a new signal for importance sounds nice. that would allow the ability to better match the most urgent requests with the most urgent calls for "active providing", but this still can't replace the signal for a min size.

btw: typing error: "priority 5 are transported before priority 4 and before priority 6." should probably be "after 6" ...

the order changes during movement and is in the moment of arrival at the provider eventually useless.
Example: I have an iron outpost that mines 4000 iron per minute...
Another example: order obsolete, Train could return to the depot. Instead he insists on delivering.

yes, but it is difficult or even impossible to always correctly react to changing numbers.

what should the ore train do when it was ordered to transport some amount and there is a different amount when it arrives?

when there is more at a loading station, it might be nice to transport more, but at most the amount could/should be calculated once again when the train arrives to reduce the difference that is caused by the time the train took to go from depot to loading station (easy to do, unless more trains from the same or another depot were sent in the meantime). correcting the amount more often could lead to virtually endless loading and other problems. if you want to always do more than those 1000, then set the "min size" signal to a bigger value (that's what that signal is for: to wait for a threshold even if there are requests and provider offers). thus the train would only be sent if eg 8000 are available, and with a proper buffer, it should even out after a few transports, similar to filling a belt with items until the first items arrive.

on unloading, it is too late to correct anything (besides recalculating and dumping surplus in a void chest), and if the player has filled the chests himself in the meantime, the train can't simply go back and drop its surplus at the loading station's buffer which might be full again now. the player is responsible to order correct quantities, provide proper buffers, and not mess anything up on purpose by adding items from his inventory to the unload station's buffer or picking items from the loading station's buffer.

[Anson]

Do logistic bots turn around and put requested items back to provider? There's your answer.
Instead of having 2 logistic network behaving totally different I aim to make them behave as consistent as possible.

bad behavior in one system shouldn't cause the other to do the same just to do the same.
but in this case, there are reasons for the bahavior of bots that also apply to logistics on trains.
and because of these reasons, the bahavior is not just "bad" but unavoidable.

one difference between bots and trains is that a bot usually has a small surplus only (max the size of the bonus carrying capacity) while trains can have dozens kilos of items as surplus and thus the problems can quickly be bigger. otoh, sending 5k bots to deliver accidentally requested 20k ore adds up to similar dimensions too. the second difference is that there are storage chests where bots theoretically could put all items from canceled requests, while trains have no such option for storage and thus their situation is much more unsolvable.

players would be utterly confused if trains suddenly stop with "no path" on their network optimized for the Depot > Provider > Requester > Depot route.

if it would be only confusion, then it would only require more detailed explanations.

but there are too many practically unsolvable problems, eg what optera wrote: the tracks would have to be built in such a way that trains from anywhere could go everywhere, with no dead ends in the routes (eg caused by terminus stations that must be passed), with shortcuts to quickly return on long oneway tracks, etc. and if a train finally succeeds in returning (to the depot? to the loading station? where?), where should it put those items if eg a loading station already has refilled its buffer chests ?

ps: i started writing my last long post before optera posted his, but finished writing that looong post only after he had posted.

[Optera]

The sole meaning of the grey signal is for short circuit detection. if output and input are connected input will see 2 color signals and lock down the station. While not the most elegant solution it's certainly one of the most runtime friendly.

does that mean that i can temporarily shut down a station by sending any color signal to the input?
that would be a nice and easy way to edit a station or its values without accidentally sending trains for unintended requests.

It "should" do just that. There are some bugs with it though. When I short circuited a depot it got caught in an infinite loop trying to delete invalid storage data.

Honestly I didn't think too deep about progression. Putting Train logistics at the same level as robot logistics seemed appropriate since players by then should know what behavior to roughly expect.

by requiring blue science, oil industry and red circuits, you suggest (almost force) people to do robots first. i don't know whether a train based "small delivery system" late in the game would be used by many people (for doing only mass transport of ore and maybe plates in fast and long trains, i mostly don't need a logistics trains mod)

i thought of using your system together with the JunkRail mod for doing transports in the factory in the early game, or when resources (most important oil) are limited in the starting area and i have to expand in the early game while or before i do oil and robots.

one example for use might be using a logistic train network with junkrails eg replacing a big multi-lane master belt by those trains. this would also allow to have separate areas for producing specific items like plates/smelting, one green and one red circuits factory, later transport plastic and batteries all around in the factory, etc. and all that without the need to first research oil and robots, and without having to build a belt system first, then do the oil, and finally replace the entire factory by a new one that uses this mod. when adding also bio industries and bergius process (which currently have the same problem of needing a tiny bit of real oil to start the oil-less chain), i could almost do an entire factory based only on wood, with wood trains, and without the need for oil

setting up a train network with multiple trains is already quite some task since trains require additional space and overhead in comparison to robots. whoever uses mods in general and this mod in particular to do logistics with trains should have played one or a few vanilla games already and thus "should know what behavior to roughly expect".

Ah yes, the dreaded blue science jump. I intended it to be a late game toy for huge networks, but an early game alternative to main bus sounds fun too.

In Factorio you can put a signal every wagon making theoretical roro throughput much higher than terminus.

i noticed that too, but only a while after i had written the last post.
implementing such a station will still be some challenge if it should be avoided to load and unload those following trains at incorrect locations (hehe, i always am wondering why i have coal in ore-unloading chests after i stopped trains and/or drove them manually

Together with how dangerous 2L-6C-2L at full speed are and how manual trains don't reserve blocks made me use automatic mode even for PAX trains.

The default min delivery size of 1000 is to prevent trains running wild when initializing the system. if you really want trains to rush at a delivery of 10 belts, set min delivery size < 10.

Sorry, this min delivery makes no sense.
I repeat my argument: You cannot decide the importance of a transport by the amount, that might be transported. It's not the task of a logistic system.

what does the min delivery size have to do with importance ? nothing.
i find it nice that people can chose themselves whether and to what amount partial deliveries should be done, eg setting min delivery size for oil barrels to 20, for circuits to 2000, and for ore to 9500 on a 5-wagon train.
and whoever doesn't find it useful can simply leave that parameter as is, or set to a very low value that he desires as HIS default.

btw: can this value be set only at the provider or also only at the requester (and what happens with multiple providers and/or requesters), or both (and which value will then be used, which provider's or which requester's, or min or max of all of them) ? and similarly, does the same value apply to each item type separately or all of them together (eg when i request 10k ore and 30 barrels with min size 20 ? i probably don't care much which of these variants you implement, but i want to know to do my setups accordingly.

Min_shipment_size is only stored at requesting stops and like you said is only a threshold below witch deliveries are started.
If a station requests 8k ore but only 4k are available the 4k will be shipped. That pushes the request size to 4k and further shipments are started only after dropping below 8k again.

I'm currently brooding over min_shipment_size for merging shipments and sending them by age rather than what requesting station happened to be earlier in the list.
I'm leaning towards a min size/item rather than a total shipment size, simply because it allows me to filter before having to store and merge all those 1 of x requests.

the idea about a new signal for importance sounds nice. that would allow the ability to better match the most urgent requests with the most urgent calls for "active providing", but this still can't replace the signal for a min size.

btw: typing error: "priority 5 are transported before priority 4 and before priority 6." should probably be "after 6" ...

Maybe in future versions.

when there is more at a loading station, it might be nice to transport more, but at most the amount could/should be calculated once again when the train arrives to reduce the difference that is caused by the time the train took to go from depot to loading station (easy to do, unless more trains from the same or another depot were sent in the meantime). correcting the amount more often could lead to virtually endless loading and other problems. if you want to always do more than those 1000, then set the "min size" signal to a bigger value (that's what that signal is for: to wait for a threshold even if there are requests and provider offers). thus the train would only be sent if eg 8000 are available, and with a proper buffer, it should even out after a few transports, similar to filling a belt with items until the first items arrive.

on unloading, it is too late to correct anything (besides recalculating and dumping surplus in a void chest), and if the player has filled the chests himself in the meantime, the train can't simply go back and drop its surplus at the loading station's buffer which might be full again now. the player is responsible to order correct quantities, provide proper buffers, and not mess anything up on purpose by adding items from his inventory to the unload station's buffer or picking items from the loading station's buffer.

I'd rather have a stupid, fast system than one with excessive calculation overhead.
To just recalculate when a train arrives at a loading station i'd have to

• parse through all deliveries to find that train
• parse through all stations to get the request station's current demand
• recalculate request with provided items and train inventory size
• parse through internal storage of this data and update all
• send updated loading amounts to the train via schedule update

That's only if this is the only train delivering for that requester. If a 2nd train is already under way to a different station to complete the request things get really messy.

Using dynamic numbers is a guarantee for headaches in such a system.

[Lezreth]

Great mod, trains have always been annoying to troubleshoot issues. However altering the minimum delivery size at requester stations was giving me issues.
Original scenario: I set the minimum size to 7.9k at the iron and copper ore offloading stations for my big forge, but the trains keep delivering 2k or less, sometimes 200-300. As i write this 2 trains dropped off 87 and 45 copper ore respectively, as per the order the depot gave them.

I disabled the combinators feeding the requests to the big forge, waited for the trains to return to the depot, and re-enabled the combinators. All the trains launched with 8k requests, then stopped after returning to the depot even though the provider stations are well overstocked and requester stations still need a great deal more ore. Now I am at a loss as to what is going on.

Link to zip containing save and mods used: https://drive.google.com/file/d/0Byroz2 ... sp=sharing

[Optera]

Great mod, trains have always been annoying to troubleshoot issues. However altering the minimum delivery size at requester stations was giving me issues.
Original scenario: I set the minimum size to 7.9k at the iron and copper ore offloading stations for my big forge, but the trains keep delivering 2k or less, sometimes 200-300. As i write this 2 trains dropped off 87 and 45 copper ore respectively, as per the order the depot gave them.

I disabled the combinators feeding the requests to the big forge, waited for the trains to return to the depot, and re-enabled the combinators. All the trains launched with 8k requests, then stopped after returning to the depot even though the provider stations are well overstocked and requester stations still need a great deal more ore. Now I am at a loss as to what is going on.

Link to zip containing save and mods used: https://drive.google.com/file/d/0Byroz2 ... sp=sharing

That's a lot of mods, even by my standards.
From what I see you connected the small chests for unloading and the warehouses on one green wire. Warehouses+chests+-50k from combinator = +620. Meaning you are well overstocked according to the parameters you provide the system. The next train will run when ore is below -7900.

If you want warehouses almost full you have to use a much lower value on the constant combinator or disconnect the warehouses to let warehouses spill into clogging the unload.

[ssilk]

Suggestion: Some sort of List
Click on a train-stop and all stops provide information, looking about like so

Screen Shot 2016-11-22 at 20.32.17.png (18.54 KiB) Viewed 8627 times

Taken from OpenTTD.
That would be the list for stop, that provides and requests something.

Would look more like this:

Code: Select all

Provides
4220 Iron Ore XXXXXXXXXXXXXXXX
2040 Copper Ore XXXXXXX

Requests
100 Reapir Pack XX
10 Wall X

That would be just step 1. Step 2 could be a list of trains, that drive to this stop for loading or unloading.
Step 3 could be an overview over all stops and switching between the stops.

[Optera]

Would be nice as addition to the normal train stop window. Can mods expand base ui windows like that?

As list on the side it might get clustered pretty fast once a station provides 10+ items.

Edit: as List i think it'd need at least this much to be user friendly
Depot:
Train list with name and length

Stations: with station name in alphabetical order
items per line should look like this
4220 Steel / -4000 being picked up
-5200 Iron Plate / 3200 being delivered
with more than 2-3 lines an dropdown arrow could expand to see all requests/provided items

[Lezreth]

I think I see what is going on now. With item threshold set to 50k ore and minimum delivery size set to >7.9k the network will try to meet or come close to 50k ore, in multiples of 8k. Since the sum of iron ore on hand and ore requested: 50,000 - 48,583 = 1417 is less than 8k an order will not be placed until some ore gets used up. So the system will only create orders for increments of the minimum delivery even if the amount on hand is a little less than what is requested.

Yes, I do have a lot of mods. I like to explore what people come up with and keep the ones I find fun or useful. I download a few every so often, play with them and then purge the list every few months. There are some however that provide similar features overall, but have a few small differences that end up being significant enough to keep both variants. It would be nice if some of the authors would collaborate and release one super mod. That way I would have to have only one blueprinting mod instead of 3.

[Optera]

I think I see what is going on now. With item threshold set to 50k ore and minimum delivery size set to >7.9k the network will try to meet or come close to 50k ore, in multiples of 8k. Since the sum of iron ore on hand and ore requested: 50,000 - 48,583 = 1417 is less than 8k an order will not be placed until some ore gets used up. So the system will only create orders for increments of the minimum delivery even if the amount on hand is a little less than what is requested.

Yes, min delivery size is the threshold below with items are requested. You set it to 7.9k, so only once the station sees less than - 7.9k (notice the minus) a delivery is made.
Keep in mind requesting stations should always stay at negative values. If your station sees +1417 it would qualify as provider and trains might be sent there to pick ore up should it happen to be the stop with the highest count of this item.

[Lezreth]

Just when I have it figured out, my depot starts creating orders below the set minimum again. The original issue I posted is not resolved after all. I just watched a few trains get dispatched for orders of 111, 8000, 732, 1519, 2131 copper ore. A little down the line, a few 8k iron ore trains followed by a 120 copper ore train. I set an 8k (>7.9k) minimum size on raw ore deliveries and the depot is ignoring that.

[Optera]

Just when I have it figured out, my depot starts creating orders below the set minimum again. The original issue I posted is not resolved after all. I just watched a few trains get dispatched for orders of 111, 8000, 732, 1519, 2131 copper ore. A little down the line, a few 8k iron ore trains followed by a 120 copper ore train. I set an 8k (>7.9k) minimum size on raw ore deliveries and the depot is ignoring that.

Sounds to me like your ore mine had provided-deliveries < 8k when the shipments where created. If there's no provider for the full shipment the next highest available amount will be used.