Skip to main content ↑ ↓
Topic: Signal for Scheduling (Read 12069 times) previous topic - next topic

Signal for Scheduling

Hi all,

I have buses that run in loop on the same route but they always end up clustering together one after another.  :-\

I just wonder if it is possible to create a special signal that behaves like this :
1)  Upon creation, it shows a green light
2)  When a player click on it, a dialog box is shown where the player can set a countdown time period. The dialog box should also show the current countdown time figure if countdown is in progress. Optional buttons (a) to restart countdown and (b) to toggle between green/red light will be convenient.
2)  After a single vehicle p****es throught it, it will immediately turn red to block further traffic
3)  Countdown starts as soon as the red light is on.
4)  Once the countdown is finished, green light will be shown again

To use it,
1)  Set up a dedicated side-lane for the bus route (so as not to block other traffic)
2)  Place a special signal on the side-lane, setting it to an arbitrarily large countdown period (X)
3)  In the bus schedule, include a way point right on the special signal to ensure that buses will drive past it
4)  Send out the first bus to drive past it. Red light turns on and countdown starts
5)  Wait till the bus finishes the loop and return to the special signal. Click on the special signal and note down the current countdown time figure (Y)
6)  Calculate (X - Y) / [Total No. of Buses on the Route] , and set the result as the new countdown time period (which should also reset the current countdown time figure to the new setting)
7)  Send all buses out for queuing at the dedicated lane if the lane is long enough to accommodate them all. They will then depart one by one, equally paced.

Upon running the route,
(A)  if a bus arrives earlier than scheduled, it will wait at the special signal for the green light
(B)  if a bus arrives later than scheduled, it can still p**** through but countdown will start late, meaning that all subsequent buses can only drive p**** at a later time.
Thus, equal pacing can be maintained. A train/tram/monorail version of the signal can also be introduced as an alternative to long block signal if more precise time control is desired.

It doesn't matter in what unit the time figure is measured. It's equally fine to use milliseconds as to use "number of simulation cycles", or any similar unit deemed preferrable.

I think it will not take a lot of programming efforts to create this special signal. It will act as a remedy for not being able to set a fixed time schedule for bus/tram/train departure which we normally have in reality. It helps to maintain a more regular service of buses and trains alike by smoothing out the occasional delays.

Sincerely hope that this special signal will be approved and get implemented. A thousand thanks in advance!  :D

Re: Signal for Scheduling

Reply #1 –
'Busses bunching up is actually quite realistic ;-) However, one easy way of going some way towards solving the issue in the game is to set one or two 'busses to wait at certain stops for a certain load percentage; if there is enough variation in which 'busses are set to which stops, bunching should be avoided.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: Signal for Scheduling

Reply #2 –
Maybe I can't enthuiastically support this idea but I certainly do not think it is a bad idea.  I would like to see a more robust p****enger situation.  Actually the only downside to me for this idea is the need for more roads, even short ones.

It seems to me that although the p****enger spawn works very well it is somewhat lacking in strategic capability for the player.  To be more specific, when I click on an industry, it would be great if I knew the number of workers who worked there and what shifts they worked.  That way if I could schedule departure times for buses, it would be possible to roughly estimate if the line would be worthwhile - just some strategy stuff to play with although it likely could get pretty heavy into micromanagement.

That said, I do not mean to hijack Knightly's thread nor offer my idea as an extension.  I meant it merely as something else to consider in the discussion of p****enger travel.

Re: Signal for Scheduling

Reply #3 –
Using the wait for 100% load in combination with a certain waiting time does work for me quite well. You won't get a fixed interval, but busses are not bunching up.
Bob Marley: No woman, no cry

Programmer: No user, no bugs


Re: Signal for Scheduling

Reply #4 –
@ jamespetts and Combuijs :

Many thanks for your suggestions. I did think about using this approach but this "wait-for-loading strategy" may block and delay other routes' buses which share the same bus stop or which need to p**** the portion of road where the bus stop lies. It also doesn't work for bus stops that can easily fill the bus with 100% load in a short time.

Besides, such waiting is indiscriminating -- that is, even if the buses are fine in running at equal pace, they are still forced to wait for some time before departing the bus stop and that would unnecessarily lengthened the time for serving the route.

