On 27/12/21 09:37, Thomas Jones-Low - tjoneslow at gmail.com (via tml
list) wrote:
> <snip>
>     The challenge with putting something like this into PyRoute, and
> the underlying GT:Far Trader system is it operates on a order of
> magnitude scale. That is it's trying to estimate trade across 5+
> orders of magnitude. So unless the "cashographic" penalty is going to
> have an order of magnitude (or half an order of magnitude based upon
> BTN values), you won't see any affect. The scale of the process is
> wrong. There is a -0.5 BTN penalty for crossing borders, but that may
> be much more impactful than you are interested in seeing.
>
>     That said, PyRoute does calculate a "route_weight" via a function
> of the same name to encourage the routing to pass through better ports
> and more important worlds. I'm quite sure you could tweak that to your
> heart's content to encourage or avoid specific worlds.
>
>     Keep in mind the way PyRoute works is once it decides that a
> specific route is "most efficient", it reduces the weights of that
> route. In effect funneling all of the traffic along that route. This
> is configurable.
>
>     And the initial setting for the route_weight, purely based upon
> distance, was a guesstimate based upon several different builds of the
> same sized ship with different jump/cargo capacity. So the
> profitiablity of a generic trade ship built at J1/J2/J3/J4/J5/J6
> determined what was the most efficient design, and the routes weighted
> that way.
>

Thomas,

Thanks for confirming the impressions I've picked up as I've been diving
into PyRoute's guts, and for giving me another way to think about my
problem.  I suggested the local-distance-penalty approach to (try to)
actually reduce trade volumes, but that would affect local routes
disproportionately more than long-haul routes, where it gets folded into
background noise.

Alex
--