vectorial1024/expressbusservices

Buses skip stops whenever possible.

Express Bus Services

Unlock the peak efficiency of buses:

1. Buses skip stops whenever possible
2. Buses do not unbunch (except when at first stop of line)
3. Niche: can choose to allow buses self-adjust their service levels to better meet commuting demand
4. Niche: can choose to allow minibuses (ie, buses where capacity <= 20) to depart faster when pax boarding+alighting <= 5
5. Special extension: trams can be configured to not unbunch at non-terminus stops (Light Rail mode and True Tram mode)

Mod Status

• Compatible with Transport Line Manager (implemented compatibility; TLM can work more completely)
• Compatible with Improved Public Transport 2 (implemented compatibility; IPT2 would override things otherwise)
• Mods available for this mod (yes, mod-ception):
  • Express Bus Services (IPT2 Plug-In) https://github.com/Vectorial1024/ExpressBusServices_IPT2
  • Express Bus Services (TLM Plug-In) https://github.com/Vectorial1024/ExpressBusServices_TLM
• Special thanks to Klyte45 from TLM for letting me implement their "Express Bus" mode code on this side
• I am quite satisfied with the current state of the mod; future updates will be less frequent!

Because this mod is very small and simple, I am open-sourcing this to everyone out there.

Types of Transportation Covered

These transportation types are currently covered by this mod:

• Buses; as a result of game mechanics, the following transportation types are also covered:
  • Evacuation buses
  • Tourism buses
• Trolleybuses