As Combuijs has pointed out, it cannot maintain a close-to-equally-paced schedule. A close-to-equally-paced schedule is good not only because it avoids bus clustering and the related traffic jam, it also increases bus service regularity (this helps to avoid overcrowding at bus stops and minimize city cars)  and the profit of the route (buses no longer run at zero or low load).

@ Roads :

Many thanks for your comment. Indeed, some portion of road needs to be reserved for such scheduling. Such road reservation can be minimized to 1 tile if road configuration is like an "H" and the special signal is placed right in the middle of the "H". But of course, other routes may need to set way points to ensure their buses won't get caught in these special signals.

Besides, as long as you are confident that no other vehicles will p**** a certain road portion (especially the case if you are dividing city into different regions, each of which are served by a dedicated route), you don't need to reserve any specific road portion to set up the special signal.

If you are still feeling uncomfortable about it, the special signal may be made in such a way that a single route can be registered with it and only buses of that route will be affected. However, that will most probably increase the programming work and may not be accepted. Nonetheless, this would be the most logical solution, I would say, and a label can hover over it to show the registered route.

As for your suggestion regarding industries showing how many or percentage of workers from each city, I think it is good, though I am not sure whether the industries simply "employ" workers from cities with available route and not from those without, instead of having a preset worker percentage for each city.

@ All :

Actually, I have asked Vilvoh for opinions before posting this extension request, and he recommended this old forum thread to me for planning bus routes. Both VS and Vilvoh's circular route solutions are ingenious. Both approaches eliminate the need for more than one bus on each route and prevent roads from overcrowding with buses of different routes.

For VS's adjacent rings approach, the circle served by a single-bus circular route cannot but too large, thus more adjacent circular routes are needed to accomodate city growth, and p****engers will inevitably need to change buses more often to arrive at the desired destination, especially those living in the outskirt. Besides, there will be many routes to manage and to take care of. This approach can be optimized with the special signal. We can build larger circular routes with 2 or 3 buses, thus reducing the number of adjacent circular routes. P****engers will change buses less frequently. Fewer routes also means easier monitoring, maintenance and management.

As for Vilvoh's radial rings approach (radiating from city centre), there is a maximum or optimal number of such radial rings and if the city growths really large, these radial rings would still have to get larger and larger. In that case, more than one bus will be needed in each ciruclar route and the special signal can help to ensure regular bus service. In short, the special signal increases the scalability of such radial ring routes.

One more comment : for those who would like to create a bus terminal (an area with one-way entrance lane(s) and parallel exit lanes each for a single bus route and has a terminal bus stop on it), the special signal can be placed right before the terminal bus stops to enable time-scheduling.

Re: Signal for Scheduling

Reply #5 –
Quote
I did think about using this approach but this "wait-for-loading strategy" may block and delay other routes' buses which share the same bus stop or which need to p**** the portion of road where the bus stop lies.

Very true, but your solution with a time schedule is suffering from the same problem!!!

Quote
It also doesn't work for bus stops that can easily fill the bus with 100% load in a short time.

Yes, but if the bus is full there is no need to wait, is there? Sounds a bit strange to me: you walk to your local bus-stop, you see the bus is waiting for you, and then you can't go in, because it's full! Why wait for p****engers that can't travel with you?

If they easily fill the bus with 100% load every time, then this does not matter: the stop is hardly a stop then for every bus, e.g. every bus is affected by it in the same way.
Bob Marley: No woman, no cry

Programmer: No user, no bugs


Re: Signal for Scheduling

Reply #6 –
@ Combuijs :

Quote from: Combuijs – on
Very true, but your solution with a time schedule is suffering from the same problem!!!

Yes, you are right Combuijs :) . But I think a bus stop's location is usually set to maximize coverage (and minimize overlapping coverage too) and hence it may not be changed easily. But for a road signal, I guess we can have somewhat more liberty as to its location. Besides, bus stops and the special signal which I am proposing are fundamentally different in function and nature -- many bus routes may share the same bus stops, but special signals are usually used by one route and can be easily circumvented by way points.

