old LTN discussion thread

[MrFreohr]

I already posted a report in the game "Bug Report" forum since I thought it was an issue with the game LUA engine, but RSeding replied that it was normal behavior, and up to the mod author to correct the behavior.

Here is the report : [0.14.22] Variable conflicts when loading different mods

Basically, the MOD_NAME variable is both in the global scope, and also used by the WaiTEX mod, which cause an error when loading the optional RailTanker graphic resource. I can fix it for my personal use (by hardcoding the path to the resource), but it is overwritten every time there is an update to the mod.

[Optera]

I already posted a report in the game "Bug Report" forum since I thought it was an issue with the game LUA engine, but RSeding replied that it was normal behavior, and up to the mod author to correct the behavior.

Here is the report : [0.14.22] Variable conflicts when loading different mods

Basically, the MOD_NAME variable is both in the global scope, and also used by the WaiTEX mod, which cause an error when loading the optional RailTanker graphic resource. I can fix it for my personal use (by hardcoding the path to the resource), but it is overwritten every time there is an update to the mod.

Thanks for bringing this to my attention. That might have been why some mod packs wouldn't work well with LTN.
Paths in 0.9.12 are now hardcoded.

[ssilk]

I thought over the problem of my jammed depot stations. See some posts above.
And I have an idea: All I need to do is to create an order if there is a jam detected.
It could be just a random order with empty cargo.

So my suggestion, Optera: would it be possible for you to build in some "go-to-a-random-provider"-signal that creates an order with empty cargo to a random stop that provides anything? (If only one/no stop provides it should search just any stop which matches for its configuration)

That makes much sense: i can simply detect the jam situation and create that new signal for that depot. The train will go to some provider, load nothing (if the stop was correctly built with filter inserter) and then searches for the next depot, hopefully more space left.

That works even for the case that there is also a jam, cause the train takes a while to dive to that position and in that time it doesn't block.

[Optera]

I thought over the problem of my jammed depot stations. See some posts above.
And I have an idea: All I need to do is to create an order if there is a jam detected.
It could be just a random order with empty cargo.

So my suggestion, Optera: would it be possible for you to build in some "go-to-a-random-provider"-signal that creates an order with empty cargo to a random stop that provides anything? (If only one/no stop provides it should search just any stop which matches for its configuration)

That makes much sense: i can simply detect the jam situation and create that new signal for that depot. The train will go to some provider, load nothing (if the stop was correctly built with filter inserter) and then searches for the next depot, hopefully more space left.

That works even for the case that there is also a jam, cause the train takes a while to dive to that position and in that time it doesn't block.

How about using better signaling and enough space so jams don't happen in the first place?

Here's what will happen if you order trains to go on a (random) delivery:
One train leaves the depot, its space is freed up. That much is true.
While on the journey that train is not available for meaningful deliveries
When the train returns guess where it is. Back in the jam.

What you achieved is burning fuel and making trains unavailable for required deliveries. You might as well just reduce the number of trains.
But if you truly want this you can pull a wire or use a wifi mod to get a signal to a a designated jam clearing stop and have that order something once you detect a jam.

[ssilk]

How about using better signaling and enough space so jams don't happen in the first place?

Sorry, but I tried hard but I run into situations where I need to store 40 LLCCCC trains at one place. That makes no sense.

Here's what will happen if you order trains to go on a (random) delivery:
One train leaves the depot, its space is freed up. That much is true.
While on the journey that train is not available for meaningful deliveries
When the train returns guess where it is. Back in the jam.
What you achieved is burning fuel and making trains unavailable for required deliveries. You might as well just reduce the number of trains.

I don't know why the train should return if there is a more near depot.

The train is on the rails to another stop that is likely to be the next source-target. He is not missing anywhere, cause he is sent CAUSE there are too much waiting for orders.
If you placed a depot near that provider, that train will choose that depot for waiting for the next order. If that depot is crowded too, the process continues until all trains found their "optimal positions".

