[Train GUI] Circuit condition progress bar

[DrParanoia]

Hi there!

EDIT and TL;DR;
In the situation on the image the <Copper plates> circuit signal should be used to draw a progress bar instead of simply being "all or nothing" since there is no reason it should be different from the "Cargo" leave condition.


OP:
First of all - LOVE THE NEW UPDATE! Great work!

Now to the point. In your blog post, you've stated "Circuit condition - Here we just show nothing or full, as we can't really know.". Though it really makes me wonder why?

For example, I am connecting all my chests to a Train station and setting the "departure" condition to "<Iron ore> >= 19200" and I can't shake off the feeling that there should be a progress bar, but there isn't one Is there any reason why this can't be implemented? Thanks a lot!

[Pi-C]

For example, I am connecting all my chests to a Train station and setting the "departure" condition to "<Iron ore> >= 19200" and I can't shake off the feeling that there should be a progress bar, but there isn't one Is there any reason why this can't be implemented? Thanks a lot!

Basically, the train station is waiting for one signal (e.g. "If Iron ore >= 19200 Then output GREEN") which it forwards then to the train. However, this one signal is all it will ever see, and it's the output of a black box. There could be dozens of combinators processing different inputs and checking for a number of conditions! You just have no solid basis for displaying a progress bar. It's just like a weather forecast saying that tomorrow, the temperature at your location will be between -5 °C and +43 °C, and there will either be snow, rain, or bright sunshine: I'm willing to bet that this forecast is completely correct -- but it is also completely useless.

[DrParanoia]

Basically, the train station is waiting for one signal (e.g. "If Iron ore >= 19200 Then output GREEN") which it forwards then to the train. However, this one signal is all it will ever see, and it's the output of a black box. There could be dozens of combinators processing different inputs and checking for a number of conditions! You just have no solid basis for displaying a progress bar. It's just like a weather forecast saying that tomorrow, the temperature at your location will be between -5 °C and +43 °C, and there will either be snow, rain, or bright sunshine: I'm willing to bet that this forecast is completely correct -- but it is also completely useless.

I can see this happening only if you have let's say a "Decider combinator" before your station which outputs either 0 or 19200. But in my case, I have all my boxes connected directly to the station and the station has a "<Iron ore> >= 19200" condition.

In this case, every single value increment should be visible to the station and result in a progress bar. Basically what I am saying is that every value passed to the station can be used as a basis for the progress bar. And the only situation when the progress bar should have only two states (on or off) is when the station has a conditions "<something <= count>" or "<something >= 0|1" because in these cases you can't know the maximum number from which to count down (and even then if the connection is directly to the boxes, we should know the maximum amount they can hold). All station conditions like "<something> >= count" should be able do display a progress bar.

Of course I have no idea how it works under the hood and maybe there are some optimisations preventing this functionality.

[Pi-C]

I can see this happening only if you have let's say a "Decider combinator" before your station which outputs either 0 or 19200. But in my case, I have all my boxes connected directly to the station and the station has a "<Iron ore> >= 19200" condition.

In this case, every single value increment should be visible to the station and result in a progress bar. Of course I have no idea how it works under the hood and maybe there are some optimisations preventing this functionality.

Well, you have a rather simple setup (sorry, no offense meant), with only one condition to check. So I can see why you're disappointed that there is no progress bar. However, think of mixed-cargo trains. Say you already have 15k iron in your unloading chests. Now a train fully loaded with iron pulls into the station. It could fill the chests up to the limit you've set without problems, so a progress bar would make sense in this case. But instead of a train fully loaded with iron ore, there could be one with lots of copper and only 200 iron ore. After unloading all iron, the chests would hold 15.2k iron -- which is less than 19.2k. So the station will never signal that the limit is reached, and the train will wait forever because it never can fulfil the circuit condition.