Quote from: Combuijs – on
Yes, but if the bus is full there is no need to wait, is there? Sounds a bit strange to me: you walk to your local bus-stop, you see the bus is waiting for you, and then you can't go in, because it's full! Why wait for p****engers that can't travel with you?

If they easily fill the bus with 100% load every time, then this does not matter: the stop is hardly a stop then for every bus, e.g. every bus is affected by it in the same way.

What you said is definitely right : of course, if the bus is full-loaded, why the need to wait?

However, please note that when I said "It also doesn't work for bus stops that can easily fill the bus with 100% load in a short time", what I was having in mind is this thread's main theme of maintaining equally-paced bus scheduling, and we are not discussing bus loading problem here. Since you suggested using load percentage + maximum wait time as a method to maintain the equally-paced bus scheduling, what I said was to point out that there are cases where your approach will not work as intended. I hope you can understand my point clearer by now.

And you are absolutely correct to say that a "stop is hardly a stop then for every bus" if "they easily fill the bus with 100% load every time". But again, in view of the main theme of maintaining equally-paced bus scheduling, this amounts to admitting that your approach doesn't work in such situations -- those bus stops can't maintain a certain distance between the buses as intended.  ??? I hope you can see now that you are a bit self-defeating in your argument here.

I strongly suggest you to re-read my previous posts with the main theme of maintaining equally-paced bus scheduling in mind. Anyway, thanks a lot for your feedback, Combuijs :D

P.S. If I have not mistaken the developers' intentions, the loading percentage function and the maximum wait time function which go hand in hand are originally designed as a means for controlling loading, but not for equally-paced time scheduling. They have nevertheless been exploited as a workaround for equally-paced time scheduling due to a lack of similar function offered by the game. If we have this newly proposed signal, we don't have to exploit those 2 functions anymore for purposes which are not originally intended.  ;)

Re: Signal for Scheduling

Reply #7 –
The wait for intervall function was only added for equal spaced buses. The AI never use it, and neither do I.

Re: Signal for Scheduling

Reply #8 –
I didn't read your post (sorry), but if you use choose-sign, a bus will wait there until next stop will be empty.

Re: Signal for Scheduling

Reply #9 –
Quote from: prissi – on
The wait for intervall function was only added for equal spaced buses. The AI never use it, and neither do I.

Thanks a lot for your feedback, prissi.

But isn't that the month wait time function only works in conjunction with percentage of loading function? If we use it alone, there should be no effect, right? That means, its primary function is simply to prevent a bus from waiting to load for too long, and that's why I say it's a function for the loading part.

IMHO, since the effect of month wait time function depends also on the p****enger/freight level at the stop (ie, if load percentage is achieved the vehicle will drive off regardless of whether the month wait time has reached) , it is difficult if not impossible to use it to precisely control the distance between 2 buses.

Please correct me if I am wrong and thanks once again for your clarification :D!

EDIT:

Quote from: z9999 – on
I didn't read your post (sorry), but if you use choose-sign, a bus will wait there until next stop will be empty.

No need to say sorry, z9999, for I have the bad habit of expounding my ideas too far (to avoid being misunderstood) and making my posts lengthy  :P

As for your suggestion, I must say is a very good suggestion which I have not thought about before. Yet, the limitation is, if we need to keep 2 buses at a distance that spans over 2 or more bus stops (which is more likely the case than not), this approach will not work.

But many thanks for your suggestion anyway!  :D

Note by admin: please, do not double-post so much. Preferentially, use "Modify" tool, and everyone will see a "New" tag in topic index of this board. ;-) .
- IgorTekton

Re: Signal for Scheduling

Reply #10 –
Hi! As to my "ingenious" design, perhaps you misunderstood something: I keep them in a purely hierarchical structure. Touching can happen, but only on one level in the same branch.

Geographical placement aside, the situation looks like this:

(kind of fractal-like, no?)


Keeping vehicles from "stacking" has been a common issue since the day Simutrans was born. Since there has not been found any solution in the past... what, 11 years? Well keep trying - we might get there one day.

PS: Oh - just remembered the solution: add vehicles only when the line is too overcrowded ;D


PPS: I have nothing against the proposed kind of "signal". If I do not want it, I do not build it, simple. Just as with choose signs.