And so much to be said: that idea comes from real life, cause there this problem is really a cost factor (they are just able to direct directly to the nearest depot with the least number of trucks at the probable next provision).


... all comes from the problem that depots needs to have equal names to be effective enough in such a big map...
It would be much easier if depots could have any name and just need the depot signal. Then I could feed in the number of wanted trains at a depot and the train could directly drive to the depot with the most wanted trains.

[Optera]

And so much to be said: that idea comes from real life, cause there this problem is really a cost factor (they are just able to direct directly to the nearest depot with the least number of trucks at the probable next provision).

Well unlike RL logistic systems I have no clue where stops are, how they connect to one another, not even where trains currently are (unless parked at a stop).
Sidenote: I was part of the development team for a fleet management system.

... all comes from the problem that depots needs to have equal names to be effective enough in such a big map...
It would be much easier if depots could have any name and just need the depot signal. Then I could feed in the number of wanted trains at a depot and the train could directly drive to the depot with the most wanted trains.

Wow your info is seriously outdated. Are you really using my current version and not your ancient fork?

0.5.4
- changed Depot detection from name "Depot" to virtual signal "Stop is Depot"

[ssilk]

And so much to be said: that idea comes from real life, cause there this problem is really a cost factor (they are just able to direct directly to the nearest depot with the least number of trucks at the probable next provision).

Well unlike RL logistic systems I have no clue where stops are, how they connect to one another, not even where trains currently are (unless parked at a stop).

Yes, that is the basic problem. But that was the reason, why I think that my idea with sending the trains to some provider will work.
And no: it doesn't matter much, cause for the near reach (of about 200 tiles in diameter) Factorio already manages quite well to fill all depots equally. So no usage to be really exact with this. What's important is: should it take the nearest depot or should it take one 2000, 3000, 4000 tiles away? (Assumed the depots are all connected it would be just enough to check the distance.)
That was the idea of sending the train to some random provider, which is eventually 4000 tiles away, cause then Factorio chooses the next depot.

Sidenote: I was part of the development team for a fleet management system.

For that you implemented not so much from that into your mod.
No, seriously: That explains your interest and some of your design decisions. And it explains also why it doesn't allow much different layout than your idea of what "logistics" is.

... all comes from the problem that depots needs to have equal names to be effective enough in such a big map...
It would be much easier if depots could have any name and just need the depot signal. Then I could feed in the number of wanted trains at a depot and the train could directly drive to the depot with the most wanted trains.

Wow your info is seriously outdated. Are you really using my current version and not your ancient fork?

No I use the current. You played it and gave me tips. But go back to the former page: My problem is the size of my map. LTN works perfectly in an area of - let's say 2000x2000 tiles. But in 6000x6000 it behaves more and more annoying.
Ok, I explain it again:
At first I had only one central depot, with enough space for all trains.
Problem: An outpost provides something which is needed anywhere else. The trains are only in the center. Until the train drives to the outpost 1-2 mins are over (the map was at that time about 2000x2000). I found that much too long. For my taste acceptable is 30 seconds. More makes the network inefficient.

So I begun to built depots at the outposts, cause that way a train near the depot is chosen.
Uhm, btw: Does LTN try to choose the nearest free train?
Problem 1: I cannot foresee, how many trains are really needed. Sometimes only one train of 5 is out, sometimes 10 trains are not enough! In doubt there are always too less. But that is no problem, when you have a central depot with all trains, cause the pool is much bigger.
Problem 2: Really ugly is, that now it is possible, that a train from the OTHER SIDE of the map is requested. That takes not 2 minutes, but 5! Much, much, much too long! I don't want to built so big buffers, but I can meanwhile smelt much more than 100000 items in 5 minutes.

So I begun to name all depots for one type of train equally. I have currently supply trains (LCC), bulk trains (LLCCCC) and liquid trains (LCCC).
Problem: That works astonishing well, until I have nothing to do for my factory. Trains are suddenly free and search for the next depot.

So I begun to search for a method to send the trains from a jammed depot to another depot, that is not jammed.
Problem: I found no solution. So I asked here.

