Smart Train Deliveries with Combinator Magick [0.13/0.14]

[NoriSilverrage]

Could multiple depots work with something like a bitmask? Give stations a number then logical-AND that number with some bits that represent the depot(s) that should service the station, and have the depots filter the requests and availables they listen to based on that bitmask.

I was kind of wondering that as well. Didn't mention it earlier as I have no idea how it would work or how to build it and I don't like asking people to make things for me.

[jhyatt]

NoriSilverrage ,

i have 2 depots however i have rewired for a green bus on my 2nd depot. with the new system you don't need separate depots for your ore just separate unloading stations. I have 20 trains set to Depot 1 and they deliver Iron ore, Copper ore, coal, stone, iron plates and copper plates to separate requester stations. my 2nd depot uses the green buss and handles my oil.

[siggboy]

Alright, first of all jhyatt did exactly what I would suggest if you want two logical train lines for some reason (that implies having 2 depots, one for each train line).

Just using a green wire bus is by far the easiest approach, and it comes with zero downsides if you have the green wire running already. I do not know what jhyatt did to make the circuit compatible with a green bus, I assume he used drivers to recolor the wire, as suggested (because actually changing the circuits is very finicky unless you have diagrams or reverse engineer the whole thing).

Regarding the "bit mask" suggestion: I don't see how a bitmask or "AND"ing the values would help.

Here's a quick rundown of what actually happens on the red wire, so you can see what would be necessary to make this work with two separate depots and two separate train lines. This is now about the new version, with requester and provider outposts.

1. The depot polls all requesters for demand. While this search is going on, the providers will advertise availability of goods on the red wire.
2. A requester will be selected that does demand a product which is currently available at a provider. We can easily make this match because the providers are advertising their products.
3. The requester, and all the products that the requester is interested in, will be stored in a register, and the polling will switch to the providers.
4. Similarly to step 2, a provider will now be selected that does provide one of the products that are requested. We are guaranteed to find such a provider, because the requester selected in step 2 was already pre-filtered for available products.
5. When a provider has been found, it will be notified of an incoming train and it will store the station number of the requester, so that it can send the train there when it has done loading the product.
6. The protocol ends here, all registers in the depot will be cleared and the next train can be serviced.

How will you apply "bit-masks" to all the information that is exchanged that way? It is not possible. It is not enough to apply "bit-masks" to the station numbers, or use any other partition scheme. You also need to separate the actual information, about available products etc.

The only way I can think of is to run a COMPLICATED full-blown encoding of everything on the wire, and it would need to allow for signal being super-imposed (i.e. added) on the same wire without information getting lost.

Good luck with that, if you have a circuit with good documentation please post it here . (I'm pretty sure it can be done, somehow, but it will be very complex and maybe use more combinators than the entire depot uses right now.)

As you can see, it is more complicated that just having a "Yellow" polling signal and then having the information appear "magically" at the depot and outpost circuits. The red wire bus is 100% occupied by the depot and the protocol running on it. You cannot run the same protocol a second time, simultaneously, from another depot, even if you change the polling signal.

What you can do, is to put signals on the red bus that are not used at all by the depot circuit, but ONLY signals that are never used.

This specifically EXCLUDES any product that you need to advertise on the bus. If your red-wire train line needs to talk about "iron ore", or "plastic bars", then these signals are completely off-limits for any other protocol that you are running on the red bus.

You can make another protocol, for example to run a second train line, but then you need to change all signals to be distinct (also the special purpose signals, such as "requester chest", "provider chest", etc. in version 2).

It's certainly possible to run a second protocol on the red bus for handling oil barrels, but this then has nothing to do with the current setup (as long as you're careful enough to avoid collisions).

[Minichris72]

I see what you have done and it is very good but I just wanted to let you know that I have already made a simpler version of this system without any mods. Check it out and see what you think: viewtopic.php?f=8&t=24915

[siggboy]

I see what you have done and it is very good but I just wanted to let you know that I have already made a simpler version of this system without any mods. Check it out and see what you think: viewtopic.php?f=8&t=24915

Your system seems to aim at loading only "just enough" goods into a train. I'm afraid that doesn't really solve a problem because you still have to send the entire train to the destination, only it will be half-or-so-empty. What exactly is the point of that?

Maybe I'm missing something. You should write a shorter version of your article where you explain what you do, and why you do it, at a fairly high level (not "arrange 5 combinators like this, then connect 12 wires like so, and..." because that's not interesting or useful for understanding what's going on, at least not for me).

[Resom]

I think that I only understand about half of what you are saying. I will figure it out soon (once I play around with it for a bit). This is something I was trying to figure out how to do but was not able to..
So thanks.

Cheers,
Resom

[NoriSilverrage]

Well I just finished setting up my iron stations last night. Up to 23 stations on the depot so far. 14 trains; it's working quite well. I need a lot more mining outposts though. Only two of each, so that is my task tonight. I might have to increase that station limit...

[NoriSilverrage]

I'm liking this setup, but I've run into a couple issues.

One, for whatever reason, a provider station will say it has a train coming even though one was never sent. It will then sit in this state indefinitely. I've had this happen 2-3 times usually something i notice right after I load in. So I wonder if the signal has issue on loading the game?
Is there a "simple" way to see if there is really a train still coming? Or timeout or something..

Second, the following picture happens to me a lot...

stacking

Basically that station, a requester, says I want stuff and the depot sends a crazy number of trains out to fill it. It appears that it would send a least one train per provider. I didn't notice this at first as I had only 2 copper stations. But once I hooked up my iron I could see as many as 8 trains all trying to go to the same station.

Now I have no issue with 8 trains out and about, but all queuing up at one station isn't good. I actually had to set my requester limit to about 70% because it goes so far over.

That brings me to my final point. When two or more stations request the same resource, the first station in the order gets all the trains. They could all be sitting there, literally right next to the other requester and they are all going to the same one.
I was thinking that it'd be awesome to put some sort of "round robin" system in where it won't send two trains in a row to the same station. Another option if that doesn't work is some sort of configurable thing that lets use set the max number of trains servicing a specific station at a specific time. This would of course require a register at each requester, so maybe not ideal, but it would solve both point 2 and 3.

Anyway, overall the system is quite nice and I've been trying to tweak some points a bit. Really looking forward to 0.13 with the wire highlighting so I can try more stuff easily.

[siggboy]

I'm liking this setup, but I've run into a couple issues.

One, for whatever reason, a provider station will say it has a train coming even though one was never sent. It will then sit in this state indefinitely. I've had this happen 2-3 times usually something i notice right after I load in.

There's a bug in SmartTrains that causes this issue. You have to use the latest pre-release of SmartTrains, it does fix this bug and is a tremendous improvement over the older versions in other areas as well.

Second, the following picture happens to me a lot...
Basically that station, a requester, says I want stuff and the depot sends a crazy number of trains out to fill it. It appears that it would send a least one train per provider. I didn't notice this at first as I had only 2 copper stations. But once I hooked up my iron I could see as many as 8 trains all trying to go to the same station.

Now I have no issue with 8 trains out and about, but all queuing up at one station isn't good. I actually had to set my requester limit to about 70% because it goes so far over.

Yes, this is a problem with the current version, because it means the order fulfillment is very spiky.

It's important to note that on average, or in the long run, this is not a problem, because every requester will get their delivery eventually (if there is enough train capacity).

I still don't like the current behaviour, because it means that a lot of trains may be queuing up at the requester stations -- but I do not want to make waiting bays everywhere to avoid problems.

It's not too difficult to extend the circuit so this situation will be avoided. I'll post the extension soon (it will be compatible with the current version, so the upgrade can be made in a running game).

One thing you can do to avoid this happening too much, is simply by putting a hard, low, limit on the amount of stuff that gets buffered at the providers. So, for example, don't buffer 128k iron plates, only buffer 12k (one load of 4 wagons). Then you limit the delivery at the supply side. Lean, small buffers are a good thing anyway in most cases, but of course this is only a small fix and doesn't really solve the problem.

That brings me to my final point. When two or more stations request the same resource, the first station in the order gets all the trains. They could all be sitting there, literally right next to the other requester and they are all going to the same one.

I was thinking that it'd be awesome to put some sort of "round robin" system in where it won't send two trains in a row to the same station. Another option if that doesn't work is some sort of configurable thing that lets use set the max number of trains servicing a specific station at a specific time. This would of course require a register at each requester, so maybe not ideal, but it would solve both point 2 and 3.

Here's how I will solve all of these issues. Well, actually there are two options, an easy one and a slightly harder one, but we'll pick the harder one.

Easy option: Lock down the requester station until it has taken delivery. Pretty much exactly what happens right now with the provider stations, only at the other end. This would be extremely easy to implement, but it would be limiting in high demand situations. The latency between "depot" and "requester" is much longer than between "depot" and "provider" (obviously, since the route of travel is "depot -> provider -> requester"). The requesters with a high resource drain might simply run out of buffer in a high demand situation. (Numbers example: with LL-CCCC trains you can deliver 6k ore at a time; the latency between order and delivery might well be 120 seconds; if the requester uses more than 3k ore/minute then it will eventually run dry; not good for end-game bases).

(The easy option will already require a register at the requesters.)

Intermediate option (this is what I will implement soon): Count the amounts that will be delivered at the requesters. This is not as difficult as it sounds. The "easy option" above already requires us to notify the requester of an incoming train. We might as well send the complete information and tell the requester what it is going to receive (type and amount of resource, e.g. "6000 iron ore" or "12000 electronic circuit"). The requester will simply discount all the "promised" deliveries, ie. it will pretend the delivery has already happened. When a train arrives it will balance the books accordingly (e.g.: "10,000 iron ore are currently promised; a train with 6,000 iron ore arrives; afterwards 4,000 iron ore are still promised). It's not necessary to track which train will arrive with what. Only the total amounts of everything are interesting and they can all be kept in the same register. It won't be count perfect but it doesn't have to be.

The extension, as I have it in mind, requires that the provider knows how much will be loaded. That's easiest to achieve if you use a circuit condition to limit the loader at each provider (instead of the simple "leave when full" condition). In 0.13 I want to make a multi-product provider, so then this will be required anyway. I already have loader circuits in my current game, because it's more flexible in any case.

Anyway, overall the system is quite nice and I've been trying to tweak some points a bit. Really looking forward to 0.13 with the wire highlighting so I can try more stuff easily.

I will make new diagrams of the version 2 and update the description, that will make it much easier for others to make changes to the system. I will probably do this when I'm finished making the change described above.

[NoriSilverrage]

Ok that sounds great.
Updated to the prerelease smart trains version and it has been running a lot better so far. I got 14 trains setup and it's pretty great to see most of them running around doing their thing.

[siggboy]

Ok that sounds great.
Updated to the prerelease smart trains version and it has been running a lot better so far. I got 14 trains setup and it's pretty great to see most of them running around doing their thing.

It's possible to fuck things up, but the circuit itself runs without problems.

What still gives me a semi-boner is when I set up a new requester station, and connect it and after 1 minute a train arrives just as by magic and brings the correct items. It's so much fun.

I've managed to shoot myself in the knee when I didn't set the signal correctly in the SmartTrains configuration, and what happened was that the trains kept unloading (12000...) copper plates at the iron ore requester. That's extremely annoying to unravel . It's probably wise to only use filtering inserters at the requesters until things are running smoothly.

It also takes a bit of practice to get into the correct routine of setting up the outposts and requesters. It's not so great if you make a mistake with the station numbering or naming, that will cause a lot of train confusion (another reason to use filtering inserters where possible).

I'm using mnemonic names for my stations, as I have in the demo map: "(R-Cu) Smelting" is a requester for copper ore; "(P-PlB) Refineries" is an output of plastic bars; and so forth. That will keep the stations nicely sorted in the list, and it makes it easier to find a station if you want to send a train to a requester manually (e.g. after you need to dump coal from a train). The special stations (PAX etc.) get an "(A)", like "(A) Depot", "(A) Main Base".

Probably the best order after setting up a new station is this:

1. Give the station a name
2. Add the station to the supply line (important to add it to the END of the list, it's a shame this can't be enforced; super bad if you don't add it to the end because that changes all the station numbers after it...)
3. Note the number of the station
4. Set the number in the combinator
5. Configure the station in the line, if not done yet
6. Connect the red bus

It would be AMAZING if the train station could output the station number from the combinator. This would only make sense if the station is only on exactly 1 line. I have to ask Choumi if he can add that feature. That would make setting up new stations a lot easier and one could even change the ordering etc. and the system would not break. That would also make it easier to delete old (depleted) stations without reserving the numbers manually.

[Choumiko]

2. Add the station to the supply line (important to add it to the END of the list, it's a shame this can't be enforced; super bad if you don't add it to the end because that changes all the station numbers after it...)

It would be AMAZING if the train station could output the station number from the combinator. This would only make sense if the station is only on exactly 1 line. I have to ask Choumi if he can add that feature. That would make setting up new stations a lot easier and one could even change the ordering etc. and the system would not break. That would also make it easier to delete old (depleted) stations without reserving the numbers manually.

If i understand it correctly you might want to use the new Station mapping? When setup correctly the order in the schedule doesn't matter and once you have a depleted station: create a new one, give it the same number as the old, add it in the schedule, remove the old. That should be all i think.

Since i'm already outputting the line number, i could aswell output the station number (but which one if the station is in the line multiple times?) and/or the mapping number.

[kann_]

Since i'm already outputting the line number, i could aswell output the station number (but which one if the station is in the line multiple times?) and/or the mapping number.

Outputting the station number if the station in a single train line would be helpful aka save one constant combinator and some manual work. At least in my setup since I use one train line for everything.

I think the current system works ok. In these kind of circuit routing systems every station has a circuit number, which has to be equal with the station number. This can be very annoying.
In my case I use channel number 1 to 12 for storage depots and 21 to 60 for outposts, which means I need 13-20 as filler stations just to complete the schedule. I guess the station number is coupled with the schedule position out of convenience and honestly it is better this way. Setting each station number when placing the station would be also annoying.

Btw siggboy I can confirm this double arrival bug now. I realized that this caused some issues for a long time in my setup.

[siggboy]

If i understand it correctly you might want to use the new Station mapping?

The new station mapping is very helpful, but in this case it only makes it slightly easier to rearrange stations -- you still have to keep exact records about which station has which number, because a single mistake disrupts the entire system.

One could even say that having a non-standard mapping complicates things. It certainly does not solve the problem that you have to spell out the station number manually in a combinator.

When setup correctly the order in the schedule doesn't matter and once you have a depleted station: create a new one, give it the same number as the old, add it in the schedule, remove the old. That should be all i think.

Yes, that would work, but when I'm doing that I might as well add the new station in the place of the old; that would also preserve the numbering and re-use the number of the old station. The station mapping does not really solve a problem in this case.

Since i'm already outputting the line number, i could aswell output the station number (but which one if the station is in the line multiple times?) and/or the mapping number.

If the station is in multiple lines you'd output a "-1" or nothing at all (you could also output the negative count of lines that the station is in; but these sort of things end up not being used and are potentially confusing so I'd advice against it). Only output a station number if the station is in a single logical line (which should be easy to check and is not even a rare case; it's probably the common case). It would be important that the station number is output all the time -- not just when a train is at the station.

Of course you'd output a "mapped" station number if the player is using the remapping for that station. Basically you'd output the station number that we'd have to input as a signal if we want to go to that station.

BTW this feature would also make things like a "taxi" service easier to create. Put all the "PAX" stations in a taxi line, add the taxi train(s) to the taxi line. Then you can call the taxi to any PAX stations quite easily without having to set up the station numbers of the PAX stations. The taxi controller could very easily extract it from the combinator and send it to the PAX depot to call the taxi.

[siggboy]

Outputting the station number if the station in a single train line would be helpful aka save one constant combinator and some manual work. At least in my setup since I use one train line for everything.

It's the same for all these systems, for Xeteth's system it would be equally helpful (he also has to set the station number manually in a combinator, he shows it in his demo video).

The main reason why this would be good is not that it saves you some work (setting one combinator value is not a lot of work), but that it eliminates a source of human error. I always triple check the station number because it's so awkward if you mess it up and then have to manually re-arrange the trains to sort it out.

Btw siggboy I can confirm this double arrival bug now. I realized that this caused some issues for a long time in my setup.

Yes, it's not surprising me that it messed with your system as well. Choumiko was really, really fast in fixing it, though, actually quite amazing how quickly he figured out the root of the problem.

[Choumiko]

Since i'm already outputting the line number, i could aswell output the station number (but which one if the station is in the line multiple times?) and/or the mapping number.

If the station is in multiple lines you'd output a "-1" or nothing at all (you could also output the negative count of lines that the station is in; but these sort of things end up not being used and are potentially confusing so I'd advice against it). Only output a station number if the station is in a single logical line (which should be easy to check and is not even a rare case; it's probably the common case). It would be important that the station number is output all the time -- not just when a train is at the station.

I meant if a Station "A" is in a logical line more than once, which isn't really necessary for the kind of setup you guys are doing, but might be in some other systems. But then again, those probably don't need that signal anyways. So most likely it will output the first occurence of the station.

Yes, it's not surprising me that it messed with your system as well. Choumiko was really, really fast in fixing it, though, actually quite amazing how quickly he figured out the root of the problem.

TBH, i noticed the FlyingText upon arrival appearing twice way back, and always kind of new the reason, i just delayed fixing it, since then it didn't matter (as either signals weren't there yet or noone used them like you guys do now)

[NoriSilverrage]

I've been meaning to ask.. I noticed the flying text a few times in some demo systems, but I don't know how/why it is there. Is that a product of some specific configuration?

Siggboy, I just added a bunch of new ore outposts and man is it nice to just put in a number and name and voila insta ore. I do get trains queueing up a bit at the requester, but it does even out eventually. I wish I could have less requester stations, but with my setup I don't know if I could. Might have to look into that some more.

[jhyatt]

Here is the console command to enable/disable the flying text

/c remote.call("st", "toggleFlyingText")

[siggboy]

I meant if a Station "A" is in a logical line more than once, which isn't really necessary for the kind of setup you guys are doing, but might be in some other systems. But then again, those probably don't need that signal anyways. So most likely it will output the first occurence of the station.

Probably there is no really clean way of providing that bit of information in a combinator. It's a fairly advanced way of using the train stations, so I think it should be OK if that feature comes with some caveats (if you don't understand very clearly what it means and does, then you shouldn't be using it I guess).

Siggboy, I just added a bunch of new ore outposts and man is it nice to just put in a number and name and voila insta ore. I do get trains queueing up a bit at the requester, but it does even out eventually. I wish I could have less requester stations, but with my setup I don't know if I could. Might have to look into that some more.

The requester queues will go away when I get around to adding that extension that I have in mind. Right now I'm busy playing an actual game so it might be a few days. I don't want to release anything that might be broken.

About the number of requester stations: I'm using "mixed" requesters in a few places (with robot unloading). For example at the Rocket Parts factory it would be unreasonable to have a separate requester/unload for every single component. Currently I only have one requester for everything (copper, plastic, blue chips, speed modules, steel, ...) and unload it into provider chests and let the bots do the rest.

Dedicated requesters I only have for high volume goods where I want as many inserters unloading in parallel as possible (ores and plates, basically).

With 0.13 our possibilities increase, because the OP batch inserters will make bulk unloading a lot more powerful, and the ability to program the filter on the inserter will make it possible to have flexible providers that can provide several goods at once. That will probably reduce the number of stations that are necessary.

[kann_]

I lost a little bit track of the development here, but maybe it is relevant for this system. I try to optimize my circuits and make modules out of the big mess.

As a first step I worked on the train counter for 60 stations. I posted it in the multiplexing thread.

I managed to have a train counter using the green signal on the multiplexing bus and 7 combinators per station + a central memory cell.
My idea is that every stations send it own supply/depands together with the approaching trains. Than the real supply is caluclated by real_supply = supply - trains.