The one issue that might kill this idea is - how general will the signal be? Will it affect all vehicles? Since you speak about buses, do consider implications of stopping citycars and stacking them at the sign. What happens in the city? What happens to other lines? If citycars can p****, then only your vehicles are stopped? Citycars start stacking behind them. What about other lines accidentally going through the same place? And so on. It could be very hard to use this sign properly, requiring a lot of planning. Or impossible in most conditions.

But as I said... not against.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: Signal for Scheduling

Reply #11 –
Quote from: VS – on
Hi! As to my "ingenious" design, perhaps you misunderstood something: I keep them in a purely hierarchical structure. Touching can happen, but only on one level in the same branch.

Sorry for any misinterpretation and thanks a lot for your clarification :D Really very systematic. If I haven't got you wrong, according to your diagram above, does it mean that a p****enger needs to change vehicles (whether train or bus) 4 times to get from a stop on the smallest circle in a certain city to a stop on the smallest circle in another city?

Quote from: VS – on
The one issue that might kill this idea is - how general will the signal be? Will it affect all vehicles? Since you speak about buses, do consider implications of stopping citycars and stacking them at the sign. What happens in the city? What happens to other lines? If citycars can p****, then only your vehicles are stopped? Citycars start stacking behind them. What about other lines accidentally going through the same place? And so on. It could be very hard to use this sign properly, requiring a lot of planning. Or impossible in most conditions.

You are getting right to the point. This is also something that I have been worrying about but have not thought of an ideal way to resolve. But I think it would be easier to code by making it general rather than specific.

Although I propose above to register the route with the special signal and only registered route's buses are affected, that doesn't really solve all the problems : if the route's bus is waiting at the special signal, it will still block the way of other routes' buses and keep them waiting behind, even if they don't belong to the registered route.

So, I think a once-and-for-all solution is to modify the route-finding logic to avoid any road portion that has such special signal on it, as though they are dead-end lanes, EXCEPT if a way point is specifically set on the special signal. Of course, that would amount to automatic lane reservation but if the special signal is placed wisely, the effect can be reduced to a minimum.

I know this isn't going to be a good solution, as it would touch upon the program logic for route finding, so I sincerely look forward to any input from you all regarding this aspect.

Many thanks once again!  :D

P.S. I want to point out that, even in reality, we have to set aside some space (namely, lanes in bus terminals) in order to achieve time scheduling. So, it will just be normal if we need to sacrifice a few tiles of the road in order to achieve similar time scheduling in Simutrans.

Re: Signal for Scheduling

Reply #12 –
I am stupid... that is just what you proposed in the beginning. I should have read more carefully ::) That could work well with other player's traffic. Only citycars don't have routes, they just drive more or less mindlessly, so it would not work well with them.

But I feel that it could be simpler - to me it seems that this sign would be useful mainly in cases where there are not many vehicles on the particular route, which also implies less developed city - or rather lower population density - and lower "density" of citycars. Then it should not matter so much.

By the way: you can use traffic lights as a simple "ticker" that holds and releases traffic periodically, too. It is probably the only function they can serve, apart from annoyance or eye candy.


Offtopic, re the line layouts -

I like having things under control and this design stems from that fact. There should be always only one place where lines touch with the higher level. Then it is always known which stations are hubs, and there are no nasty surprises like 10549 people wanting to travel by a single bus to castle and there take another bus to next town.

Circular routes (for all kinds of rail) I use simply because they are more effective in terms of capacity. All vehicles move in the same direction and thus don't wait at crossings etc. Or at least it feels so to me. It sort of follows that one line serves one area - even if it could be in principle possible to have them cross at some place, as long as it is not a station and don't create another hub.

Usually there is some "historical reason" and I don't have one single line at top of the hierarchy. There the 4 hops come in handy (sometimes the smaller loops don't even exist and it's only 2), as maximum is usually set to 8. By keeping the number of hops between any places lower than this limit, it is ensured that everything will find route as long as there is connection. And, if maximal number of hops is 8 due to performance issues and you never reach that, guess what - it runs faster :)

Of course this is no big reason to do so, as other players build networks without this artificial restriction and can play just fine. But it helps to keep the network well understandable; when there is a rise of flow in some direction, you can just look at destination and immediately see what lines will be hit.