While I agree that the most common way of playing seems to be using dedicated trains that only transport one good, there are people (myself among them) who do use mixed trains. So, how is the game to know your play style? That is something which is entirely unpredictable, so I think having only two states for the progress bar -- condition is/is not fulfilled -- is fully justified.

[DrParanoia]

Well, you have a rather simple setup (sorry, no offense meant), with only one condition to check. So I can see why you're disappointed that there is no progress bar. However, think of mixed-cargo trains. Say you already have 15k iron in your unloading chests. Now a train fully loaded with iron pulls into the station. It could fill the chests up to the limit you've set without problems, so a progress bar would make sense in this case. But instead of a train fully loaded with iron ore, there could be one with lots of copper and only 200 iron ore. After unloading all iron, the chests would hold 15.2k iron -- which is less than 19.2k. So the station will never signal that the limit is reached, and the train will wait forever because it never can fulfil the circuit condition.

While I agree that the most common way of playing seems to be using dedicated trains that only transport one good, there are people (myself among them) who do use mixed trains. So, how is the game to know your play style? That is something which is entirely unpredictable, so I think having only two states for the progress bar -- condition is/is not fulfilled -- is fully justified.

Non taken The setup is meant to be simple. Though your described situation is not related to the progress bar since it not filling is not related to having rules setup wrong (in my case I have a "Cargo: <Iron ore> <= 0" OR "Circuit: <Iron ore> >= 19200") which works perfectly but I really expected the "Circuit: <Iron ore> >= 19200" rule to display a progress bar to see which rule triggers earlier.

[GrumpyJoe]

The circuit condition schedule option itself is not a leave condition with a 0-100% scale, its boolean, either true or false.
Mr.Bool doesn´t know how much % away you are from 100% you, he just looks at a number and says its >= or <= or ==, compared to what number you gave him

But we have, now even visually displayed as a progress bar, the Item/Fluid Count and Full/Empty cargo options.

If you wanna use the circuit condition sent to the train to control it, but also a progress bar, you´d need a lamp display, but that wouldn´t even need to have effects on the train, as you could just display whats in the chests via the "other" cable (red/green)

[DrParanoia]

The circuit condition schedule option itself is not a leave condition with a 0-100% scale, its boolean, either true or false.
Boolean doesn´t know how much % away from your 100% you are, it just looks at a number and says its >= or <= or ==, compared to what number you gave it

But we have, now even visually displayed as a progress bar, the Item/Fluid Count and Full/Empty cargo options.

If you wanna use the circuit condition sent to the train, you´d need a lamp display, but that wouldn´t even need to have effects on the train, as you could just display whats in the chests via the "other" cable (red/green)

Every leave condition is a boolean in the end. But I fail to see how Circuit condition (unless from a combiner with an output of 1) is different from the "Item count" condition in terms of displaying progress.

[Pi-C]

The setup is meant to be simple.

I acknowledge this. The point is, however, that somebody has to program the game and the GUI, and they have to do it so that all cases are covered, be it really simple setups or complicated ones, with lots of combinators and conditions to check.

Like I mentioned in my first post: The station (and thus, the train) will only receive one signal that comes out of a black box. There is no way for the game developers to know what people will put into this black box -- it may be as simple as "If TrainID > 0 Output GREEN", but it could also be lots and lots of combinators crunching different numbers. In simple cases, progress could be predicted with a certain accuracy; in more complex ones, that is impossible. If I see a progress bar that gradually grows, I will assume that progress can be measured -- and I will be disappointed if it stops forever because some condition cannot be met. So saying "I definitely know when your train will leave, even though my guess is probably wrong" is worse than saying "Sorry, I really can't know when your train will leave". The second is what the developers have done when they decided to make the progress bar binary instead of gradual for circuit conditions. It may be a bad decision where only simple setups are concerned, but it is fair and honest when you have to account for all possibilities.