Summary: I have now about 20 depot-stops. I tried a lot around with your counsel. But there is currently from my sight no good way to build very big train networks, cause they are either quite slow or have other problems, that I don't want.

Maybe it looks a bit close-minded, I see me just focused to solve a very special problem.

[Optera]

For that you implemented not so much from that into your mod.
No, seriously: That explains your interest and some of your design decisions. And it explains also why it doesn't allow much different layout than your idea of what "logistics" is.

I'm certainly "betriebsblind" (professionally blinkered?). To some degree we all are.

... all comes from the problem that depots needs to have equal names to be effective enough in such a big map...
It would be much easier if depots could have any name and just need the depot signal. Then I could feed in the number of wanted trains at a depot and the train could directly drive to the depot with the most wanted trains.

Wow your info is seriously outdated. Are you really using my current version and not your ancient fork?

No I use the current. You played it and gave me tips. But go back to the former page: My problem is the size of my map. LTN works perfectly in an area of - let's say 2000x2000 tiles. But in 6000x6000 it behaves more and more annoying.
Ok, I explain it again:
At first I had only one central depot, with enough space for all trains.
Problem: An outpost provides something which is needed anywhere else. The trains are only in the center. Until the train drives to the outpost 1-2 mins are over (the map was at that time about 2000x2000). I found that much too long. For my taste acceptable is 30 seconds. More makes the network inefficient.

So I begun to built depots at the outposts, cause that way a train near the depot is chosen.

Uhm, btw: Does LTN try to choose the nearest free train?

Problem 1: I cannot foresee, how many trains are really needed. Sometimes only one train of 5 is out, sometimes 10 trains are not enough! In doubt there are always too less. But that is no problem, when you have a central depot with all trains, cause the pool is much bigger.
Problem 2: Really ugly is, that now it is possible, that a train from the OTHER SIDE of the map is requested. That takes not 2 minutes, but 5! Much, much, much too long! I don't want to built so big buffers, but I can meanwhile smelt much more than 100000 items in 5 minutes.

Currently LTN has no concept of distance. All trains parked across all depots are stored in a single list and LTN will pick the first suitable train from it.

So far it seemed pointless to add distance calculations.
Best I could implement is beeline which might make things worse if it decides a depot 500 tiles across a lake with a real path length of maybe 2k is closer than one 600tiles along the shore.
That effect can easily happen even without lakes in networks that are not grids, but naturally grown like your save.

Without concern for the above problems, what i could do without much performance hit is calculate linear distances between all stops when they are placed and work with these precalculated values. With 100+ stops there would probably be a noticeable stutter.

[ssilk]

So far it seemed pointless to add distance calculations.
Best I could implement is beeline which might make things worse if it decides a depot 500 tiles across a lake with a real path length of maybe 2k is closer than one 600tiles along the shore.
That effect can easily happen even without lakes in networks that are not grids, but naturally grown like your save.

It doesn't matter much if you sometime use pure random.

Or if you introduce the already mentioned "needed trains" signal. With such a signal, every train depot could have its own name and the train would come back always to the same depot. Until the "needed trains" signal becomes negative or other depots have a much bigger "needed trains" value. In that moment the train in the depot could choose another depot, with a "needed trains" bigger than 0. (technically it exchanges the train-stop name).

I think I have an idea, that might work. In detail:
- All depots have unique names (A "depot" is a limitless number of stops, where train can wait). They just need to be able to handle trains as they are configured.
- Now a train comes back to depot.
- The stop now looks: Is the signal at my stop < 0?
IF YES:
The depot is FULL. There are too much trains in it, this train should search another base-depot. For that:
In 50% of the cases: Search any provider that provides something for this type of train by random. From that point search the next train depot by beeline-distance that has a non-negative.
In the other 50% of the cases just search any matching random depot.

- The other case is needed-trains-signal is 0 or positive:
Look if there are train depots with a needed-trains-signal 3 times bigger than me? (E.g. mine is 1 and another is 3)
IF YES:
There are depots that needs more trains than me.
Change the depot-stop in my schedule to that which needs the "most trains" or if equal choose one by random.

