load a train with missing items(without circuit net between stations)

[oleg4f]

Hi.

May be anybody need this .
Case:
Base station and mining station. A mining station has separate trains for ore and needed stuff(magazines, mines, repair packs, robots, etc).
Problem:
Need a maximum simple solution for a train with needed stuff. It must bring a missing items to a station with as minimum logic and simple train schedule as possible.
Solution:
* mining station:
- combinators with substract operation are used for specifying item maximum and coding item for this item(e.g. use iron plate for mines)
- these combinators produce a future values(after that these values go to combinator with devide operation and later a train items count substract from these values in the wire) for filter of filter inserters that work with coding items
- decider combinators are used for specifying critical minimum for every item where train need to go to a base station
- each coding item represent 10 item that it code(e.g. 1 iron plate represent 10 mines that we need for maximum count of mines)

station.jpeg (147.33 KiB) Viewed 7734 times

* base station:
- combinators with multiply operation to get actual needed counts for items

base.jpeg (273.43 KiB) Viewed 7734 times

* train schedule:
- on the base station it simple wait until 5 sec of inactivity
- on the mining station it wait until inactivity and event of critical minimum
- the mining station acts as a buffer station for the train

schedule.jpeg (36.86 KiB) Viewed 7734 times

[mmmPI]

- the mining station acts as a buffer station for the train

Does that mean you have 1 supply train buffered in every mining station ?


Your system seem designed to use train to carry information instead of wire.

They physically carry some metal piece that gets decoded and sent back with the supply so they can be re-used to code other message.

it is an uncommon approach because it doesn't use the "enable/disable train stop" feature .

[oleg4f]

- the mining station acts as a buffer station for the train

Does that mean you have 1 supply train buffered in every mining station ?

Yes. I took this approach .

Your system seem designed to use train to carry information instead of wire.

Yes. Wire on a long distance is unhandy.

They physically carry some metal piece that gets decoded and sent back with the supply so they can be re-used to code other message.

Yes.

it is an uncommon approach because it doesn't use the "enable/disable train stop" feature .

I think this scheme doesn't need this .

[oleg4f]

Does that mean you have 1 supply train buffered in every mining station ?

This solution was evolute from the desire to make mining stations that don't need my presence. I go to station 2 times - when i build it and when i dismantle it.

May be there is simpler approach, but i don't know it.
It would be better to have smaller count of supply trains where each train service several stations, but i can't make this without mods now .

[oleg4f]

it would be greater to have some custom items just for coding purposes. For example, 1 iron plate + 1 magazine = 1 iron plate with magazine print on it. Like a virtual signals - virtual items that can't use anywhere, but only for information. In this case, configuration of conditions in case like mine would be simpler . May be there is some mod for this?

[Pi-C]

With Trains Signal Sender, you can put custom signals directly on the train, and read them like any other signal (cargo, train ID etc.) at train stops. I'm not sure if you can set these signals via the circuit network. Last time I played, I used the GUI to set the signals. For my purposes, constant signals were sufficient because all I used them for was to specify the train type (fluid/solid cargo, armored train, express train etc.).

(Just checked: The mod hasn't been updated for Factorio 1.1 yet, and it's some months since the last version has been released.)

[oleg4f]

With Trains Signal Sender, you can put custom signals directly on the train, and read them like any other signal (cargo, train ID etc.) at train stops. I'm not sure if you can set these signals via the circuit network. Last time I played, I used the GUI to set the signals. For my purposes, constant signals were sufficient because all I used them for was to specify the train type (fluid/solid cargo, armored train, express train etc.).

Thanks for the info!
I think virtual items more general. You can send info with they in any ways and need not support for this in a data carrier . Train, belt, robot or ship - it doesn't matter .

[mmmPI]

This solution was evolute from the desire to make mining stations that don't need my presence. I go to station 2 times - when i build it and when i dismantle it.

May be there is simpler approach, but i don't know it.
It would be better to have smaller count of supply trains where each train service several stations, but i can't make this without mods now .

Another approach could be using the "enable/disable" for train stop.

This doesn't allow you to transmit the amount of material required. So your supply train need to always be loaded with everything an outpost could demand.

Then you enable the outpost only when material drops under a threshold, using decider combinator to check "If mines <100 output green", "if turrets < 100 output green", "if repair pack < 100 output green"; and "enable station when green >0".

This means the trains knows when a station need something and goes there. It will otherwise stay at the supply loading area when all other station are disabled.

