Topic: Oneway Twoway Road Patch for the Extended

[Andyh]

Thank you and congratulations to everyone involved in bringing this new functionality into the game.  It really does bring a whole new level of realism to road transportation in Simutrans. 

I have a question: what is the purpose of the "Inverted lane" option?  I know what it does mechanically, but what sort of real life situation is it meant to simulate, or what problem in the game is it meant to solve?  The other road types I get, but I'm scratching my head with this one.

[ACarlotti]

Originally posted June 02, 2018, 02:07:40 PM; partially reposted to assist splitting the topic. This section of the original post is about specific issues in THLeaderH's changes, many of which had been raised before. The remaing paragraphs can be found here.

I was looking through these changes last night, and I noticed that many of the issues mentioned in the Standard thread for this patch are still present in this thread. I've made some changes to your code, which James has now incorporated into master, so you should be able to look at them fairly easily. In no particular order:

(Also the patch files of github seems uneccessary large since a lot of identical lines (maybe with whitespaces) are contained within.)

This was my first observation too. In fact, while the full diff of your changes (using standard git diff settings) is over 10000 lines long, if I tell git to ignore whitespace changes then the diff is less than 5000 lines long. While it might be good to fix whitespace inconsistencies, this should always be done separately to other changes. The reasons for this are that it allows people to inspect and understand your changes, and that it makes it easier for people to understand the history of the code.
To take one particular example, if I look at boden/wege/weg.cc, there are a lot of changes to whitespace mixed in with actual code changes, all under the commit message "bring from standard". Ideally the code changes would have been separate to the whitespace changes, and that commit message (at least read in isolation) is quite misleading, as these changes were not taken from standard, but from a patch on top of standard.

Logic incomplete and even flagged with TODO's, yet still left.

I spotted and removed one out-of-date TODO relating to version numbers (which is fairly reasonably something to leave in until James merged it). However, there are still some others, among which this one in bauer/wegbauer.cc particularly worries me:

Code: [Select]

// TODO: not edited since it's quite different from that of standard...To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.

Maybe try using this new fangled keyword called 'else'. if(a), if(!a) yeesh.

It took me less than a minute to find an instance of if(a) {stuff} if(!a) {stuff} in your changes, and even though it might take you longer if you're not as familiar with the relevant git commands, you should still be capable of looking at your changes and reading through for things like this. I think I replaced all the instances of this particular non-pattern, but since I haven't read the patch through line-by-line I cannot be certain.

refleshing. what? I can't even...

I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant. My guess would be that you meant "refresh" instead, but even that seems like a poor name choice, with "refresh_vehicle_images" probably being a better name for the method in overtaker_t. (I would also make this method take no arguments, and move the check into overtaker.cc).
I also removed the "reflesh" method from vehicles because (as it was implemented) it was duplicating a lot of code that already existed - see my changes for (in my opinion, at least) a better way of doing that.

Another thing I've noticed that could be improved in your code is a lot of places where your manipulation of booleans is unecessarily complicated, or you store intermediate results that don't need to be stored. In one example that I simplified last night, you use about 5 lines of code with an if branch in the middle where you could have used a short boolean expression. A couple of lines later you create a whole new overtaker_t variable just to test if it is null. Storing the object suggested that you would use it again later and that the null check was partly to avoid null dereference errors; in fact I realised after a bit that the null check was the entire usage of the object.

Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.
https://forum.simutrans.com/index.php/topic,16659.msg165492.html#msg165492

Edit: Four paragraphs extracted to a new topic - see here.

I also know that there are many more changes that could (and should) be made to improve the code. I'm not going to list every single change that should be made, because that would take me days or more likely weeks, and then I might as well make them myself. (See also 'code smells'.) That is the point Turfit was making - we can tell you the sorts of issues we see, and we can maybe give you some examples, but you then have to be able to extrapolate from this and seek out other instances of these issues yourself. For example, you complained "Please make your issue posts as concrete as possible. For example of if ~ else, please point out at least 1 line that is malformed."  Did you even try looking yourself? As I said, it took me less than a minute of skimming through your changes to find an example of this; it shouldn't have taken you too long to find one yourself, even if you were unlucky and looked in the wrong places first. If you can't look for and find issues yourself, even after you are told what those issues look like, then the only alternative is that someone else rewrites your patch for you. That shouldn't be necessary.

With your knowledge and understanding of the code, you should be able read through it and rewrite bits of it more easily than me, because everywhere that something is written out poorly (e.g. with duplication, unnecessary complexity or vague of misleading code/comments) you already know what it's supposed to do. Fundamentally, what I (and Turfit, and prissi, and Ters) want is for you to read through the entire patch, line by line, and section by section, a couple of times, and think about how you could make it easier for other people to read. I'm sure James will be glad to incorporate such changes, and that is also the only way you're going to get this into Standard.

(James: I think this should enable you to split the topics - posts 34 and 37-41 being the new topic)

[jamespetts]

Thank you - I think that I have split this correctly (and edited your post to insert the links in the designated places).

[TurfIt]

Note: This ended up being quite a long post, in which I express quite a bit of frustration.

Frustration for sure with this patch, and ultimately somewhat disappointment. From a "Fun patch", to claimed trunk candidates, through sheer obstinance and even outright bold faced lies (Multiplayer tested working while the required code was completely missing!), to a final give up and ceasing work. Not fun, but wait, it's back with a series of 'updates' to fire up the rah rah crowd, all the while not addressing the deep functionality issues, and then into SimEx it goes seemingly duping with it's shiny bauble...
If feeling generous, I'd assign it a 30% completion. If not, a failed proof of concept. In neither case, something 'ready'.

I get there's serious pent-up demand for such a feature, and I truly hoped this patch would've been usable/went somewhere, but the experience has definitely reinforced my gut feeling that this approach in the code is not workable.

To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.

Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.

I expect such issues have not been resolved, and TODO's remain undone, even if the TODO itself is removed from the patch after pointing out it's existence. It's trivial to setup tests where the vehicle behaviour fails; Let's not even talk about trying corner cases. Expect bad things whenever the overtaking mode changes, or worse where they meet - aka intersections. Restrict the patch's use to creation of controlled access divided highways, and things mostly work (still issues with the inherent intersection where on/off ramps are...), but for avenues which seem to be the most desired feature, disaster.

refleshing. what? I can't even...

I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant."

'tis like something straight out of a horror movie. Tops even the factory boost mechanism 'consuming' passengers we had for a while in development of that patch I thinks.

The signalling code is, I must confess, an example of an erroneous decision on my part about how to handle the project at an early stage. The erroneous decision was to keep as much of the Standard signalling code as possible and build the additional features by adding to that code rather than starting afresh.

That sums up my feelings on the approach taken with OTRP. The existing code for vehicle movement through intersections is already stretched to the limit. Grafting multilane road logic onto it, and the existing overtaking logic takes it beyond breaking; Erroneous to continue in this way.

I intend to revisit getting the previously discussed 'intersection_t' object implemented. That should greatly simplify things w.r.t vehicle control especially with multi tile intersections. Unfortunately my on again, off again enthusiasm for contributing anything, and meandering interests has already delayed that by years...

[Ranran]

Currently, menuconf.tab of 128britain-EX has not been edited so you can not see the OTRP arrow as it is. (Is this intentional?)
If you add it to line 191 in menuconf.tab as follows, you can see the OTRP arrow by pressing ":" key.

Code: [Select]

simple_tool[37]=,:
OTRP arrow is also displayed on tracks, trams, rivers or canals. I believe it is unnecessary on there.
These ways can not be controlled with OTRP and these run on a system different from the road, for example, railway track controls the direction of the train using one way sign, but OTRP arrows are not linked with railway direction restriction, so players will get confused.

When you build the tram track on the road, these two arrows are integrated and the display of the arrow no longer makes sense. This is an obvious bug that should be fixed. (´・ω・｀)

[jamespetts]

The "," key cannot be used for this, I am afraid, since it is already used for reducing the rate at which time passes - do you think that you could find a spare key?

[Rollmaterial]

He meant the ":" key, not the comma.

[jamespetts]

Ahh - I misunderstood, my apologies. The : key appears to be free, so I have integrated this.

[Phystam]

Ranran — I think that the ribiarrow (you say “OTRP arrow”) is not only for road waytype, so it is not a bug. This is also useful for confirmation of railroad oneway sign
However, if we can display arrows for each waytype separately, it will be more convenient, I think.

[THLeaderH]

James, thank you for making a change to enable the feature of showing Ribi-Arrow.

As Ranran says, I think ribi-arrow should be only showed for street. I made a pull request.
https://github.com/jamespetts/simutrans-extended/pull/90

As Phystam put it, ribi-arrow might be useful for checking the direction of railroad oneway sign. Ribi-Arrow should be configured separately for each waytypes, but assigning keys for all waytypes is not appropriate. Also, creating GUI selection window is not a good solution. I don't know what is a suitable interface for this...

[THLeaderH]

Hello, James.
My recent releases of OTRP for standard contain some bug fixes and I brought them into the extended. Please refer the pull request.

P.S. I'm sorry that one of the commits contains an unnecessary change, the removal of spaces, but Atom editor forced me to do so :(

[jamespetts]

Thank you for that. Can I ask which bug fixes have been ported to Extended?

[THLeaderH]

This pull request contains bug fixes that was done in OTRP v14.

• bug fix for algorithm of vehicle control
• bug fix for lane yielding
• do not execute other_lane_blocked when street is twoway
• allow changing overtaking_mode for elevated way with ground way

The last one is an improvement of UI, not a bug fix.

[jamespetts]

Splendid, thank you: now incorporated.

[THLeaderH]

OTRP now becomes a kind of fork project of simutrans and continues evolvement. And it's time to bring the improvements into the extended. The latest version of OTRP is v17, so I want to bring the following changes.

• The ribi-arrow can be called from the display settings window.
• Some fixes around vehicle movement.
• Flags for road. "citycars do not enter" and "avoid becoming cityroad" feature.
• Improvement of citycars. Citycars follows lane affinity signs and the lane yielding rule.

In OTRP, Citycars now determine their route for certain tiles (e.g. 15 tiles). Determination of the route in advance is needed for lane affinity signs and other OTRP's function. Also, routing algorithm is modified so that citycars avoid a sharp turn and congested road. The acceleration of citycars is also changed to simulate a smoother movement. Are these changes acceptable for simutrans extended?

Thanks to @shingoushori, recent versions of OTRP contains some construction tools which are useful for the large scale development. The transplantation of these tools to simutrans extended should be discussed as another topic.

[ACarlotti]

Are these changes acceptable for simutrans extended?

I think there are at least three questions to ask here:
1) Are these features desirable? (Probably? I haven't tested related stuff yet.)
2) Are these features that would also be accepted in Standard (in theory, not just for the current implementation)? (If so, then I think work should probably be to add them to Standard first, so as to minimise unnecessary divergence between the code for Standard and Extended)
3) Is the code well written and likely to be maintainable? (I have my doubts based upon previous code, but will have a look if/when there is a specific proposed patch.)

[jamespetts]

Yes, given some of the problems identified with the previous version of this, we do need to be careful about merging anything other than fixes.

It would be helpful to have two things in particular (1) a separate patch just with the fixes; and (2) a more detailed description (and possibly demonstration) of the new features.

Thank you very much for your work on this.

[Phystam]

THLeaderH, thank you for your great works!

I have a question about "avoid becoming cityroad" feature.
Currently there is almost same feature in Extended version, and this is implemented with "waytype=noise_barrier" configuration for wayobj .dat file. (but I have never seen it in pak128.Britain-Ex)
So I do not think it should be incorporated for extended version, at least.

[jamespetts]

THLeaderH - can I ask whether you might be able to provide:

(1) the fixes on their own; and
(2) a more detailed description of the new features?

[THLeaderH]

(1) the fixes on their own;

Yes, I will do that. I apologize for leaving OTRP related bugs for a long time.
However, I've not heard about the defects of OTRP related feature in extended recently. Could you explain some of the defects that I have to fix?

(2) a more detailed description of the new features?

I apologize for not having provided the description while it had been requested before. Is there any template of feature description or articles that I should refer to write the description?

[jamespetts]

Thank you for your reply. I am not aware of any defects other than those that have been reported on this forum (and I think mainly in this thread). As to documenting the new features, there is not a standard template for this. I suggest that, for each feature, you set out a separate heading and describe (1) what problem that it is seeking to solve; (2) in general terms how it does it; (3) how it works algorithmically; and (4) how it works from a user interface perspective.

Thank you for your work on this so far.

[THLeaderH]

A description of OTRP for extended.

Oneway Two Lane Road

The road of simutrans standard supports only two-way traffic. Even when the road is operated as oneway with oneway signs, vehicles use only one of two lanes. When roads are congested, the traffic lane is filled and the passing lane is empty.
With simutrans extended, passing lanes are used more effectively than simutrans standard when road is set "oneway mode" by relaxing the conditions to overtake other vehicles. oneway mode enables you to build a 4-lane highway. To set the mode to roads, please select a road icon holding a ctrl key, and the road configuration dialog appears. Halt mode, oneway, twoway, only loading convoy, prohibited and inverted mode are available. With halt mode, vehicles are allowed to stop on the passing lane. This is useful to build a bus terminal.

Show Road Connection Tool

Conventionally, road tile dialogue that appears by clicking the tile was the only way to check which directions the road is connected. With the oneway mode feature for roads, checking road connection is frequently needed. In simutrans extended, simple_tool[37] is assigned to "show road connection tool". This tool visualizes the directions of road connections with arrow images.

[jamespetts]

I think that you may have misunderstood the request: my apologies if this was not clear. I was referring to this post. That post referred to a pull request, which contained both bug fixes and additional features for the OTRP. What I was after was:

(1) a separate branch/commit containing only the bug fixes already contained in the commit to which the pull request referred so that I can apply the bug fixes straight away; and
(2) a description of the new features in the commit referable to that pull request so that consideration can be given to whether also to incorporate those features.

The description above seems to be a description of the OTRP generally. I should be very grateful if you could provide the items listed above so that progress can be made. Thank you again for your work on this.

[THLeaderH]

The bug fixes that I planned to post a PR are
https://github.com/teamhimeh/simutrans/commit/bfd5806f6cc3b4a955929fae403e8c9c051c0750
https://github.com/teamhimeh/simutrans/commit/e7266465ada1cb33e7788c0a736f6ddcae85c527
https://github.com/teamhimeh/simutrans/commit/fb76da14392aeaf3e6fcb0147677d3741ee9a391

The new feature is road reservation. With this feature, vehicles reserve tiles in intersections and this prevents dead lock in big intersections that consists of more than one tiles.

I'm working on TWO pull requests separating the bug fixes and the road reservation. However, I have a trouble in compiling the code. I apologize you to take some more time to post the two pull requests.

[jamespetts]

That is very helpful, thank you. There is no rush as there are many other things to be done - but when you have the time, I shall look forward to the bug fix commits/pull requests.

As to the new feature, this is an interesting idea. Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.

I should be grateful for feedback more generally on the tile reservation feature. In the meantime, I shall look forward to the bug fixes. Thank you again for your work on this - it is appreciated.

[THLeaderH]

Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.

Traffic stuck can be often seen in the intersection that consists of multiple tiles with a dense traffic like this.


Vehicles checks the existence of other vehicles in advance when they enters an intersection. However, vehicles only checks, do not reserve the tiles. If two vehicles reache the intersection at the same step (time) , the vehicles cannot recognize other vehicles and enter the intersection. This can cause a traffic stuck. Tile reservation can solve this problem, because vehicles reserves the whole path of the intersection before they enter. As a fact, I implemented this feature because users of OTRP for standard reported me that road vehicles often stuck in a big intersection.

I continue dealing with the compile problems and they can be posted in another thread as a bug report.

[jamespetts]

Can I clarify - does the problem that intersection reservation addresses exist only when the OTRP features are used, or does it exist even with the roads' default settings?

[THLeaderH]

Theoretically, this problem exists even with the default settings, twoway mode. However, the traffic stuck phenomenon itself emerges much more frequently when the road is oneway mode. It is not clear why it is.

[Phystam]

Implementation of “intersection_t” is now needed, as A. Carlotti suggests. This class makes more simpler the code.

[jamespetts]

Thank you both for your replies. Some consideration may be needed of whether it would be preferable to implement intersection_t before making these changes; I should be grateful for A. Carlotti's view on that, since it was he who suggested adding this class.

[Ranran]

Sorry for exhumation the old thread, but I now see some issues.

I used this option to restrict a road, and after a while, when I laid the road again in another place, I forgot that I changed the option before and unintentionally made a one-way road. It may be laid. And sometimes player don't notice it, because player doesn't always display the colorful arrow.
I think it's better to reset the restrict option to default mode once exiting road laying mode.


Secondly I think this arrow has some flaws. First of all, I don't understand why the colors differ depending on the direction.
This may be a design issue, but  in any case we can't change the color due to restrictions.
I think this should be color coded according to one-way, parallel stop mode, etc.
In fact, it is not possible to distinguish the parallel stop mode from the arrows.
And at the end of the road, player may not be able to tell that it is a one-way street, as only half of the arrows are visible.

For example, the default is a color that seems to be unlimited, such as green or blue or light blue. One-way traffic colors appear to be restricted - pink, orange or red.
Then use special colors or arrows for parallel stop mode and overtaking mode.


Thirdly, why does this arrow appear with the highest priority over vehicles? That's why I hide this in most cases.
Block reservations, for example, do not hide the train.


Fourth, the arrow is affected by day and night changes, making it less visible at night. Block reservations do not. It conflicts with the basic UI behavior of simutrans.

[THLeaderH]

For the first claim, Road options including overtaking mode are preserved in the road construction tool to avoid meaningless re-selection of overtaking mode and etc. This is a design choice.

For example, if you are building a highway on the ground, you want to build a road with "oneway" mode and "avoid becoming cityroad" option. You sometimes need to construct piers and fences while the road construction. If these options are reset every time you select the road construction tool, you will always need to re-select the road construction options and that will sure be bothersome.

For the second claim, ribi-arrow is made to check the connected direction of roads and not to show the overtaking mode. The author of ribi-arrow made arrows colorful so that you can check the connected direction in an instant. Separating the color according to the overtaking mode may be useful, but it needs a remaking of the ribi-arrow addon.

For the third claim, as I put in the previous paragraph, ribi-arrow is made to check the connected direction of roads in an instant. Thus, ribi-arrow has the highest drawing priority.

For the last claim, I agree. I will make ribi-arrow not be darkened in the next release.

[Ranran]

Sorry for the late reply. Working with Dr. Google translate is a pain for me. Ranran's health is almost 0.
But rest assured. Many Japanese wear zombie-like traits to stay alive with HP1. They always seem dead, but they are alive. It's not walking dead.

I'm afraid, but I don't think I got a valid answer. First of all, I think you gave such an answer because you are not aware of the PROBLEM this feature is causing.
You had to see at these bug reports:
https://forum.simutrans.com/index.php/topic,19732.0.html
https://forum.simutrans.com/index.php/topic,20063.0.html

Defects in this design can cause great disaster. You can use this function to easily carry out harancement. Most people don't notice the fact that someone changes all the roads to "overtaking prohibited". Moreover, it is difficult to identify the criminal.
As the administrator may find by looking at the history from the log, but as I explained at the beginning, it can happen not because of the bad faith of the player, but because of the unkindness of the design.

And finding and fixing it is also a laborious task. Because it is not easy to recognize where the trap is set.

This is a design choice.

The work of discovering that trap is a meaningless work created by an unfriendly design.

For example, if you are building a highway on the ground, you want to build a road with "oneway" mode and "avoid becoming cityroad" option. You sometimes need to construct piers and fences while the road construction. If these options are reset every time you select the road construction tool, you will always need to re-select the road construction options and that will sure be bothersome.

I can't understand why you are assuming to switch and limit at the same time.
Isn't it easiest to overwrite and limit all of them once they are completed and connected?
It looks like you're making bothersome yourself. And is this bothersome a trade-off with the above problem?


Station stop mode is convenient, but I don't think this mode should be set ignoring both roads and stations.
It forces status with no relation to economy or appearance. That is why I think that color coding of arrows is the minimum necessary.
Also if we don't pay the cost, there is no reason not to set "only loading convoy" for all bus stops on roads that aren't one-way or not on the terminal end. Players who don't set this are so stupid. It only appears to be intentionally blocking traffic.
But setting it up on every bus stop is a tedious task. It's like a Japanese social game.

avoid becoming cityroad

What are you talking about? Is this a feature for standard? I don't know if that matters here. Can you elaborate?



I think a design change is necessary to solve above problems.
Because even if you prohibit the rewriting of the road restrict of other players, all the streets are public roads in the city, so you can either rewrite it except admin or you can rewrite it.
You may also enter the roads of other players. Visualization of which restriction set on the road is needed. It's rediculous not to know the information unless you click and check all the tiles that pass by.
I mean, currently, only one-way traffic can be identified. But how can you see "overtaking prohivite"?
However, frankly, in most cases, the restricted display is cut off due to excessive display, so even that may not be useful.
I didn't notice until I saw my horse take a weird route that one-way restrictions were imposed in the big city of server games.
This is inconsistent with the traditional simutrans method because it eliminates the one-way road sign and imposes such restrictions. And replaced with sometimes useless arrows.


I enumerate some measures and improvement ideas. It's like brainstorming. In the future I may try to change some if I have the time, but when I do that I will probably start by breaking down and reorganizing features. There is no doubt that a huge amount of time will be required.
However, there are many problems in the current situation, so I hope for early improvement.



Measures against incorrect limits

Although from what I saw that this endevour had become maybe a little too complex (like five overtaking modi and hidden flags by special tools) for the normal casual player.

As prissi pointed out, this is very hard for new players to understand. In addition, I believe the UI is unfriendly and not a universal design.
The one letter abbreviation of the alphabet is the worst for Japanese. Alphabets other than H have no meaning.
People in the Kanji culture will understand how stupid it is to get things understood with one letter of the alphabet.
The alphabets set in these are extremely difficult for Japanese people to understand. And this is not translatable. Is this made only for English?
I think many Japanese who are not good at English think this way. Why is it "L"? Why is it "I"? Why "H"?
Especially normal Japanese people are not familiar with "halt". Ranran thought it is German too(´・ω・`)
So you should know that this is happening in English as well. English is translated as "parallel stop mode". But the alphabet is "H". This is truly Jarapagos LOL
Also, no tooltip is placed.
If at least this color matches the color of the arrow, there is still salvation.
You know what it does because you made it. However, the UI needs to be easy to understand for those who do not know its function.



There are more things you can do to improve the design than just coloring the arrows.
- Change cursor according to mode
- Show an arrow when laying. In other words, when a mode other than the default mode is selected at the time of construction, for example, in the case of one way, the arrow from the start point to the end point is displayed regardless of the display mode.
Rather, I'm wondering if it's showing the arrow now, but not. However, this is only useful for indicating whether it is one way because there is only one type of arrow.
I also thought about writing it in a tooltip that displays the estimated cost, but that will not be very effective.

Separating the color according to the overtaking mode may be useful, but it needs a remaking of the ribi-arrow addon.

I don't understand why the default mode requires an "arrow". In other words, it is not necessary to use it, and a light blue "straight line" is sufficient. It's in both directions. The exit and entrance are sufficient for the arrow.
And "overtake stationary only", "overtaking prohibited" and "opposite lane driving" do not need arrows in the first place. This is just an area. I wonder if the station stop mode should be combined with road direction restrictions. As mentioned before, I prefer bus stop to have such a setting. Depending on the type of bus stop you decide whether you can overtake or stop in parallel, some modes are no longer needed in the first place.
The direction does not matter. At least you don't have to draw a new arrow to indicate the "area".

Anyway, it is necessary to make it easy to understand where the restrictions are imposed, as the problem is pointed out. Putting strange and colorful arrows everywhere is just confusing.
At least in many cases, I have to say that this display is excessive. I've used block reservations a number of times to compare this, but it's like coloring non-reserved blocks as "here is not reserved". Since it is excessive, it feels very annoying that it is displayed with priority over the vehicle.

I think color distinction is needed, but I think the option to show arrows only in non-default places is needed even if you don't implement it.
Otherwise, players may have restrictions that can only be found by clicking on each tile to see it.

ribi-arrow is made to check the connected direction of roads and not to show the overtaking mode.
ribi-arrow is made to check the connected direction of roads in an instant.

With the current specifications, it is impossible to know if it is in both directions without the cooperation of the tile next to it. This is a design error. So your goal does not appear to be achieved.
First, the arrow does not have to be on the center line of the road. There should be two lanes on the road. For some reason, I'm going to write the arrow on the centerline, not on the lane. If it's a one-way street, it could be right.
I have left-hand and right-hand traffic problems, but I just shift the offset from the center depending on the settings. This may support "Invert".


I like the combination of appearance, economy and function. That is, cost, appearance, and function are linked. It should be easier for players to understand. But I can understand that implementing it can be tedious.

For example, an overtaking bus stop on one way would look like this.


If it can overtake in both directions, the bus stop will be on the back side.
In case of pararell stop, there should be a bus stop in the same direction. Because the bus has a door on only one side. It's strange that it has a parallel stop at an ordinary bus stop. Passengers who get off the road will be killed by cars in the next lane.

Another thread doesn't point out that it's unnatural for someone to be able to pass on a narrow trail. However, this feature allows overtaking on any road. No additional cost required.

[Vladki]

For the third claim, as I put in the previous paragraph, ribi-arrow is made to check the connected direction of roads in an instant. Thus, ribi-arrow has the highest drawing priority.

If this is the primary purpose - to find accidentally disconnected roads, then this arrows should be displayed for all waytypes. It is much more common to forget disconnected rail track.

Otherwise I would have this suggestion (combining ranran's ideas):

- The current style of arrows is good for railways (and maglevs, etc.) Different colors for each direction are not necessary, but not a problem either. Different color for road and tram would be good (see below).
- For roads the arrow should be offset to show to which lane it applies. This would allow easy show of "oneway", "twoway" and "inverted" modes. (Also a tram arrows could be shown in the middle lane - perhaps distinguished by color).
- overtaking prohibited = full thin line in the center (a bit like the pink arrow on ranrans picture)
- halt mode - AFAIK it implies oneway so arrows should be like that. To distinguish it from oneway, a full line as for no overtaking could be shown, or some other color used.
- only loading convoi - maybe dashed center line? Or full line of different color?

BTW: I'm not sure setting "only loading convoi" on all stops makes any improvements. AFAIK Stopped vehicles can be overtaken anyway if the rules for overtaking are met (no cars in opposite direction, etc.) This will not relax any of the restrictions. It will just forbid overtaking of non-loading convois. However I'd like to see a mode where loading convois can be overtaken more easily. Especially in situation where you have longer stop (2-3 tiles), used by many 1-tile long buses. So that they could overtake each other and use any free stop (using choose sign).

Single sided bus stops on one way road would be nice, but it would work only if the stop does not have any painting on ground (like old style bus stops in pak-britain). The you could just show only frontimage or only backimage. But the road painting is always backimage, so you would have both in one direction, and non in the other.

EDIT: and one more mode would be nice - parallel bus stop (halt mode) for dead end stops.
EDIT2: and show the arrows when building the road by dragging

[Ranran]

If this is the primary purpose - to find accidentally disconnected roads, then this arrows should be displayed for all waytypes. It is much more common to forget disconnected rail track.

I think the spaced arrows aren't very good at checking connectivity. Also, arrows do not support slopes or diagonals.

BTW: I'm not sure setting "only loading convoi" on all stops makes any improvements. AFAIK Stopped vehicles can be overtaken anyway if the rules for overtaking are met (no cars in opposite direction, etc.) This will not relax any of the restrictions. It will just forbid overtaking of non-loading convois. However I'd like to see a mode where loading convois can be overtaken more easily. Especially in situation where you have longer stop (2-3 tiles), used by many 1-tile long buses. So that they could overtake each other and use any free stop (using choose sign).

I don't know if this involved a bug. It seemed that the passing carriage did not pass the stopping carriage on the two-way road. The carriage stopped for about 7 minutes and was blocking the carriage.

The you could just show only frontimage or only backimage. But the road painting is always backimage, so you would have both in one direction, and non in the other.

I think it's still easy to implement a single-sided bus stop.
Having a central bus stop for parallel stops requires modification. However, the ability to draw objects in the center has other extensibility. (E.g. policeman signal at intersection, center pole of trolley line, but policemen will be run over and killed by trams)