PS: if you need absolute overkill, use ships. They just drive over each other and thus scale well for truly insane amounts of cargo.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: Signal for Scheduling

Reply #13 –
Quote
As for your suggestion regarding industries showing how many or percentage of workers from each city, I think it is good, though I am not sure whether the industries simply "employ" workers from cities with available route and not from those without, instead of having a preset worker percentage for each city.

If you click on any industry now, the popup tells you in what city the workers live.  So this situation is totally independent of routes and roads and even the same continent.  My idea is to have the number of workers based on the output of the industry once the player has established a connection to it.  This would provide the player some options.  He could think about how he could increase the output of the industry for no other reason than to increase the worker count.  Obviously you would need shift times to schedule buses.  These shifts need not and probably should not all begin at the same time just as they do not in real life.  For example a sand plant often starts its shift very early (5:00 AM for the one here)while a car dealership salesman might not show up until 9:00 AM.

While I like your idea I think the ability to schedule buses to leave a stop at a certain time (not a wait time or based on load but actual game time) would work better.  This is regardless of the idea of industry worker count and travel.

Re: Signal for Scheduling

Reply #14 –
There are no "hours" in Simutrans, only for eye candy (you can't see a thing in the dark except for lights). The period closest to reality you can get is months. Or, if you put up with three days per month... then maybe.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: Signal for Scheduling

Reply #15 –
In that case VS, whenever the extension requests stop flying fast and furious, expect one from me requesting time. :)

Re: Signal for Scheduling

Reply #16 –
Back to topic: There are also traffic lights, which even work on a straight ways and would provide some spacing.

The one month wait time limit is for internal reasons. And you can easily force a bus to wait a a stop. Just use a goods only station. A bus will never load anything there.

Re: Signal for Scheduling

Reply #17 –
Quote
And you can easily force a bus to wait a a stop. Just use a goods only station. A bus will never load anything there.

Prissi, unless I'm missing something here, wouldn't a bus waiting at a goods only station cause the goods trucks to have to wait as well?

Re: Signal for Scheduling

Reply #18 –
Not, if there are also no goods to wait. I mean, just build a goods station for your bauses to space out.

Re: Signal for Scheduling

Reply #19 –
Ahhh Prissi you've been doing freeplay.   ;D

Who can afford a station just for bus spacing?  Not me.  I still set my games up where at least two industries share a station to keep costs down.

Re: Signal for Scheduling

Reply #20 –
Then you should not care about bunching, because it indicates that you are using too many buses.

Re: Signal for Scheduling

Reply #21 –
Quote
Then you should not care about bunching, because it indicates that you are using too many buses.

Actually I think it is because my game has not progressed to the point where I have a big profit margin.  But of course you are right.  If you can't afford a station for spacing, you're probably either too little to worry about it or have too many buses.  Sorry for wasting your time arguing about it.
 

Re: Signal for Scheduling

Reply #22 –
@ IgorTekton : Really sorry, I just forgot that when I reply separately to 2 persons' replies, my 2 posts actually constitute double posting. Will watch out next time  :)

@ Roads : Thanks for your feeback. Regarding your preference for "the ability to schedule buses to leave a stop at a certain time", I am sorry that this has already been included in the Denied Extension Request List (pls see the item "Timetables" under the heading "Denied for other reasons"). That's why I am trying to think of another way of achieving similar time scheduling, which should entail less development efforts, hoping that it can finally be approved.

@ prissi : Thanks a lot for your suggestion regarding setting up a "dummy stop" just for pacing out the buses. But as I have said before, such waiting is indiscriminative : if the buses are currently running fine at equal pacing, they will still have to waste time stopping there. This will unnecessarily lengthen the time it takes to complete the route. Besides, if a circular route is rather large with just 3 or 4 buses, the waiting time needed to keep buses at appropriate distances will be quite long, which would not be desirable at all.


I understand very much the reason why most of you would like to remind me of the various ways to achieve a certain extent of pacing among buses on the same route with the existing game capabilities -- there are simply so many extension requests and developers don't have time to cope with all, and thus have to be selective. But then, I just want to emphasize once more that, the current ingame functions actually cannot maintain a close-to-equally-paced route without significant drawbacks (pls see comparison table below) -- after all, they are not designed to do so in the first place.

