I setup the simple loading station below for the train I use to build rail and destroy nests I findwa. I setup simple logic to read the train's supplies and wired the inserters to only load when the train's load is less than a certain amount.
But every time the train stops at the station it seems to load a few extra items. Is there a bug that makes the signal from station to inserters too slow so that the inserters start loading before being told by the the logic that it should not? Or is there a flaw in my logic?
Did you remember to limit the inserter to only grab one item at a time ?
(I know it's obvious, but sometime the obvious stuff gets missed).
Re: Slow circuit?
Posted: Thu May 10, 2018 1:56 pm
by Loewchen
Depending on how the circuit works the inserter might hold items when no train is waiting and instantly insert when one arrives, you can check for a train ID > 0 to prevent that.
Re: Slow circuit?
Posted: Thu May 10, 2018 2:26 pm
by zOldBulldog
Zavian wrote:Did you remember to limit the inserter to only grab one item at a time ?
(I know it's obvious, but sometime the obvious stuff gets missed).
I thought of it (I was using green inserters at first) but then replaced with blue.
So maybe not so obvious... don't blue inserters only grab one item at a time? Or do those inserter bonuses we research apply to blue inserters too?
Loewchen wrote:Depending on how the circuit works the inserter might hold items when no train is waiting and instantly insert when one arrives, you can check for a train ID > 0 to prevent that.
Can you give more than one condition to an inserter? If yes, how (short of having a couple decider combinators for each inserter... which would be messy)? I'd need both train ID > 0 and <particular ore> < X.
Re: Slow circuit?
Posted: Thu May 10, 2018 2:29 pm
by Zavian
At max stack inserter bonus, regular inserters can grab 4 items at a time. (If you check the research, you can see when they get bonuses).
Re: Slow circuit?
Posted: Thu May 10, 2018 2:35 pm
by zOldBulldog
Zavian wrote:At max stack inserter bonus, regular inserters can grab 4 items at a time. (If you check the research, you can see when they get bonuses).
I think that is exactly it then... once I switched to blue inserters I noticed several of the not so much used items were being overloaded by 3... 1 that was probably needed and 3 extra from the bonus.
I'll look into limiting the stack size of the blues.
Re: Slow circuit?
Posted: Thu May 10, 2018 4:01 pm
by bobucles
Zavian wrote:At max stack inserter bonus, regular inserters can grab 4 items at a time. (If you check the research, you can see when they get bonuses).
+1 at "inserter capacity bonus lvl 2" (green)
+1 at "inserter capacity bonus lvl 7" (hi tech)
Re: Slow circuit?
Posted: Thu May 10, 2018 6:29 pm
by zOldBulldog
I reduced the stack size to 1. No joy.
This is frustrating, the logic is so simple:
- Train stop is set to "Read train contents".
- Wire goes to every inserter.
- The inserter has override stack size set to 1.
- Each inserter has Enable/Disable based on the condition [itemType] < [#].
The train can arrive with exactly # of the itemType... and still adds one every time it stops.
If nobody can spot a flaw, I am calling it a bug.
Latest blueprint (for an even simpler train loading station):
Inserters activate at the same time a train arrives, but the item signals take 1 tick to turn on.
The bug was resolved as "won't fix", because it's possible to solve by doing circuit operations with the stopped train ID.
Somebody mentioned that... but how do you put 2 conditions on the same inserter?
I need one condition for the number of items, and one for the "stopped train". I only see one condition on the inserter, and it seems to me that it would take a ton of combinators (I'm guessing at least 2 per inserter, at 12 inserters per wagon that's 24)... and I can't imagine that is what the devs call "good enough", so there must be a better way to do it with circuits so that you don't need combinators or at most 1 or 2 per train... but I just can't find it.
Re: Slow circuit?
Posted: Thu May 10, 2018 6:57 pm
by DaveMcW
Here is an example of how to solve it, an imaginary "full train" is created whenever the train ID is missing.
You could also use a power switch that turns off inserters when the train ID is missing.
Thank you sir, the power switch was not an option due to close proximity to other live poles, but the blueprint approach required a little work but it did the trick.
I understand why the devs won't fix this bug during Beta. Not an urgent thing. But I do hope they fix it before full release, as such a bug and a statement of "won't fix" (in full release) would make the game look less than professional... and the game is too good to get unnecessarily downgraded.
Re: Slow circuit?
Posted: Thu May 10, 2018 9:03 pm
by Loewchen
zOldBulldog wrote:
I understand why the devs won't fix this bug during Beta. Not an urgent thing. But I do hope they fix it before full release, as such a bug and a statement of "won't fix" (in full release) would make the game look less than professional... and the game is too good to get unnecessarily downgraded.
There is nothing to fix, circuit signals need to propagate, the circuit needs to account for that.
Re: Slow circuit?
Posted: Thu May 10, 2018 10:05 pm
by zOldBulldog
Loewchen wrote:
zOldBulldog wrote:
I understand why the devs won't fix this bug during Beta. Not an urgent thing. But I do hope they fix it before full release, as such a bug and a statement of "won't fix" (in full release) would make the game look less than professional... and the game is too good to get unnecessarily downgraded.
There is nothing to fix, circuit signals need to propagate, the circuit needs to account for that.
The bug is that the inserter does not recognize the circuit condition for 1 tick. It can be called anything anyone wants and choose not to fix, but it is still a bug.
In general there is a distinction between professional software development and game development. Game development is FAR more tolerant of bugs, and often looks for other names and excuses to escape recognizing them. Still, those that do professional software development tend to be sticklers for the right terminology and will always call this a bug.
In any case, there are a couple workarounds that work and that is what really matters to me.
Re: Slow circuit?
Posted: Thu May 10, 2018 10:13 pm
by Koub
A bug is when things do not work as devs intend them to.
This is not a bug, it's a feature. Or at least, it's working as intended.
Re: Slow circuit?
Posted: Thu May 10, 2018 10:18 pm
by zOldBulldog
Koub wrote:A bug is when things do not work as devs intend them to.
This is not a bug, it's a feature. Or at least, it's working as intended.
ROFL, if I told that one to my boss the next time my software didn't work as the customers expect... I'd get fired. The most I'd get away with is calling it a Design Flaw and asking him at what priority should I place fixing it at.
But thanks, I needed a good laugh.
Re: Slow circuit?
Posted: Thu May 10, 2018 11:47 pm
by Loewchen
zOldBulldog wrote:
ROFL, if I told that one to my boss the next time my software didn't work as the customers expect... I'd get fired. The most I'd get away with is calling it a Design Flaw and asking him at what priority should I place fixing it at.
But thanks, I needed a good laugh.
Even in your example not meeting the customers expectation is not what makes it a bug. What makes it a bug is that your boss sets for the product the requirement that: "Every single customer expectation must be met."
Which again means that it is a bug because things do not work as devs intend them to.
Re: Slow circuit?
Posted: Fri May 11, 2018 4:27 pm
by Jap2.0
DaveMcW wrote:Here is an example of how to solve it, an imaginary "full train" is created whenever the train ID is missing.
?