If you want to set an upper limit to the material you can use the schedule condition as you did but with inactivity OR circuit condition green when the train is an outpost. ( train come when material under 100 but leave when material is above 500 ). If a station disable while the train is unloading (when refilled above the triggering threshold), it will continue unloading, and will still receive the signal telling him to go back ( reaching the upper threshold). the use of "OR" is to make sure that the train don't wait at an outpost if it wasn't loaded enough to reach the upper threshold.

The information is transmitted using the train algorithm, you can't transmit how much or what you need, you can just transmit "open". Then a train is dispatched carrying all sorts of material, and come back with a little less .

[Impatient]

On a meta level, the problem, you are trying to solve, is, that you have two points A and B, information in point B and want to transmit that info without wire or mods.

Eg train stations A and B and the information in B is "I need 1000 iron plates".

An immediate idea would be to define a convention for station A, which could be: "If I receive one item of a specific type, I send back 100 items of the same type."

In the example station B would need to send 10 iron plates to station A, to let A know, it should send 1000 iron plates back.

Does this general thought help?

[SoShootMe]

Then you enable the outpost only when material drops under a threshold, using decider combinator to check "If mines <100 output green", "if turrets < 100 output green", "if repair pack < 100 output green"; and "enable station when green >0".

Or a constant combinator with the negatives of the desired minima, connected to the stop along with storage chests, and the stop enabled if anything < 0.

[oleg4f]

Another approach could be using the "enable/disable" for train stop.

Yes and no. I use enable/disable of train stop at some stations. But this isn't work if we have common refuel stations. For example, you have a train with the next schedule - (L -> F -> U), where L - load station, F - refuel station, U - unload station. If you disable U, then a train will go between L and F until U become enable again. This makes unnecessary traffic and congestions. This can be solved with fake train stop at U(in addition to U) and buffer station B and transformation a train schedule to (L -> F -> B -> Uf -> U). And due to additional 2 stations, increasing complicity of schedule and filters in wagons this approach isn't simpler.

This doesn't allow you to transmit the amount of material required.

Yes. This is a drawback of this approach.

[oleg4f]

Does this general thought help?

Helps in what ?

[Impatient]

To find a solution.

[mmmPI]

Or a constant combinator with the negatives of the desired minima, connected to the stop along with storage chests, and the stop enabled if anything < 0.

yes even better, this way you keep the green signal for "everything > 300" for example, then you emit green signal to tell the train to leave. and train stop enable if anything <0. It sets the 2 bounds.

To find a solution.

I think what you have described is already achieved by the design in OP .

Yes and no. I use enable/disable of train stop at some stations. But this isn't work if we have common refuel stations. For example, you have a train with the next schedule - (L -> F -> U), where L - load station, F - refuel station, U - unload station. If you disable U, then a train will go between L and F until U become enable again. This makes unnecessary traffic and congestions. This can be solved with fake train stop at U(in addition to U) and buffer station B and transformation a train schedule to (L -> F -> B -> Uf -> U). And due to additional 2 stations, increasing complicity of schedule and filters in wagons this approach isn't simpler.

Yeah the new trick to avoid loop in a ABC ABC schedule is to set limit to 0 instead of disabling, this way the train doesn't skip the closed station but instead wait staying static with the message "destination full". ( if C limit is set to 0 train wait at B they don't go to A ). But it's new and i'm not familiar with it.

Also i haven't tested yet how it can change refueling systems. Most of the time i had a refuel train that delivers fuel where i have stations. Using dedicated train stop that enable when fuel buffer are low. (many "Fuel" receiver for 1 "Fuel supply"). Then i belt fuel from the the stations called "Fuel" to where i have othere regular scheduled station so to keep refilling train everytime they pass.

The way you utilise things makes is so that each area has its dedicated train that bring various supply, repair kits, turret, walls, and so on. You pick the ressources and transmit the quantity needed from outpost to supply. You could code say "1stack inserter" means " 100 solid fuel", so that each area is serviced with fuel instead of having a refueling terminal. And you simplify your other trains schedule

This doesn't allow you to transmit the amount of material required.

Yes. This is a drawback of this approach.

You know the amount only when the train come back, you know what's missing . But at this point it's no longer relevant. Your system requires less buffer of material.

[rhynex]

overall it is a nice solution. I guess creating a mod about virtual items should not be a problem. we have signal letters/numbers and it should be easy to convert them into items/recipes I guess. like item "A", created with green circuit etc. it shall be your substitute.

sorry, I have not checked the entire thread if already answered. but I have some question:

