-
Notifications
You must be signed in to change notification settings - Fork 3
Routing rules and capabilities
When upro optimizes the active route, it considers a list of rules and capabilities that determine the best way to get from A to B.
In short, capabilities determine how a system can be reached (if at all), rules determine which way is better to reach it.
A capability determines what kind of transport between two systems is possible and should be considered. The most common capability is "Jump Gates", which allows the route finding algorithm to consider jump gate corridors to be used. When searching a route for a capital ship for example, this capability must be turned off and instead the "Jump Drive" capability turned on.
upro considers the following capabilities:
- Jump Gates: Will consider the standard jump gate corridors in New Eden.
- Wormholes: Will consider wormhole jump corridors (both static and dynamic). Enable this if you have a probe launcher and/or bookmarks for the wormholes.
- Jump Bridges: Take jump bridge corridors into account.
- Jump Drive: Use this for jump drive capable ships. This capability can furthermore be configured what the maximum jump range is. This parameter uses the unit of light-years and can be set in 0.25 increments.
Capabilities are set in the main context menu of the 3D map under "Routing" -> "Capabilities".
Ignored solar systems are a special form of capabilities in the way that these systems are not considered as transit systems when trying to reach the destination, but still can be reached when they are set explicitly as waypoint/checkpoint.
When upro finds a possible path between two systems according to the capabilities, the rules define the relevance of the path. Rules are listed in order of their priority, can be disabled and have a parameter which refines the rule.
The order of the rules is important as the rules with the lower priorities are only considered if two paths have the same 'cost' according to the higher rule. See examples below for clarification.
Note that if a route was found that still violates a given rule (e.g. going through nullsec although preferring highsec) then this was the best route to do this.
This rule has the system security level as parameter in the range of 0.0 to 0.5 . When enabled, paths which contain systems with at least this security level are better than those below.
Disabling this rule is the equivalent of disabling "Prefer Safer" in the NeoCom. But the main difference is to be able to set it to 0.4 for example to avoid the possibility of warp bubbles. Set it to 0.1 to avoid nullsec.
This rule has also the system security level as parameter in the range of 0.5 to 1.0 . When enabled, paths which contain systems below this security level are better than those equal or above.
Enabling this rule is the equivalent of enabling "Prefer Less Secure" in the NeoCom. Again, here you have the capability to fine-grain this setting: Some pilots are not allowed in 1.0 security systems only...
This rule can be used in combination with the jump drive capability. It considers routes with the least jump drive travelling distance (saving jump fuel).
The parameter for this rule adds a little leeway to the comparison. If two routes have nearly the same total jump distance, they can be considered to be identical if the difference is within this configured margin. This can help in finding better routes in combination with other rules.
This rule is the classic 'shortest route' rule. The parameter of this rule is another margin that will consider paths of similar length to be equal.
The idea of this margin is again to have a more detailed control over the routing. For example, if a route containing jump drive jumps is shorter by one system compared to a second route which has no jump drives, a margin of 1 would then resolve to the second route as it uses the least amount of jump fuel.