Topic: One-way Two-lane road Fun Patch

[An_dz]

Ok, fair point, but no implementation for now.

And about the UX, can we go with it?

[sheldon_cooper]

Good afternoon, or good day, or night, I do not know! 
I wanted a more detailed explanation of the five options for creating existing roads in the future OTRP Patch update.
I still have not played with version 10, due to compatibility problems of my saved game.

[THLeaderH]

https://twitter.com/himeshi_hob/status/886043618695303169
How do you think about this video?
In the next release, overtaking_mode can be set in a window and oneway_mode road becomes genuine oneway. No special addons are needed.

I wanted a more detailed explanation of the five options for creating existing roads in the future OTRP Patch update.

I'll make a video which explains the detail of this patch in a few weeks.

[sheldon_cooper]

thank you!
I use OTRP Patch V.8.0, with the special add-on to be able to use on the roads, with the new update, do I have to exclude this special add-on so there will be no problems? Or is it not necessary?

[THLeaderH]

It's necessary. And unfortunately, v10 cannot load the v8's data.

[prissi]

You should be able to downgrade the version (in the settings option dialogue show with new world window). If properly coded, then the info will not be written in a slightly older savegame version.

[THLeaderH]

You should be able to downgrade the version (in the settings option dialogue show with new world window). If properly coded, then the info will not be written in a slightly older savegame version.

It's already done. Current nightly code set savegame version 120005 and I use version 120006 for OTRP. If version >= 120006 then rdwr methods read and write data such as overtaking_mode.

<EDIT>
Oops, this was an advice for sheldon_cooper! Yes, you can downgrade the version and downgraded data can be read on v10 or v11, which are going to be released in a few weeks.

[sheldon_cooper]

Would it be this?

[An_dz]

@THLeaderH I've pushed my overtaking menu patch on GitHub, I decided to keep my patch clear of yours to focus on the features I'm building, this might facilitate you merging my changes as well.

[THLeaderH]

Would it be this?

Yes, maybe the latest one is fine.

[THLeaderH]

Here is a new release of One-way Two-lane Road Patch, OTRP ver11.
This time, the patch file and the executable binaries are simutrans nightly r8275 based, and the patch can be easily integrated to the nightly trunk.
Source code can be seen on git. https://github.com/teamhimeh/simutrans/tree/OTRP

patch:https://drive.google.com/open?id=0B_rSte9xAhLDY0tCTWdHSnBUQ2c
~Executable Files~
:simutrans:
win:https://drive.google.com/open?id=0B_rSte9xAhLDMDNuakoya19xbHc
mac:https://drive.google.com/open?id=0B_rSte9xAhLDa2FWRTVjdGdMRFU
:makeobj:
There is no special makeobj. Please use the makeobj of simutrans standard!

Be sure that this version cannot load sve data of previous versions of OTRP.
I made a video which explains how to use this version. The video is spoken in Japanese, but English subtitle is available.

~The features of this version~

• Rewriting numbers of overtaking_mode to enum reached its completion. This makes the code much easier to read.
• No special addons are needed! Players choose overtaking_mode when they build roads. Please see the tutorial video for the detail.
• Oneway_mode roads become automatically oneway. The direction in which vehicles can go depends on the direction in which players build the road. This solves various problems that happens on oneway road, such as facing traffic, placing so many oneway signs, and sudden turn of city cars. Also see the tutorial video for the detail.

I made a support patch that visualizes the ribi of way so that players can easily recognize the tile whose ribi is set incorrectly. This makes construction of oneway road much confortable. See here for the detail.
Patches and executable files listed on this pages do not contain the ribi patch.

I set this version as a candidate version for integration again. I would like great developers of this forum to do code review.

Any bug reports and ideas for improvement are welcome!

As I make this patch, I found that some more projects are neccesary for father improvement of two lane road transportation. OTRP is already so a huge project, thus these should be discussed as different topics.