However, we are in Factorio! If the GUI is limiting you, you can try to work around it. What do you expect from the progress bar, after all? It is just an indicator, a visual aid, a GUI element. Your train will leave once it's unloaded. If you want to see how much space is left in the buffers, just hook up a few lamps and combinators to the chest and program them to light up in different colors, depending on the fill state. If that is too complicated, there are mods like Nixie Tubes where you just connect the tubes to the chests and get to see some real figures.

[GrumpyJoe]

and thats the point, technicly there is no difference in signals, so if you absolutely need a progression bar, why not use that?
Its just that one is for external control, the other reads the train content, without cables

You could wait for condition
"Fish<=Red"
AND
A(default accu signal)>=Y(robo network output)

While these still would be somewhat comparable to eachother (see, this game is so awesome, you can compare apples with oranges ), why bother?
I mean, why bother with trains specificly, you could ask for a scale in every combinator GUI you opened, and it doesnt stop there.

Just pointing out that you gave no reason why this would be favorable over the existing item/fluid/timepassed scales we just got.
looking at the suggestion template

[DrParanoia]

I acknowledge this. The point is, however, that somebody has to program the game and the GUI, and they have to do it so that all cases are covered, be it really simple setups or complicated ones, with lots of combinators and conditions to check.

I fully understand what you are saying, however, even if there are tons of combinators before the station, in the end the final signal will have a value right? The progress bar is not time based it's value based. So the progress equals to (100 / <target value> * <circuit value>). It does not matter how many combinators you have, you only need to display the progress bar relative to the information you have.

In worst case, you will have the result as it's currently implemented (ON or OFF) but in all other cases, you will have a progress indicator base on current signals sent to the stations (and yes, even if it moves backwards it's still a good progress bar).

You don't need to know what is happening in the entire network, you only need the values that are sent directly to the station and display the progress based on those.

[DrParanoia]

While these still would be somewhat comparable to eachother (see, this game is so awesome, you can compare apples with oranges ), why bother?
I mean, why bother with trains specificly, you could ask for a scale in every combinator GUI you opened, and it doesnt stop there.

Because Train GUI is currently being reworked in the 0.17 branch and I am suggesting some improvements while it's not released.

[Pi-C]

I acknowledge this. The point is, however, that somebody has to program the game and the GUI, and they have to do it so that all cases are covered, be it really simple setups or complicated ones, with lots of combinators and conditions to check.

I fully understand what you are saying, however, even if there are tons of combinators before the station, in the end the final signal will have a value right? The progress bar is not time based it's value based. So the progress equals to (100 / <target value> * <circuit value>). It does not matter how many combinators you have, you only need to display the progress bar relative to the information you have.

The thing is, you seem to assume that only circuit network conditions on that one particular station are relevant. In my last game, I tried to implement a train-on-demand setting. All stations had the same name, and all trains shared the same schedule. If a station had produced enough of an item to load an entire train AND if there was demand for that item somewhere on the network, it would order a train it could load into. Now it might happen that a train was routed there that had no space -- or only part of the space -- left. Checking simply for "Train > 19.2k iron ore" wouldn't work in this case, because some of the space might already be occupied. I don't quite remember the details, but I had to check for lots of conditions when a train pulled into a one-cargo-only station -- and for even more if the station was meant to receive different goods. So I had, indeed, to take all circuit network signals on my train network into account.

It would even be possible to account for entirely unrelated stuff! Say your train is at an outpost deep down in biter territory. You have a whole lot of miners powered by a local solar farm to prevent the biters from cutting off power by destroying power poles, and the outpost is surrounded by walls, with laser turrets close behind. In case of an attack, you switch off all the miners because all power should go to the lasers. Now, you don't want your train to travel with all those precious ores right into the battle area. So you set your station to check for "Train is fully loaded AND miners are connected to power" before you send the train on its way. If the miners have no power, it means there is a battle ground near the outpost -- thus, whether the train can go or should wait would depend on a condition completely separate from how much load it carries. However, you can't really know how many biters will be out there -- so how would you measure progress in that scenario?

[DrParanoia]