- Now continue. Look up for an order as already working before leaving the current stop.

Without concern for the above problems, what i could do without much performance hit is calculate linear distances between all stops when they are placed and work with these precalculated values. With 100+ stops there would probably be a noticeable stutter.

I don't think so. The above algorithm just needs to work, when a train arrives at a depot and then he needs just to lookup those stations, which match. It is N*O where N is the number of stops -1 .

[Optera]

Or if you introduce the already mentioned "needed trains" signal. With such a signal, every train depot could have its own name and the train would come back always to the same depot. Until the "needed trains" signal becomes negative or other depots have a much bigger "needed trains" value. In that moment the train in the depot could choose another depot, with a "needed trains" bigger than 0. (technically it exchanges the train-stop name).

I think I have an idea, that might work. In detail:
- All depots have unique names (A "depot" is a limitless number of stops, where train can wait). They just need to be able to handle trains as they are configured.
- Now a train comes back to depot.
- The stop now looks: Is the signal at my stop < 0?
IF YES:
The depot is FULL. There are too much trains in it, this train should search another base-depot. For that:
In 50% of the cases: Search any provider that provides something for this type of train by random. From that point search the next train depot by beeline-distance that has a non-negative.
In the other 50% of the cases just search any matching random depot.

- The other case is needed-trains-signal is 0 or positive:
Look if there are train depots with a needed-trains-signal 3 times bigger than me? (E.g. mine is 1 and another is 3)
IF YES:
There are depots that needs more trains than me.
Change the depot-stop in my schedule to that which needs the "most trains" or if equal choose one by random.

- Now continue. Look up for an order as already working before leaving the current stop.

Problem: How would you prevent tanker trains from going to a new depot made for normal freight trains?

Trains should always remain bound to depots of the name the player sent them to.
Basically what I'd do to send trains between depots of the same name is the following hack:
- read depot-full signal at depots
- if depot-full, find an empty depot of the same name
- if empty depot found, rename the stop to name + trainId
- set train to the renamed stop
- when it arrives rename the stop back
It'd be ridiculously simple if instead the api allowed to send trains directly to certain stops by unit_numbers.

[blippincott]

Would it be possible to set a "maximum train limit" so that we can limit the number of trains going to a station? When I first set up a station, it sends out a huge number of requests to get the buffers full, and my train stackers are overflowing. I'm thinking this would just be a signal like "maximum delivery size".

[steinio]

Hello,

it seems that the 'Ignore Minimum Delivery Size' signal don't ignores the config.lua value and only the LTN Stop 'Minimum Delivery Size' signal.

Greetings steinio

[Eugenii10]

Hello!
I have deleted a "RailTanker" mod. After that, every attempt to load game (where RailTanker mod was enabled) caused error in your mod control.lua line:74

error.png (94.93 KiB) Viewed 7565 times

However I have fixed that for myself, just wanted you to know about such possibility. Thanks.

[Optera]

it seems that the 'Ignore Minimum Delivery Size' signal don't ignores the config.lua value and only the LTN Stop 'Minimum Delivery Size' signal.

I have deleted a "RailTanker" mod. After that, every attempt to load game (where RailTanker mod was enabled) caused error in your mod control.lua line:74

Thanks for the reports. Should be fixed in 0.9.13

Would it be possible to set a "maximum train limit" so that we can limit the number of trains going to a station? When I first set up a station, it sends out a huge number of requests to get the buffers full, and my train stackers are overflowing. I'm thinking this would just be a signal like "maximum delivery size".

I'm reluctant to add a signals for edge cases like this. It usually happens only once for every stop.

[ssilk]

