Factorio Forums

www.factorio.com
https://forums.factorio.com/

Train Detection in 0.14: First, some science

https://forums.factorio.com/viewtopic.php?t=32994

Page 1 of 1

Train Detection in 0.14: First, some science

Posted: Mon Sep 19, 2016 8:03 pm
by golfmiketango
Although in 0.13 we can now wire train signals to the circuit network, vanilla factorio has not (yet?) provided a documented means by which we can detect via circuit conditions whether or not a train parked at a given train station just "happened" to be there or is making a scheduled delivery. We can detect a train has turned a signal red, but the fact that it turned red could just mean a train was zipping by or was manually parked there or waiting for a train in front of it to get out of the way. This makes it quite difficult to orchestrate a plurality of nonstandard things we might want to automate at train stops

However, after playing with signals in various positions I noticed a few anomalies which I thought might be exploitable for distinguishing between a train that happens to be in front of a station "incidentally" and a train that is there as part of a scheduled delivery.

I set up a test rig to look into it these more rigorously; this post will document my findings.

First, I made a nice, slow 1-14-1 train that slowly ambles between four stations like so:
Station Map
The train's route instructions are:
  • go to the East Wye terminus and wait zero seconds
  • proceed to Demonstration Station and wait for five seconds
  • go to West Wye, wait zero seconds
As you can see, "Skippy" is not on the route at all, so on the way back to the East Wye, it slowly moves right through Skippy without stopping.

I then laid down some signals like so:
Test Signal Layout
Demonstration Station, to be clear, is the one on top; Skippy is the one on the bottom.