However, you can't really know how many biters will be out there -- so how would you measure progress in that scenario?

In this case, if your circuit is providing a value of 0 when the power is on and 1 when the power is off the progress will simply be as it is now (ON or OFF). But imagine if you had let's say 5 different circuits connected to the station, and the rule is set to "Circuit: <whatever signal> >= 5" then the progress will be displayed from 0 to 5 (0% to 100%) based on how many signals you send.

[Darinth]

Note: I've not played with the most recent update as of yet.

It seems like several of you want to over-complicate the scenario. Yes, trains cannot realistically look to the entire circuit network beyond themselves to see all of the computations that go into sending a signal. Thus, when a train or train station is only receiving a boolean value for 'Go or don't go' you can't display a progress bar. We know this. We accept this. We can move on from that point.

Just because the trains cannot display a progress bar in such situations, doesn't mean a train cannot display a progress bar for other situations. If a train has a circuit condition set on itself for 'Iron ore >= 19200', and that's the only condition on that circuit, the game could display it. I can think of no reason that it couldn't work. Now... as for whether or not it's worth Wube's time to implement... that's a bigger question. I have to acknowledge, I'm not sure I actually care about the progress bars to begin with. But I do understand that they made it in because someone wanted them there... and so it makes sense that the progress bars be displayed where they realistically can, and this is a situation that they realistically can.

[DrParanoia]

Note: I've not played with the most recent update as of yet.

It seems like several of you want to over-complicate the scenario. Yes, trains cannot realistically look to the entire circuit network beyond themselves to see all of the computations that go into sending a signal. Thus, when a train or train station is only receiving a boolean value for 'Go or don't go' you can't display a progress bar. We know this. We accept this. We can move on from that point.

Just because the trains cannot display a progress bar in such situations, doesn't mean a train cannot display a progress bar for other situations. If a train has a circuit condition set on itself for 'Iron ore >= 19200', and that's the only condition on that circuit, the game could display it. I can think of no reason that it couldn't work. Now... as for whether or not it's worth Wube's time to implement... that's a bigger question. I have to acknowledge, I'm not sure I actually care about the progress bars to begin with. But I do understand that they made it in because someone wanted them there... and so it makes sense that the progress bars be displayed where they realistically can, and this is a situation that they realistically can.

Exactly my thoughts. Though the thing is, that since they've already made the decision to rework the train GUI and added progress bars for it, currently it looks like a bug, since the data is definitely there, but the progress bar simply flicks when the condition is met, which is counter intuitive.

[Ranakastrasz]

Note: I've not played with the most recent update as of yet.

It seems like several of you want to over-complicate the scenario. Yes, trains cannot realistically look to the entire circuit network beyond themselves to see all of the computations that go into sending a signal. Thus, when a train or train station is only receiving a boolean value for 'Go or don't go' you can't display a progress bar. We know this. We accept this. We can move on from that point.

Just because the trains cannot display a progress bar in such situations, doesn't mean a train cannot display a progress bar for other situations. If a train has a circuit condition set on itself for 'Iron ore >= 19200', and that's the only condition on that circuit, the game could display it. I can think of no reason that it couldn't work. Now... as for whether or not it's worth Wube's time to implement... that's a bigger question. I have to acknowledge, I'm not sure I actually care about the progress bars to begin with. But I do understand that they made it in because someone wanted them there... and so it makes sense that the progress bars be displayed where they realistically can, and this is a situation that they realistically can.

And past that, I see so no reason why that "Go or Don't go" couldn't be a comparison like Iron ore >= 19200 is. After all, the circuit could send a value which is compared, and used for a progress bar, instead of a boolean.

[Pi-C]

Note: I've not played with the most recent update as of yet.

Neither have I come to the stage yet in my new game where I could control trains via combinators.

Just because the trains cannot display a progress bar in such situations, doesn't mean a train cannot display a progress bar for other situations. If a train has a circuit condition set on itself for 'Iron ore >= 19200', and that's the only condition on that circuit, the game could display it.