• Improvement of routing algorithm of citycars. Current citycar's routing algorithm that decides its course randomly when it reaches at intersections is too rough. Since we can know the position of only two tiles ahead, sensitive controls such as lane pinning cannot be applied to city cars. Also, current city cars behaves so stupid in intersections. City cars often turn more than 180 degrees and that corrupts traffic. Also acceleration of city cars seems so unnatural.
  I think that city cars should have their destinations and route. Also, city cars should have power and weight parameter, which enables more accurate motion simulation of city cars. I've heard that these are realized in simutrans extended, but I don't know about that in detail.
• Intersection object is needed to realize more sophisticated intersection control. For example, we cannot set right turn lane or left turn lane under the current intersection system. Also, traffic signal for multiple lanes should be discussed.

Without these ideas, OTRP does work as it is and is already revolution for road traffic of simutrans. However, If a father improvement is desired, these concepts should be discussed.

[jamespetts]

...

• Improvement of routing algorithm of citycars. Current citycar's routing algorithm that decides its course randomly when it reaches at intersections is too rough. Since we can know the position of only two tiles ahead, sensitive controls such as lane pinning cannot be applied to city cars. Also, current city cars behaves so stupid in intersections. City cars often turn more than 180 degrees and that corrupts traffic. Also acceleration of city cars seems so unnatural.
  I think that city cars should have their destinations and route. Also, city cars should have power and weight parameter, which enables more accurate motion simulation of city cars. I've heard that these are realized in simutrans extended, but I don't know about that in detail.
• Intersection object is needed to realize more sophisticated intersection control. For example, we cannot set right turn lane or left turn lane under the current intersection system. Also, traffic signal for multiple lanes should be discussed.

Without these ideas, OTRP does work as it is and is already revolution for road traffic of simutrans. However, If a father improvement is desired, these concepts should be discussed.

Full routing for private cars is a problem because of the computational load that it exerts in a very large map. I did once try, many years ago, implementing actual routing for city cars in the same way as player vehicles, but the game became completely unresponsive.

In Extended, the actual private car objects behave in the same way as they do in Standard, but there is a very approximate, high-level means of simulating private car journeys so as to simulate competition between private cars and player transport.

[Isaac.Eiland-Hall]

I just wanted to say that I loved the cloverleaf in the video!

[Leartin]

Full routing for private cars is a problem because of the computational load that it exerts in a very large map. I did once try, many years ago, implementing actual routing for city cars in the same way as player vehicles, but the game became completely unresponsive.

Was that a unique route for each vehicle? What if every now and then, a "citycar-route" was precalculated by picking two semirandom spots and routing a connection once, than saving it in a list of possible citycar-routes, and each citycar that spawns just needs to pick a route and follow it - thus no individual routing. If a citycar gets 'stuck' because a piece of road is missing, it simply disappears and marks the route it was on as invalid. There would be a lot less of actual routing, and never time sensitive, so if Simutrans is aware of how much ressources are used, it could be done whenever there is time, possibly even in pause mode.

[jamespetts]

Was that a unique route for each vehicle? What if every now and then, a "citycar-route" was precalculated by picking two semirandom spots and routing a connection once, than saving it in a list of possible citycar-routes, and each citycar that spawns just needs to pick a route and follow it - thus no individual routing. If a citycar gets 'stuck' because a piece of road is missing, it simply disappears and marks the route it was on as invalid. There would be a lot less of actual routing, and never time sensitive, so if Simutrans is aware of how much ressources are used, it could be done whenever there is time, possibly even in pause mode.

It was indeed a unique route for each vehicle - it was a simple implementation derived directly from the system used to route player vehicles. This was before I learnt how to profile the code, so there is a possibility that performance could have been improved even within that model, although it was so bad (the game being indistinguishable from frozen on a moderately sized map) that it seems unlikely that ordinary optimisation would have made enough of a difference.

Multi-threading, which should be readily possible, might help a little, but I suspect that more than four cores would be needed to get reasonable performance using this method. Multi-threading is already used in Extended for the private car route finding system there, and that involves only finding one route between each townhall and each other townhall, and even that workload has to be spread over quite some time so as not to impair responsiveness.

I did consider some years ago when I first had this problem a fragmentary route system, not quite the one that you suggested, but a different one, in which routes within towns were treated separately to routes between towns: the idea is that there would be stored routes between each town exit point and each town entry point, and then between each building and exit/entry point in a town (possibly created only on demand), and, in journeys between buildings in different towns, three routes (from origin to exit point, from exit point to entry point, and from entry point to destination) would be concatenated to produce the final route.

That was never progressed as I considered it too much work at the time in light of other priorities, and the very basic system worked well enough.

[sheldon_cooper]

Also, traffic signal for multiple lanes should be discussed.

[/list]

I do not know if you are referring to these traffic signs, but taking advantage of that, this pak is for multiple lane, different crossing situations, I think it can be very useful for this patch. (Pak128)



>>> https://www.dropbox.com/s/4dkwndtazs3v0z6/Sem%C3%A1foro%20moderno.rar?dl=0 <<<
If you can not download through this link, just let me know and I'll try to solve it.

(Credit: Filipe Jucélio)

[IgorEliezer]

The traffic signal is an issue of its own. The main problem is, when you place traffic signals next to each other, at least 2 signals at their "sharing" sides overlap causing traffic jams.

Further discussion:

• http://forum.simutrans.com/index.php?topic=2566.0
• http://forum.simutrans.com/index.php?topic=14782.0

EDIT: Merged both threads.

[THLeaderH]

I do not know if you are referring to these traffic signs, but taking advantage of that, this pak is for multiple lane, different crossing situations, I think it can be very useful for this patch. (Pak128)

Think about this situation. Note that vehicles drive on left. There is 4 signals in this 2×2 intersection. You are on tile 1.

However, there is two problems.

• When the vehicle turns right, it will go 1→2→3→4→5. The signal on tile 2 shows blue and the vehicle starts. However, signal on tile 4 blocks the vehicle and it cannot turn right immediately. The vehicle must wait until signal light changes even when there is no facing traffic! Of course this makes traffic jam.
• When the vehicle goes straight, it will go 1→2→3→6. In the case that the traffic light changes from blue to red suddenly when the vehicle is on tile 2, this vehicle must wait until the traffic light changes again. So, this vehicle blocks north and south traffic!

these problems on a 2×2 intersection can be solved by putting signals like this. (Signals are put on "S" tiles.)


However, even with this solution, you'll find that you cannot solve the second problem on a intersection like this. North and south traffic will be suffered from the problem 2.


So I think that we should think about intersection object that enables more sophisticated intersection control.

EDIT

Further discussion:
http://forum.simutrans.com/index.php?topic=2566.0
http://forum.simutrans.com/index.php?topic=14782.0

Yes, I think this issue should be discussed in the either topic.

[THLeaderH]

For code reviewers, code related to oneway road feature is written in

• weg.h, weg.cc
• brueckenbauer.h, brueckenbauer.cc
• tunnelbauer.h, tunnelbauer.cc
• wegbauer.h, wegbauer.cc
• simtool.h, simtool.cc

This version is a candidate version for integration. Though I believe that this version has enough quality to be integrated, please let me know if there are bugs or code that requires fixing.

[TurfIt]

Overtaking mode selection does not work in multiplayer.
Mode selections being per object is not friendly. Makes more sense for a global selection that applies for all constructions.
Way builder route search needs to take directionality into account before merging new construction with existing.
Still indications of incompletion:

Code: [Select]

+ //TODO: This initialization of "tiles" should be considered again. 2 is not appropriate considering LC patch.
+ //Warning: diff_speed == 0 is acceptable. We must consider the case diff_speed == 0.
+ //Whether this code is safe is not clear!!(can ignore cars on the other lane?)
+ // !It is not clear whether we should consider opposite lane in this case!


[THLeaderH]

Overtaking mode selection does not work in multiplayer.

This seems to work correctly in multiplayer for me. Please describe the issue in more detail.

Mode selections being per object is not friendly. Makes more sense for a global selection that applies for all constructions.

I don't think so. When you are building trunk road and narrower road, you will use two types of road. Trunk road should be oneway_mode and the narrower should be twoway_mode. So, with mode selections being per object, you have to select overtaking mode only twice. With a global selection, you have to select overtaking mode every time you change the type of road and that is unfriendly, I think.

I'll answer to the other two indications later.

[TurfIt]

I don't think so. When you are building trunk road and narrower road, you will use two types of road. Trunk road should be oneway_mode and the narrower should be twoway_mode. So, with mode selections being per object, you have to select overtaking mode only twice. With a global selection, you have to select overtaking mode every time you change the type of road and that is unfriendly, I think.

Start building a oneway road. Run into a river. Build a bridge - oops it's two way.  With global selection, you can build an entire oneway road with bridges, tunnels, all without having to change for every object.

This seems to work correctly in multiplayer for me. Please describe the issue in more detail.

Start as server. Attempt building a oneway road. Observe twoway road built instead.

I don't know how to respond to this claim of it working for you. From the code, there is 0% chance of this working. Ever. At all. In the slightest. Zero.
(commanded tool instances don't persist  -  try set_default_param)

[An_dz]

Start building a oneway road. Run into a river. Build a bridge - oops it's two way.  With global selection, you can build an entire oneway road with bridges, tunnels, all without having to change for every object.

That's why my patch with the toolbar was global per player.

[jamespetts]

Start building a oneway road. Run into a river. Build a bridge - oops it's two way.  With global selection, you can build an entire oneway road with bridges, tunnels, all without having to change for every object.

Of course, this would also not be a problem if the system of having bridges separate from their underlying way as used in Extended were adopted.

[Leartin]

Start building a oneway road. Run into a river. Build a bridge - oops it's two way.  With global selection, you can build an entire oneway road with bridges, tunnels, all without having to change for every object.

But also: Start building a road. Run into a river. Build a bridge? - oops, you have to change tools. Pretty sure I'm not the only one who instead continues the road on the other side of the river to fill in bridges later, since changing tools is inconvenient. Additionally changing the direction of the tool you need to select does not add much inconvenience, since your way-building workflow already got interrupted.

I don't think either option is better than the other, since it much depends on the players style and the options of the pakset. There are players who will always pick the same road, thus always have to switch, so it's better if it's global, to save 2/3 of the switching. But there are players who will always pick different roads depending on the directions settings if the pakset/addons offer roads that lean themself towards a certain use graphically such as a motorway (one-way with overtaking) or a motorway access (one-way without overtaking), while having the same costs, and for those, it's better to have it per-object and even preset by the pack. It's simply a clash of interest between different player demographics.

Perhaps if it was more consequent, per-pak-settings would not be required. The settings were introduced such that any way could have any direction and we would not need multiple versions of each way. But those who play for looks want ways to look different based on their directions. If the same way does not look different based on directions, they will get different ways - which means one reason to do it with settings rather than different ways is gone and you need per-object settings. But if you could completely change the look based on directions within one way, there is no need to have multiple versions and players would instead switch directions within the same way, making a global setting more useful.

[IgorEliezer]

My workflow would be:
1. Build roads, bridges, tunnels, whatever. (default = two-ways, I would prefer to lay out the ways and decide about the flow later on)
2. Paint and install the signaling. (by using a tool to apply/change directions or flow control of the ways)
3. Then I check if I missed any bit. (by using a visualizer).
4. I'm done. If I change my mind on something, I can use the flow control tool to change the directions and tweak a bit.

Probably this is not intuitive for players, they may want to build a one-way road right off the bat. I'm speaking as someone who works with urban infrastructure. :>

[THLeaderH]

So I should provide a configuration so that the selection can be both global or local.
I'm still dealing with the indicated issues. I'll add the configuration after solving those.

[TurfIt]

The one-way roadsign lane fixing thingy also cannot work in multiplayer. The selection needs to be syncronized across clients. You'll need to add a tool_change_roadsign_t (see the traffic light tool for an example).

Actually I can't make this sign work in singleplayer either. Convois freely still enter the other lane after passing the sign despite turning at the next intersection. Can you provide an example save showing this working? Maybe I'm not setting things up right... lane_fix == 0 always on my convois.

Why the existing ribi_maske and added ribi_mask_oneway?  Can't these be combined?

Since overtaking applies only to roads, wouldn't the variables make more sense in strasse_t instead of weg_t?

When a stopped convoi changes lanes immediately upon starting to move, it's graphic is left behind as a glitch in it's former lane. The marking dirty mechanisms for moving objects is quite a hack, but this patch is introducing some new behaviours that the hack isn't handling, so needs changes.

Also noticed with stopped convois changing lanes immediately upon starting is trailers in tiles behind aren't being accounted for. i.e. A two tile long road train will sideswipe a convoi alongside when it changes lanes.

Intersection object is needed to realize more sophisticated intersection control. For example, we cannot set right turn lane or left turn lane under the current intersection system. Also, traffic signal for multiple lanes should be discussed.

There was some discussion about this is one of the last big discussions about multilane roads: http://forum.simutrans.com/index.php?topic=8906.0
It is something required to make the logic work in town with avenues. Extending the current ist_weg_frei and no_cars_blocking for multilane intersections would be a nightmare.

Improvement of routing algorithm of citycars. Current citycar's routing algorithm that decides its course randomly when it reaches at intersections is too rough. Since we can know the position of only two tiles ahead, sensitive controls such as lane pinning cannot be applied to city cars. Also, current city cars behaves so stupid in intersections. City cars often turn more than 180 degrees and that corrupts traffic. Also acceleration of city cars seems so unnatural.
I think that city cars should have their destinations and route. Also, city cars should have power and weight parameter, which enables more accurate motion simulation of city cars. I've heard that these are realized in simutrans extended, but I don't know about that in detail.

I don't think they need destinations and a full route. But, the route does need to be determined for several tiles for them to properly navigate intersections, and lane_fixing as you mention.
After I finished the overhaul of convoi movements through intersections, I was burned out from dealing with that section of code, so the planned work to bring the citycars up to the same standard never happened. Putting the controls into an intersection_t with path reservations through the intersection would make the task much easier IMO.
The current citycar movement behaviour has the advantage of them atleast trying to get out of the way in a traffic jam rather than making it worse by sticking to a preplanned route. Any changes should try to preserve that as much as possible IMHO.

[THLeaderH]

(commanded tool instances don't persist  -  try set_default_param)

So, using default_param as a key, should I use static hash table to store selected overtaking_mode?
EDIT:

Since overtaking applies only to roads, wouldn't the variables make more sense in strasse_t instead of weg_t?

Yes, overtaking_mode and ribi_mask_oneway should be in strasse_t and I'll do so.

Why the existing ribi_maske and added ribi_mask_oneway?  Can't these be combined?

They can be combined. However, if these are combined, we have to consider the effect of roadsigns or etc when we change ribi_mask_oneway every time. Separating these makes code more simple and robust.

[TurfIt]

So, using default_param as a key, should I use static hash table to store selected overtaking_mode?

I'd think you just pass the overtaking mode directly in the param., and make sure the bauers all use that passed param rather than some local globals.

They can be combined. However, if these are combined, we have to consider the effect of roadsigns or etc when we change ribi_mask_oneway every time. Separating these makes code more simple and robust.

IMHO, since they're performing the same function, they should be merged.
Keeping these datastructures as small a possible helps the game to support huge maps at reasonable performance. ( I'd go so far as to kill the overtaking mode enum too - 32bits for that - 28 wasted!  [old] c++ annoying at times...)


Why are the overtaking mode selections per player? Just because I change from human to public to tricky transport, I can't see why I'd what the overtaking mode I've already selected to change.

For lane fixing, how about renaming to lane affinity?

[THLeaderH]

I'm dealing with default_param for network game but I'm pretty confused with default_param. In tool_build_way_t, I edited get_default_param so that default_param contains overtaking mode and it succeeded. However, I did the same thing in tool_build_bridge_t, wrote get_desc() function to replace "bridge_builder_t::get_desc(default_param)" to "get_desc()", and built a bridge. Then I got the following error.

Code: [Select]

Process 30152 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x6f7c6b5b000a)
    frame #0: 0x000000010000b9bb sim`image_list_t::get_image(this=0x00006f7c6b5b0002, i=18) const at image_list.h:34
   31 
   32  uint16 get_count() const { return count; }
   33 
-> 34  image_t const* get_image(uint16 i) const { return i < count ? get_child<image_t>(i) : 0; }
   35 
   36  image_id get_image_id(uint16 i) const {
   37  const image_t *image = get_image(i);
(lldb) bt
error: brueckenbauer.o DWARF DW_TAG_array_type DIE at 0x000078ca has a class/union/struct element type DIE 0x000078c5 that is a forward declaration, not a complete definition.
Try compiling the source file with -fno-limit-debug-info or disable -gmodule
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x6f7c6b5b000a)
  * frame #0: 0x000000010000b9bb sim`image_list_t::get_image(this=0x00006f7c6b5b0002, i=18) const at image_list.h:34
    frame #1: 0x0000000100047604 sim`bridge_desc_t::get_background(this=0x00000001230c0000, img=N_Ramp2, season='\0') const at bridge_desc.h:69
    frame #2: 0x0000000100047d70 sim`bridge_desc_t::has_double_ramp(this=0x00000001230c0000) const at bridge_desc.cc:129
    frame #3: 0x000000010000457e sim`bridge_builder_t::find_end_pos(player=0x000000010dbee8f0, pos=(x = 151, y = 222, z = '\x03'), zv=(x = 0, y = -1), desc=0x00000001230c0000, error_msg=0x00007fff5fbfb0d8, bridge_height=0x00007fff5fbfb0e7, ai_bridge=false, min_length=5, high_bridge=false) at brueckenbauer.cc:334
    frame #4: 0x000000010045a80a sim`tool_build_bridge_t::do_work(this=0x00000001280799e0, player=0x000000010dbee8f0, start=0x0000000128079a15, end=0x00007fff5fbfb220) at simtool.cc:2705
    frame #5: 0x000000010043b889 sim`two_click_tool_t::work(this=0x00000001280799e0, player=0x000000010dbee8f0, pos=(x = 151, y = 217, z = '\x03')) at simmenu.cc:1008
    frame #6: 0x000000010023ac16 sim`nwc_tool_t::do_command(this=0x000000012807e5f0, welt=0x000000012d5e3400) at network_cmd_ingame.cc:1196
    frame #7: 0x00000001004a3156 sim`karte_t::do_network_world_command(this=0x000000012d5e3400, nwc=0x000000012807e5f0) at simworld.cc:6482
    frame #8: 0x00000001004a2c00 sim`karte_t::process_network_commands(this=0x000000012d5e3400, ms_difference=0x00007fff5fbfb92c) at simworld.cc:6431
    frame #9: 0x00000001004a373f sim`karte_t::interactive(this=0x000000012d5e3400, quit_month=2147483647) at simworld.cc:6585
    frame #10: 0x0000000100431f7d sim`simu_main(argc=2, argv=0x00007fff5fbffb00) at simmain.cc:1342
    frame #11: 0x000000010044b29d sim`sysmain(argc=2, argv=0x00007fff5fbffb00) at simsys.cc:827
    frame #12: 0x00000001004da422 sim`main(argc=2, argv=0x00007fff5fbffb00) at simsys_s2.cc:793
    frame #13: 0x00007fffe8d4d235 libdyld.dylib`start + 1

What's wrong?

For lane fixing, how about renaming to lane affinity?

IMHO, The nuance of "affinity" is weak. How about lane instruction of lane pinning?

When a stopped convoi changes lanes immediately upon starting to move, it's graphic is left behind as a glitch in it's former lane. The marking dirty mechanisms for moving objects is quite a hack, but this patch is introducing some new behaviours that the hack isn't handling, so needs changes.

Where is the process related to this hack written?

[THLeaderH]

I tried to fix some issues suggested by TurfIt. The new patch file can be downloaded from here.
The solved issues are

• Overtaking mode selection of way does work in multiplayer.
• Dealing with indications of incompletion.
• The one-way roadsign lane fixing works in multiplayer. The selection is now synchronized across clients.
• Overtaking_mode and ribi_mask_oneway were moved from weg_t to strasse_t.

Renaming of lane_fix is undone. I still can't determine what is a proper name for that.

And I couldn't solve these issues :(

• Overtaking mode selection of bridge and tunnel does not work in multiplayer. I tried to use default_param to handle overtaking_mode but it resulted in out-of-range access and the cause is unknown.
   See also.
• When a stopped convoi changes lanes immediately upon starting to move, it's graphic is left behind as a glitch in it's former lane. I couldn't find where to edit to change marking dirty mechanisms.

Since I cannot deal with these problems by myself, I have to wait for somebody who solves these or gives me an additional information.

[Dwachs]

The crash report with bridge building seems to be strange. The desc pointer is not NULL but the data of the desc structure seems to be corrupt somehow.

You can send the overtaking mode information with the help of tool_build_bridge_t::rdwr_custom_data(memory_rw_t *packet), and implement it for roads/tunnel tools as well.

[TurfIt]

From what I'd seen, there were several places where the extra information added to default param wasn't stripped back out before it was used to find the desc resulting in weird descs.
But, great timing,  I literally just finished changing the patch to use the rdwr_custom_data to pass the info instead of default param - much simpler! I'll post the patch for that once I get git to stop producing stupid patches...

EDIT:
GIT still deserves a place in the trash bin.... How hard is it to sensibly handle LF vs CRLF? sheesh.

Attached a patch that should be for ontop of  38dd8065 in your github branch.
Note: the v11_2.patch you posted on the 10th is bad - stowaway junk. Would've been easier had that worked...

Issues remaining as I see it:
Minor - lane fixing wording -> I still think affinity is the correct / sensible word here. See setting a processes' processor affinity to 'pin' to a particular CPU as an example or precedent usage.
Medium - stopped convoi changing lanes on restarting graphics glitch. -> will look at giving you a pointer to the many places this is hacked in.
Major - convoi changing lanes overlapping with vehicle in the other lane due to not taking into account trailers in tiles behind.
Major - lane fixing appears completely non-functional. See the previous post on this - I never seen a response.
Medium - building only a tunnel portal (i.e. With CTRL held) results in overtaking mode selection dialog opening.
Major - requires the show ribi patch too IMO for usability. See comments in that thread from a month ago...
Disagreement - merging of ribi_mask with ribi_mask_oneway. -> I still think the latter is redundant - two things doing the same thing... Require third party mediator!

[Dwachs]

Disagreement - merging of ribi_mask with ribi_mask_oneway. -> I still think the latter is redundant - two things doing the same thing... Require third party mediator!

I also do not like this. In particular, as this patch also makes the trivial method weg_t::get_ribi virtual. Why not merging all masking into the existing member variable ribi_mask?