Why ShipAI alone does not have skipQueue

@krzychu124 did you forgot to add skipQueue to ShipAI? If so we should delete this line:

//CreatePathPatch.cs
if (ai is ShipAI) args.skipQueue = false; // TODO [issue #952] why ShipAI should be different than others?

If not we should add a comment there explaining why.

[originalfoo]

Maybe it would help to group things in to “meta” network categories, and then seek consistency within each meta category?

• Dynamic: No fixed network (eg. helicopters)
• Flexible: Easy to reroute (eg. cars, cims)
• Limited: Difficult to reroute, but feasible (eg. ships, aircraft)
• Rigid: Not logical/possible to reroute (eg. track-bound vehicles)

The frequency at which users alter networks is influenced by those same factors, which determines the importance of repathing already-spawned vehicles.

I assume failing to repath a vehicle leads to despawning. So on things like ship and plane routes it could be problematic if we try repath too soon?

[krzychu124]

Wait… skipQueue was not changed (for other types) to speed up searching for path, but for fixing problem with despawning, because every time you touch segment or node (changing restriction and other things) segment is invalidated, so without skipQueue, those vehicles (driving through invalidated segments) could despawn before they get corrected path again. In vanilla there are not such problems because invalidation occurs only when you remove or add segment/node (despawn is not surprise).

We don’t have any restrictions for aircraft or ship lines, so I don’t think we need to change anything there