If I remember correctly from a past FFF, trains can check the amount of a certain cargo, and a progress bar will be displayed in this case. But displaying a progress bar for a circuit condition is something entirely different because -- as said before -- you're trying to look into a black box there.

So, progress bars are meaningful and should be displayed for every condition except circuit network conditions.

Sorry, work to do for now -- I'll check back later!

[DrParanoia]

If I remember correctly from a past FFF, trains can check the amount of a certain cargo, and a progress bar will be displayed in this case. But displaying a progress bar for a circuit condition is something entirely different because -- as said before -- you're trying to look into a black box there.

So, progress bars are meaningful and should be displayed for every condition except circuit network conditions.

Sorry, work to do for now -- I'll check back later!

It is a black box if you try to look into the circuit network, but it shouldn't be a black box if you're just looking at the numbers that are passed directly to the station.

[Pi-C]

Waiting for the next delivery, so time for the forum again.

For example, I am connecting all my chests to a Train station and setting the "departure" condition to "<Iron ore> >= 19200" and I can't shake off the feeling that there should be a progress bar, but there isn't one Is there any reason why this can't be implemented? Thanks a lot!

Reading your first post again, could it be that our whole discussion circles around a big misunderstanding? My impression was that you want to unload a train and wait until the boxes have >19.2k iron ore. For this, you really would depend on the circuit network, and that is where the whole black box concept comes into play. Now, I have the feeling that you want to wait until the train has a load of 19.2k iron ore -- is that correct?

In that case, I don't think you need any combinators at all. Again, I haven't arrived at the point yet where I have circuit-network-controlled trains in my new game. But according to FFF 279, you can set a waiting condition on item count:

Wait condition visualisation

One of the things I always missed in the Train GUI was an indication of how much longer the train going to wait in the station. After some discussions, we decided to give visual feedback to all reasonable conditions by gradually changing the style of the condition frame to green as if it was a progress bar.

The question is, how do we calculate the fraction of completeness for individual type of wait conditions?

• Elapsed time - The most obvious one, as it is known how much time the train has spent in the station, and how much more is remaining.
• Inactivity time - Also simple, similar to elapsed time.
• Inventory full - We can calculate the fullness of individual cargo wagons and average it.
• Inventory empty - Simply (1 - fraction of full)
• Item count - Here it starts to be tricky. If the comparator is > (greater than) or ≥(greater or equal than), we just calculate the amount of that item and divide it by the goal. If the comparator is anything else, I can't show a progress. I know how far I'm from the goal, but I don't know what to compare it to, so in this case, we just show either not completed at all, or fully completed.
• Fluid condition - Basically the same as Item count.
• Circuit condition - Here we just show nothing or full, as we can't really know.

Is that what you've actually been looking for?

[Darinth]

Waiting for the next delivery, so time for the forum again.

For example, I am connecting all my chests to a Train station and setting the "departure" condition to "<Iron ore> >= 19200" and I can't shake off the feeling that there should be a progress bar, but there isn't one Is there any reason why this can't be implemented? Thanks a lot!

Reading your first post again, could it be that our whole discussion circles around a big misunderstanding? My impression was that you want to unload a train and wait until the boxes have >19.2k iron ore. For this, you really would depend on the circuit network, and that is where the whole black box concept comes into play.

Still not a black-box scenario. Black box would be circuits do analysis and send a boolean condition to the train when it's ready to leave. At that point, the train doesn't actually receive any meaningful signal outside of a 0 or 1 so to speak for stay or leave. That's a black box, the train never actually receives a signal that it can display a progress bar on. But, if on the other hand, the train is receiving a signal for quantity of different materials (Lets say it's instead a depot, and this is a supply train dropping off magazines) if the train is set to leave when the depot has 1000 magazines, if the magazine count is being sent directly to the train via a signal, the train can actually have a condition to wait until magazines >= 1000 and a progress bar could be displayed on that.