[MOD 0.15] SmartTrains 2.0.5

[siggboy]

Wow sounds really great.

This would mean the timetables are obsolete, because on demand a free train would scheduled just-in-time for duty.

Yes, the setup does not use the waiting time at all (all the trains "wait forever", everywhere, and only react to signals). But it's going to be even better, it will be a logistic network with trains, I just need to make that work with the current design because I do not want to start from scratch.

[janook]

I've never managed to make the "Depart" option work in my games. I think it's bugged. Somebody mentioned a few posts ago that "Depart" does nothing if you have a "Refuel" station but the refuel option is not enabled. Maybe you should change the name of your "Refuel" station in the settings, as that is supposed to fix it.

Regarding your oil problem: there's only one good way, and that is to make a combinator circuit that actually checks for oil availability and only then sends a train to the oil outpost. That's not easy to do, however.

If you want an easy solution, just have the train wait "forever until full" at the Dead Oil deposit. It's basically be a mobile oil tank that will go to your station when it's full. Of course that means your train will spend most of its time doing nothing, waiting around at the Dead Oil deposit. Not the prettiest of solutions, but it works.

By the way: you can put two small pumps on each side of the rail tanker, resulting in a flow of 120 oil/second. That fills a tank in 21 seconds.

Thanks for the response but I don't think this solves my issue; I don't have a refuel station at all! And, the standard "depart when full/empty" stuff does work as expected.
Thanks for letting me know about the double pumps! I don't think I have enough pumpjack throughput to need it but I'll keep that in mind.

[Choumiko]

I'm having a lot of trouble getting my rail tankers to leave stations that have low oil flow.

I have Min flow rate set all the way to 200 for testing but my rail tankers all still stay at stations for their full waiting period. The tankers are assigned to a line with "depart" checked.

The problem is that lines dont work with Depart (right now), i changed some things and nver bothered to test depart again
Since the fix is incredibly simple, here is an updated control.lua Just replace the one in the zip with it and it should work (untested).

The new SmartTrains version will have Depart as a new rule in the line settings and disable it for trains without a line (and i will test it this time )

[siggboy]

The problem is that lines dont work with Depart (right now), i changed some things and nver bothered to test depart again

LOL. And I was sure that I always did something wrong, because "Depart" never did anything when I tried to use it, no matter what. Thanks for the fix but I'll wait for the next version, the new UI looks really like huge improvement over the current one.

BTW, I have a question: how often do you poll the signal at the train stations? I've found that it's not possible to pulse (single-tick) input to the signal and have the train depart reliably. This can be a real burden because you have to work around that fact with registers to hold the input for the signal.

I've tested it and the station seems to require about 10 ticks until it reliably releases the train.

I also have a minor feature request: Can you add a "departed" signal that will pulse the number of the next destination when a train leaves? This would be useful to get a pulse when a train departs, and get the destination at the same time (it might be configured in the UI and not from a circuit, and then this would be the only way to find out where the train is going).

[Xeteth]

By default trains check for a signal every 12 ticks. You can change this setting by hitting the "ST Settings" button with a train GUI open. Be warned though - if you make this something like 1-2 ticks it will cause smart trains to use more processing power and may result in lag. I actually have mine set to 60 ticks as losing <60 ticks to a train is minimal in terms of throughput etc of trains.

[siggboy]

By default trains check for a signal every 12 ticks. You can change this setting by hitting the "ST Settings" button with a train GUI open. Be warned though - if you make this something like 1-2 ticks it will cause smart trains to use more processing power and may result in lag. I actually have mine set to 60 ticks as losing <60 ticks to a train is minimal in terms of throughput etc of trains.

It's not about the throughput. For my "Logistic Network of Trains" scheduler it's important that the system stays in sync -- because I not only send the train away but I also signal to the outpost that the train is incoming.

And it's a lot easier if you can work with 1-tick signals everywhere, because then you don't need to make registers to hold the signal until some condition becomes "true" (if you look at my current design there are several combinators that I could shave off if 1-tick signals did reliably work).

Furthermore, there's no direct, explicit feedback from the station along the lines of "the train has now left to station #n", it has to be implied/deduced from the fact that (a) train-at-station goes from 1-to-0 and (b) the signal that you've written to the station yourself.

I'd prefer a more explicit approach, even though my current design reliably works around these issues.

Lastly, it wouldn't even be enough if I made it "something like 1-2 ticks", the only thing that would help (compared to the current design) is if it's 1 tick exactly.

Thanks for pointing out that it can be changed in the settings, though, I haven't actually looked there (I actually thought about looking at the source code of the mod, LOL).