So, I think, I will now recap and then let the devotees and developers decide whether this is a worthwhile improvement -- whether the benefits to the players justify the programming costs of the development team.

Before the recap, I would like to say a bit more about my conceived setup of the road to use with the special signal. I have found out that Timothy has done a nice set of road signs which you can find here. He introduces a "private" road sign, and I have tested ingame that this sign can really stop city cars from venturing p**** it. So, the city car problem is solved, and as long as we set aside a portion of road for the queueing and waiting, the special sign should work fine.


Recap here :

Signal Design
1)  Upon creation, it shows a green light
2)  When a player click on it, a dialog box is shown where the player can set a countdown time period. The dialog box should also show the current countdown time figure if countdown is in progress. Optional buttons (a) to restart countdown and (b) to toggle between green/red light will be convenient. Any unit for time measurement like Simutrans world seconds or simulation cycles will be fine, but cannot be large units like number of months which makes fine-grained calibration and calculation difficult.
3)  After a single vehicle p****es through it, it will immediately turn red to block further traffic
4)  Countdown starts as soon as the red light is on.
5)  Once the countdown is finished, green light will be shown again
6)  Please set the one-way attribute for it (to save player the cost of another one-way sign)
7)  Please set the private attribute for it (property similar to Timothy's "private" sign)

Road Setup
1)  Set up a dedicated side-lane for the bus route (so as not to block other traffic) or find a portion of road which you are confident that other vehicles won't p**** through
2)  Place a special signal on the side-lane
3)  Place "private" signs wherever necessary (It would be convenient if Timothy's road sign set can be included in the standard pak)
4)  If a bus stop is wanted, place it after the special signal
5)  Buses from other route can set way points to circumvent the lane whereupon the special signal lies

Signal Usage
1)  Setting the special signal to an arbitrarily large countdown period (X)
2)  In the bus schedule, include a way point right on the special signal to ensure that buses will drive past it
3)  Send out the first bus to drive past it. Red light turns on and countdown starts
4)  Wait till the bus finishes the loop and return to the special signal. Click on the special signal and note down the current countdown time figure (Y)
5)  Calculate (X - Y) / [Total No. of Buses on the Route] , and set the result as the new countdown time period (which should also reset the current countdown time figure to the new setting)
6)  Send all buses out for queuing at the reserved lane if it is long enough to accommodate them all. They will then depart one by one, equally paced. Alternatively, you may send them out one by one if your lane is not long enough for queuing up all buses.

Bus Behaviour with Special Signal
(A)  if a bus arrives earlier than scheduled, it will wait at the special signal for the green light
(B)  if a bus arrives later than scheduled, it can still p**** through but countdown will start late, meaning that all subsequent buses can only drive p**** at a later time, keeping the preset distance.
(C)  Equal pacing can then be maintained.

Miscellaneous
(A)  The special signal is best used in a bus terminal layout
(B)  A train/tram/monorail version of the signal can also be introduced as an alternative to long block signal if more precise time control and more equal train pacing is desired.

So, these are probably all the ideas I can think of, and from now on I will leave it to you all to decide whether or not to develop this new feature. Sincerely hope that this special signal will get implemented and make vehicle bunching in general a thing of the past, after, according to VS, 11 years of struggle.  :D


EDIT 1 : Below and green words above

I think, before I go, I should elaborate by comparing prissi's dummy stop approach and the special stop that I am proposing, so that you will see more clearly why the special stop works better.

First of all, some simple algebra for prissi's dummy stop approach. ****uming :

  O = original total travelling time, which includes any waiting time, of the route
       (note here that our focus should be on travelling time, not travelling distance, as we are dealing with time scheduling)
  B = number of buses running on the route
  W = waiting time at the dummy stop
  A = actual total travelling time = (O + W)

Then, in order to keep buses apart with equal travelling time, we set waiting time = separating travelling time between buses :

           W = (O + W) / B
         BW = O + W
    BW - W = O
  (B - 1)W = O
           W = O / (B - 1)
 