how do you start this? you have to deliver X amount of that item "A", "B", "C"... to your stations. item "A" means 10 ammo lets say. demand station should always have back that 100 amount of A, nothing missing.

the scenario:
- demand station shall call train because it needs something. how? timer? in same ore train perhaps?
- your demand station shall put 1 A item to wagon because it needs 10 ammo, this should be synced, only 1 A must be put, not more
- your train shall go to supplier (or unload if it is ore train), has 1 A
- supplier station shall put 10 ammo but not take A because demander should take it back?? right?
- your train goes back to demand station and it shall take both A and 10 ammo.
- at this point another 1 A shall not be put to train like I mentioned in step 2. both A and ammo must be taken at the same time or it shall go in a loop or unnecessary delivery shall be done. ex: inserter 1 takes A but your logic says 1 A must be put so inserter 2 puts 1 A. ammo shall be taken but not A? or A shall be taken before all ammo is taken?
correct?

[SoShootMe]

Or a constant combinator with the negatives of the desired minima, connected to the stop along with storage chests, and the stop enabled if anything < 0.

yes even better, this way you keep the green signal for "everything > 300" for example, then you emit green signal to tell the train to leave. and train stop enable if anything <0. It sets the 2 bounds.

I think the simplest solution is to stop unloading when the maximum is reached (eg filter inserters unloading into limited chests), and have the train leave after a short inactivity. This avoids the potential problem of the train running out of an item without its maximum being reached and hence never leaving. The downside is that misconfiguration (eg requesting items that the train does not provide) can result in the train looping, which is perhaps less obvious than staying put.

To allow multiple types of item per chest, ideal for supplying modest quantities of a range of items, you can use one constant combinator to specify the maxima plus one arithmetic combinator per chest, in addition to the constant combinator for the minima I mentioned before.

[mmmPI]

this way you keep the green signal for "everything > 300" for example, then you emit green signal to tell the train to leave. and train stop enable if anything <0. It sets the 2 bounds.

I think the simplest solution is to stop unloading when the maximum is reached (eg filter inserters unloading into limited chests), and have the train leave after a short inactivity. This avoids the potential problem of the train running out of an item without its maximum being reached and hence never leaving. The downside is that misconfiguration (eg requesting items that the train does not provide) can result in the train looping, which is perhaps less obvious than staying put.

Yes it's simpler but it doesn't always function properly. Those are implementation details but consider the case of unloading sulfuric acid to a uranium patch. Most likely you can't unload 25K because you didn't wait for the buffer tank to run completly dry. So there is still some letft in the wagon, but you won't get inactivity because it will trickle down directly from the wagon as your miners consume acid. Same goes for material in limited chest. You'd fill it up entirely, but then everytime 1 get consume it will be refilled immediatly from the wagon. Thus preventing the train from leaving until empty, or consumption stops.

Depending on where you implement the logic the not-so-simplest-but-safer way would be : ["inactivity > 2 sec" OR "green signal >0"]. So that the train leaves if empty, which would cause an inactivity, or if the supply was delivered properly. Which is pretty similar in notation to the ["inactivity > 2 sec" AND "green signal >0"] used in OP's.

Compared to OP's design where only the requested amount of material is transmitted, you would refill approximatively the same quantity of material everytime with this system, only with different period.

The supply train would bring 25K sulfuric acid everytime, but you configure on each outpost how much you keep before sending back the train. If the train had not enough, it goes back to load. And depending on your condition, waits, or come to try and fulfill the request, over and over at the closest open outpost.

