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

[Vectorial1024]

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 Buses still stops at bus stop #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.