1.12 And the artificial limit on max pax station capacity

[djplong]

I know I've mentioned this in the past, but the 10K max pax station capacity has got to go. As soon as I developed the New York and Boston systems, I started bumping into these limits - and, initially, more trains per hour helped.

But I've got a situation in Chicago (less so in other places) where central hubs with regional, local and long distance lines just can't handle things no matter how many platforms there are.

New York's Penn Station handles 1,000 pax every 90 seconds - 600,000 in a day. In my build, like real life have long distance routes leaving, at times very UNlike real life trying to handle the crowds wanting to go everywhere, every 10 minutes from that particular station - meaning that the feeder routes (Subway, LIRR, NJT) can, in those 10 minutes, dump more than 10K pax into the station.

I know it's hard to talk about "reality" when I have a build here that has a trans-Atlantic rail route. But that 10K just seems so arbitrary.. Lord knows an airport "station" could hold more than 10,000 passengers.

[aminimus]

For me, the standard is that real life lines should work. They need not be the best, but they shouldn't break the game. With the addition of POIs, it does feel like the station limit is probably the biggest remaining barrier to semi-functional real life networks.

That being said, Carlos is much smarter than me about this stuff, so I assume there's a performance reason that he has probably explained before. Naively, I would imagine the number of destinations would be the performance constraint, and not the number of pax. A limit directly on number of destinations, that only bounced pax going to a destination that wasn't already on the list, would seem less disruptive, since the biggest destinations would quickly fill the top of the list. But I couldn't code my way out of a cardboard box so [shrug].

[Weird and Wry]

The "artificial" limit is there to balance pax boarding flow, max train wait at stations, and not introducing massive lag spikes every time a train arrives to a busy station. Contrary to what is being implied in this thread the assignation of "next train" is not done once, it is constantly being refreshed as trains arrive to the station because trains can be late. Refreshing that decision is slow, therefore it is staggered over time, therefore it dictates a maximum pax boarding flow, which combined with the 3m boarding limit, gives roughly a 10K max amount of pax which could be reviewed over 3m.

Any of these numbers could be bumped up or down with a variety of undesirable and desirable results. The current balance is towards making sure gameplay stays smooth while having the least undesirable results most of the time for most stations and trains.

[adlet]

I wonder if this may be less of an issue with 1.12 that should have generally reduced ridership unless the network is fully built out.

[MirkoC407]

1.12 has shifted the lag from wayfinding in overcrowded stations into wayfinding of the last mile. However, it already lags more now than 1.11

[djplong]

Originally posted by adlet:

I wonder if this may be less of an issue with 1.12 that should have generally reduced ridership unless the network is fully built out.

My issue is a situation like Chicago. In real life, there are several stations withing walking distance of Union Station for commuter rail with the Loop nearby. In theory, this would allow for breaking up the crowds from the 4 subway lines in the Loop (plus 2 underground) numerous commuter/regional rail lines and, in my build, 10 cross-country lines that all converge or run through Chicago (all current Amtrak lines plus a couple of historical ones).

But there's no way for a person to walk to the station next door. It's like how St. Pancras and Euston are in London or, to a lesser degree, North and South Stations in Boston (although, to be fair, they ARE a mile apart)

1.12 resulted in an instance of me getting over a half-billion dollars charged in refunds in one day just in Chicago so, at least on that metric, I'm not seeing reduced demand.

Don't get me wrong, I'm loving many of the other features and can't wait to dive into the POI stuff. But I'm running around trying to fix "central stations" that have gotten worse.

[Weird and Wry]

If your save is big, 1.12.6 has made world weight pax spawn factor (the extra boost to pax spawn induced by the reachable population from a given point) go from linear in 1.12.5, to logarithmic in 1.12.6. In other words it was out of whack for very large saves and now it will be very hard to make it go over 2x (you need 500M activated population for a 2.1x factor, for example).

[aminimus]

Originally posted by Weird and Wry:

Any of these numbers could be bumped up or down with a variety of undesirable and desirable results. The current balance is towards making sure gameplay stays smooth while having the least undesirable results most of the time for most stations and trains.

Thank you very much for the explanation! Sounds like a very difficult/impossible problem. "Realistic" rush hour waiting pax counts at major urban hubs would likely require an order of magnitude bump in the station limit, which seems absolutely game-breaking, given what you've described in this thread.

Thinking about it more (I can't help myself--I love this game!), the way you describe pax behavior, I'm not even sure it's "realistic" to have more than 10k people in one station. It's not like everyone in these hub stations are all staring at the same arrival board, assessing every movement on every platform. Perhaps the blue-sky ideal for a major hub is to have the complex divided into different adjacent/overlapping stations, each with a 10k limit and walking transfer time, rather than one larger station where a horde of pax are burning a hole in the CPU with every arrival. In the Penn example OP provided, we might imagine LIRR, NJT, Amtrak, and the two subway lines each as separate components of the complex. Certainly from a railroad operational perspective, places like Shinjuku and Gare du Nord are viewed as a bunch of different stations, even if the customer-facing materials might put them all under the same name.

Really appreciate your work!

[trolley_trev]

I wonder if there's a way to achieve the same or similar results of the current pax algorithm without having to cycle through every single pax every time a train arrives? A thought that comes to mind is a cyclical check of pax' "Late Counters" ie how far passed the expected departure time is it? Over a certain (adjustable) arbitrary threshold, eg 10 mins, that pax will get a recalculation event. The recalculation event should nominate the next time a recalculation is needed for each pax. This way, unless all of your trains are all really late all the time, most cycles through what I assume is a giant array will escape after 1 check: Is current time >= next recalc time? No -> return; Yes - > Recalculate.

So that you're not looping through an array of 100000 pax, you could probably split the array into smaller blocks. If the late counters are only in whole minutes, as long as you can cycle through the whole array within a minute, that is what will determine max station capacity. So WaW stated it takes about 3 mins to recalculate 10000 pax. It probably takes only a few seconds to go through 10000 pax with no recalculations. So if we aim for 100k station pax capacity, we can determine the % of really late trains before lag starts for a given late counter. (Ie, when total loop time exceeds 1 min)

Based on the 10000 pax per 3mins for recalculations, it takes about 18ms for a full recalculation. I don't know how many calculations that is, but lets just say it's 90x more onerous than just checking the time. So checking the time will take 0.2ms, a recalc will take 18ms. We have 60000ms to get through the full array. If we divide the array into blocks of 10k, best case scenario (no recalcs) for 1 block is 0.2 * 10k = 2000ms, or 2s. We have 4s leftover for recalcs. If we are aiming for 100k pax limit, each block can take no more than 6s, or 6000ms. So, every recalc is a penalty of 17.8ms vs no recalc. 4000ms / 17.8ms = approx 225 recalcs. 225 / 10000 * 100 = 2.25; So for a 10 min late counter and 100k pax limit, 2.25% of trains can be over 10 minutes late *departing* before lag starts.

I have picked some very arbitrary figures here and WaW will know how far off the mark I am (and in which direction!). I'm sure there's lots of optimisations possible, this is just an off the cuff idea I made up as I went haha. (eg, late counters in 2min increments, so for 100k pax, a cycle of 10k can take 12s. This gives 8s for recalcs, or about 450 recalcs. ie 4.5% of trains leave more than 10 mins later than scheduled.)

That's my 2c worth at least :)

[djplong]

One interesting aspect I've noticed is that I have this problem where there are big central stations or single threads 'through' (New York, Chicago, Boston, Montreal, London). I've worked on Berlin and Paris in this build and Paris doesn't have this problem - and I'm presuming it's because not EVERYTHING *has* to connect at Gare du Nord - the regional rail comes in from different areas to different stations taking different metro lines with SOME of that volume going to Gare du Nord to get to London and North America.

I'm going to try and solve my "Chicago Problem" by taking the express line that goes to the Trans-Atlantic connection in Canada, and using some of the existing freight network to put in something akin to a Ringbahn that will connect to the other regional and long distance lines to take the pressure off of Chicago's Union Station.

[aminimus]

I just ignore the "Chicago Problem" and build the big stations anyway, haha. Replicating, improving, and embellishing the world's great cathedrals of public transit is too much fun, even if the pax numbers are wonky.

[djplong]

Originally posted by aminimus:

I just ignore the "Chicago Problem" and build the big stations anyway, haha. Replicating, improving, and embellishing the world's great cathedrals of public transit is too much fun, even if the pax numbers are wonky.

I'd ignore it if it weren't for the half billion dollar hit to my bottom line.... :)

