Smart Train Deliveries with Combinator Magick [0.13/0.14]

[Pajamas]

Huge thanks to Sigg, Choumi and everyone else in this thread. This is the kind of rewarding challenge that really helps keep the game interesting for me. Definitely interested in whatever you come up with for .13 now that we have an updated mod to play with.

[siggboy]

There still are bugs in SmartTrains and in Vanilla 0.13 that prevent any real games from happening.

For example there's a completely showstopping bug that makes a train leave the station when you place or remove a rail anywhere on the map... stuff like that (not related to SmartTrains, it's a Factorio bug).

I'm currently testing the setup in a sandbox 0.13 map and making some adjustments that use the new features of SmartTrains. Then we'll have to wait for the dust to settle and when I've got it working on a real map without issues I will finally publish the documentation for version 2 that I've promised for so long.

This really would not be happening without Choumiko's dedication to his mods, and his motivation to keep everything up to date and eliminate bugs. I'm just messing around with a few combinators and waffling about it here.

[DemiPixel]

For example there's a completely showstopping bug that makes a train leave the station when you place or remove a rail anywhere on the map... stuff like that (not related to SmartTrains, it's a Factorio bug).

I believe that got fixed in 0.13.5

In the mean time, I figured out a way to make this setup work in Vanilla. It's a bit clunky, but it does indeed work. I'll probably make a video on it some time before Friday.

[siggboy]

Yes it's fixed now, it all works in 0.13

But I'm currently reworking everything to make it more compact and elegant. I'd like the outpost circuits to be a bit smaller, probably I can make everything smaller while adding functionality, we'll see.

In the mean time, I figured out a way to make this setup work in Vanilla.

So, every time you add a new train, you add every single outpost in the exact order required to the train schedule? Is that what you mean by "clunky"?

I'm very interested to see what you've come up with.

[DemiPixel]

Yes it's fixed now, it all works in 0.13

But I'm currently reworking everything to make it more compact and elegant. I'd like the outpost circuits to be a bit smaller, probably I can make everything smaller while adding functionality, we'll see.

In the mean time, I figured out a way to make this setup work in Vanilla.

So, every time you add a new train, you add every single outpost in the exact order required to the train schedule? Is that what you mean by "clunky"?

I'm very interested to see what you've come up with.

It would be easy to copy the scheduele from one train to another...

But that would be horrible because every train would have to go to every station! The best you could do is that every train goes to every station and stops for 0 seconds at each one. Nah, I've got something a bit better...

[siggboy]

How? I'm extremely curious now, can you throw us a bone here? Please.

BTW good point about copying the train schedule, I've used SmartTrains for so long I've even forgot that's possible. Just that it would still be impractical because trains will be all over the place and you don't want to wait for each and every one of them to appear in the depot just so you can update the schedule. And then you'd forget one and things go haywire.

[DemiPixel]

If there are multiple stations with the same name, a train will go to any station that does not have a train there (if possible).

[siggboy]

Yeah, I think I understand what you did. Lovely idea.

The Pigeonhole Train Scheduler.

I guess it will work in practice, it might even perform well due to reduced latency.

A couple of thoughts on downsides:

• If things go wrong, disaster recovery will be a nightmare.
• Makes it hard to see what's going on (in FatController and on the map) due to identical station names.
• Requires a lot of trains (that's acceptable as it comes with an upside, too).
• You need manual records of station numbers, external to the game, since making a mistake in this area can be really painful (see point 1).
• It's practically impossible to direct trains manually (to pick up ore, or dump cargo from a misdirected train); anything out of the ordinary will be difficult to impossible.

Probably all these systems can be adapted to use the pigeonhole principle.

Interestingly, if we get the ability to disable train stations, the pigeonhole scheduler (that is possible now already) will probably still be better because it will perform better.

[DemiPixel]

Makes it hard to see what's going on (in FatController and on the map) due to identical station names.

Well, all trains do the same thing, though!

In reality, it's a cheap hack, but it would likely work xD

[siggboy]

While the system is running smoothly, it's a great system. After all, it does what is supposed to do (deliver resources).

However, as soon as things go south, you're in hell, because untangling that mess is not easy.

I speak of experience, I actually played a real game with my own scheduler where I liberally spread my base all over the map (decentralized), and in some cases things just didn't go as planned, and it wasn't always easy to get the system back into a working state.

With the Pigeonhole Scheduler it would have been way, way harder, usually to the point where loading an old save and avoiding the problem would have been easier (and that's cheating ).

[DemiPixel]

While the system is running smoothly, it's a great system. After all, it does what is supposed to do (deliver resources).

However, as soon as things go south, you're in hell, because untangling that mess is not easy.

I speak of experience, I actually played a real game with my own scheduler where I liberally spread my base all over the map (decentralized), and in some cases things just didn't go as planned, and it wasn't always easy to get the system back into a working state.

With the Pigeonhole Scheduler it would have been way, way harder, usually to the point where loading an old save and avoiding the problem would have been easier (and that's cheating ).

I'm confused as to why things would go south and that would ruin the system...?

[siggboy]

"Things going south" means "shit happening".

There are all kinds of reasons why the system might be thrown off-balance, you just have to put the wrong station number into an outpost and then not notice it for a while and suddenly all your train are half-full with iron ore and half-full with coal.

Then the fun begins.

A lot of stuff looks good on paper but in practice the caveats start to appear one after the other.

I think the Pigeonhole Scheduler is a great idea and probably good enough in many cases.

[DemiPixel]

"Things going south" means "shit happening".

There are all kinds of reasons why the system might be thrown off-balance, you just have to put the wrong station number into an outpost and then not notice it for a while and suddenly all your train are half-full with iron ore and half-full with coal.

Then the fun begins.

A lot of stuff looks good on paper but in practice the caveats start to appear one after the other.

I think the Pigeonhole Scheduler is a great idea and probably good enough in many cases.

I'm very confused. Could you possibly describe the pigeonhole scheduler, because I don't think we're talking about the same thing...

[siggboy]

Here's would I would do it:

All provider stations get the same name ("Provider").
All requester stations get the same name ("Requester").
The depot, which can be only one station (no multi-lane) gets the name "Depot".

The leave conditions on the various stations are circuit conditions that need to be calculated by the scheduler, at the moment they will all be "false" (trains will remain at the stations).

Now you need to send a train to all of the stations, so they will be all occupied.

The train schedule for all trains is "Provider -> Requester -> Depot".

Now if you want to make a transport from Provider P to Requester R, you need to release the train at R (it will go to the depot). Station R will now not be occupied anymore, and it will be the only station that isn't occupied. Next you release the train at P (assuming that it is already loaded). This train will want to go to R, because its the next station name in it's schedule, and R is the only station with that name that is not occupied.
It should now be safe to release a train from the depot, and it should take the place of the train that has just left P.

Choice of P and R, and timing everything correctly will be done by the scheduler.

The stations still need a "number" or other unique identifier, so you can address them, and you're missing some input that Vanilla does not provide (but SmartTrains does), such as cargo contents, and if there's actually a train at the station. Some of it you can infer but that's another layer of hacks.

If your timing is off, or you remove a train by accident or you set the station numbers incorrectly (you need a list on your desktop to keep track of all the number, all the stations have the same name, it's very easy to make a mistake here), and for all other kinds of reasons, then your trains will go to the wrong target, or trains will leave the stations when they shouldn't, which will trigger a domino effect. The trains will then proceed to load stuff they shouldn't and unload it where they shouldn't. It's going to be a perfect storm of hellcrap.

BTW I'm calling it the pigeonhole scheduler because of the Pigeonhole Principle: https://en.wikipedia.org/wiki/Pigeonhole_principle (that principle does not really apply to the scheduler, but the pigeonholes somehow do).

[Nexela]

I am impatiently for V3

[siggboy]

I have a version 2 with resource counting (at the requester stations) that works in 0.13. It also added multi-lane depot support.

I can post blueprints for that if you want something to play with in 0.13.

The rework I'm currently working on won't add new features, but I'm trying to make the circuits at the outposts smaller (even if that means I have to make the depot a bit larger). Right now I have 17 combinators at the provider, and that's little too much for my taste. The requester needs 12 combinators, which is still acceptable.

The depot is now at over 30, but some of it is due to multi-lane depots, which is kind of optional, and also it doesn't really matter how big the depot is; it's only built once and usually not in the way of anything (like loading belts).

In my rework I also want to make sure that providers can provide more than one resource at the same time, which will reduce the number of stations that you need to build when you make a distributed factory. It could also be useful for low-throughput mining outposts that are close to eachother, especially if you play with custom ores that you don't need much of.

I think I'll test my current V2.1 setup (before the rework) in my sandbox and if everything still works I'll just post it here so you can play around with it; but it's not going to be the one that I'll be releasing to the front page and documenting.

[DemiPixel]

There is a more annoying but safer way to do it:

All stations have the same name, but you have two types of trains and four total stations:

Code: Select all

HOME
PICKUP
DROPOFF
TEMP

This is because you have two types of trains:

Code: Select all

Transporter
- Home
- Pickup
- Dropoff

Temp
- Pickup/Dropoff
- Temp

Every station has a one-diesel-locomotive temp train. Each station also has a tiny loop with a station called "Temp" on it. It immediately leaves when the signal for that station is called, freeing up the spot for the other train. The temp train will move to the "Temp" station. When the transport train gets into the station, it will make the current block's light go red, which sets the temp train off to the station again, making it stop immediately behind the transport train so it can fill it's place when it leaves. The transport train can leave when it's full, when time is up, or any other conditions you want to set.

My design stopped there (because I was just thinking about pickup at the time). I presume you'd do the thing where you send to the station the requester on a circuit. When it becomes time for the train to leave, it would instead be triggers by a circuit which would be called immediately after telling the temp requester train to leave.

Not sure if it's any better, and it's a bigger headache since you need more space for each station, but it seems like it could be easier because trains are only at a station if they need to be.

[siggboy]

This approach is probably less prone to breaking, but it still has enough serious downsides attached to it that nobody would probably consider it for a serious playthrough (maybe for a small setup, but then you don't need this fancy stuff anyway).

It's also ugly as hell, with the Temp trains and all.

The idea itself is neat, though -- and it shows that the 0.13 train stations are still missing some important features.

What we need is SmartTrains as a part of Vanilla, there's just no way around it (at least the part that allows you to save "train lines" as separate logical entities, that gives numbers to the stations so you can send trains directly to a destination; and also some useful OUTPUT from the train station, such as cargo contents, presence of a train etc.).

[NoriSilverrage]

Siggboy, Does your v2 system work in 0.13 or did the logic/station changes break it? I haven't tried loading it up yet cuz I'm scared.

[siggboy]

The circuit itself works fine, you only need to change the train station configuration.

You also need to use the latest version of everything, SmartTrains and Factorio.

The signal input still has to go into the lamp, but the circuit condition that makes the train leave is now handled by the train station, and it has to be added to the train schedule (if you use a circuit condition, if you only use basic stuff like full/empty that does not apply). SmartTrains does some migration to make that happen in old saves, but I have not fully tested it.

So for example, if you used the "empty" condition in SmartTrains in 0.12, you now have to set it in the train schedule (SmartTrains does not check this anymore, and the option is gone, since it is now handled by Vanilla).

In the depot train station you have to put a circuit condition on the train station, that is tied to the signal (on the lamp) becoming non-zero. At provider/requester you can use full/empty, respectively, depending on your setup.

It boils down to this: destination station number has to go on the lamp. The correct condition has to be set on the lamp (same as in 0.12, should be migrated for you). Leave condition has to be set in the train station itself; needs to be the lamp condition for the depot, and what you had before for the outposts.

I also recommend you remove and replace all the train stations manually, because it looks a lot nicer and the migration from SmartTrains can't make it perfect.

It's probably not going to work straight away just by loading/migrating a 0.12 save but the changes that are needed should be easy enough to make. I don't think anything in the circuit itself is incompatible with 0.13 (I'm not 100% sure because there have been so many bugs and stuff in SmartTrains and Vanilla that I never got the chance to do a "clean" migration test).