#Reservation "upgrade should be togglable"

1 messages · Page 2 of 1

glossy hound
#

there are many other places loop saturation can happen, like trains around a city block (or any loop in the network, hence the name)

neon loom
#

The loop would never saturate with the change to train limits

glossy hound
#

oh boy, one specific example that could be easily fixed without the feature

neon loom
#

Again, try easily fixing it when you're two planets away and relying on your network to be stable to supply you resources

glossy hound
#

this is where bots come in

frozen orchid
neon loom
#

I'd much rather the train limits be more predictable, with an option to immediately clear the limit

#

I feel like this whole thing has been me trying to explain why I think they made the change, and why I think it's good but we should be able to make it how it was before with an option, and a lot of 'well it shouldn't have been changed because you should just be better at the game'

glossy hound
#

finally home, new demo incoming

ocean adderBOT
glossy hound
#

there, no tick delay or anything, works perfectly

#

all you need to do is have the train limit be 1 less than you actually want it and this signal will compensate for it

#

very easy to work around, and insanely simple with static limit 1

#

@cerulean birch this you should see

#

if you design your network in such a way where it could cause an issue, then you can just do this instead

dusty depot
#

very cool!!! Is it possible to make it the other way? Like so it "undoes" the change?

glossy hound
#

not as simple as this, no

#

you'd have to specifically add an extra signal in front of a station to localize a block entirely to just after the station, as well has having an arithmetic combinator to invert the signal, and it's not instant as the train has to accelerate before actually entering the block, so it doesn't even work anyway because trains tend to leave instantly if they're queued up

dusty depot
#

interesting

warm sky
#

Some people wanted a comparison between what happens with the old system vs with the new system:

OLD SYSTEM

image.png
#

NEW SYSTEM (simulated by lowering train limit by 1)

image.png
#

In the old system, the total number of copper trains that were doing actual work dropped down all the way to 5, which is why the 2nd copper mine in the picture stopped working altogether.

In the new system, although 4 copper trains stop working, the rest continue, and thus the other copper mines also continue working.

#

The deadlock is maintained by the interesting circular sequence:

the iron train isn't moving -> copper trains aren't moving -> copper consumption is low -> iron consumption is low -> no station requests the iron train -> the iron train isn't moving

And one interesting consequence is that it therefore can be fixed by the following solutions:

  • "throwing iron into lava." (which causes more iron to be requested)
  • "shutting down all iron mines" (same)
  • "open 10 copper mines at the same time (with corresponding trains) to overload the train network with copper"
glossy hound
#

I'm not even sure what I'm looking at

#

also why are your city blocks only one rail block for the whole length of the thing

chrome juniper
#

Without taking the time to reinvent the wheel and simulate the Old/New above, I think both would have no issue affecting any stations other than the defective one if all stations were built with a bypass exit. That, of course, is based on the issue being something wrong with the rails, not a user-controlled train parked in the way.

#

Building a robust network, no matter which version is used, means seeing where issues could happen and working to prevent them from happening, or at least from spreading. Unless a rail is borked in the main line there ought to be zero stations affected outside the one with a problem.

#

I'm also back to the two interpretations of what they mean by a train leaving the train stop's block. If it is the entire train, all cars, being clear of that block before the reservation is given up, I see no reasonable way to salvage a high throughput fast changeover. Multiple stops with a shared belt might recover the throughput, but at quite a cost in construction and space. For that case I would want, at the least, the ability to return to 1.1 behavior with a toggle, of even drop the change and allow circuits and signal design to solve the issue discovered in their playthroughs.

#

If the alternate version, train begins rolling out counts as leaving, it seems likely that there will be few edge cases where the loss of throughput is irreparable. It's probable that the signalling tricks used to enable the fast change now will be just as effective under the new system, and the change times might be unaffected at all. I would, even if there is some loss, not want a toggle added to the GUI. (Perhaps a game-wide setting similar to map settings, maybe.) I don't know how complex it would be to code the toggle's operations, but I gather it's not as elementary as it seems. The research queue toggle was dropped for the reason of reducing the maintenance tasks, and adding a new toggle seems like a way to toss out the gains made from that.

#

It would, however, be an excellent thing to have a dev clear up what I perceive as the ambiguity of when, specifically, the reservation is given up.

vivid stream
#

I'm pretty sure the devs meant that the train has to leave the block entirely, as Kelvin explained here. What we don't know is if they even considered the alternative of just entering the next block.

glossy hound
#

that doesn't help if there's two blocks right after each other that are short and the second one is red

vivid stream
#

Yes, but how often does this happen in practice? Considering this feature is not solving anything that can't be already solved in other ways, be it better signalling or circuits, but it's about removing the tedium of having to do that for a scenario that is, according to the devs, common enough to warrant it.

#

I'm still not clear on what these scenarios are, so in my mind it's possible that nose-past-the-signal could still have the desired benefit in the majority of cases, without the throughput loss.

#

That said, whatever is common for the devs, might not be representative of the whole Factorio playerbase.

#

I would love to see the test setups posted earlier in action btw, because I'm having trouble visualizing the flow of trains.

warm sky
# glossy hound also why are your city blocks only one rail block for the whole length of the th...

It turns out chain signals are key to making this effect consistently. It can happen randomly with regular signals, as the previous screenshots have shown, but it's not 100% in that case. (basically it required the train to randomly repath while in the block with a chain signal at the end; it can do that randomly at any point, but if there are blocks with regular signals on both the entrance and exit, a train can end up in that block permanently and refuse to repath)

In the previous attempt at replicating the effect (where there were blocks with regular signals on both ends), the amount of stuck trains was random an inconsistent through attempts. It could still grow enough to make 1 blocked mine turn into 2 blocked mines, but it rarely got big enough to block the 3rd mine.

#

So theoretically 1 solution to the problem is to never use chain signals; use rail bridges for intersections instead.

chrome juniper
#

Looking at the two maps and attempting to deduce where signals are and what type are in use while guessing which trains are "stuck" is an apparent exercise in futility. I'm guessing that @warm sky has more time in-game than I, yet I'm drawn to the conclusion that the signalling is not only sub-optimal, but it is operationally wrong. Of course, that's only based on my guesses as to what the signalling actually is, which is sure to be wrong.

warm sky
warm sky
chrome juniper
#

On a different note, as a point of etiquette, the discussion of the issue itself is probably best moved somewhere else rather than using this thread for it. I'm going to end up mostly out of the loop, and on mobile, since I have hardware issues to handle that trump even Factorio time. 😿

warm sky
#

TBH I thought the discussion was over about 5 times, but people kept coming back an asking me questions so IDK