Note: Intercity buses were previously affected by this mod, which does not make much sense and might have caused some other problems (#15 (comment)), and so they are now free and are not affected by this mod.

These transportation types are covered by this mod, but contains a different set of settings:

• Trams

These transportation types will NEVER be covered by this mod because it will not make sense:

• Cruisers
• Airplanes
• Cable cars
• Ferries

These transpotation types will not be covered by this mod because they will become unrealistic:

• Metros
• Trains
• Blimps
• Monorails
• Helicopters

Modes of Stop-Skipping

• Prudential (Legacy): buses etc still stop at stops, but will depart immediately when the stop-skipping criteria is met
• Aggressive: buses etc will try to predict whether it needs to stop at non-terminus stops, and will literally skip the stop if the prediction passed. Not available for trams.
• Experimental: a stronger version of Aggressive Mode. WIP.

Trams-only: Tram Mode

• Disabled: trams behave according to "default behavior" (eg if you have TLM, it uses TLM behavior)
• Light Rail: trams stop fully at stops, but do not unbunch at non-terminus stops
• True Tram: equivalent to Prudential mode as described above

Extra Stop-Skipping Options: Service Level Self-Balancing

When activated, buses will have a chance to immediately transfer themselves to the most in-demand section of the bus line, resuming from the relevant first-stop terminus, thereby skipping multiple stops at once (refer to #12 for more info); this will be helpful when commuting patterns are asymmetric.

When attempting to transfer over a long distance (currently set to 1 city tile), buses will send themselves back to depot, and let (another) depot spawn a replacement bus. This reduces the time that the bus "arrives" at the intended transfer target, and speeds up the transfer.

Extra Niche Options: Minibus Mode

Minibuses are defined as buses where capacity is <= 20.

When activated, minibuses will pay attention to the number of passengers boarding and alighting at the bus stop: if that number is <= 5, then the minibuses may wait less and depart earlier than usual, simulating the Hong Kong minibus situation.

Extra QOL Behavior: Improved Unbunching

Buses will now unbunch based on the number of vehicles on the line. This results in generally higher effectiveness of high-frequency buses, while also maintaining reasonable spacing for low-frequency buses. (Note: due to tech limitations, there is a max amount of time that buses can wait at termini, and I cannot influence that; so low-frequency buses cannot be too low-frequency if you are aiming for an even distribution of buses in the line.)

Motivation

This mod aims to salvage vanilla CSL buses from being borderline unusable to being competitive against metro and tram lines.

By skipping stops and removing most of the unbunching, buses can now become an efficient alternative to metro and tram lines when e.g. the streets and curves are too tight for metro stations, or when conversion to tram lines are not possible due to street layouts.

Combined with mods such as Transport Line Manager and Improved Public Transport 2, it should be much more likely to earn profits per bus line. (Upkeep of depots should be covered by some other, stronger income source.)

Technical Information

This mod uses Harmony to modify ("patch") the CSL code to achieve the effect.

The integrated compatibility to IPT2 is achieved by utilizing Harmony's ability to detect other mods in runtime and selectively apply patches. See the source code for more details.

The ability for this mod to determine whether a certain vehicle has loaded all loadable CIMs is powered by Harmony's "reverse-patching" feature available since Harmony v2. See the source code for a working example of reverse-patching.

Expanding on my answer on #1, the general procedure of this mod is something like this:

0. General event occurs: bus arrives at bus stop
1. Bus AI tries to unload passengers
2. I count how many is unloaded
3. Bus AI tries to load passengers
4. I count how many is loaded
5. Enter loop:
6. If non-first bus stop:
   1. If unloaded + loaded = 0 then depart immediately, exit loop
   2. If some CIMs boarded/alighted & waited enough time at stop & all boarding CIMs boarded then depart immediately, exit loop
   3. Else wait for next loop
7. Return control to game

No data is written to the save-game because instant-departures are, well, instant. It is very unlikely that the arrival state persists at the moment a save occurs. (Well, unbunching right after loading a save game shouldn't be too severe.) Moreover, I can determine whether the bus is at the first bus stop of the line just from vanilla CSL data structures. There is no need to save any data.

expressbusservices's Issues

Notice on IPT2 non-intervention, and recommendation to use TLM

More details to be added later, but TLDR:

There are tests conducted by me and someone else separately that confirmed the following:

The unbunching by IPT2 does not seem to work even by itself. This means that while there are unbunching problems observed when using EBS + IPT2, it is probably IPT2's problem at the core. As such, those IPT2-related problems will be put to low priority until further notice.

#13 is affected.

---

Recommendation to change to TLM

Always enable specific config for every transport line in your city!

By changing to TLM, the following IPT2 features are kept (or may reasonably change into another form):

• Line budget
• Vehicle select

Unfortunately, these IPT2 features will be lost or changed in a strong way; see if you are willing to take a compromise:

• Passenger change per vehicle per stop: instead of tracking each vehicle and checking their pax change, you could consider also using Commuter Destination (https://steamcommunity.com/sharedfiles/filedetails/?id=2475986859) to track destinations for the same stop, which should be more convenient than the IPT2 way
• Profit per vehicle: you can view line overall profits instead; or, go to line view -> Profit Current Week
• Unbunching points: TLM line stop list -> right click on stops to mark them as terminus (star shape)
  • TLM has a useful feature to shift stop order in a line so that, internally, another stop becomes the first stop in line; useful to use with EBS; go to line view -> Starts At
• Specific model select (eg I want 5x Volvo and 2x B8L): no replacement, bus spawning is fully random
• Day-night select: TLM offers generalized replacement, and day-night select is equivalent to setting the budget to >0% for eg from 6am (6) to 6pm (18)

[WIP]

New Feature: Continuous Boarding

Buses only collect passengers the moment they arrive at bus stops. This is usually OK, but if they are unbunching, they will refuse to pick up additional passengers. This may reduce the bus line's carrying capacity at termini.

The suggested solution is therefore to make the bus board more passengers if they are unbunching.

However, this will most likely break other mods that rely on the vanilla process to count passengers boarding/alighting, so this will be a low priority task.

Open question: should trams be allowed to use the "redeployment" feature?

Initial thoughts suggest a solid "no" because trams have to use their network to move around. It is very likely that there are no shortcuts available to move trams around, and so redeploying trams will likely cause inefficiencies.

This is very different from buses where it is basically possible to find a shortcut to the other side of the bus line.

This is kinda similar to the trolleybus "aggressive mode" open question.

New alighting behavior: premature alighting

And no, the joke is unintentional.

---

You may get what I mean if you live in Hong Kong long enough and you take the bus frequent enough. In some (TM) cases, before the bus can properly arrive at a bus stop, the bus driver may elect to just drop off the passengers first.

This will be super low priority.

Consider: disallow repeated redeployment

This is a problem observed when the redeployment chance is too high during development:

Let's say a bus is instructed to redeploy to a certain segment, and the bus arrives at that segment's terminus. Then, because of the time elapsed and the change in commuting direction, the bus is told to redeploy into the opposite segment.

This is very wasteful because the bus does not pick up any passengers and must travel the entire line with no income contribution.

The proposed solution is that, for the duration of the gameplay session, buses are not allowed to repeatedly redeploy; if it has redeployed, when it arrives at the terminus, it must not redeploy. This allows simple engineering while maintaining good enough anti-repeating behavior (hopefully).

Architecture reversal: read TLM values through the TLM plugin

Because of the nature of C# and their dll, as long as the main mod is updated with a new vesion number (my style), the plugins must also be updated by simply rebuilding it. If you do not rebuild the plugins then the plugins will simply not work because the required assembly could not be found.

With #20, it is becoming more feasible to just integrate the TLM plug-in back into the main mod. However, it is not trivial because of the complexity of the TLM code involved.

Edge case: buses depart even when some passengers haven't boarded yet; not allowed!

This is very unlikely with vanilla buses because of its small vehicle size, but if you use it with mods e.g. Realistic Walking Speed, it becomes much more obvious.

This is a problem with me currently using a fixed value as the wait timer to achieve no-unbunching.

Fix by checking why the bus cannot depart yet, and carefully determine/signal if it could depart.

New stop skipping behavior "Protocol 424" ("P424")

We don't even have any official name for this, so let me grant it a name:

"Protocol 424" ("P424")/"424模式" (Source (note: Chinese only): https://hkbus.fandom.com/wiki/%E9%A3%9B%E7%AB%99#.E3.80.8C424.E3.80.8D.E5.9F.8B.E7.AB.99.E6.96.B9.E5.BC.8F )

Regardless of whether the reverse-engineering mentioned in #1 is going smooth or not, what we already have in TLM is sufficient proof that "it is possible". Therefore I can draft a new version of stop-skipping which is stronger than the TLM version, inspired by yet again another Hong Kong concept: Protocol 424.

To put it simply, it is a stronger version of the planned TLM-style stop skipping, but in turn, it is more complicated, and I will have to think more carefully as to not cause unwanted side effects. Unlike previous stop-skipping modes, this Protocol 424 CANNOT be blindly applied to all bus lines. Care must be take to confirm the need of P424 in specific bus lines.

As of writing these are the planned/available modes:

• Prudental mode (available)
• Aggressive mode (WIP reverse-engineering from TLM in #1 )
• Protocol 424 (WIP drafting)

The draft pseudocode for P424 is as follows:

When about to enter stop:
  Check if no one will drop off
  Check if there is already another same-line bus in front of us
  If all check passed:
    Skip this stop

This is a mechanism to self-balance bunching behavior, just like stop-skipping itself. Note that, just like IRL, P424 is a tradeoff between waiting and travel time: in P424, waiting time is sacrificed in favor of travel time. This cannot work for all lines: if the bus frequency of some bus line is low enough, P424 should never be used even when bunching occurs: the benefits simply cannot compare to the sacrifice.

Therefore, a draft check of whether P424 should be enabled is as follows:

True if line budget > 100%

This will be low priority.

Proposed New Features

Features proposed by a Steam user, writing it down in case I forgot about them after the Harmony update mess, because back then I thought some of those are indeed interesting.

The guy proposed 3 features, and I try to summarize my thoughts/replies on them:

Dead trips on counter flow

Dead trips on counter flow, on the other hand, means buses from a depot do not pick up passengers until the start of the route, or do not let off passengers until the depot once those are pulled out of service. If AI chooses to pull a bus out of service, it should be able to allow passengers to be let off at a stop before going out of service (or, when starting a trip, allow the bus to board passengers at any stop until the start of the route, which may be an interesting thing to code).

Short-workings

[Operate from midway bus stops] is the same concept as short workings where you have a bus line that does multiple schools and letting them off at residential areas.

Operate from midway bus stops

Operating from midway stops means buses don't have to do the full trip and instead do part of the trip (e.g. if your bus line has a busy section and a quiet section, you can add more money and vehicles (say, 200%) on the busy section while keeping the value at 100% for the rest of the route).

Agressive and Experimental mode can cause bus despawning

I have spotted an issue with bus stops on 3u long road. Buses will return to depot or despawn on the second time they come across a 3u stop, which makes buses quite unreliable at picking up passengers. I made a video showing the problem, where everything works fine until I shift the stop to the 3u-long road. You can also see that the buses seem to return to the depot every other stop.

https://www.youtube.com/watch?v=15dtyXIzZFE

With this savegame below, buses on the red line will despawn but only once as I couldn't reproduce the repeating pattern like on the video. It could still be useful for testing purposes.

https://drive.google.com/file/d/1nDLBsCtM-3BnNj_MwJxX8e9HigpR1TkZ/view?usp=sharing

In the end, here are my findings :

• TLM alone with express buses setting enabled causes despawning
• TLM alone with express buses setting unchecked works just like vanilla, long stops but no despawning
• TLM + EBS mod and its TLM plugin in Aggressive and Experimental mode causes despawning
• TLM + EBS mod and its TLM plugin in Prudential mode doesn't cause despawning

I hope this have been helpful. I'm happily using prudential mode at the moment as it's still way better than vanilla ;)

Disallow trolleybuses from using anything stronger than Prudential Mode

It just does not make sense. Colossal Order already mentioned somewhere that trolleybuses are not supposed to overtake each other. This means trolley buses are not allowed to use eg Aggressive Mode, which allows overtaking.

If trolleybuses can overtake each other, then it is a bug.

New IPT2 detected

New IPT2 detected:

https://steamcommunity.com/sharedfiles/filedetails/?id=2864524762

Compatibility unknown.

Extend to trams

The tech should be simple, but do try to extend this to trams:

Also add this config:

• No Express Trams: no effect/changes
• Trams are Light Rails: express trams, but act closer to metros. They will not unbunch everywhere, but they will perform the full stop-cycle on each non-terminus stop (perhaps call this the tram-mode?)
• Trams are Trams: express trams, but act closer to buses. While they can depart early when no one alights or drops, (max level is Prudential mode), they cannot skip stops.

Just that I can be lazy...

ArrayIndexOutOfRange

AFAIK, reported both from Steam and Discord.

Should be sth like, when loading into map, or when simulating, it throws ArrayIndexOutOfRange, and the stack trace immediately mentions ExpressBusServices.

Can we further reduce the minimum time for termini unbunching?

The current minimum (due to overcrowding) is at 2x standard dwell time (at 2*12 = 24 "ticks").

This is technically possible, but we should be asking ourselves whether we should. If such distance is too low, then it may make the redeploy-midway feature less useful as it should be, because then theoretically, there is no gap in between buses that are coming from the same terminus.

Think about it.

New feature: fast boarding

Inspired by the minibuses in Hong Kong, if the bus capacity is <= 20 and the number of pax boarding+alighting is <= 5, then the bus is allowed to stay for less time at non-terminus stops: I wish for staying for 4 units of time.

The specifics can change though, but this is the main idea of it.

New Feature: Rapid (or Slowed) Deployment

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.

ReflectionTypeLoadException when Harmony is missing

Hi Vectorial, I think I found a bug in this mod. The technical detail of why this happens is described at drok/Harmony-CitiesSkylines#9

It happens in corner cases like the user not having Harmony installed yet. See the issue post above for more scenarios in which it happens.

I found this by using my new Harmony mod, which sniffs out issues like this.

Loading D:\Users\Radu\AppData\Local\Colossal Order\Cities_Skylines\Addons\Mods\PopulationDemographics\CitiesHarmony.API.dll  [Mods - Internal]

Non platform assembly: data-0000000016098CC0 (this message is harmless)
Fallback handler could not load library q:/SteamLibrary/steamapps/common/Cities_Skylines/Cities_Data/Mono/data-0000000016098CC0.dll
Assembly CitiesHarmony.API, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null loaded.  [Mods - Internal]
 
Loading D:\Users\Radu\AppData\Local\Colossal Order\Cities_Skylines\Addons\Mods\PopulationDemographics\PopulationDemographics.dll  [Mods - Internal]
 
Non platform assembly: data-00000000160A3D00 (this message is harmless)
Fallback handler could not load library q:/SteamLibrary/steamapps/common/Cities_Skylines/Cities_Data/Mono/data-00000000160A3D00.dll
Assembly PopulationDemographics, Version=1.0.7746.31976, Culture=neutral, PublicKeyToken=null loaded.  [Mods - Internal]
 
Assembly resolution failure. No assembly named 'CitiesHarmony.Harmony, Version=2.0.4.0, Culture=neutral, PublicKeyToken=null' was found.  [Serialization]
 
ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetExportedTypes () [0x00000] in <filename unknown>:0 
  at ColossalFramework.Plugins.PluginManager+PluginInfo.AddAssembly (System.Reflection.Assembly asm) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
ColossalFramework.Plugins.PluginInfo:AddAssembly(Assembly)
ColossalFramework.Plugins.PluginManager:LoadDependenciesRecursive(Assembly, Dictionary`2, Dictionary`2, List`1)
ColossalFramework.Plugins.PluginManager:LoadDependencies(Dictionary`2, Dictionary`2)
ColossalFramework.Plugins.PluginManager:LoadAssemblies(Dictionary`2)
ColossalFramework.Plugins.PluginManager:LoadPlugins()
Starter:Awake()

Potential problem: FPS tanking

I am using FPS booster and whatnot to adjust the framerate to a lower level, but I received reports about this mod tanking performance.

Will need to investigate.

The bus doesn't start.

The bus doesn't start from the starting point.

When the gauge indicating the ride rate reaches its limit and then initializes, the bus must start, but the accumulation of the gauge begins again. It was only after a few repetitions of this action that the bus was able to start. I don't know if this action is intended, but I think it's the cause of the problem.

[https://www.youtube.com/watch?v=r9_HgQ6scbQ](youtube video)

IPT in use, I don't know if IPT works properly when not using it.

New feature: Departure Ushering

There is an ideal separation between buses at all times. As an example, a 4-bus bus line might have an ideal distance of 25%.

At termini, when an unbunching bus detects that the "distance" between itself and the previous bus in the line (should have departed earlier) is way too large, then it should not unbunch. It should depart immediately to catch back progress.

Upgrade the Service Self-Balancing: target high demand non-terminus stops

With #12 being released, bus efficiency should be higher than before, but the efficiency can still be pushed higher still.

Now, buses can be randomly sent to the terminus of the "route section" (ie route direction) with a higher relative demand. The problem is, when there are stops in the middle of the line which is in high demand (e.g. a very effective bus interchange stop), and this is detected by #12, buses will still travel to the terminus of the segment. Currently, there is an observable rate at which bus termini dispatches the next bus, so #12 causes a lot of buses to get piled up at termini, which can be much more than expected and starts blocking roads. On the other hand, the many buses are needed to ensure the termini keeps dispatching buses (to be sent to high-demand stops), so if you are using TLM, the line budget is forced to stay high, and the upkeep remains high too.

The improvement, then, is to allow buses to redeploy not only to bus termini, but also to high-demand middle-of-line stops. Another set of rules is needed for this feature, but most of the required code is already done in #12 as infrastructure, What is needed is truly only to think of the rules of sending buses to middle-of-line stops instead of always the termini, and add them to the existing code.

We will gradually add more details to this.

Bus Boarding at ~10000% at the First Stop of the Line

Hi, I am not sure if this is expected behaviour, but this mod is causing bus to "un-bunch" very aggressively at the first stop of the line, often to "boarding" at ~10000%.

It would be great if there is an option to lessen the unbunching intensity, or to toggle off the unbunching changes caused by this mod.

Incorrect detection of minibuses

It seems that we are not detecting minibuses correctly. Some buses with a way too high capacity count could depart early because the number of pax alighting was below the quick-depart threshold.

Consider UI additions

It has been thought by myself and suggested by others that this mod get new features that will most likely depend on modifying the UI, such as:

• Configurable two-side terminals (or even n-side terminals if it allows); this is about adding a simple toggle to let users designate multiple terminals; basically the "unbunch here" button from IPT2, but make it applicable to TLM and vanilla (update 30 April 2021: already implemented by TLM; soon we will read from them and apply the stop-skipping if possible)
• Configurable unbunching duration/bus interval; this is about providing some control as to how buses should unbunch, eg, unbunch so that the frequency can stay regular with respect to time (this might be hard due to requiring understanding on how the game works with time and etc)

All the above suggestions are hard to do because

• I am not exactly a UI programmer
• The complexity needed to handle multiple scenarios: vanilla, TLM, and IPT2; they require different UI designs to better fit into each of them

New feature: Redeployment by Teleportation

I have thought about this but keep forgetting about this...

Not actually real teleportation, but hear me out.

Sometimes, when we want to redeploy buses, the distances that the bus has to travel is too long to be of any effective use. Assuming that bus depots are set up appropriately, there should be a depot much closer to the redeployment target than whatever termini that the bus may happen to be at.

Then, instead of sending the bus from the termini to the target, we can send that bus back to the depot, and then call the other depot to deploy a bus. Total number of vehicles is unchanged, but suddenly, it is as if the bus has teleported from one side of the map to the other. Efficiency is therefore greatly improved.

The way that I see this implementation, is to store a flag/value, and after we mark a bus for RTB, when the replacement bus comes out, we can cancel the flag/value and tell that bus to move to the specified target to start their shift.

Inconsistent internal logic

The internal logic to determine stop-skipping was not consistent enough, so that the IPT2 plugin keeps generating bug reports.

• non-centralized logic to determine terminus status (it directly correlates with stop-skip status)
• existing logic not expressive enough to allow correct application of IPT2 unbunching rule interpretation

Negotiation Rounds against Compatibility Report

Eventually I have to face it.

With Compatibility Report making such a fuss over this + latest P2P DLC releasing, I had to check the situation of EBS + 81 Tiles.

Apparently, as I load up my main save file, the game crashed with a blank map.

I am currently testing with this version of 81 tiles due to the release of the latest DLC:

https://steamcommunity.com/sharedfiles/filedetails/?id=2862121823

I will have to determine which mod is causing problems, but this can be a good place to start.

New Feature: Unbuncher

This might look like a bruh moment, but what I am trying to do is to somehow stretch the unbunching of the buses when the budget is low.

The magic number waiting time of 64 might not work everywhere especially if the bus line is a long one. Such 64 waiting time would be insufficient. But there is also this problem where the wait counter can only count up to 255, so we will be forced to release the bus when it reches 255. This 255 will have to be part of the feature.

Essentially, I am trying to create a new unbuncher than the one in vanilla.

This is much more difficult than expected. It will work reasonably well when the bus line is short OR when the bus line is adequately supplied with buses, but it breaks down when the bus line is long OR when the line is undersupplied.

Recheck compatibility with More Citizen Units

Came across More Citizen Units (https://steamcommunity.com/sharedfiles/filedetails/?id=2654364627) and they warn against using a magic number to check for looping list validity.

I will have to recheck whether I am using such magic numbers.

Mod is broken: side effects caused by incorrect termini detection

Steam user reports this mod being broken and that buses failed to "bunch". This seems to align with my recent, personal observations during my CSL environment reset that this mod would throw Harmony exceptions + buses failed to "bunch".

Putting this on hold until I have the time to investigate.

"Pulling" buses to meet commuting demand (aka "service self-balancing")

As mentioned in #5:

Short-workings

[Operate from midway bus stops] is the same concept as short workings where you have a bus line that does multiple schools and letting them off at residential areas.

I have a rough idea from my observation on my save file: we should be able to simulate some sort of "asymmetric service headway".

What do I mean by "asymmetric service headway", for example, is some bus lines serving business districts. (This may be more obvious with e.g. Real Time installed.) There is always a certain direction of commuting at certain hours, eg in the morning ppl move from residential to commerial, and in the evening, ppl move the other direction. Even when I increase the bus budget, the commuter service is unstable because there are about 50% of buses stuck at the direction where there are less passengers. Or, for some reason the buses simply prefer to start service in a certain direction.

In real life, when it comes to commuter hours eg in Hong Kong, very often we see operators pull a few buses on the opposite terminus back to service on other direction. The bus would still belong to the same line, but it will not be used to transport passengers until it reached the other side of the line ("私牌回車"). Or, the bus would be pulled to help clear out passengers waiting at busy stops ("私牌中載").

This is an advanced feature; would be interesting to see this implemented.

For example:

• If the bus is empty:
  • Check if it should be "pulled to other places"
  • If yes, then set the next stop appropriately; let the bus be "pulled" to a better position

The above cannot happen too frequently otherwise too many empty buses will be reassigned too frequently, and some waiting passengers will get unfairly reduced services. Perhaps I set it to occur max once per minute per line, and perhaps the max number of buses being pulled depends on the budget %.

Perhaps similar to #9, I also set it such that this behavior can only occur when the budget is above 100%.

Buses still stops at bus stop

I am not sure if this is an issue or is it intended.

I have a line of 5 stops, there are 2 stops without people alighting or boarding. the buses will enter the empty bus stop, stopped and resumed service immediately if no passenger movement for that stop. Although the bus resumed faster than the vanilla, is it suppose to have a very brief stop at every empty bus stop or is it a drive-by (non-stop)? Of course, this does not include the starting of the line where there is unbunching for the buses.

Known Issue: transport line vehicle mass-return to base

Checking for vehicle overcrowdedness (i.e., whether a certain stop has received too many buses) is one core feature of this mod. This feature relies on the so-called "percentage progress" to be available. However, for some reason, this value is not always available.

Perhaps this is related to #33 . Maybe when we send vehicles to base, we did not set something correctly and the percentage progress becomes invalid. (An invalid percentage progress can be easily seen by realizing that the selected bus does not appear on the line bus dot list.)

This causes confusion to me and perhaps others too.

How to deal with this is an open question.

Seeemingly incorrect percent-progress of freshly-redeployed buses

This will greatly interfere with the improved unbunchers, which relies on the percent progress to calculate things... Where even are these buses on the progress graph???