Closed Vectorial1024 closed 1 year ago
OK so this can be too long.
TLDR:
Currently, the game unbunches buses by using the "(abstract) values" obtained at 100% budget levels, which may be unoptimal due to the fluctuation of budgets. This may cause problems. When the budget is too high, excess buses get stuck near the termini and cannot depart as quickly, reducing the transport capacity of the bus line. When the budget is too low, some sections in the line will see no buses, causing fake high-demand observations and causing wrong judgements.
The solution, therefore, is to make the game unbunch using the aforementioned value adjusted for the current budget percent. This will either bunch the buses closer in high-budget situations or spread the buses further in low-budget situations, increasing the flexibility of buses overall.
If we are changing unbunching, might as well also see whether the existing unbunching has problems.
For example, I can see a problem with the vanilla unbunching that holds vehicles too long even if the vehicle is running late; this function may contain hints on what to do with this problem:
BusAI.GetProgressStatus(ushort vehicleID, ref Vehicle data, out float current, out float max)
Well, I mean, if #29 works, then if I modify it a bit, then the low-budget case should also be doable.
Well, how fun it is, that with the basic comlpetion of #30, this task is completed simply by implicitly using the budget for calculation. No actual budget percentages are read or used.
This means we now have the following effects; at termini:
The system is now flexible and somewhat self-balancing. When eg you are using Real Time, and the budget is increased to cater for rush hour, the system can now dispatch buses more frequently from termini; and vice versa for low budget situations.
This is now on Steam. Closing.
Buses currently always unbunch as if they are always operating on 100% budget, which is untrue. Sometimes the budget can fluctuate, and this will cause the unbunching to be inaccurate. This causes problems:
When the budget is high
When the budget is high, for example it is during rush hours to cater for the high demand, then buses are staying far too long in the terminus, and the effective headway of the transport line is affected. It usually ends up in the situation where there are a lot of buses in the terminus but only a few is actually running in the line.
12 might help with this a bit, but that requires an asymmetric commuting pattern; if the commuting pattern is symmetric but also under high-load, #12 will totally not be triggered beacuse bot sides will appear as if they have similar demand levels, which ignores their "high demand" aspect.
This also has the problem where, if you are using eg TLM, then (under certain conitions, eg low pax turnover rate) it is possible that very popular bus lines end up losing money, because too few buses are actually running the line to collect fares and move passengers. This causes bus services to be incorrectly reduced based on their falssey "poor performace". (This might partially explain why A Certain Department keep cutting bus services out of nowhere; I believe some IRL bus lines do have this situation.)
Of course, having said the above paragraph, this also makes it very very difficult to allocate more buses to popular lines because it would make it lose money fast.
Eventually, at a certain point, alternative services eg metro are considered, but they are usually much more expensive than buses, and suddenly the entire system steers away from the natural equilibrium, and settles in an equilibrium where passengers can get to their destinations exrtemely fast (read: too fast) but at a very high cost of operation, which might be undesirable.
When the budget is low
When the budget is low, for example it is at late night to cater for the low demand, then this time buses are staying far too short in the terminus, and usually the bus service is not uniformly distributed. Depending on which buses got selected to return to depot, you would have a section where buses operate at 100% headway, and another section where there is no bus at all.
This has the obvious problem where a way higher amount of buses are required just to maintain reasonable waiting time of the passengers. It usually be like, a bus can carry all the pax waiting, and then the next 2 bus got nothing, and then pax gathers due to no bus, and then the cycle repeats by having another bus collect all the pax.
There is also this another problem with carrying capacity. If suddenly the decision is to use a lower-capacity vehicle in the line to deal with late night low capacity, then the bus line will fail because of relatively high demand during daytime.
Proposed solution
This might have been discussed by others, but it should be possible to adjust the unbunching waiting time by making it scale with the budget of the bus line in question.