Overtaking. Fun patch.

[isidoro]

After reading http://forum.simutrans.com/index.php?topic=339.0, I decided to try my programming skill with it.  I'm highly proud to say that... it was a complete failure   

Then I thought that a partial solution to that problem would be overtaking (yu-yu  ).  Once a vehicle is going to stop due to another vehicle in the way, it can try overtaking.  I have read that this is a very sensitive topic here, so excuse me if this is not convenient.

After some tries, I came to this patch.  It is not serious, only a first approach.  You can try it with r2011 and pak64 and the attached savegame.

A vehicle (the overtaking vehicle) will try to overtake if:

• The road is blocked by other road vehicle (the overtaken vehicle)
• Neither the overtaken nor the overtaking vehicle is being overtaken or overtaking
• The speed of the overtaking vehicle is at least 5 kmh over the maximum speed of the overtaken vehicle

The tiles involved in the overtaking are calculated.  For all these tiles, it must happen:

• No stops, no crossings, no signs, no change in speed limit
• Flat tiles (no slopes)
• No other vehicles apart from the two involved

Problems:

• Facing traffic is not checked apart from those tiles (I don't know how to take facing traffic apart).  It should be checked for some tiles more.  That means that you can see "some frontal crashes" (not actual crashes).
• City traffic (that belonging to no player) is not overtaken (not checked)
• Perhaps overtaking should not be allowed in bends and now it can happen
• Calculation (specially for diagonals) should be polished
• Don't know if there are performance issues

This is only some fun in order to learn something about Simutrans source.  Be kind to me.   

[VS]

I have read that this is a very sensitive topic here, so excuse me if this is not convenient.

I'd say implementing this yourself does not count as a making problems (as opposed to asking others to do it).

PS: I have no experience with Simutrans code, but... am I right that the "expensive" check for overtaking happens only in situations when the vehicle actually has something in front of it?

[prissi]

Some comments to get this done to be ready for inclusion:

First: Don not touch ding_t, if you can avoid it. I would suggest a flag in vehikel_basis_t for the static offsets. There are still six flags left to fill one byte. Add one for overtaking shift, which is better done directly in get_screen_offset() (One can think of making this function virtual for this purpose, if one worries about speed.)

The offsets should be init by set_diagonal_multiplier(), since the it should be clear if driveleft is enabled or not, and it is called only a single time. ding_t::init is not the right place, since trees and all other stuff rarely overtakes ...

Also the check for stree speed should just check if the car in question can still go with its maximum speed. I do not worry about 80kmh limit, if my bus runs only 75kmh ...

I would also not work in hop(). Use automobil_t::betrete_feld() (since it is car specific.) to update convoi counter.

And the check for overtaking should by probably better done in a step and not in a sync_step. Look at the way trains (or airplanes) are doing it: They use step for this, becuase during a sync step vehicles are moved in random order (and it is time critical). The trick is: They retrun false for the next tile free check, but the do not reduce the speed. Next time, (during a step) they check if the road is really blocked.

is_moving() will indeed report all moving stuff, no matter what direction. You can check for facing traffic (since you do not have crossings) easily by calculationg the direction on this tile (from previous and next coordinate) and the use ribi_t::rueckwaerts() to get the reverse. Any vehicle with this fahrtrichtung will come against you.

And one further comment on some formatting rules of simutrans. if() return; is not allowed, please use
if() {
   return;
}
(Stricht one statement per line rule.)

And avoid if(a) {
  if(b) {
     ...
  }
}
use
if(  a  &&  b  ) {
}
...

But others than these it is good to see somebody else again working with the source code.

[isidoro]

[...]
PS: I have no experience with Simutrans code, but... am I right that the "expensive" check for overtaking happens only in situations when the vehicle actually has something in front of it?

Neither do I,  .  In my opinion, you're right.  The check is done whenever there is something in front of the vehicle.  Without overtaking, that check would be repeated every now and then but if overtaking succeeds, it is done no more.  But overtaking code is also an overhead in itself.

Some comments to get this done to be ready for inclusion:

Thank you very much, prissi, for your answer.  I have to study it.  Some things are easy to change (coding style, etc.), some more complex.  I would like to get the code polished and sure will need your help. For the easy ones:

The offsets should be init by set_diagonal_multiplier(), since the it should be clear if driveleft is enabled or not, and it is called only a single time. ding_t::init is not the right place, since trees and all other stuff rarely overtakes ...

I have noticed that.  As a static member I was looking for a place only executed once to set the offsets, but wasn't sure of where.  By the way, I need a way to measure distances on diagonals to fix the code there.  And I suppose that that has to do with the diagonal_multiplier topic of last revisions, hasn't it?

Also the check for stree speed should just check if the car in question can still go with its maximum speed. I do not worry about 80kmh limit, if my bus runs only 75kmh ...

At the beginning I programmed that that way, but then I was concerned with facing traffic in order to simplify calculations.  I decided that the worst case is when facing traffic comes with maximum road speed.  To make it simpler, I decided that all tiles should be of the same road speed limit and I changed it.  But can be studied in more detail.

But others than these it is good to see somebody else again working with the source code.

Thanks, again.  I will change the code as suggested.  I hope not to make a lot of questions...

[prissi]

Well, ding_t::init is unfourtunately executed very many times, some million times during game creation or object loading.

And the offsets on a diagonal (or normal tile) are calculated in get_screen_offset(). There you get the relative position of a vehile: Its position relative to the length to travel on this tile is display_steps/steps_next.

Do not hesitate to ask.

[isidoro]

Here is another version of the patch with some things done.  I have found some problems I would like to comment:

First: Don not touch ding_t, if you can avoid it. I would suggest a flag in vehikel_basis_t for the static offsets. There are still six flags left to fill one byte. Add one for overtaking shift, which is better done directly in get_screen_offset() (One can think of making this function virtual for this purpose, if one worries about speed.)

This is, I hope, done.  I have passed all the stuff to vehikel_basis_t, and ding_t is untouched.  The offsets are added in get_screen_offset.  I see all now more logical.  But I found a big trouble.  I noticed that after doing that, the program stopped with a invalid pure virtual call.  After debugging, I noticed that it happened when pedestrians disappeared!  :-\  Then, I realized that this sequence of calls happened:

• ~fussgaenger_t()
• ~verkehrsteilnehmer()
• mark_image_dirty()
• get_screen_offsets()

And the pure virtual call was to gib_typ() in order to get the type of vehicle.  After reading this good article about this (http://www.artima.com/cppsource/nevercall.html), and not knowing how to tell apart pure virtual calls, I decided to implement the flag you suggested, but I found a little problem: the flag is in vehicle and not in convoi and didn't like the idea of setting and resetting the flag for all vehicles of the convoi each time.  So, I decided to include a flag in vehicle (read-only) which tells if the vehicle can overtake and is set in the constructor.  Once I know it is a vehicle that can overtake, I can safely cast to an automobil.

The offsets should be init by set_diagonal_multiplier(), since the it should be clear if driveleft is enabled or not, and it is called only a single time. ding_t::init is not the right place, since trees and all other stuff rarely overtakes ...

When I tried to do this, in that place, get_tile_raster_width() gave me a different value than afterwards.  So, I programmed another function (set_overtaking_offsets()) and placed it afterwards.  I don't know if the place I chose is the best.

[...]
I would also not work in hop(). Use automobil_t::betrete_feld() (since it is car specific.) to update convoi counter.

Done.

And the check for overtaking should by probably better done in a step and not in a sync_step. Look at the way trains (or airplanes) are doing it: They use step for this, becuase during a sync step vehicles are moved in random order (and it is time critical). The trick is: They retrun false for the next tile free check, but the do not reduce the speed. Next time, (during a step) they check if the road is really blocked.

This, I don't really understand well.  The overtaking test is done in automobil_t::ist_weg_frei.  This is only called from convoi_t::step() in cases CAN_STARTx and WAITING_FOR_CLEARANCEx.  The function is not called from convoi_t::sync_step().  I've seen the waggon_t::ist_weg_frei() implementation and can only see that it separates the first cases (CAN_STARTx).  Is that what you meant?

Formatting rules have also been observed.  I will now try with avoiding frontal crashes, then with measuring more exactly in diagonals.

[PatrickN]

isidoro, I hope you realize that if this ends up working well enough to find its way to the official release, you may become a minor hero to all simutrans players.   I will nominate you for one of those monuments.

[prissi]

To avoid the said situation with the pure virtual call I suggested to make get_screen_offset() a virtual function. This way it would be only only called for cars, if they are cars. Otherwise the basis get_screen_offset() is called.

The system with step is the following:
The car sees that there is a car in front.
Then, it checks the convoi state => cnv->is_waiting()==true => we are in a step
If akt_speed>16 (not stopped): Try to overtake
If overtaking fails return_speed->0 if suceed return simply true.

During a step however, vehicle may move, and vehicle may jitter a little bit before overtaking. Therefore, keep it to the sanc_step first, and then lets profile it.

[isidoro]

isidoro, I hope you realize that if this ends up working well enough to find its way to the official release, you may become a minor hero to all simutrans players.   I will nominate you for one of those monuments.

Thanks, PatrickN.  You are very kind.  But let's not "sell the eggs before buying the hens"    And a better candidate, if this has a happy ending, will surely be prissi because of his patience with my endless questions.  And talking about the king of Rome...

To avoid the said situation with the pure virtual call I suggested to make get_screen_offset() a virtual function. This way it would be only only called for cars, if they are cars. Otherwise the basis get_screen_offset() is called.

Done.  Now code is much cleaner, I think.  My knowledge of Simutrans code is not deep, together with the death of many (the least fitted, I hope) of my neurons with lots of "happy hours" and the like, makes me not understand the sync_step/step dichotomy.  So, I decided to postpone that to the end.  In this version of the patch calculation has been adjusted and hopefully overtaking is done well, even for diagonals.

Some code has been added to check for facing traffic but it doesn't still work fully and needs debugging. I will do that next and also try to make city traffic overtaking possible.

Some other things have been fixed:

Also the check for stree speed should just check if the car in question can still go with its maximum speed. I do not worry about 80kmh limit, if my bus runs only 75kmh ...
[...]
is_moving() will indeed report all moving stuff, no matter what direction. You can check for facing traffic (since you do not have crossings) easily by calculationg the direction on this tile (from previous and next coordinate) and the use ribi_t::rueckwaerts() to get the reverse. Any vehicle with this fahrtrichtung will come against you.
[...]

Both things should be done by now.  One question, though.  When checking for facing traffic, I do something like:

      grund_t *gr=welt->lookup(pos);
[...]
      const uint8 top = gr->gib_top();
      for(  uint8 j=0;  j<top;  j++ ) {


Should that loop start in 0 or in 1.  I've seen some code starting in 1 and I don't know why.

[prissi]

The magic is in dingliste. SOme things need to be drawn before other things. (This is due to sorting order for drawing.) First is of course the way (but in old versions, waylist were not part of dingliste.)

And I though on your comments with the flag: THis might be useful, if you want to make citycars overtake, since those would use this routine too. But before more neurons die, I rather try the current state.

And the calculation for the direction needs to look one tile ahead (for diagonals), i.e. old_pos, next pos ...

[isidoro]

The magic is in dingliste. SOme things need to be drawn before other things. (This is due to sorting order for drawing.) First is of course the way (but in old versions, waylist were not part of dingliste.)

So, it is safe to start the loop in 1 (since 0 is the ground tile image), right?

And I though on your comments with the flag: THis might be useful, if you want to make citycars overtake, since those would use this routine too. But before more neurons die, I rather try the current state.

No problem.  My neurons have problems with alcohol only.      I've taken the flag back to life again.  It dies, it is born, it dies...  Following your advice, now city cars can be overtaken.  It shouldn't be difficult now to make them overtake too. But I need to know where to place the can_overtake check.  Again, we have a sync_step() and a ist_weg_frei() to program it.  I'll try to investigate it again, but any help would be appreciated. 

In order to make easy to make city cars and automobiles overtake, I've created a new class overtaker_t in simconvoi.h.  Classes convoi_t and stadtauto_t inherit from it.

And the calculation for the direction needs to look one tile ahead (for diagonals), i.e. old_pos, next pos ...

That's done.  Now, cars are more proficient overtaking and rarely crash.  I've tried the patch with a saved game and see the first cars overtaking "live"   

[prissi]

By the way, citycars have no route. Thus, as long as all way ribits are twoways, citycars could just check by checking next tile until exhausted.

I am currently ill and on a conference next week, thus I am not sure, if I can finish integration of the patch. Making an extra class sound like a good idea for simutrans, I thing. (Without haveing looked into the code ... )

[Ashley]

This all looks very cool, should allow for the construction of dual carriageways too with one-way signs, very cool change

[prissi]

Just on think when looking at it: Perhaps that has sign could be ignored for one way signs or unimportant maxspeed signs? And maybe no crossing (is_crossing checks only for railway crossings, to check for normal crossings, you better use ribit_t::is_twoway(ribi) for the masked ribi.

And the overtaker class should rather get a new cc/h file, since city cars have no convois ... and both, simvehikel.cc and smconcoi.cc are already quite long.

Anyway, more next week end.

[isidoro]

Thanks, Timothy.

By the way, citycars have no route. Thus, as long as all way ribits are twoways, citycars could just check by checking next tile until exhausted.

This patch is a first attempt with that.  Now city cars may overtake.  But must be debugged.  BTW, is there a way of knowing the length of a city car?

I am currently ill and on a conference next week, thus I am not sure, if I can finish integration of the patch. Making an extra class sound like a good idea for simutrans, I thing. (Without haveing looked into the code ... )

Next, apart from some debugging, I will try to avoid the overtaken to stop due to the overtaker, if possible.

I will also have less time next week.  But there is no hurry, is there?  Take care and get well, prissi.

[isidoro]

Sorry for double posting.  This should be a working version of the patch.  Some errors have been corrected:

• City cars now overtake in diagonals and everywhere
• Overtaken vehicles now don't stop when being overtaken
• Multi-vehicle convois are now properly measured and hopefully properly being overtaken

In the attached savegame, if you use a patched executable, you can see "The king of the road", a green city vehicle overtaking nearly everything  .

I'm concerned about performance, though.  If you try it, tell me.

Just on think when looking at it: Perhaps that has sign could be ignored for one way signs or unimportant maxspeed signs? And maybe no crossing (is_crossing checks only for railway crossings, to check for normal crossings, you better use ribit_t::is_twoway(ribi) for the masked ribi.

And the overtaker class should rather get a new cc/h file, since city cars have no convois ... and both, simvehikel.cc and smconcoi.cc are already quite long.

Feel free to change whatever you like, prissi.  You have a much deeper knowledge of Simutrans source code than I have.  I think you're right about the signs (if it is not heavily time-consuming).  And I didn't know that the crossing check was for railway only.  I understand ribis by now but don't know what is a masked one.

I agree again with the new cc/h file, but if I change my working copy, can I submit a patch with new files?  I'm new to svn.

[wernieman]

For with Version is the patch?

Do you need a "nightly" for it?? ;o)

[IgorEliezer]

Do you need a "nightly" for it?? ;o)

A Fun Nightly with this fun patch would be nice.

[VS]

Please...?

[isidoro]

I've branched in r2011, but I have tried it with r2022 and works the same.  A patched nightly would be nice.  At least for Windows.  I cannot produce it.  I left the "dark side of the force" time ago...   

[wernieman]

Just look at the nightly-Webside ...

http://www.wernieman.de/simutrans/index.en.html

Look there for the:
sim-....._2008-09-15_v100.1_r2022-overpatchV7.zip

But ... I don´t testet it ...

[VS]

It works!

[vilvoh]

Could you please upload some screenshots of that glorious moment? Just to ensure I'm not dreaming....

[isidoro]

Just look at the nightly-Webside ...

I've tried it with Wine and works fine.  Thanks!

[PatrickN]

Could you please upload some screenshots of that glorious moment?  Just to ensure I'm not dreaming....

I'd say a youtube video would be more appropriate.

[DirrrtyDirk]

But why? There is a nightly version available that has this patch included - so everyone should be able to see it for himself live not just on picture or video...

[PatrickN]

I downloaded the nightlys for windows and they won't run.

[VS]

Call me an ungrateful bastard, but when it is finally witnessed in person, the vehicles jumping to opposite lane aren't that much of great show Nevertheless it is important improvement and also another proof that Simutrans liiiiives!

[DirrrtyDirk]

Sure is - and my windows version worked without a problem.

[vilvoh]

This is great!!!  ...thanks very much Isidoro and Prissi for your work. Nominated for the Couple of the Year Awards!!


P.S: the video is on the way... :
P.S. II: Other thing, Do you think that this patch has posibilities to be included in the official release? After polishing it, of course...

[VS]

I can't really speak for prissi, but as far as I can tell, all involved parties aim for it to go in.

If its addition doesn't drain too much computing power and doesn't obscure codebase, why not? Plus it requires no new graphics. So, this is 100% usable from the moment it is merged into code, just by itself...

[DirrrtyDirk]

Also, judging by the degree of interest that prissi has shown so far, I would not rule the possibility out... 

[VS]

Dirk, do you ever sleep? I probably don't

[DirrrtyDirk]

Sure I do - just not yet.  Right now my life's rhythm is quite out of sync with daylight cycles - but that's probably going to change again soon. 

[vilvoh]

I'd say a youtube video would be more appropriate.

Your wishes are orders for me.....video.......yeah!!

[DirrrtyDirk]

LOL GREAT!!!!

[IgorEliezer]

WOOT! WOOT! WOOT! WOOT! WOOT! WOOT!

Simutrans rules!

[wernieman]

@PatrickN:
Whats your Problem with the nightly?

@All
It looks wonderfull!!!

P.S. I use for the patch-nightly the wrong compiler for windows (gcc4 and not gcc 3), so there are some error in some menüs ...

But only in the windows-Version, NOT in the Linux-Version

[isidoro]

Call me an ungrateful bastard, but when it is finally witnessed in person, the vehicles jumping to opposite lane aren't that much of great show Nevertheless it is important improvement and also another proof that Simutrans liiiiives!

That's the problem with too much expectation.  At the end, here comes crude reality     In fact, there is not much
merit behind the patch.  The idea is simple: "Overtaking = temporarily drive on the left".

Your wishes are orders for me.....video. [...]

Really nice music.     Thanks, vilvoh.

[DirrrtyDirk]

But it's really nice that it also works for drive_left=1 !!!

[vilvoh]

No, thanks to you for this awesome patch..

P.S: The music is Highway to hell from AC/DC.... :

[PatrickN]

@PatrickN:
Whats your Problem with the nightly?

I didn't have some of the dlls installed.  But I have 2022 working now and a bus with a max speed of 140 refuses to pas a bus with a max speed of 30.

[wernieman]

yust put the dll´s in the simutrans-Direktory ... not installing ;o)

[jatypc]

My guess the patch was only in 2022-overpatch build, but not in the regular 2022.

[jatypc]

Otherwise, let me congratule isodoro on a great patch - finally highways on large maps can become reality!

[Ashley]

Out of curiosity, does this patch mean that a moving vehicle with overtake a stationary one (which has stopped at a bus stop, for example) but which has a higher top speed? E.g. Bus A with topspeed 120 is stopped at a bus stop, is it overtaken by Bus B with topspeed 60 which doesn't stop there?

[jatypc]

Although I like the patch, there is sadly a bug to report: moving the vehicle, which overtakes, to the left lane is done by moving the picture by a (fixed) offset, which does not respect the zoom of the map. That is, if I zoom out (so that I see large area and all objects look small), the overtaking vehicle rides outside of the road during the overtaking maneuver (its picture is shifted too much). Hope this helps improving it further.

[vilvoh]

IRRC, the patch doesn't allow vehicles to overtake other ones that are stopped.

The speed of the overtaking vehicle is at least 5 kmh over the maximum speed of the overtaken vehicle
...
..
The tiles involved in the overtaking are calculated.  For all these tiles, it must happen:

• No stops, no crossings, no signs, no change in speed limit

I guess you should consider this case, Timothy:
- bus A stopped (max speed 120)
- bus B running (max speed 60)
- we suppose that both have different acceleration, power and weight, which means that one accelerates faster than other.
- if A starts running while B is overtaking, in theory, if B has more acceleration power, it will probably overtake A. However, if B is worst than A in terms of acceleration, it would be possible that B never overtake A (failed overtake) so you may have two vehicles running by the same way, in the same direction!! The overtaker would try to finish the action, and the overtaken one do not worry about whether to stop, to let the overtaker pass (like happens in real life)

I guess that's why overtaking stopped vehicles has not been implemented...

[isidoro]

But it's really nice that it also works for drive_left=1 !!!

You're right.  In fact, the sentence should have been:  "Overtaking = temporarily drive on the other side".  It works more or less like this:  if I get stuck, I check if I may overtake and how long will overtaking take.  Once decided, that cannot be changed.  So, the vehicle has to be faster than the maximum speed of the overtaken vehicle and there has to be nothing that makes the overtaking vehicle slow down.

Similarly, if you have two vehicles of max speed, let's say, 25 kmh one after the other and behind them, one 90 kmh bus, the bus may not overtake even if there is enough room between the two slow vehicles.  The reason is that the vehicle in front may brake and reduce that distance.  In summary, when a vehicle decides to overtake, overtaking must succeed.

Out of curiosity, does this patch mean that a moving vehicle with overtake a stationary one (which has stopped at a bus stop, for example) but which has a higher top speed? E.g. Bus A with topspeed 120 is stopped at a bus stop, is it overtaken by Bus B with topspeed 60 which doesn't stop there?

No.  For two reasons:

• Different acceleration, as vilvoh correctly points out.  Bus A may start after Bus B has decided to overtake and accelerates quickly and prevents Bus B to successfully complete overtaking.  There is no way in the patch to abort an started overtaking process.
• Overtaking will never take place on a stop, even if neither vehicle is going to stop there.  I didn't like the way it looked and is more complicated to program.

Otherwise, let me congratule isodoro on a great patch - finally highways on large maps can become reality!

Thanks.  If the patch is finally decided to be put into trunk, some game strategy may change:

• One-way roads makes overtaking easier and can make sense in some additional circumstances.
• Slower vehicles can have longer life-spans.  For instance, the horse-carriage 25kmh mail vehicle of pak64 can now be used for locations with little mail without interrupting buses.

Although I like the patch, there is sadly a bug to report: moving the vehicle, which overtakes, to the left lane is done by moving the picture by a (fixed) offset, which does not respect the zoom of the map. [...]

Correct.  When copying the offsets used for driving on the left, I noticed that those offsets depended on the zoom factor.  I first used the offsets without correction and postponed the correction, but when I checked, it seemed to work!

In fact, as you say, it doesn't work when you zoom out, but works when you zoom-in     It shouldn't be difficult to correct that.  I'll try and see.

EDIT:  v8 should correct the zoom error.  However, I had to touch simgraph16.cc and my instinct tells me that that is not correct perhaps.  Let's wait for prissi to see what he thinks.

[wernieman]

Should I make a spezial nightly?

Ore it is better to wait?

[Ashley]

Fair enough then, I was just curious Best still to put stops on such routes into their own little "lay-by" to keep stopping vehicles out of the way of non-stopping ones.

[IgorEliezer]

• Overtaking will never take place on a stop, even if neither vehicle is going to stop there.  I didn't like the way it looked and is more complicated to program.

You have my support.

For me, overtaking in bus stops is very dangerous in real life (think of pedestrians), and I suspect in my country overtaking in bus stops is against law too.

[jatypc]

Just a curious question: is overtaking supposed to work in tunnels? Thanks.

[prissi]

One comment on stops: One can calculate the acceleration: If a stopped vehicle (only convoi_t can do this) and kW<=mykW  &&  weight>=myWeight  then overpassing can happen.

But I will need this weekend to look at it in depth.

[wernieman]

@isidoro

Do you work on the patch?

When yes, I would like to make a new nightly-patch-Version ...

[prissi]

I am currently working. However, my computer tends to freeze periodically without proper reason :( Therefore integration into trunk will take a little longer.

[isidoro]

Do you work on the patch?

When yes, I would like to make a new nightly-patch-Version ...

Unfortunately, now I lack time.  It is in good hands (prissi's).  Last version of the patch was v8.

I am currently working. However, my computer tends to freeze periodically without proper reason :( Therefore integration into trunk will take a little longer.

If I can be of any help, just tell.

[prissi]

Well, I found out that plugging the hard disk into another esata plug solved this. However, it was around 1am, thus this has to be on the backburner for a little longer.

[Brunel]

Great add-on guys.

Watching vilvoh's video it comes out to me the idea of having oneway highways (made up with signs that already exits on the game) that would have a fast lane (left one) and a slow lane (right one) useful and used just in case of traffic jams or a convoy of slow vehicles. What do you think.

[Ashley]

This is something I'm working on at the moment, all it needs are road graphics, appropriate signs and this patch.

[jatypc]

One question regarding the calculating max. speeds for overtaking:

I have noticed that for a given power and weight of a vehicle, the maximum speed if can achieve is either its maximum speed from its definition or something lower = max. achievable speed (the higher the weight, the lower the achievable speed). For instance, truck with 251 kw power, weight 18t, and load 35t does not go faster than 76 km/h (if you give it an (almost) infinitely long flat road).

Could the routine for overtaking work with the maximum achievable speed instead of the nominal ones when comparing vehicles and computing the space needed for overtaking? Please? 

At the moment, if I have a highway with the same kind of trucks going in all directions, then all empty ones (which could go 110 km/h for instance) are slowed down by the full ones (which go 80 km/h for instance and never more). But the overtaking does not take place, because all of them have the same nominal speed (e.g., 110 km/h).

[IgorEliezer]

This is something I'm working on at the moment, all it needs are road graphics, appropriate signs and this patch.

If I see just citycars using opposite lane as an oneway highways, be sure, I will get absurdly proudly very happy (I hope I continue alive after I see that).

I don't ask so much: Seeing citycars using opposite lane would be enough for my happiness as urban planner EVEN... and vehicles (player's ones) may continue using normal lane as always it has been until now (well, almost until now).

Timothy, what would this feature be based in? I would have to place signs to make an oneway or there will be a special lane that forces citycars to use opposite lane?

It's just my curiosity...

[Ashley]

It'll be based on one-way signs, make a road one-way by controlling entry to and exit from it, that way there won't be any opposition to overtaking.

Nothing you couldn't do already, just the overtaking patch makes it worthwhile, it's entirely a graphics issue.

[Brunel]

And what about attaching 'virtual/hidden' oneway signs to roads tiles, i mean that the game do it automatically in case the road is two lanes, I think it could have the advantage of opening the way not only for highways and freeways but for avenues with same level crossings and possibly maybe roundabouts.

Of course all these should have dedicated graphics. In case of highways and avenues a road of 1 tile long and 2 tiles wide, and in case of highways with hidden oneway signs on three out of four sides (one on the side in-between the two tiles just to forbidden same level crossing to the opposite way) and in case of avenues with hidden oneway signs on two out of four sides (to allow same level crossing to the opposite way). In case of roundabouts should be a minimum number of tiles of 3 long and 3 wide circle to allow same level crossing of four two-ways roads.

[prissi]

The oneway signs actually do exactly this.

[Colin]

It's possible to make dual lane highways already, one going for example, North, the other going South. It's the overtaking that is really needed.

[Fabio]

wow, this looks to be a giant leap forward in roads!!!!

in any meaning, ihihihihih

[isidoro]

I've just seen that overtaking is in trunk (r2037).  Thanks, Prissi.  I've quickly seen some of the improvements and to devise them would have taken me ages for sure.  When I look at them closely, I will ask what I don't understand if you don't mind.  One minor detail: gcc says that variable gr_last in vehicle/simverkehr.cc:893 is defined but not used.  Probably used for a test?

Just a curious question: is overtaking supposed to work in tunnels? Thanks.

To be honest, I haven't answered that before because I didn't know...     So, I went empirical and tried the new version with the attached savegame and overtaking works with bridges and tunnels, even at the entrance/exit.

[...]
Could the routine for overtaking work with the maximum achievable speed instead of the nominal ones when comparing vehicles and computing the space needed for overtaking? Please? 
[...]

Again, my ignorance is certainly unlimited.     Although if that speed could be efficiently calculated, it would only mean a substitution in one line of the overtaking code.  Question apart is if that is desired/realistic.

When I started the patch, I named it a "fun patch", meaning it was nothing serious.  Now, I can say it has really been *FUN* to develop it.   Thanks, guys.

[prissi]

Well, the routine can be surely improved for convois. Citycars take already nearly their maximum speed.

Saveing/loading will not work yet ... and some other stuff is not fully finished. But I felt like I had to release it (actually spend most of the week debugging citycars on bridges and using as less CPU as possible.)

[jatypc]

Although if that speed could be efficiently calculated, it would only mean a substitution in one line of the overtaking code.  Question apart is if that is desired/realistic.

From what I see on many central-european highways, it is very realistic to work with the maximum achievable speed given the load of a convoy. That of course does not say anything about feasibility - is it possible to quickly and easily compute the maximum achievable speed - I have no idea, unfortunately.

One more remark for improvement: it seems to me that the overtaking does not take place if all conditions are satisfied, but the first (slower) car is turning to the right (whereas the overtaking car continues straight on). In such a case, the overtaking should take place (if it is not difficult to code) because the overtaken car will actually be overtaken sooner...

[snide]

If you make a class virtual (having at least one virtual function), you should also have a virtual destructor.

Here is a patch that does just this :

Code Select Expand


=== vehicle/overtaker.h
==================================================================
--- vehicle/overtaker.h (revision 131)
+++ vehicle/overtaker.h (local)
@@ -56,6 +56,9 @@

        // since citycars and convois can react quite different
        virtual bool can_overtake(overtaker_t *other_overtaker, int other_speed, int steps_other, int diagonal_length) = 0;
+
+       // Virtual destructor since there is at least one virtual function
+       virtual ~overtaker_t() { /* do nothing*/ };
};

#endif



Very nice patch btw.

[prissi]

Well, only if you are not sure, that the virtual function is not called during destruction, which could not happen. But it is better style anyway.

[isidoro]

From what I see on many central-european highways, it is very realistic to work with the maximum achievable speed given the load of a convoy.
[...]

I don't know the right answer.  I only think: if I cannot see inside the truck, how will I know if it is fully loaded or not to begin overtaking?

[...]
One more remark for improvement: it seems to me that the overtaking does not take place if all conditions are satisfied, but the first (slower) car is turning to the right (whereas the overtaking car continues straight on). In such a case, the overtaking should take place (if it is not difficult to code) because the overtaken car will actually be overtaken sooner...

The  problem with crossings is that calculations complicate quite a lot (traffic can go away as in your example, but can also appear, you should look at all possibilities and that may not be feasible).  With city cars, it is ever more complicated because, in normal configuration, they have no route.  When they reach a crossing they choose an exit at random.  Besides, if I'm not wrong, at least where I live, overtaking is not allowed in crossings.

[PatrickN]

What about a T intersection, where there is a turn off to one side but not the other.  While passing a car in a 4-way stop would be illegal, it should be perfectly fine to pass a vehicle when there is a road to the right because the straight road doesn't stop.

[jatypc]

The  problem with crossings is that calculations complicate quite a lot (traffic can go away as in your example, but can also appear, you should look at all possibilities and that may not be feasible).  With city cars, it is ever more complicated because, in normal configuration, they have no route.  When they reach a crossing they choose an exit at random.  Besides, if I'm not wrong, at least where I live, overtaking is not allowed in crossings.

All points very correct - I agree. My mistake I have not realized all these things.

I don't know the right answer.  I only think: if I cannot see inside the truck, how will I know if it is fully loaded or not to begin overtaking?

In reality, you do not know the load of the truck, but the trucks typically go at the maximum economical speed (we do not have that in simutrans, but we have a maximum achievable speed) - unless there is an obstacle such as hill, crossing, city, but that is excluded already in "simu-overtaking". Thus, the second truck driving behind the first one sees the speed when he is driving a little while after the first truck and based on this information (if their economical speed is higher) they decide to overtake. The truck drivers make sometimes (not very often) mistakes in their guess, but then the overtaken truck lets them pass at the end, and moreover, the mistakes are not possible in simutrans. The same situation occurs when you drive in a car behind a truck - after short while you know whether the truck can keep up with the maximum allowed speed (e.g., 90 km/h), for instance, or whether it is too slow (e.g., less powerful or heavily loaded). If you see he is slow, you decide to overtake...

Thus, I think it is realistic that the cars/trucks overtake each depending on the maximum achievable speed - it is only that the maximum achievable speed computed in simutrans (which requires the knowledge of the weight/load) replaces observing the speed in the real world (which would be difficult to implement I guess).

[prissi]

Overtaking on exits only for citycars is not possible, since the overtaking citycars can exist too ... and rarely convois overtake citycars (at least in pak64), usually it is reverse. This would add a lot of tests for not real win, imho.

And in most middle europeen countries overtaking on crossings is strictly forbidden.

[CX257]

Sorry for my stupid question, but just wanna ask where should I locate this .PATCH file ?
(Well ... using patch is still a new stuff for me x[ )

By the way, I remember that there is a overtaking function in a ancient version of simutrans ...  :

[IgorEliezer]

See posts of this topic. If I remember correctly, there are some patch files attached at post's footers.

[prissi]

Anyway, it is in the trunk since a month or so.

[KingTy]

where do i get this patch and where do i put it after downloading?

[vilvoh]

This patch is already included as a feature in the latest stable releases (102) have a look at the changelog.

[jamespetts]

Perhaps this thread should be moved to the "incorporated patches" section?

[KingTy]

in pak 128 the city cars will over take other city cars but will not over take my cars and my cars will not over take city cars    will this download make it so they do that or no?

[Combuijs]

This is incorporated in version 0.102. Cars will only overtake if it is safe, e.g. no cars coming from the other side, no crossings or junctions, no cars waiting in front. Sometimes speed difference is not much and opportunities for taking over are rare. But it certainly works!

[jamespetts]

Overtaking works much better on faster roads, I have found.

[Severous]

Ah.  Didnt know overtaking could happen.  Will look closer in Ragoland challenge next time I load it up.

[Isaac Eiland-Hall]

Tips to see overtaking:
1. Long straight stretches of road (15-20 tiles) are condusive.
2. Divided highways (e.g. using do-not-enter signs of some sort to restrain traffic flow) ensure no oncoming traffic, and are therefore also condusive.

Divided highways have another trivial benefit now with overtaking (the flow control they already provided, if carefully set up, was moderately marginal, and now overtaking has helped them become slightly more useful yet )