[patch] Vehicle steady speed at speed limit

[skreyola]

What I'd like to see is for fast vehicles to slow to the speed of the vehicle in their way instead of stopping and accellerating. They're wearing out their brakes and burning fuel to accellerate. hehe. Of course, if they can pass, they should, but if not, they should match speed.

--Mod Note: split from original topic and moved.
http://forum.simutrans.com/index.php?topic=5945.0

[ӔO]

What I'd like to see is for fast vehicles to slow to the speed of the vehicle in their way instead of stopping and accellerating. They're wearing out their brakes and burning fuel to accellerate. hehe. Of course, if they can pass, they should, but if not, they should match speed.

I saw this implemented for trains in experimental, however it's not for road vehicles.

[Fabio]

What I'd like to see is for fast vehicles to slow to the speed of the vehicle in their way instead of stopping and accellerating.

this would definitely be great, for all vehicles!

[prissi]

It is somehow implemented since some revisions ago. However, this is not possible to drive with the same speed, or they would never bee able to pass.

[paco_m]

And what about a max speed sign?

[skreyola]

It is somehow implemented since some revisions ago. However, this is not possible to drive with the same speed, or they would never bee able to pass.

I mostly use rail vehicles, where passing is not feasible, but on roads, this is a good point. I just think rails would be more efficient if the trains didn't stop and start but just matched speed with the train in front of them until they reached a parting of ways.

[prissi]

Trains in reality do the same, since they do not know (in general) if the train in front just broke down or is a goods train running late behind schedule. (Only very recently there is line base signalling on high speed lines.)

Furthermore, train slow down, when they approach a red signal 3-tiles 200, 2-tiles 100 and one tile in front 5. Just like in reality (and OpenTTD). It is rather the challenge of the player to not mix high-speed and freight (or just do so cleverly with bypasses and waypoints).

[Kondator]

It would be a great thing for road vehicles
I think the issue commented about the total stop is the only one thing  I don't  like from simutrans, and it make it almost impossible to me make fluid traffic. 

[ӔO]

Trains in reality do the same, since they do not know (in general) if the train in front just broke down or is a goods train running late behind schedule. (Only very recently there is line base signalling on high speed lines.)

Furthermore, train slow down, when they approach a red signal 3-tiles 200, 2-tiles 100 and one tile in front 5. Just like in reality (and OpenTTD). It is rather the challenge of the player to not mix high-speed and freight (or just do so cleverly with bypasses and waypoints).

I've seen the need for a steady speed feature and overtaking feature on the road.
If there are 2 to 3 vehicles in front that run at the same speed and than there is a vehicle behind it that is 5~10km/h faster, the vehicle behind will stop in the middle of the road when it catches up and will almost never overtake. This usually leads to a traffic jam and accordion effect of all the vehicles behind the stopped vehicle stopping and accelerating.

In real life, there's no obligation for the slow driver in front to pull over and let everyone stuck behind him pass, but it's courteous.

[paco_m]

