How does trade volume vary with fuel price? Alex Goodwin (26 Dec 2021 07:01 UTC)
Re: [TML] How does trade volume vary with fuel price? Thomas Jones-Low (26 Dec 2021 16:56 UTC)
Re: [TML] How does trade volume vary with fuel price? Alex Goodwin (26 Dec 2021 17:49 UTC)
Re: [TML] How does trade volume vary with fuel price? Thomas Jones-Low (26 Dec 2021 23:37 UTC)
Re: [TML] How does trade volume vary with fuel price? Alex Goodwin (27 Dec 2021 06:53 UTC)
Re: [TML] How does trade volume vary with fuel price? Rupert Boleyn (28 Dec 2021 16:30 UTC)

Re: [TML] How does trade volume vary with fuel price? Thomas Jones-Low 26 Dec 2021 23:37 UTC

On 12/26/2021 12:49 PM, Alex Goodwin - alex.goodwin at multitel.com.au (via tml
list) wrote:
> I'll take a gameable abstraction, such as something I can implement in a fork of
> PyRoute.
>
> Maybe a distance penalty along affected links?  Relative price of X (X > 1)
> means links are (X - 1) pc longer.  A "cashtrographic" distance penalty, if
> you'll pardon the lame pun.
>
> For example, assume Teacup Station charges 3x the going rate for fuel. Dismal to
> Kushuggi 2631 (when it gets developed) is 4 pc astrographically (via Teacup, at
> Kushuggi 2431), but a total of 8 pc cashtrographically (+2 pc penalty per link
> adjoining Teacup, 2 such links involved).
>
> Would trade volume be perfectly inelastic wrt fuel price?  (ie, completely
> unaffected)
>
> How about somewhat inelastic?  (Total fuel revenue increasing with price)

	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 Jones-Low
Work:	xxxxxx@softstart.com
Home:   xxxxxx@gmail.com