[Choumiko]

I also have a minor feature request: Can you add a "departed" signal that will pulse the number of the next destination when a train leaves? This would be useful to get a pulse when a train departs, and get the destination at the same time (it might be configured in the UI and not from a circuit, and then this would be the only way to find out where the train is going).

This should be possible i think, but not for the next release. There are already quite a few changes and when 0.13 hits i'll have to update again.

As Xeteth said, the signal is polled every 12 ticks per default.
It works like this (at least in the version i'm working on, but the key parts are true for the released one too):

• Train arrives at a station, if it's a smart one, it outputs the current cargo to the combinator and then it registers itself for cargo updates (updating the constant combinator) every 12 ticks
• It checks what rules are set, if only empty/full then it registers to check that rule every 2 seconds ("Interval for checks" in the settings), if signal is set it rechecks every 12 ticks instead of 2 seconds (also checks full/empty every 12 ticks then)

I did a quick test, and only testing whether a signal condition is fullfiled every tick makes the update time go to ~0.3 ms for one train. So ~ 54 trains at a smart station would take all the time you have for 1 tick without ups loss
That is without cargo checks, updating the constant combinator or getting the actual signal value. Depending on what the circuit network update brings in 0.13 some things might get cheaper to poll, but as i see it, the condition check itself is already as fast as it can get.

[siggboy]

I did a quick test, and only testing whether a signal condition is fullfiled every tick makes the update time go to ~0.3 ms for one train. So ~ 54 trains at a smart station would take all the time you have for 1 tick without ups loss
That is without cargo checks, updating the constant combinator or getting the actual signal value. Depending on what the circuit network update brings in 0.13 some things might get cheaper to poll, but as i see it, the condition check itself is already as fast as it can get.

OK, nice, awesome, thanks for the detailed information, it is exactly what I was wondering about.

The numbers above suggest that it would be no problem at all to at least make the signal check every tick, and thus make it possible to trigger a train departure with pulsed signals. This could then be the default behavior of the smart train station (I'd personally prefer that a lot over having to change a somewhat obscure setting to make certain circuits work).

All the other things you've mentioned don't have to happen every tick (e.g. updating cargo every tick would be unreasonable, since nobody needs that information at such a high resolution).


While I have your attention one other thing: When you deconstruct a smart train station with robots, then the two proxy objects (the combinator and the lamp) are not removed from the map. In fact, the only way to remove those is to replace the train station and remove it manually ("mine" it). If you can't do that there's no way to remove the proxy objects at all, without mods or console commands.

Do you think it's possible that the proxy objects will be removed if the thing is deconstructed with robots?

[Xeteth]

By default trains check for a signal every 12 ticks. You can change this setting by hitting the "ST Settings" button with a train GUI open. Be warned though - if you make this something like 1-2 ticks it will cause smart trains to use more processing power and may result in lag. I actually have mine set to 60 ticks as losing <60 ticks to a train is minimal in terms of throughput etc of trains.

It's not about the throughput. For my "Logistic Network of Trains" scheduler it's important that the system stays in sync -- because I not only send the train away but I also signal to the outpost that the train is incoming.

And it's a lot easier if you can work with 1-tick signals everywhere, because then you don't need to make registers to hold the signal until some condition becomes "true" (if you look at my current design there are several combinators that I could shave off if 1-tick signals did reliably work).

Furthermore, there's no direct, explicit feedback from the station along the lines of "the train has now left to station #n", it has to be implied/deduced from the fact that (a) train-at-station goes from 1-to-0 and (b) the signal that you've written to the station yourself.

This is true, in my current setup I send the signal to the smart station and once the train leaves it waits for a "train is at station = 0" return so it knows that the train is sent. I also need to register that a train has been sent (and where) so that it can be stored in memory cells to keep track of my trains. Here's a quick run down of how my system works, it sounds like you might have something similar but thought I'd share anyway;

1. 'Controller' decides that a train needs to be sent to an outpost (based on variables such as ore level etc) and stores this in a memory cell
2. The memory cell output gets bundled with the address of the outpost and this is sent to the train yard
3. A train receives the signal and once the train leaves a pulse is fired back to the controller
4. The controller is notified that a train has been sent and stores this in a memory cell
5. The pulse continues through the controller until it decreases the 'send train count' in the original memory cell

This all happens in less than 60 ticks, otherwise multiple trains would be sent when I only wanted one to be sent. Unfortunately I think we're always going to see at least some performance impact on entities checking for circuit network condition until they change the way the circuit network actually works in the game; that it would work on a 'push' mechanism rather than a 'pull' mechanism (ie. when the condition becomes true it tells all entities connected to it's output that something has occurred, whereas now every single entity checks every single update).

I agree with you though - if it were possible being able to make it tick perfect and work on single tick signals it would be much, much easier to do. Thankfully Choui has done a fantastic job of optimising Smart Trains so it might just be possible to do it this way

Anyway, if you're interested in seeing my build in action I put a short video together you might be interested in: https://www.youtube.com/watch?v=rF5tm0HbAGg

[Choumiko]

The numbers above suggest that it would be no problem at all to at least make the signal check every tick, and thus make it possible to trigger a train departure with pulsed signals. This could then be the default behavior of the smart train station (I'd personally prefer that a lot over having to change a somewhat obscure setting to make certain circuits work).

All the other things you've mentioned don't have to happen every tick (e.g. updating cargo every tick would be unreasonable, since nobody needs that information at such a high resolution).

Actually, i wanted to suggest that it would be a probelm I don't know the average update times for saves, but a save sufficiently big enough to warrant these SmartTrains setups probably has a Game Update time ~10ms ? (no mods, just vanilla). That would leave 6ms for script updates, which reduces the number of smart trainstops to ~ 20 before you experience UPS drops. Anyways, i'll try to make the individual updates as modular as possible, so that each interval can be adjusted as one wants.

While I have your attention one other thing: When you deconstruct a smart train station with robots, then the two proxy objects (the combinator and the lamp) are not removed from the map. In fact, the only way to remove those is to replace the train station and remove it manually ("mine" it). If you can't do that there's no way to remove the proxy objects at all, without mods or console commands.

Do you think it's possible that the proxy objects will be removed if the thing is deconstructed with robots?

It should be removed with the station, at least the event is registered to do so..

Unfortunately I think we're always going to see at least some performance impact on entities checking for circuit network condition until they change the way the circuit network actually works in the game; that it would work on a 'push' mechanism rather than a 'pull' mechanism (ie. when the condition becomes true it tells all entities connected to it's output that something has occurred, whereas now every single entity checks every single update).

That would do nothing for SmartTrain, i think you're describing how it works/should work internally.
I'd need an event that gets triggered when a lamp turns on due to a condition becoming true. Might actually request that, who knows..

Btw, i'm hoping that

Train Station - read the contents of the stopped train and control trains by disabling/enabling the station
Train Signals - still in the process of designing it. Basically be able to stop trains or see if a train is about to arrive

makes it into the first 0.13 release. This sounds like it could either make SmartTrains nearly obsolete or at least improve performance by a huge amount

[siggboy]

Anyways, i'll try to make the individual updates as modular as possible, so that each interval can be adjusted as one wants.

Well, it's not a huge, deal-breaking issue. It can be worked around with the use of registers to hold the input to the signal. I've already done it (and Xeteth, too, apparently). I just wanted to point out that it's -- a lot -- easier to deal with if you can pulse 1-tick signals into it reliably. It only matters if it is the default; if you have to set it manually to "1 tick" and then it comes with all sorts of strings attached ("will hurt UPS after 20 stations") then it's not worth making a change.

Do you think it's possible that the proxy objects will be removed if the thing is deconstructed with robots?

It should be removed with the station, at least the event is registered to do so..

Nope. If you "mine" the station by hand it gets all removed just fine. But if you deconstruct the station with robots (usually along with other entities), then both proxy objects will remain on the map (and they can't be mined, they only way to remove them is to reconstruct a smart train station on top and mining it).

Train Station - read the contents of the stopped train and control trains by disabling/enabling the station
Train Signals - still in the process of designing it. Basically be able to stop trains or see if a train is about to arrive

makes it into the first 0.13 release. This sounds like it could either make SmartTrains nearly obsolete or at least improve performance by a huge amount

It won't make SmartTrains obsolete at all, because the great and amazing things about SmartTrains are (1) the logical train lines and (2) the ability to direct trains via signals. Neither is going to be possible in vanilla 0.13.

[terror_gnom]

Can´t you set a internal Variable to the train station, that remembers the stationnumber (and #line) until a train leaves? Should be more easy in Lua than with combinators

When there is written a second number before a train left, just override the old one (or build them up in a stack, would be great, I dont like to build the register for several trains )

[siggboy]

in my current setup I send the signal to the smart station and once the train leaves it waits for a "train is at station = 0" return so it knows that the train is sent. I also need to register that a train has been sent (and where) so that it can be stored in memory cells to keep track of my trains.

Very similar to my circuit, except I don't store train destinations explicitely, instead I tell the destination outpost "you've got a train incoming", and that will "mute" the outpost so it won't advertise any resources for pickup until that train is done loading. I deliberately do not allow more than 1 train to be en route for an outpost.

Here's a quick run down of how my system works, it sounds like you might have something similar but thought I'd share anyway;

My system is somewhat different, please take a look at it here. It would be great if you could look at it, any sort of feedback is appreciated (my post has a very detailed explanation of the entire setup).

Importantly, my setup only requires about 15 combinators for the depot and about 10 combinators for each outpost. That's way smaller than what you've built. The circuits are highly optimized to save space, I don't use things like general purpose memory cells, it's more like custom hardware. I wanted to pack as much functionality as possible into a setup that I can still peddle to the "average player" who might be interested in such a setup but is not ready to put a lot of work into setting it up.

Now I have a lot of things to say about your project, and a lot of questions, I'll try to keep it short.

Most important:

1. Can we have a save game of this demo map (from the video)? It's the only way to understand it really, unless you have schematic diagrams (I suppose not, it's a ton of work to make those...)
2. Would it be possible to talk to you on Discord about this?

OK, now some thoughts after watching your video :

• Your demo maps are really staggering. I was quite amazed when I saw the trains tutorial video that you and ColWill made, because of how much work you put into the map. This is the same, very impressive.
• It's interesting that you actually used a solar farm for energy instead of just hiding a "test mode solar panel" or equivalent somewhere. And by making fake mining outposts with actual ore fields and mining drills you've firmly stepped over the "ludicrous line" . (That's not to say that it isn't very cute.)
• Distributing the train depot over many different stations is quite different from what I've built. You can handle many trains at once, but it seems to me you lose a lot of that advantage because you need to be careful not to send too many orders for the same outpost, and you have that 60 tick delay. In my setup I have only 1 depot, and all trains have to go through there, so there are no such problems. It would be interesting to figure out which approach gives better throughput, or if that never even becomes a concern on real maps.
• I think you've over-engineered the part that distributes the trains. Is it really necessary to make complex calculations involving resource flow so you're able to send several trains to the same outpost simultaneously? You're solving the problem of having to carry 1.5k ore per wagon-minute over a train distance of a minute, per outpost. That's a very extreme edge case. The outpost would need to mine 6k (200 mining drills) and be at least 60 seconds away (one-way) before you'd need a second train on that rail to pick up everything (that's for a 4-wagon train).
• Can your unloading stations request resources? Do you take resource demand into account? In my current setup I won't bring in resources that are not in demand by the factory, because that obviously wastes bandwidth and blocks trains. In my next version I also want to assign the unload stations dynamically to each train, so they would behave much like requester chests.
• You seem to use a lot of combinators, are those general purpose circuits (for example the memory cells)? Do you use any sort of CPU to make the various calculations?

I'll probably have to watch the video again and make a few more notes, it's a lot to chew on. Having access to the demo map in order to make experiments and reverse engineer would help a lot, though.

Thanks for posting it, it's a very interesting project.

[siggboy]

Can´t you set a internal Variable to the train station, that remembers the stationnumber (and #line) until a train leaves? Should be more easy in Lua than with combinators

When there is written a second number before a train left, just override the old one (or build them up in a stack, would be great, I dont like to build the register for several trains )

The mod would still have to check the signal condition every tick (because that's where the value that you want to buffer in an "internal variable" comes from). As I understand it, checking the signal condition once per tick might be a performance problem. Holding the target station number is not the real issue here.

[Choumiko]

It only matters if it is the default; if you have to set it manually to "1 tick" and then it comes with all sorts of strings attached ("will hurt UPS after 20 stations") then it's not worth making a change.

Yeah, i think i get what you mean. Still going to make the different things that need updating/polling seperate.

Nope. If you "mine" the station by hand it gets all removed just fine. But if you deconstruct the station with robots (usually along with other entities), then both proxy objects will remain on the map (and they can't be mined, they only way to remove them is to reconstruct a smart train station on top and mining it).

It seems to be fixed for the next release. Haven't tried removing more than the station in 0.3.82 version yet, i'll try that later.

Train Station - read the contents of the stopped train and control trains by disabling/enabling the station
Train Signals - still in the process of designing it. Basically be able to stop trains or see if a train is about to arrive

makes it into the first 0.13 release. This sounds like it could either make SmartTrains nearly obsolete or at least improve performance by a huge amount

It won't make SmartTrains obsolete at all, because the great and amazing things about SmartTrains are (1) the logical train lines and (2) the ability to direct trains via signals. Neither is going to be possible in vanilla 0.13.[/quote]
Probably true. I'm curious how they gonna make sure disabling/enabling train stations via the network doesn't leas to no path issues (e.g. disabling a trainstation while there still trains en route to that station and skipping it has them in a place where they can't get to the next one).

For pulsing the destination: Right now the combinator output gets set to nothing as soon (i.e. same tick) as the train leaves. I think if i set the destination signal 1 tick before it leaves that should be enough to create the pulse.

Side note: while working on the full/empty rules, i realized that currently it should be faster to implement them via a single combinator if you're dealing with 1 item type trains
I'm currently thinking of skipping updating the combinator if no wire is attached to it, since then there really is no use for it. Not sure how often a signal rule doesn't depend on the output from the combinator though. Any thoughts?Not possible right now.

[siggboy]

Probably true. I'm curious how they gonna make sure disabling/enabling train stations via the network doesn't leas to no path issues (e.g. disabling a trainstation while there still trains en route to that station and skipping it has them in a place where they can't get to the next one).

I've had a (short) conversation with Twinsen about these changes, and it appears to me that it's still very preliminary and he is still thinking about what to do exactly. So I wouldn't expect these changes in the first 0.13 release and I wouldn't take at face value what he's written in the FFF.

If you can actually disable stations they could still accept trains that are already on their way there. I don't think there would be pathing issues.

Generally I'm not a big fan of making these sorts of changes to the train stations because the entire train user experience needs a BIG overhaul. The current user interface is a disgrace, and things such as FatController and SmartTrains need to be part of the vanilla game (oh and FARL, too). My point is: they have to fix trains first and then they should add fancy combinator stuff.

Without your mods the train game in Factorio would be a big joke.

For pulsing the destination: Right now the combinator output gets set to nothing as soon (i.e. same tick) as the train leaves. I think if i set the destination signal 1 tick before it leaves that should be enough to create the pulse.

Yes, I'm doing edge detection to get a signal "train has left", this works fine, no problem there. The other information (destination) has to be deduced (it must be the value of the signal during the game tick when the edge detector triggers).

If the destination signal comes from somewhere else (e.g. you provide it on the combinator), it needs to still be present when the "train" signal is already "0" -- so, one tick longer than you suggested.

The edge detector does trigger during the tick when train-at-station is already "0", and it's only then that we can read the destination from the combinator, not earlier.

Having said all that: what I actually had in mind was a "train-leaving" signal that does pulse the destination (station) number for 1 tick exactly when the train has left. That would be the first tick when "train-at-station" is now "0" -- but it doesn't really matter in which tick you set it because if I can look at "train-leaving" I don't need to examine "train-at-station" at all.

In my opinion it would be most consistent to have it like this:

Code: Select all

Tick:               1 2 3 4 5
train-at-station:   1 1 0 0 0    (the "Train Signal" signal)
train-has-left:     0 0 5 0 0    ("5" is the station number)
other signals:      x x 0 0 0    (stuff like wagon count etc.)

(That's basically what I've described above.)

[terror_gnom]

Can´t you set a internal Variable to the train station, that remembers the stationnumber (and #line) until a train leaves? Should be more easy in Lua than with combinators

When there is written a second number before a train left, just override the old one (or build them up in a stack, would be great, I dont like to build the register for several trains )

The mod would still have to check the signal condition every tick (because that's where the value that you want to buffer in an "internal variable" comes from). As I understand it, checking the signal condition once per tick might be a performance problem. Holding the target station number is not the real issue here.

Ahh, I thought the real problem is the train checking the where it´s journey will go... Is lua that slow compared to the C implementation of the combinators?

[siggboy]

Ahh, I thought the real problem is the train checking the where it´s journey will go... Is lua that slow compared to the C implementation of the combinators?

LUA is extremely slow compared to C.

If you write a mod that needs to do something at each game tick, then 60 times per second the game engine needs to "call back" to your LUA code, so you can run your function.

Checking the signal at the train station requires just that. Even if you do nothing except check the signal condition for "true" or "false", the game still has to call back into your script each tick -- and that's way slower than just doing things inside the game engine (the "C implementation").

[Xeteth]

My system is somewhat different, please take a look at it here. It would be great if you could look at it, any sort of feedback is appreciated (my post has a very detailed explanation of the entire setup).

Importantly, my setup only requires about 15 combinators for the depot and about 10 combinators for each outpost. That's way smaller than what you've built. The circuits are highly optimized to save space, I don't use things like general purpose memory cells, it's more like custom hardware. I wanted to pack as much functionality as possible into a setup that I can still peddle to the "average player" who might be interested in such a setup but is not ready to put a lot of work into setting it up.

That's actually a really neat and simple setup, well done! I like how you essentially 'mute' an outpost that has a train incoming; that is certainly easier than using memory cells and having a system calculate trains based on the data. Your setup (as you mentioned) is certainly much simpler and could be used by other players who don't really have an understanding of combinators quite easily. I am glad you have decided to do it this way; it shows the devs (Twinsen in particular) that adding certain functionality that is in Smart Trains could be adapted and integrated into the base game and allow players to come up with automated train systems without getting too complex.

One question I have though; is there a way of you detecting when an outpost has run dry and needs to be removed (and a final train sent to empty the outpost)? I'm guessing the idea is that the player would take a disposal train of sorts and just manually get the last remaining ore which is not a huge issue.

I have a lot of things to say about your project, and a lot of questions, I'll try to keep it short.

Most important:

1. Can we have a save game of this demo map (from the video)? It's the only way to understand it really, unless you have schematic diagrams (I suppose not, it's a ton of work to make those...)
2. Would it be possible to talk to you on Discord about this?

1. I am currently finishing off the system, there's a little more work to do on it but I intend to release it to everyone once it is finished - I'll let you know when it's done
2. Sure! You can find me on Colonelwill's discord server here, I'm always up for talking anything Factorio - https://discord.gg/0kerBVfUSMlHuoqz

• Your demo maps are really staggering. I was quite amazed when I saw the trains tutorial video that you and ColWill made, because of how much work you put into the map. This is the same, very impressive.
• It's interesting that you actually used a solar farm for energy instead of just hiding a "test mode solar panel" or equivalent somewhere. And by making fake mining outposts with actual ore fields and mining drills you've firmly stepped over the "ludicrous line" . (That's not to say that it isn't very cute.)

Thanks! I find it much easier to work with large scale combinator systems when I just have a free space and purpose built world to deal with. I actually have a blank concreted world scenario saved for any future projects haha

• Distributing the train depot over many different stations is quite different from what I've built. You can handle many trains at once, but it seems to me you lose a lot of that advantage because you need to be careful not to send too many orders for the same outpost, and you have that 60 tick delay. In my setup I have only 1 depot, and all trains have to go through there, so there are no such problems. It would be interesting to figure out which approach gives better throughput, or if that never even becomes a concern on real maps.
• I think you've over-engineered the part that distributes the trains. Is it really necessary to make complex calculations involving resource flow so you're able to send several trains to the same outpost simultaneously? You're solving the problem of having to carry 1.5k ore per wagon-minute over a train distance of a minute, per outpost. That's a very extreme edge case. The outpost would need to mine 6k (200 mining drills) and be at least 60 seconds away (one-way) before you'd need a second train on that rail to pick up everything (that's for a 4-wagon train).

The main reasons for having the large distribution station is for both train throughput (as multiple trains can be sent in quick succession) and because I play with the RSO mod I require a large number of trains as the resources are vastly spread out and travel distances are quite large. Due to using RSO the 60 tick delay is basically negligible as the train travel times are quite long anyway; but it would be awesome (and much easier) to make a single tick based system as previously discussed. It is most likely that the majority of time outposts will only have 1-2 trains being assigned at any given time, but I have specifically designed the system to allow for a buffer of resources at the main rocket factory by using my smart unloading system (details below) which is why I have such a large train yard. These features are mainly the result of the system being built for an RSO map; they are likely very much over-engineered for a vanilla map.

• Can your unloading stations request resources? Do you take resource demand into account? In my current setup I won't bring in resources that are not in demand by the factory, because that obviously wastes bandwidth and blocks trains. In my next version I also want to assign the unload stations dynamically to each train, so they would behave much like requester chests.

The main map I am implementing it on is a multiplayer map with ColWill and the others in the Factorio Engineer group with the main goal being to launch as many rockets as possible; so resources are always in demand. As such the unloading stations don't really take resource demand into account; it's more assumed that we always want a lot of resources so we always want to be bringing in those resources from the mines. There are multiple unloading stations for the main factory due to the high resource demand and I have come up with a system that dynamically ensures that incoming trains distribute each load to the unloaders as required. Here's a short video of this in action (sorry no sound). You can see that the trains are waiting in the stacker until the resource count in the unloader drops below a certain threshold and it 'requests' a train load from the stacker. This allows us to keep a buffer of resources in the trains that are waiting in the stacker and that they are distributed as needed. This was just a first draft of the unloader, I need to make it a bit neater and I am sure I can remove a few unnecessary combinators when I go over it again.
There is a set limit to how many trains of each resource type can be active at any given time (15 by default) which ensures that you don't end up with 60 iron trains or 60 copper trains etc and this limit is easily adjustable within the controller.

• You seem to use a lot of combinators, are those general purpose circuits (for example the memory cells)? Do you use any sort of CPU to make the various calculations?

The main controller part uses a lot of combinators, most of which are the memory cells which hold the information for each outpost. These are structured using a data bus to read/write the various data to the appropriate cells as required. The rest of it (in particular the 'brain' part in the top left box) is mainly based off the use of clocks that cycle through the various data and perform 'tests' on the data. When a test passes (ie. a train needs to be sent) it jams the clock whilst it sends the train and increases the train count; before the clock is unjammed and can continue cycling through the data and performing the tests on each outpost. Note that I have absolutely no prior knowledge of computer science and have taught myself a decent amount of basic computer science throughout learning combinators (with the help of some fantastic people in the community I might add!) and as such there is probably more elegant or simple ways of achieving what I have come up with. I love seeing other setups and how they work as I find there are always multiple ways of implementing these kinds of setups (check out Hoefni_X's Smart Trains setup, it's also very awesome!).

Thanks for the kind words! It was a great read going through your post about your system. I'll keep you updated on my progress; I'm hoping to be finished with my system in the next week or two at most

[siggboy]

That's actually a really neat and simple setup, well done! I like how you essentially 'mute' an outpost that has a train incoming; that is certainly easier than using memory cells and having a system calculate trains based on the data.

Thank you for your kind words. I don't want to count trains in my system because I think it does not give enough benefit for the complexity that is involved.

I am glad you have decided to do it this way; it shows the devs (Twinsen in particular) that adding certain functionality that is in Smart Trains could be adapted and integrated into the base game and allow players to come up with automated train systems without getting too complex.

That's an interesting aspect, I actually never thought about motivating the devs into any direction while I was designing it. I just wanted something simple enough that I myself will still be able to understand it 6 months later :), and something simple enough so I won't end up being the only person using it -- and then, of course, there's some beauty in compact designs.

As far as "convincing Twinsen" goes: I think he's doing a great job with the combinator stuff, but he needs to realize that the combinators are used quite differently from what he, or the devs, imagined. In order to solve interesting problems, you need to make circuits, and making circuits is artificially hard because the combinators were created to solve "simple" problems; but nobody solves "simple" problems with combinators, there aren't any. Right now, combinators are either almost useless, or potentially very powerful but only if you invest a lot of time into understanding the quirks. A huge gap as far as player experience goes.

One question I have though; is there a way of you detecting when an outpost has run dry and needs to be removed (and a final train sent to empty the outpost)? I'm guessing the idea is that the player would take a disposal train of sorts and just manually get the last remaining ore which is not a huge issue.

Nah, I don't want to add bells and whistles like that, it's really out of scope. Detection of mining deposit depletion can easily be done separately, and since you have to go there yourself in order to deconstruct the outpost, not much is gained by making it automatic like you've outlined. (Plus, since I'm using the resource monitor mod I don't need separate detection.)
Of course it's fun and interesting to solve this particular problem with a circuit, I just don't consider it part of a logistic train network.

1. I am currently finishing off the system, there's a little more work to do on it but I intend to release it to everyone once it is finished - I'll let you know when it's done :)

Awesome, looking forward to it.

2. Sure! You can find me on Colonelwill's discord server here, I'm always up for talking anything Factorio - https://discord.gg/0kerBVfUSMlHuoqz :)

That's great!

Thanks! I find it much easier to work with large scale combinator systems when I just have a free space and purpose built world to deal with. I actually have a blank concreted world scenario saved for any future projects haha

Yeah, I've made such a "sandbox map" as well, it's just the best way if you have to fiddle with complicated stuff like combinators (and also for anything train related).

These features are mainly the result of the system being built for an RSO map; they are likely very much over-engineered for a vanilla map.

Well, I'm playing with RSO myself (never completed a serious playthrough without it), but even then it's not easy to hit a throughput limit with mining outposts (at least not with the standard mining drills, with Bob's Mods it's something else).

I can live with the fact that, at some point, very, very late in my game, it might be possible that a large outpost will be distant enough so that a 4-wagon train won't be enough to allow the outpost to mine at full speed. It's fine. I'll just add another outpost then instead of solving that problem the hard way :).

Having said that, your bases are ginormous... so... the usual rules don't really apply :).

There are multiple unloading stations for the main factory due to the high resource demand and I have come up with a system that dynamically ensures that incoming trains distribute each load to the unloaders as required. Here's a short video of this in action (sorry no sound).

There's sound, I can hear somebody (you?) breathing :).

I have to admit that I don't really understand the point behind the unloading concept. As far as I can see, the trains (waiting on the stacker before the unload) are basically buffer chests. Why not unload them as quickly as possible, maybe balanced among the unloading stations?

If there are several trains (with ore in them) waiting on the stacker, that means you've picked up too many goods from the outposts, and now you've effectively reduced your total train bandwidth because those trains are forced to idle; and you need infrastructure (such as the stacker) to handle the situation.

You can see that the trains are waiting in the stacker until the resource count in the unloader drops below a certain threshold and it 'requests' a train load from the stacker. This allows us to keep a buffer of resources in the trains that are waiting in the stacker and that they are distributed as needed.

Why are you buffering the resources in trains, in a stacker? So they are closer to the unload when you finally need them? Is that even a problem with a large enough buffer at the unload? The buffer can't suddenly run dry, prompting an "emergency" train delivery, can it?

Maybe I'm missing something here.

There is a set limit to how many trains of each resource type can be active at any given time (15 by default) which ensures that you don't end up with 60 iron trains or 60 copper trains etc and this limit is easily adjustable within the controller.

As far as I can see, as long as the system only delivers goods "on request" (or "on demand" if you will), no such arbitrary limits are necessary (and no stacker at the unload is necessary either).

There's another player here on the forums, kann_, he's actually made a system that does train requests and deliveries much like the robot logistic network (reddit post is here: https://www.reddit.com/r/factorio/comme ... _provider/). I want to make my own system work like that as well.

With such a system, in your case, your various unloads would request a set amount of resources. Given that you have constant demand for the rocket manufacturing, you make your unloads (the "requesters") demand enough so there will always be a healthy buffer.

The trains will service these demands (from the various outposts, which are arbitrarily picked and act like "passive provider chests"). As long as the demand is met, the resources are not even considered for pickup. The situation that you have "too many" trains carrying a single resource type is not even possible then, unless you don't have enough trains to begin with. And it won't be possible for trains to "pile up" in front of the unload, because that would mean that way more resources are delivered than have been requested.

Or am I missing a crucial aspect of your map/factory here? (As I've said your bases are so big I can't even imagine some of the challenges that must pose.)

The main controller part uses a lot of combinators, most of which are the memory cells which hold the information for each outpost.

Does that mean you use 1 memory cell per outpost? So your outpost count is limited by the amount of memory at the base?

Note that I have absolutely no prior knowledge of computer science and have taught myself a decent amount of basic computer science throughout learning combinators (with the help of some fantastic people in the community I might add!) and as such there is probably more elegant or simple ways of achieving what I have come up with.

To be honest I don't think computer science knowledge is that useful when it comes to combinator designs. I have a strong (university-level) background in CS, albeit not much experience in hardware design, and it really doesn't help that much when learning this.
Classic electric engineering knowledge, especially, does more harm than help -- combinators don't work like traditional logic circuits.
It helps to know some concepts, such as signal buses, multiplexing, that will make it easier to come up with practical solutions, but beyond that it won't help much.

There are some areas that are arcane enough that you basically have no chance to figure it out unless you have a solid CS background. For example, if you know how signed integers work in low-level computer programming, and if you are aware of the fact that this is exposed in the arithmetic combinators, it opens up possibilities for advanced designs.

Other than that what you actually need is talent and the ability to abstract and think logically. You're probably talented and very smart, otherwise you couldn't have built all this. Problem solved, no CS degree required :).

I love seeing other setups and how they work as I find there are always multiple ways of implementing these kinds of setups

Yes, the possibilities are endless, it's important to get others' designs for inspiration.

(check out Hoefni_X's Smart Trains setup, it's also very awesome!).

Yes, very interesting going by his stream description. I have to write to him on Twitch and see if he can give me a demo map or blueprints or something.

Thanks for the kind words! It was a great read going through your post about your system. I'll keep you updated on my progress; I'm hoping to be finished with my system in the next week or two at most :)

Yes please do, I like the shows you're doing on YouTube, I've yet to join your twitch stream. It's very entertaining and I'm looking forward to seeing the train network in action.