[Fermiboson]

The problem may be solvable in some parts for pedestrian transfer - b/t King's Cross and St Pancras is a good example, the only realistic way to build it right now is as a big TL-mainline-LU complex. But in other places - B'ham New St for example - this is not possible, nor is it possible to separate the station into several sections given the layout of the lines running into the station. (This is not to mention the mess of the New St - Moor St - Curzon St interchanges.)

The simplest possible patch is a customisable option for the pax limit - though I have no idea what undesirable behaviour that brings - but I wonder if passengers with the same destination may be treated as a single bloc in some sort of data structure so the program runs through the set of destinations rather than a set of passengers. This would help considerably with problems faced by most IC lines.

[djplong]

Originally posted by Fermiboson:

The problem may be solvable in some parts for pedestrian transfer - b/t King's Cross and St Pancras is a good example, the only realistic way to build it right now is as a big TL-mainline-LU complex.

Well, I'm now in the process of testing my 'solution' to the challenge who's real cause is having one main trans-atlantic route.

I broke the London - North American route into segments. London -> Ireland -> Canada. At the Canadian transfer point, there were two lines to pick up the traffic - one to Montreal and one to Chicago. Chicago's Union Station (with a pedestrian 'platform' to connect to the subway) was giving me all kinds of trouble.

So, what I did was, I redirected the Chicago-bound traffic. It now encircles the city and makes connections with every long-distance route I have terminating or going through Chicago with ample use of the board/disembark flags. So now I have multiple stations, each one handling transfer to one route (there are routes to Boston, New York, DC, Seattle, San Francisco, Los Angeles, New Orleans and Florida). This SEEMS to be taking the pressure off of Union Station so I did the same for Montreal, making connections with the routes to Boston, New York and Toronto along with direct Metro and REM connections.

At the connection in Canada, I did a little more. I split the station into several uni-directional stations. So I have Oceanic Inbound, Oceanic Outbound - same for Chicago and Montreal-bound services - two stations each - and a shuttle loop connecting them all so that, in effect, I have SIX stations with a theoretical capacity of 60,000 (I built some ghost platforms so that each unidirectional station could handle 10,000 pax.

It's more complicated, but I think it serves the purpose and SHOULD, if it works long-term. What I see happening in Paris and Berlin (with their somewhat decentralized operations) gives me hope that I've found the right answer.

[MirkoC407]

Indeed - no matter if it is trains or look at aircraft - imagine all real world flights over the Atlantic are leaving from London and landing in either Montral or Chicago. This would include all flights originating in Frankfurt, Munich, Amsterdam, Paris, etc. and going to NYC, Atlanta, Miami, Dallas, L.A., San Francisco, Toronto, Vancouver, etc. would also only have to use these few airports.
Heathrow is already overcrowded now, and I think neither O'Hare nor Montreal-Trudeau could handle it. All three locations would require airfields the size of whole counties to deal with it.
You are probably on the right way - either split that funneling into more selection of direct destinations, or you will have to do major compromises to the real network to accomodate your funneled long distance traffic.

[adlet]

This makes sense. North America rail facilities are underdeveloped compared to European and Japanese. What you are doing is effectively elevating the level of rail traffic to the magnitude of Europe. So it is natural it requires new stations and new approaches to infrastructure.