So, what does this answer mean? If O = 1Hr and B = 4, the optimal waiting time (and hence separating travelling time) will be 1/3Hr. In other words, at anytime, there will only be 3 buses running around on the route, while 1 bus is always kept waiting at the dummy stop. When waiting finishes and the bus drives off, another bus will just arrive at the dummy stop and start waiting till yet another bus arrives. And obviously, A is 1/(B-1)=1/3 times longer than O.

Having said the above, we can now proceed to a detailed comparison between the 2 approaches :

  Dummy Stop Approach   Special Signal Approach
         
Average Actual
Total Travelling
Time 		  {1 + [1 / (B-1)]} O
That means, travelling time is unnecessarily increased by O/(B-1) 		  O
         
Number of Buses
Actually Running
on the Road at
the Same Time 		  B - 1
That means on the whole, 1 bus is always wasted on waiting at the dummy stop without generating any profit 		  B
         
Nature of Waiting   Both Indiscriminative and Discriminative
Indiscriminative here means waiting is unavoidable regardless of circumstances. 		  Only Discriminative
Discriminative here means waiting will only occur if a bus arrives earlier or any previous buses have been delayed.
         
Average Waiting Time   Somewhat larger than W
There are 2 different waiting components :
(1) Waiting indiscriminatively at the Dummy Stop for a constant duration of W
(2) Waiting discriminatively before the Dummy Stop only if the previous bus is occupying and waiting in it 		  Somewhat larger than zero
Will only wait discriminatively if countdown has not finished
         
Bus Behaviour   If a bus arrives early, it will wait till the previous bus has finished waiting and drives out of the Dummy Stop, before it drives in and wait for the constant duration of W.
If a bus arrives late, it can drive into the Dummy Stop immediately, but since the W duration will expire late, subsequent buses can only drive in at a later time		  If a bus arrives early, it will wait at the Special Signal till countdown finishes and green light turns on.
If a bus arrives late, it will drive past the green light, but then the countdown starts late, meaning that subsequent buses can only drive past at a later time.
         
Interval of Bus
Arrival 		  O/(B-1)
Longer than expected
May lead to overcrowding at bus stops if the route must be served by B buses
May even lead to fully-loaded buses and trigger the pitfall described below 		  O/B
Just as expected
         
Profits from Route   Less than expected
Buses may be fully-loaded and cannot pick up more p****engers.
Longer bus arrival interval means lower profit over the same period of time.
Overcrowding at bus stops may lead to loss of p****engers and p****enger dissatisfaction. 		  Just as expected
         
Road Reservation   Required.
As there is almost always a bus waiting at the dummy stop 		  Required.
To a larger extent because the signal interferes with other traffic, and to a lesser extent because sometimes a bus is waiting at it and will block other traffic
         
Unit of Time Measurement
and Calibration 		  The various 1/x month choices
Precise calibration is not possible with such unit of time measurement, rendering equal pacing difficult and almost impossible to achieve in most circumstances 		  Any unit like Simutrans world seconds or simulation cycles
Fine-grained, accurate calibration is possible
         
Measurement of
Original Route
Travelling Time 		  Calculate the difference between the starting time and the ending time shown on the status bar
(In Simutrans world hours and minutes)
Extra calculation is needed to find the closest 1/x month choice 		  Calculate the difference between the starting countdown figure and the ending countdown figure
(Please see Signal Usage above)
No extra calculation is needed
         
Cost of Structure   400ยข for a Freight Yard   A Special Signal should cost a few hundreds only
         
Pitfall   If a bus is already full-loaded before it arrives at the Dummy Stop, it will not wait for the constant duration of W at all but will drive away immediately, and the bus pacing will be disrupted.   None
         
Solutions to
Certain Drawbacks 		  (1) Purchase and deploy one more bus on the route : a wasteful investment of money
(2) Satisfice with imperfect bus pacing : bus arrival irregularity may still lead to certain extent of bus stop overcrowding, p****enger loss and/or dissatisfaction, as well as profit loss  		  Not Applicable
To conclude, the Dummy Stop Approach is relatively uneconomical and with which it is impossible to achieve equal bus pacing in most circumstances. Hope that by now, most of you will support the implementation of the Special Signal so that all Simutrans players can have a more convenient tool to schedule their vehicles better. Thank you.

EDIT 2 : Orange words above