( sometimes all uranium patch request acid at the same time, too bad if you don't have enough the train will only refill the closest one).

[Edit: I realise the use of green signal is unclear, i should have used 2 different signals. You need a signal to open the station if you use decider wired on chest for quantities( signal O) , or you open the station when the quantity are negative and you write the negative quantity in a constant. that's one part. You use decider combinator wired on chests to make the train leave the station when quantities are met.( signal L)].

If you were to use multiple trains with such system, to avoid all of them trying to reach the same train stop as it open, you would need to use the limit system. Where OP's system requires neither enabling/disabling nor limiting incoming train.

[SoShootMe]

Yes it's simpler but it doesn't always function properly. Those are implementation details but consider the case of unloading sulfuric acid to a uranium patch. Most likely you can't unload 25K because you didn't wait for the buffer tank to run completly dry. So there is still some letft in the wagon, but you won't get inactivity because it will trickle down directly from the wagon as your miners consume acid. Same goes for material in limited chest. You'd fill it up entirely, but then everytime 1 get consume it will be refilled immediatly from the wagon. Thus preventing the train from leaving until empty, or consumption stops.

Yes, I see the problem. It applies in general, but for outpost supply/repair (other than sulphuric acid) consumption is "bursty" by nature so I'd expect it would normally stop. I've never noticed an issue, but inserter capacity might have saved me.

[Edit: I realise the use of green signal is unclear, i should have used 2 different signals. You need a signal to open the station if you use decider wired on chest for quantities( signal O) , or you open the station when the quantity are negative and you write the negative quantity in a constant. that's one part. You use decider combinator wired on chests to make the train leave the station when quantities are met.( signal L)].

For the "leave" signal, you can use the same principle as the negative constant combinator I described to call the train, by having the negative maxima in a constant combinator (magnitudes no higher than what can be buffered, eg chest limits) and the chest(s) connected to a decider combinator set to "everything > 0 -> L=1".

If you were to use multiple trains with such system, to avoid all of them trying to reach the same train stop as it open, you would need to use the limit system. Where OP's system requires neither enabling/disabling nor limiting incoming train.

The OP's system needs the limit (and/or a stacker) at each item source instead, in case several outposts need supplying at the same time.

[mmmPI]

for outpost supply/repair (other than sulphuric acid) consumption is "bursty" by nature so I'd expect it would normally stop.

True, i made previous observations in game only when scaling the system to production ressources and not just side-supply. The only side-supply i see potentially escalading dangerously is fuel to flame turret with a tank wagon, you don't want your wagon to stay at an outpost that's constantly under attack and ignore others because 25K will be drained in a very long time .

For the "leave" signal, you can use the same principle as the negative constant combinator I described to call the train, by having the negative maxima in a constant combinator (magnitudes no higher than what can be buffered, eg chest limits) and the chest(s) connected to a decider combinator set to "everything > 0 -> L=1".

True, I haven't thought of that because i tend to also use the color signal to light up a lamp .

The OP's system needs the limit (and/or a stacker) at each item source instead, in case several outposts need supplying at the same time.

sorry but i'll be picky on this one It doesn't need the limit if it has a stacker in the central location. Sure the stacker would need to be big enough to hold all outpost train. But you'd need only 1. Whereas with the system i described, the need for stacker would be in every outpost , big enough for every ressource train. And it could force the whole herd of train to repath elsewhere for 1 single outpost closing. (in the worst case where it was the only one opened).



I'd compare op's system to an ice cream purchase, where you'd make a precise list of the specific quantity and flavour of ice cream you want, you write them on a paper , bring it to the ice cream store. You hope /make sure the loading ice cream store station understand that paper, and then will give you the ice cream if they have it. Then you go back home with your paper and your ice cream. While in the other system you call the ice cream truck. And you hope it has the ice cream you want in correct quantity when/if it arrives.

The store need a big parking ! potentially for all customers. But it's still better than each customer having parkings for a dozen ice cream trucks .

The virtual items may not be necessary because it is unikely that an outpost requires so many different item that you coud not use the remaining to code them. ( that's 50%).
But the more different item needed per outpost in general the trickier it gets to create a uniform standard for encoding request. However different train stop serving different purposes can utilize differents set of item for encoding the request like a copper plate could mean a turret for defense outpost, and a turret mean a copper plate for a green circuit factory. The green circuit factory doesn't need turret, nor do you need copper plate to defend. (making sure the ice cream store understand the paper should be ok:) ).

[gGeorg]

Yes it's simpler but it doesn't always function properly. Those are implementation details but consider the case of unloading sulfuric acid to a uranium patch. Most likely you can't unload 25K because you didn't wait for the buffer tank to run completly dry. So there is still some letft in the wagon, but you won't get inactivity because it will trickle down directly from the wagon as your miners consume acid. Same goes for material in limited chest. You'd fill it up entirely, but then everytime 1 get consume it will be refilled immediatly from the wagon. Thus preventing the train from leaving until empty, or consumption stops.

shortened

The key is find a proper condition.
Here is my simple acid&uran train setting:
Train is LCC. e.g. one cargo and one fluid
Mining train station has a condition: Leave on item count Uran = 2000
Processing station has 2 conditions:
Leave on item count Uran = 0
AND
Leave on item count Acid >2000

Route is A, B
No mods, no wires, no waste routes.

This simple setup makes sure, you carry enough acid to the mine to be able to come back full of uran.