Permit co-entry on 4-way tracks with no conflict

[poppo]

I make a patch4way_update.patch which allow 2 convoys to enter the 4-way tile only if they do not "conflict" each other.


When two convoys are conflict (e.g. N->S and E->W), they cannot enter(reserve) in the same time (see the convoys in the right side of this figure).


If you add paks, you can reduce the spacing between two digaonal tracks.


Technically, I add
  ribi_t::ribi reserved_dir
  convoihandle_t reserved_2
in schiene_t to check the convoys conflicts in 4-way tracks, and update how to resere/unreserve tracks.

[prissi]

Very interesting way to get around the two ways on one tile problem.

One would need to update the airplane logic then too, since they are derived from schiene_t right now.

EDIT:
Actually, one could add another two images to the rails (like OpenTTD has) and similar to the initial diagonal graphics. That image (if missing) could be even generated on the fly from existing diagonals (if there). That would give close diagonals with normal rails and add a flag to the schiene_t to be aware of that situation (i.e. "double_diagonal"). That way it could forbid turning and decouple reservations by just using two slots for only such tiles. Then the ribis would not need to be stored.

However, the wayfinder would need changes too. In the moment, tiles are always probed clockwise. That means on close diagonals, the driving direction of close diagonals going towards the viewer is different from the one going away from the viewer. Moreover, signals can only be placed every second tile.

I think this needs some more discussion before including.

[poppo]

In my opinion, we shouldn't restrict the direction.
Although I've only shown images of it being used to narrow the tracks width, there are other potential applications, such as reducing interference at station crossings (I'm also trying this co-entry with choose-signal).

[prissi]

I think working with choose signals is good. I am currently seeing if something can be cooked up with the diagonals without needing new graphics.

EDIT: Here is a patch for also showing them as diagonals.

Still, the route finder is quite agnostic about those. But with this extra flag of close diagonals, it should get the allowed directions depending on the previous tile.

[prissi]

Getting the routing right is more difficult. Here some corrections and a new diff that gets the display almost right in my tests.

[poppo]

Thank you very much!
but, in your patch, I think has_close_diagonal_image() does not have a default return value (should it be "false"?).

[prissi]

Indeed. Also, now the routing will obey if there are close diagonals. Now I just have to merge this with your patch and we have close diagonals, if the rails have been defined with diagonal images. (Not the case for pak64 roads and pak128 rails ...)

Actually, with having the information of being a double diagonal, I could simplifly your patch a lot. Comitted for testing to the nightlies.

(Remember, normal pak128 rails will not work, only pak64 for now.)

[poppo]

cool! but if road has sidewalk texture, images will be broken.
if merge two graphics, I think we should mask the images (in diagonal way, the actual image area to be used can be cropped into a rectangle)

[makie]

The Pak designers should be able to define extra graphics for this case.

[prissi]

I think fine tuning the images is up to pakset designers. If a road has a sidewalk graphic, then either do not define diagonal images and no close diagonals will be created. Or, of course, pakset designers are able to define their own graphics for this case.

It is the diagonal[close1] and diagonal[close1]

By defining this, even the walkway road could be fixed.

[Andarix]

....
It is the diagonal[close1] and diagonal[close1]
....

[prissi]

close2, sorry ...