Factorio Forums

ssilk wrote: Wed Jun 17, 2020 6:21 am
So I think to add the most game-value this combination would be useful:
- first research for train limitation is after signal-research. Then you can set the limits only to endless or 1. This gives the player a nice learning curve.
- the second research enables to set the limit higher than 1. This is also a warning for the player: this is a bit different now.

might I suggest "Thundering Horde" as the tech upgrade name that gives you >1?

ptx0 wrote: Tue Jun 16, 2020 10:12 pm

Lubricus wrote: Sun Jun 14, 2020 11:47 am [...] Trainsystems like HTN (https://www.reddit.com/r/factorio/comme ... haphollas/) [...]

man, that thing is just incredibly awful for UPS.

so if this is the only way to do train limiting in vanilla, well, i think it should be implemented in the game engine too.

No even system like HTN don't solve it. You have to do something like the other horribly complex system. In vanilla trains can re-path to another station (with the same name) mid way. The only way I know of to get around that is to have way-point stations between every junction to direct the trains to the right place.
I don't think HTN or similar systems is awful in any way certainly not for UPS.

ssilk wrote: Wed Jun 17, 2020 6:21 am

Ambaire wrote: Sun Jun 14, 2020 9:37 am To be honest, I don't really see a need to allow more than 1 train to path to a single station. If this suggestion were implemented, I would most likely always have incoming trains limited to 1 per.

Well, I see that. It makes sense to have a limit of 2, if you really have extreme throughput, so that the next train is already waiting at the station entry, and not in the stacker.

The stacker should be the station entry, really. But the true reason to have something with a limit higher than 1 would be to emplace a dummy station so's that you can do things like stuff N trains into a stacker, pull 1 out as required, and have the ones in the stacker available to repath elsewhere if that is required.

I'm looking into a circuit implementation that drip-feeds stacked trains back out if their local station is blocked, plus an overflow lot, but even that doesn't wholly solve the swarm issue (though it should significantly mitigate it).

EDIT:

I should also note here that 'there's a mod for that' is a silly response to a suggestion, because if there's a mod for it that suggests its something a lot of people want and find useful, which are exactly the suggestions that should be looked at most seriously!

Lubricus wrote: Thu Jun 18, 2020 12:25 pm certainly not for UPS.

circuit controlled signals are really bad for game performance.

Sorry, but that’s just not correct.
I’ve maps with hundreds of circuits and as long as the signals they are waiting for do not change a lot this is not a big issue.

For example: counting items on a fully loaded belt is a problem if you do have several of such counters. Or counting items in a stock of chests, that change every tick. Counting trains that come into a station is surely not an issue, even if you have hundreds of stations, because that event happens maybe once per second...

ssilk wrote: Sun Jun 21, 2020 7:17 am Sorry, but that’s just not correct.

then tell it to rseding91, the one who told that to me.

With 0.15 they changed, that the circuits are calculated each tick, but only when a signal changes. Which means that a circuit is sleeping, when there is no change. Of course, the bigger a circuit network, the more entities in it, the more CPU intense.

ssilk wrote: Tue Jul 28, 2020 6:44 am With 0.15 they changed, that the circuits are calculated each tick, but only when a signal changes. Which means that a circuit is sleeping, when there is no change. Of course, the bigger a circuit network, the more entities in it, the more CPU intense.

I never played .15, I am talking about .17 and .18 behaviour.

Yes. You don't need to play the old version to get the benefit of that change. What I'm saying is, that the circuits need only a lot CPU if the input signal changes.

jendenbm wrote: Tue Jun 09, 2020 10:55 pm The goal is to treat all mining as a "cloud service" where you don't micromanage individual mining outposts and name them all the same name, so that the trains figure out which station to use. The trains make this decision, not the player. The player can then increase the number of trains as the number of mining outposts increases.
...
If only there was in-game feature to limit the number of trains that provider station

Hallelujah! The devs have finally implemented the solution precisely the way it was requested. I can't believe they actually did it.
https://factorio.com/blog/post/fff-361

Perhaps this should be moved to implemented suggestions?

I was waiting the feature to go live. Right now, it's not implemented yet.

It’s implemented, but not released...