Error in 0.9.12 (I'll install 0.9.13 now, but the game was already running)

Screen Shot 2017-04-02 at 01.06.22.png (190.93 KiB) Viewed 7556 times

I've been building masses of train stops by blueprint.

Edit: Same error is also in 0.9.13.

Code: Select all

Error while running event on_robot_built_entity (ID 14)
LuaEntity API call when LuaEntity was invalid.
stack traceback:
	__LogisticTrainNetwork__/control.lua:729: in function 'CreateStop'
	__LogisticTrainNetwork__/control.lua:193: in function <__LogisticTrainNetwork__/control.lua:190>

[Optera]

Error in 0.9.12 (I'll install 0.9.13 now, but the game was already running)

Screen Shot 2017-04-02 at 01.06.22.png

I've been building masses of train stops by blueprint.

Edit: Same error is also in 0.9.13.

Code: Select all

Error while running event on_robot_built_entity (ID 14)
LuaEntity API call when LuaEntity was invalid.
stack traceback:
	__LogisticTrainNetwork__/control.lua:729: in function 'CreateStop'
	__LogisticTrainNetwork__/control.lua:193: in function <__LogisticTrainNetwork__/control.lua:190>

What your error says is surface.find_entities returned an invalid entity.
I thought those functions guarantee returned entities are valid.

Here's the part producing the error in case you want to pass it along to the devs.

Code: Select all

727  local ghosts = entity.surface.find_entities({{entity.position.x-1.1, entity.position.y-1.1},{entity.position.x+1.1, entity.position.y+1.1}} )
728  for _,ghost in pairs (ghosts) do
729    if ghost.name == "entity-ghost" and ghost.ghost_name == "logistic-train-stop-input" then

PS: I do check if entity is valid, since creative mode sometimes passes invalid entities in on_robot_built_entity

[Helex288]

Does anyone else have an issue requesting Jivolite Ore via the LTN?

Any other Angels ore does not have an issue, but when i request the Jivolite ore, nothing happens.
Yes, i have enough Jivolite ore available
Yes, i have train available for transport

Also, (once i'm able to upload a screenshot) the set filter on the filter inserter are not working for the Jivolite ore (not the filet nor the stack filter insterters).

[steinio]

Does anyone else have an issue requesting Jivolite Ore via the LTN?

Any other Angels ore does not have an issue, but when i request the Jivolite ore, nothing happens.
Yes, i have enough Jivolite ore available
Yes, i have train available for transport

Also, (once i'm able to upload a screenshot) the set filter on the filter inserter are not working for the Jivolite ore (not the filet nor the stack filter insterters).

Hello,

all fine by me.
What of mods do you use besides Angel's mods?

Sometimes it's just a missing red or green wire. But if your other setups work it's a bit puzzling.

Greetings steinio

[Helex288]

Does anyone else have an issue requesting Jivolite Ore via the LTN?

Any other Angels ore does not have an issue, but when i request the Jivolite ore, nothing happens.
Yes, i have enough Jivolite ore available
Yes, i have train available for transport

Also, (once i'm able to upload a screenshot) the set filter on the filter inserter are not working for the Jivolite ore (not the filet nor the stack filter insterters).

Hello,

all fine by me.
What of mods do you use besides Angel's mods?

Sometimes it's just a missing red or green wire. But if your other setups work it's a bit puzzling.

Greetings steinio

Bob's mods offcourse,
A lot of other mods, will be a hell of a work to test each of them.

Strange thing is indeed that for the same station all other requests are working, just not the Jivolite.

[ssilk]

PS: I do check if entity is valid, since creative mode sometimes passes invalid entities in on_robot_built_entity

Ah, maybe it's that cause I needed to "cheat" with CM to slurp all remaining liquids out of the rail tanker. I hope in 0.15 this will be no longer an issue, cause that stupid rail tankers managed somehow to poison my whole refinery with petroleum. It was 2 hours work to get that all out. So I found out, that the fluid void from CM is simple enough to clean the pipes so that the next non-empty tanker can still be unloaded.
(I think its still an issue, that the train needs to wait, until really empty)


PS: Hmm. Perhaps I should really make a bug report of that... liquids do not empty completely and ghosts are not valid.

I will try to reproduce that without CM entities.