Increased mining, over supply, waypoint monitoring

Mar 26 increased mining activity v2.7

After purchasing a SHIP_LIGHT_SHUTTLE to transport mining results from the mining drones to their import markets I found that the round trip was too long and mining drones were filling up their cargo holds before the shuttle has delivered all the goods and returned. The immediate resolution for this was to jettison non-ore results, meaning the shuttle needs ferry between the asteroid and a single market. After automating the shuttle I realised my command ship also has similar cargo space so the same shuttle logic could be applied to it when it’s not otherwise doing anything.

The big drops in Credits/hour below represent the automation buying new ships.

With increased mining I’m seeing a slow decrease in Credits/hour which I presume is the result of constant selling ore. I can confirm this once i’ve implemented some improved market monitoring, though I also want to see what effect SHIP_SURVEYOR can have on my mining operations.

Mar 28 over supply v2.8

The shuttle logic was modular enough that it was trival to refer the command ship to it should the command ship have already performed its logic. Turns out the command ship has a much larger engine and with 10x the speed I needed more mining probes to keep the transports busy. The result of this was a plummeting ore price as I over-supplied the market.

I do not know at this stage what causes the price to bounce back.

My grafana dashboards are becoming complex, and I need to implement some kind of backup/restore for them - to de-risk this in the short-term I’ve started to commit my more complex queries as views to the database.

Mar 31 improved waypoint monitoring v2.9

Increasing the mining drone count to 20 eventually caused the price of all ore in the system to bottom out and I had to stop the automation as it was slowly losing credits. I’ll need to improve how I monitor the market across waypoints so I’ve added a bunch of code to do this.

Ultimately i’ll use probes to periodically check each waypoint, but I need to write the probe automation to do this. I’ll have to purchase probes over time and slowly send them out across the system, starting with the waypoints closest to the ENGINEERED_ASTEROID. A quick route to euclidian distance in Postgres is to use the cube extension:

with originCTE as (
  select
    cube(array[x,y]) as position
  from
    waypoint
  where
    reset_date ='2024-03-24' 
  and
    type = 'ENGINEERED_ASTEROID'
), distanceCTE as (
  select 
    waypoint.*,
    cube(array[waypoint.x, waypoint.y]) <-> originCTE.position as distance
  from
    waypoint
  join
    originCTE on 1=1
  where
      reset_date ='2024-03-24'
)
select
    *
from
    distanceCTE
where 'SHIPYARD' = any(traits)
or
    'MARKETPLACE' = any(traits)
order by
    distance;