I have provisioned each of the stations with three signals: two as close as I could place them just before the station, and one as close as I could place it just after the station. Finally, I made a big oscilloscope to allow myself to visualize the pattern of data coming from the signals with tick-level granularity (this was inspired by Madzuri's recent twitch stream). Here's what the whole thing looks like:
Image of complete test rig
And here's a blueprint (nb: I am using test-mode mod but I have endeavoured to leave any non-vanilla items out of the blueprint):
Blueprint String of Test Rig
So without further ado, here are the results. I'll start with the visualizations and save any tldr prose for after the pretty pictures. Note that these are pretty damn huge animated gifs and may take a while to load in your browser. Also the forum may squish them if it thinks your screen is too small, so if you right click them in your browser and say "open image in a new tab" or something like that, you may or may not get a better light show.

Here is the scope showing the train approaching and docking at Demonstration Station:
Station Approach Visualization
Here is the train just barely leaving the same:
Station Depart Visualization
Finally, here is the train "blowing" (as you'll see, not the right word -- "creeping" more like) past Skippy on the way back:
Station Passby Visualization
What have we learned? Well, nothing super definitive, but in all my experiments, there were some identifiable patterns that occurred when a train docks at a scheduled stop which were not evident in other circumstances.

First, it is notable that the frontmost signal always stays green (this also makes perfect sense and could be achieved by manual control of the train). But I'm not sure this is the best thing to rely on to detect a scheduled train stop, because, if another train were leaving the station right in front of us, it could still cause that signal to be red.

Second, it is quite striking that just as the scheduled train docks at its scheduled stop, the middle signal transitions immediately from yellow to green. I think I have struck paydirt here. It may be possible to make this happen without a scheduled train-stop, but it would appear to be a pretty unlikely occurrence. Perhaps you'd need blow the train up, take a sudden manual turn, change the schedule, or remove a piece of track -- I have not tried super-carefully to rule out the possibility of false positives. By contrast, when the train blows past skippy, the middle signal behaves just like the other two, going from green to yellow to red.

Third, when the train leaves, the middle signal turns yellow for one tick, and then red. I've tested with a 2-0-2 train and the exact same thing happens.

So there you have it. In my next post, I'll show how these findings can be translated into a fairly straightforward combinator contraption which exploits these quirks to quite reliably detect whether or not a train is making a scheduled stop at a vanilla train station.

Re: Train Detection in 0.14: First, some science

Posted: Mon Sep 19, 2016 10:55 pm
by ssilk
Moved cause it is more above trains than circuits. :)

Train Detection in 0.14: HOWTO

Posted: Wed Sep 21, 2016 12:52 pm
by golfmiketango
In the following combinator build, I'm trying to codify the following business logic:

Criteria (ALL of which must be met) to decide a train has parked
  • The second signal before the train station is red
  • The signal directly before the station transitioned very recently directly from yellow to green
Criteria (ANY of which must be met) to decide a detected train has left the station
  • The signal directly before the station becomes red or yellow
  • The second signal before the station becomes green or yellow
The end result will be that the contraption "knows" when a train has automatically parked at the station, and indicates this by illuminating a lamp.

Physical Layout

Obviously the physical layout isn't terribly important. But I wanted to show the deciders unobstructed, first, as this picture with the wires in it probably is worth 1000 words or at least more words than I care to type.
Wiring Layout
Combinator Settings

Here's all the settings of the combinators:
Combinator settings
Blueprint String

As before, you should not need any mods to use it (that's the whole point of it).
Blueprint
Explanation for Humans, in plain CombinEnglish

The two deciders on the right test respectively for positive yellow and red, and both output green=1 when true or, to be more precise, was true, in the previous tick. Those outputs feed in together with the current-tick output from the signal next to the train stop, to left-hand decider, which also feeds into itself. So, due to this one-tick "lag", when the nearer-to-the-train-stop signal transitions from yellow to green, there are three green signals provided to the left-hand combinator.

So, if all three (the two right-hand combinators and the signal) output "green=1", then the one on the left outputs green=1 as well, which threatens to make green=4 via the feedback wire. But, since, in the tick after this one, the middle combinator will no longer output anything (because it's no longer got a yellow input in the current tick), the left-hand combinator still winds up with exactly three green inputs and stays active.

If either signal changes, the total number of green inputs to the left-hand decider will decrease, causing it to turn off. Note that the red wire is only connected to the left-hand combinator, and therefore contains green=1, not green=3, as can be seen on the lamp condition.

If we connected a green wire to it, instead, we would have to test for green=3 which is pretty weird, and then be careful not to send any garbage back on that wire that might confuse the system. Better not to do that. A good way to remind yourself of this is to keep it wired to a pole, as pictured, and to think of the pole as the output "pin" of the device, rather than the combinator itself.

The red-wire interface, as can be seen, is quite easy to consume: When a train is present, a green=1 will appear on the red wire; otherwise it will not output anything. If we wanted it on the green wire, it's preferable to flip the colors of all the wires, or else daisy-chain an extra ANY*1->ANY, to keep the wires isolated.

Caveats / Thoughts
The contraption is designed to avoid type I errors (false positives). It will probably never tell you a train is there, when it isn't, in my experience. But if we mess around with a train just before it reaches a scheduled stop, i.e., by playing with the "manual/auto" switch, it is easy to cause a type II error (that is, the contraption fails to detect the train, even though a train is, in fact, parked there). So in using this, we should design failsafe mechanisms (like time-outs on trains waiting at stations for this circuit to cause them to be unloaded) around the possibility of false negatives.

I think the science above suggests it will be hard to make a system that is immune to false negatives without causing a whole bunch of false positives, so this is not so much by design as necessity, or in the best case-scenario, some lack of creativity on my part which could be corrected.

Now that we know a train is at the station, it's not entirely clear what use the information really is. As may not surprise you, I did all this research and development for a reason: I wanted to use it for something. What that use was will be documented in an upcoming "show your creations" post I'll be making about some train load/unload designs I've been working on to improve my train delivery dynamics in early-mid-game.

Re: Train Detection in 0.14: First, some science

Posted: Fri Sep 23, 2016 11:16 pm
by Megatron
There is no distinction between a scheduled arrival or a manual stop. Using the train's speed wouldn't work because it might not have reached maximum speed for the deceleration to be uniform for each station.
One way to tell the difference is if the train reacts to signals sent to the train stop, which may quite complicately be achieved with setting up a test stop before the actual stop which sends a signal to the train to continue moving, which along with the other inputs from the train signals can be used to tell that it's on automatic mode. Although it can result in a false positive due to well timed manual driving.

Other than that, it's pretty easy to find out if a train stopped to load/unload (automatically or manually) in contrast to waiting for a signal to turn green. You just have to remove an item, preferably fuel from the engine and put it back. If that works then the train stopped at a station as scheduled, or manually.

Re: Train Detection in 0.14: First, some science

Posted: Sat Sep 24, 2016 6:42 am
by golfmiketango
Megatron wrote:There is no distinction between a scheduled arrival or a manual stop. Using the train's speed wouldn't work because it might not have reached maximum speed for the deceleration to be uniform for each station.
See my first post above -- there is a difference. When the train stops at the station although it is in front of the middle signal, that signal is green. This violates the normal rules of signaling.

Indeed, your assertion of "no difference" can be immediately disproven. Using the blueprint from my test rig, park a train at the stop using the automated driver. The middle signal will be green. Now, take all the fuel out of the train, so that it cannot move. Then, turn the train from automatic to manual mode. Even though the train does not move, and could not possibly have moved due to a lack of fuel, the signal will turn from red to green.

Grab my blueprint from the first post, and try it yourself. Or, watch the movies above, more carefully this time, if you are having trouble believing me.

Also, there are many different ways the information in my first post can be exploited -- the contraption in the second post is just one. But, I assure you, it does exist and it does work. Try it yourself! You may "in theory" be correct but that's like taking the urban legend that scientists have no mathematical model that explains the flight of bumble-bees and concluding: "bumble-bees obviously can not fly".

Re: Train Detection in 0.14: First, some science

Posted: Sat Sep 24, 2016 1:45 pm
by Megatron
golfmiketango wrote:See my first post above -- there is a difference.
Yes, there is of course a difference, thats why I had the probably silly idea with the test stop. The game does not use train stop points and breaking distance when in manual mode. But as I mentioned the approach speed matters.

Your system should actually not work, and it doesn't all the time.

Image

Here you can see the blocks used in your train stop.
The first signal separating block cyan and yellow.
The second signal yellow and magenta.
And the trainstop magenta and black.

If the train itself (the blue circle) passes the center of two blocks, the signal splitting/generating those blocks turns red. B and F mark start and end of a block, X does both, if a start and end point overlap.
A signal turns yellow if the "breaking point" (the small red circle in the front of the train) passes the center of two blocks.

In your setup, the breaking point first passes the center generated by the second signal (between blocks yellow and magenta) which turns the second signal to yellow. The breaking point then stops exactly between blocks magenta and black (generated by the train stop) while the train itself stops between yellow and magenta (generated by the second signal).

The problem is that there apparently is no exactly between two blocks.
In your specific test the breaking point overshoots the center where its stops, so the second signal loses its yellow condition, while the train itself stops short of the center. The second signal turns green.

But it should actually be either yellow or red but never green when the train stops.

I ran some tests with different approach speeds and indeed sometimes it does not turn green, but stays yellow as it should (or red, which I actually never observed).

Your "exploit" works probably because of rounding errors as I assume the trains location is stored as a floating point number.

I just made those few tests and unfortunately didn't come up with a solution to this. Maybe using signals in that specific way is the wrong approach.

PS: maybe not like the bumblebee, but more like newtonian gravitation. It somehow works, though not always, and nobody knows why without deeper understanding of the game mechanics. I mean universe :)

Re: Train Detection in 0.14: First, some science

Posted: Sat Sep 24, 2016 5:02 pm
by Megatron
Here is a, in my opinion quite dirty solution (I don't like the inserter stuff)

Image
Blueprint
It activates the inserter when the left hand signal turns yellow, and stores the result if the inserter manages to extract an item. The states get deleted once the right hand signal turns green (train leaves station or train just passes by)
It will not trigger when manually driven, because this won't produce a yellow signal. Neither does it trigger if a train just passes by or has to stop nearby, because the inserter can't take out any items.

Besides being ugly, there are a few flaws in this design though.
It won't trigger if the train arrives with no fuel left in it's storage.
It doesn't detect the trains departure, just when the train is far enough away for the right hand signal to turn green. (Means this signal isn't actually needed, but then the train's absence will be detected even later)

Re: Train Detection in 0.14: First, some science

Posted: Sat Sep 24, 2016 8:18 pm
by golfmiketango
Megatron wrote: PS: maybe not like the bumblebee, but more like newtonian gravitation. It somehow works, though not always, and nobody knows why without deeper understanding of the game mechanics. I mean universe :)
And, yeah, that actually is a more apt metaphor than mine.

Re: Train Detection in 0.14: First, some science

Posted: Sat Sep 24, 2016 8:46 pm
by golfmiketango
Megatron wrote:Here is a, in my opinion quite dirty solution (I don't like the inserter stuff)

Image
Blueprint
It activates the inserter when the left hand signal turns yellow, and stores the result if the inserter manages to extract an item. The states get deleted once the right hand signal turns green (train leaves station or train just passes by)
It will not trigger when manually driven, because this won't produce a yellow signal. Neither does it trigger if a train just passes by or has to stop nearby, because the inserter can't take out any items.

Besides being ugly, there are a few flaws in this design though.
It won't trigger if the train arrives with no fuel left in it's storage.
It doesn't detect the trains departure, just when the train is far enough away for the right hand signal to turn green. (Means this signal isn't actually needed, but then the train's absence will be detected even later)

Interesting, I will check this out later. I've seen those fuel tricks and don't love them either, but we have to work with what we've got. One thing I hate about it, (aside from the obvious aesthetic issue) is that it will fail to distinguish between a parked cargo train full of coal and an engine. If you can make a rule like "I will never put a tree (or a rocket fuel) in a cargo bay, and will only fuel my trains with trees (or rocket fuels)" then you can at least salvage the concept. But, as the demands on the user go up, the range of useful applications obviously declines.

Re: Train Detection in 0.14: First, some science

Posted: Sun Sep 25, 2016 3:30 am
by Megatron
golfmiketango wrote:One thing I hate about it, (aside from the obvious aesthetic issue) is that it will fail to distinguish between a parked cargo train full of coal and an engine.
I don't quite understand your reasoning.
The detection can handle any kind of fuel. The fuel will only be taken out of the engine, except one builds another station nearby, which is kinda stupid anyway.
If a train is manually parked there, the system won't trigger. If it's automatically, like waiting for an order, it doesn't matter as the train should have its own bay to wait in and therefore a distinct signal that orders the train to continue on it's journey can be used as an input to the already existing circuit as some kind of special case.

Just using it as a detection system, whether a train stops for loading/unloading does work.
It could well be used to stall a train, for instance if whatever it delivers won't be used as of now, or just to activate something that shouldn't be active as long no train is around (quite obviously).
I do like the "only do something when something has do be done" stuff, instead of some system working all the time even when there is nothing to be done.

Re: Train Detection in 0.14: First, some science

Posted: Sun Sep 25, 2016 4:37 am
by golfmiketango
Megatron wrote:
golfmiketango wrote:One thing I hate about it, (aside from the obvious aesthetic issue) is that it will fail to distinguish between a parked cargo train full of coal and an engine.
I don't quite understand your reasoning.
The detection can handle any kind of fuel. The fuel will only be taken out of the engine, except one builds another station nearby, which is kinda stupid anyway.
Well I still haven't looked at it further so I may be missing something. But generally, what stops that inserter from pulling coal from, let's say, a car that I accidentally left in front of it in a moment of inattention? Or a coal train's cargo wagon, that took some kind of wacky pathfinding detour and then got stopped waiting in a traffic jam a ways ahead of the inserter?
Megatron wrote: If a train is manually parked there, the system won't trigger.
Probably, this is what I'm missing: I don't see why not.

By which, I mean, not "I think it won't work," but, "I am literally ignorant of what you speak." :)

I'll take a look at it soon.

Re: Train Detection in 0.14: First, some science

Posted: Sun Sep 25, 2016 2:55 pm
by Megatron
golfmiketango wrote: Or a coal train's cargo wagon, that took some kind of wacky pathfinding detour and then got stopped waiting in a traffic jam a ways ahead of the inserter?
Yes, thats a problem. But then you just have to make the rails long enough so it wont ever stop halfway into the station. It would be a bad design anyway if a train would block the station while waiting for a signal.
golfmiketango wrote:
Megatron wrote: If a train is manually parked there, the system won't trigger.
Probably, this is what I'm missing: I don't see why not.
Because manually driven trains never set a signal to yellow, this only happens if the train is on automatic mode.
golfmiketango wrote: By which, I mean, not "I think it won't work," but, "I am literally ignorant of what you speak."
Just have a look at the train in debug mode, and be sure to set show_train_braking_distance and show_rail_segments, or maybe some more info if you wish. You can find out a lot about the mechanics then.

Re: Train Detection in 0.14: First, some science

Posted: Mon Sep 26, 2016 11:25 am
by siggboy
I like the scientific approach of both of you, but I'm wondering if this isn't a little overengineered.

Leaving aside the possibility of removing fuel for testing purposes (a solid solution that works but is a little ugly):

Wouldn't it be sufficient to check a signal immediately in front of the train station for "red", and then take a timer on a signal immediately after the train station and check if it stays green for a little while? That could only be the case if the train has actually stopped. The signal in front would start a timer and the signal after would reset it, and then your condition is for the timer to be above a threshold value (which is only possible if the train is not running through).

Also I don't really understand why we really have to strictly discriminate between a "scheduled" stop and a "manual" stop. If you're driving manually you can always run the train a little further than the train stop (if that is wanted to trigger some condition that indicates manual driver).

Re: Train Detection in 0.14: First, some science

Posted: Mon Sep 26, 2016 8:39 pm
by Megatron
siggboy wrote:I like the scientific approach of both of you, but I'm wondering if this isn't a little overengineered.

Leaving aside the possibility of removing fuel for testing purposes (a solid solution that works but is a little ugly):

Wouldn't it be sufficient to check a signal immediately in front of the train station for "red", and then take a timer on a signal immediately after the train station and check if it stays green for a little while? That could only be the case if the train has actually stopped. The signal in front would start a timer and the signal after would reset it, and then your condition is for the timer to be above a threshold value (which is only possible if the train is not running through).

Also I don't really understand why we really have to strictly discriminate between a "scheduled" stop and a "manual" stop. If you're driving manually you can always run the train a little further than the train stop (if that is wanted to trigger some condition that indicates manual driver).

For loading/unloading purposes it would make no difference whether it arrived automatically or manually. golfmiketango though wanted to detect exactly that. Probably to make the station act differently, as in a manually parked train should not be part of the network not getting loaded/unloaded.
One problem with the setup of signals in front and behind the stop is that the second signal might be red because of another train being in it's segment, or worse the train is blocked half into the station.
Or it could have a scheduled stop without loading/unloading. It's hard then to make a difference of a quick stop and a very slow passing train. To much awkward stuff could happen.

I assumed golfmiketango wanted to make it certain, consistent and that user interaction doesn't break anything. Like if the trainstop itself could send a signal (preferably with the train's contents as well), which would be quite a cool feature to add.

PS. Isn't overengineering a huge part factorio and it's amazing features, from automated oil processing to a combinator computer that can run factorio itself? Meaningful or otherwise. ^^

Re: Train Detection in 0.14: First, some science

Posted: Tue Oct 18, 2016 9:33 pm
by golfmiketango
siggboy wrote:I like the scientific approach of both of you, but I'm wondering if this isn't a little overengineered.
Well I have yet to say what my application is so, technically, you have no basis to think so :P. But in a vacuum, yes, these may well be over-engineered, especially given that they're able only to provide sloppy heuristic answers.

Others undoubtedly have other reasons for wanting train detection, but, personally, I'm getting my ducks in a row to concisely show the unbuffered train logistics design patterns I've been hacking on lately. These rely on a combinator-based "mutex" per-resource per-station, which (roughly speaking) FIFOs the flow of resources into/out of trains.

So, if two iron trains show up in a certain order, the first to arrive unloads entirely, and only once it leaves the station, does the second train start unloading. The particular designs are somewhat incidental (except one I'm pretty excited about) -- what I'm really hoping to emphasize is the broader (very simplistic) approach to backpressure and factorio economics that unbuffered train systems fit into, which is not novel -- quite the opposite -- but also not as celebrated and certainly not as well documented as it probably should be.
siggboy wrote:Also I don't really understand why we really have to strictly discriminate between a "scheduled" stop and a "manual" stop. If you're driving manually you can always run the train a little further than the train stop (if that is wanted to trigger some condition that indicates manual driver).
Sure, we don't. The underlying reason I focused on "manual" stops was mostly as a way to simulate train behaviors that might occur due to any number of mostly nonstandard situations (i.e.: traffic jams, track layout changes, out-of-fuel trains, etc) which might lead to false positives, potentially deadlocking the mutex and permanently arresting resource-flow through the FIFO. Unfortunately false negatives, which the above "detector" does suffer from, also threaten to cause major misallocations, but I have working countermeasures in place to ameliorate those problems at a tolerable cost.
Megatron wrote:I assumed golfmiketango wanted to make it certain, consistent and that user interaction doesn't break anything. Like if the trainstop itself could send a signal (preferably with the train's contents as well), which would be quite a cool feature to add.
Well, that too. I admit I have a pet peeve about getting my cargo bays jammed full of coal because I accidentally parked in front of an engine refueling bay while sorting out a traffic jam or temporarily parking a PAX train full of depot-extending supplies. But really, the main thing I need to avoid is deadlocks due to bogus phantom-train-arrivals which never phantom-depart. The manual vs. scheduled thing is just one type of false positive to worry about, but the main danger with manually controlled trains is, if we forget that we left them parked, since they won't depart when empty, the FIFO won't release the mutex, and resources would cease to flow. The whole thing could be made into a non-issue by implementing a failsafe that kicks in when resources cease to flow, but this requires distinguishing between non-flow due to backpressure and non-flow due to empty trains. As of now there is very little combinator logic and I'd prefer to keep it that way, and also minimize the amount of complexity built around limitations in factorio that probably get solved by waiting for 0.15 anyhow.

Also, it just so happens that as you say, Megatron, I could really use feedback on resources parked in a station. In my smart-trains modded builds, what I actually do is unload only that train at the station with the least amount of a given resource. A major objective -- perhaps the major objective -- of my design-pattern is to min-max a steady flow of resources to a given # of output lanes. To do this efficiently, I am endeavouring to minimize the time trains sit idle waiting to unload within the broader constraint framework I'm working with. Specifically, I think it's slightly more robust if I minimize the area under the curve i(t) = [# of empty cargo slots queued or parked at a train-unload depot at time t], which I do by (a) always unloading the train with the least cargo in it and (b) requiring as many unloading bays as there are trains scheduled to visit the station.

But that's a minor nit, since my trains are, by design, only making trips when completely full or completely empty. A literal FIFO would almost always give the exact same result or a functionally equivalent result.
Megatron wrote:PS. Isn't overengineering a huge part factorio and it's amazing features, from automated oil processing to a combinator computer that can run factorio itself? Meaningful or otherwise. ^^
Guilty as charged, perhaps. But, in my defense, it's definitely not crazy to want to know where a train is. Post-0.13 we have almost complete visibility and control, in the circuit network, regarding the movement of all resources, except when we put them on a train. Trains are now the only major circuit-opaque logistics process, unless we count production machines themselves, which is only a problem if we want to do something exceedingly "clever," which is not the focus of my design-pattern. The new train "leave" conditions are great, but they address a largely orthogonal set of problems; tasks like FIFO train unloading or dynamic train logistics are simply prohibitively difficult in vanilla factorio as of now.

Also to be clear, I'm not complaining, just stating why I went to this trouble. Indeed I am pretty sure the devs already plan to solve this problem for us sooner than later. So, to summarize:
  • Wanted to share bufferless train designs
  • Designs required circuit-controlled FIFO unloading which vanilla does not accommodate gracefully as of now
  • Wanted to provide some alternative to vanilla players without too much complexity
  • Whipped up the simplest solution I could think of that would allow vanilla players to approximate my design and documented it here.
Basically it's all a trick to create a hand-wavy way to be able to say "you can sort-of do this in vanilla factorio, see this big long thread or just use the mod until the vanilla game catches up with our pretty simple needs."

Re: Train Detection in 0.14: First, some science

Posted: Wed Oct 19, 2016 1:14 am
by Megatron
golfmiketango wrote: Also, it just so happens that as you say, Megatron, I could really use feedback on resources parked in a station. In my smart-trains modded builds, what I actually do is unload only that train at the station with the least amount of a given resource. A major objective -- perhaps the major objective -- of my design-pattern is to min-max a steady flow of resources to a given # of output lanes. To do this efficiently, I am endeavouring to minimize the time trains sit idle waiting to unload within the broader constraint framework I'm working with. Specifically, I think it's slightly more robust if I minimize the area under the curve i(t) = [# of empty cargo slots queued or parked at a train-unload depot at time t], which I do by (a) always unloading the train with the least cargo in it and (b) requiring as many unloading bays as there are trains scheduled to visit the station.
Now that's really overengineered. I think you have some game design wise constraints here. An efficient rail network might not be necessary because of the ore patches being rather close together (even for a massive factory). If you have a huge network there is no way you have control over a steady flow of materials, so you would end up using some sort of buffer anyway. A railroad network is not that expensive and there is no upkeep for idle trains so maximizing efficency is just not worth it, imo.
I like the idea of a railway but I believe it's kinda useless. If you have a map where all ressources are close together, you dont need one. If they are far apart but rich, a few trains are enough to satisfy anything you produce. And if they are sparse you would need to rebuild/expand endlessly all the time. I wish the game would somehow force me to use trains at some point.
golfmiketango wrote: Post-0.13 we have almost complete visibility and control, in the circuit network, regarding the movement of all resources, except when we put them on a train.
Maybe we have. For communication between stations, even if you had access to the trains contents, you would need a circuit network anyway, so by sending the amount you load into a train to your circuit network you could save that information. You might use one car to identify the train by loading/unloading a certain item, amount or combination of some.

A better interface between trains and circuit networks just has to be implemented some day, where you can send trains to stations via signals. Now it's just manually programming destinations. Thats not automation. I want to have trains constructed, deployed, programmed and sent on their way automatically. In my opinion, that's what Factorio is about and I hope to see that in future releases.

Re: Train Detection in 0.14: First, some science

Posted: Wed Mar 29, 2017 4:23 am
by Aeternus
Isn't the solution to this rather simple?
- If a train is making a scheduled stop at a dead-end station, the red signal signifies that the particular station bay is occupied. If somehow a train ends up on a dead end station it's not supposed to stop at, well... then you've got bigger fish to fry then detecting station occupation.
- If the station is not on a dead-end, make a signal just prior, and two just past the station. If the signal prior to the station is red but the first signal past the station remains green, you can assume that the train has halted at the station. If the second signal is also red, the train has moved past the station and is not stopping.

A combination of "Red >1" and "Green >1" of both signals should yield the desired result.
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited