Cars should prefer main roads

[kianzarrin]

Looking at the vanilla path finder code, I can see cars prefer to go through middle nodes rather than transitional node (nodes will have transition flag if the two roads do not match):

bool flag2 = (instance.m_nodes.m_buffer[(int)targetNode].m_flags & NetNode.Flags.Transition) != NetNode.Flags.None;
float num14 = Vector3.Distance(a, b);
if (flag2)
    num14 *= 2f;

I think junctions should be even less appealing. path find should take into account priority signs and going through blocked junctions (which confuse @aubergine10 lol!). if stop sign is set, cars don't want to go there too much. If yield sign is set, its more appealing. if Main sign is set (the yellow diamond) then it should act like middle node. So for example in the picture above cars should not care too much about the incoming alley.

This is particularly important in highway transitional nodes.

[kvakvs]

I suggest replacing the entire routing system with A-star implementation which will account for these little things and weight them differently

[originalfoo]

Yes, we need complete new pathfinder ideally.

I don't think we've gone that route (haha!) in the past due to fear that the vanilla patfhinder will change. But in reality I think if we have our own pathfinder it will be much easier to maintain; should any new stuff appear in vanilla we can just choose how we're going to implement it in our pathfinder.

We also need to factor in parking AI. @krzychu124 has been digging in to it and realised it needs better support in the pathfinder.

For exmaple, we should be 'drawing a box' (that snaps to building grid units) around destination, and find where the parking places are. Then we need to check if a parking place can reach destination. And then draw line between destination and source, route between destination and line, and between those successfull routes and source.

There's also contraction theory we could use: #114. Instead of doing detailed pathing to find viable routes, can we do quick pathing to build a lsit of viable routes and then scan those routes with the more detailed checks?

[kvakvs]

I am interested to step in for routing later, done some A* impls in the past too, and this is using Dijkstra very similar.

[kianzarrin]

Can we do it with transpires and pre/postfixes? does anyone else use pathfind?

EDIT: I have some experience with transpiling hehe!

[originalfoo]

For preference of roads with/without junctions, etc., we could probably have that as part of individual driving style, see: #875

EDIT: Trucks in particular should have very strong preference for main roads.

[originalfoo]

does anyone else use pathfind?

I think there are some cases of pathfind but if memory serves they all go via the vehicle AIs (eg. StartPathFind(); I am not aware of any mod interfacing directly to the main pathfinder class. So I think we have free reign to do whatever we want in the actual pathfinder.

[originalfoo]

Tagging #337

[kianzarrin]

There is one mod that tries to discourage cars from using a segment.

[originalfoo]

There is one mod that tries to discourage cars from using a segment.

this one? https://steamcommunity.com/sharedfiles/filedetails/?id=1829496988

The issue that is trying to resolve is to make cargo, in particular, choose differnet cargo stations/hubs/ports that are close together, rather than always going for the closest one (leaving the others idle).

I think if we do something to replace pathfinder, that kind of thing should be built in by default. In other words, a cargo vehicle looking for port/hub/station should scan an area via building grid and pick one at random maybe?

Alternatively we could allow user to use something akin to lane connectors, but instead of connecting lanes they'd be connecting buildings. TMPE would choose (and update when buildings added/removed) defaults, but user could customise. For example, they could set up a group of harbors along a coastline and cargo ships will choose randomly from the group rather than just use nearest (they'd find nearest, then get its "group" and choose randomly from that).

EDIT: We are veering massively off topic here hehe.

[originalfoo]

I've just realised that TM:PE probably already penalises junctions (or any place where traffic can jam) due to the advanced vehicle AI. It keeps metrics on traffic flow and then discourages paths from using conjested segments.

[me22]

In other words, a cargo vehicle looking for port/hub/station should scan an area via building grid and pick one at random maybe?

I think a big chunk of the problem here is that it's not doing any pathfinding to pick one. It (TransferManager.MatchOffers) will pick the first one it finds (in the offers list) under a certain euclidean distance, or the closest one if there's none that close.

Are there any optimizations in place for repeated pathfinds? Once an offer is matched it needs to pathfind to get the truck to the location anyway, so if the path could be re-used it shouldn't even be extra cost if we could just Dijkstra outward to find the match (automatically using the existing randomness to load balance between equivalent routes, and avoiding busy ports thanks to the traffic penalties) instead of the vanilla way of matching on poor heuristics...