Trains in reality do the same, since they do not know (in general) if the train in front just broke down or is a goods train running late behind schedule. (Only very recently there is line base signalling on high speed lines.

The point is that real trains have schedules to handle that, a slow train would never start just before the express running the same route - in Simutrans it is a normal and hardly avoidable situation.

[jamespetts]

Trains in reality do the same, since they do not know (in general) if the train in front just broke down or is a goods train running late behind schedule. (Only very recently there is line base signalling on high speed lines.)

Moving block signalling is not that new, nor is it reserved for high speed lines: it has been in use in London, for example, since at least 1992 on the Central Line (and if I remember correctly, earlier than that, even, since 1987 on the Docklands Light Railway), where speeds do not exceed 40mph. Having moving block signalling available as a(n expensive) signalling option in Simutrans would be a worthy addition, although I suspect that it would take a lot to code, and it's not really a priority.

[prissi]

Ok, in germany introduced 1976. But this was already 150 years of railways passed. So rather new still.

[skreyola]

AEO has a good point about the small advantage problem. That's usually what I see in my games, too. An accordian traffic jam. I don't recall recently seeing a road vehicle overtake another, because my fleet tends to be very similar in speeds between the fastest and the slowest. And when I run passenger/mail lines, the faster of the two is perennially running behind the slower, always stopping and starting like an impatient moron instead of like a professional driver, never passing, either because of the short distance between stops or because of some other reason I don't understand.

The point is that real trains have schedules to handle that, a slow train would never start just before the express running the same route - in Simutrans it is a normal and hardly avoidable situation.

That is an excellent point. And it's a bigger problem for rails than for road vehicles, because of the amount of mass involved. Profit margin sometimes makes it necessary to have a loco that accelerates slowly with a full load.
I guess there's something to the idea of its being a player challenge, but having fast track and slow track is sometimes more unrealistic than having one track/pair and seeing this stopping behavior.
If we had timetable control, I wouldn't mind, but as paco said, in ST we don't have schedules to prevent a slow train from starting right before and express needs the same track.

[kierongreen]

Moving block signalling is not that new, nor is it reserved for high speed lines: it has been in use in London, for example, since at least 1992 on the Central Line (and if I remember correctly, earlier than that, even, since 1987 on the Docklands Light Railway), where speeds do not exceed 40mph. Having moving block signalling available as a(n expensive) signalling option in Simutrans would be a worthy addition, although I suspect that it would take a lot to code, and it's not really a priority.

Small pedantic point but when the DLR was built in 1987 it had fixed block signaling, moving block was only introduced in the early 1990's...

[paco_m]

Full timetable control might be too complex, you would have to take care of vehicles speed and adjust travel times for each section - what happens when you have vehicles with different speed in the same line etc.?

However there are easier solutions, if you just add a "departure hour" (based on the time the in-game clock shows) option to the "minimum-load" option you can set at each station that would be sufficient to implement not a full timetable but an order of departure for the vehicles.
So the vehicle would depart when the other conditions (load limit or waiting time if set) and the dep. hour are reached.

For example: "0, 6, 12, 18" would define departures every 6 hours beginning with midnight for a line; if this is my express i would define "1, 7, 13, 19" for the slow train

This would also solve the spacing problem of vehicles of the same line leaving to close to each other and address the issue that in large railway stations (i mean with a lot of platforms using the select platform signs) some trains become blocked over a very long time before they can leave, especially when some platforms are closer to the exit than others.

Implementation should not be too complicated imho as it is just one additional check beside the existing ones like load limit...

[DirrrtyDirk]

The problem is that there are different modes for date and time (one mode uses e.g. the 24 hour clock to show a whole month passing, while others have actually days within their months, and these days have the clock running - much shorter periods than the other model), which in combination with different settings for game time to real time relations (bits_per_month setting), makes this not so simple at all, IMO...

[paco_m]

that's why I specified

"departure hour" (based on the time the in-game clock shows)

because this is the time the user sees and this time is already here so it is just a check against this given time, that there are other internal clocks also is something that does not matter for that checking - they remain untouched from that procedure.

[inkelyad]

This would also solve the spacing problem of vehicles of the same line leaving to close to each other and address the issue that in large railway stations (i mean with a lot of platforms using the select platform signs) some trains become blocked over a very long time before they can leave, especially when some platforms are closer to the exit than others.

I was trying to solve spacing problem for Experimental. (See here). Published version was with bad bugs, yes. But still there was no comments about it. And no downloads. So is it really a problem?

[paco_m]

I was trying to solve spacing problem for Experimental. (See here). Published version was with bad bugs, yes. But still there was no comments about it. And no downloads. So is it really a problem?

Personally i make this with signal spacing for trains and for vehicles you can now use traffic lights so it is in fact not an urgent topic, at least for me - but like it is always asked in several posts I mentioned it here.
Regarding to your exp-patch I got lost somewhere in the middle of the discussion and this solution is imho a bit too complex,
I would prefer something more easier just to make orders of departure without the intent to manage the whole line and calculating runtimes to the destination and all that stuff...

[prissi]

There are two clocks a user sees. 1month = 72 hours (3 days, show_month=1) Useful for smaller values of bits_per_month, old default.

Or you see the one with 24 hour a day and a fully month (although all hours are slightly different lenght for every month, since the month has the same length in ms but different number of days).

[paco_m]

There are two clocks a user sees. 1month = 72 hours (3 days, show_month=1) Useful for smaller values of bits_per_month, old default.

But this is a simuconf.tab option, the user sees only one clock (at the same time) and I think settings like departure time should be compaired always to the current and for the user visible clock, anything else would be very hard to handle for the users.

[DirrrtyDirk]

that's why I specified  because this is the time the user sees and this time is already here so it is just a check against this given time, that there are other internal clocks also is something that does not matter for that checking - they remain untouched from that procedure.

What I meant was that, depending on the individual user's settings for time display format and bits_per month, the differences for possible steppings in departure time vary a little too much.

For example, in one scenario each step (between possible departure hours, if we only allow full hours on the visible game clock) might be over 11 minutes long (real time), while for the next player (with different settings) these might be only less than 19 seconds long. And >11 minutes or <19 seconds per step... I'd say the difference is a little too big. So for one player you'd need a much finer scale, while the other would probably have no use for it. That's the problem I was referring to.

[paco_m]

Well, I was not aware of this difference, always used the standard time -
however it should not be so difficult to handle this:

standard clock setting: 6, 12, 18
means the full hours (as you say around 19secs per game-hour and aprox. 8min for the full interval/game-day)

other setting: 15, 30, 45
means the minutes (full interval/game-hour around 11min=660secs => 11 secs per game-minute)

I think this is an easy and acceptable solution for both settings...

PS: Is there any reason for having this two so different time systems?