Colonize devlog: the two fixes that mattered
A month of hardening the colonisation planner, and the two changes I would keep if I could keep only two.
Thirty-two commits in, still a private beta, Apache 2.0, CI green. Since the review I started the month with, type errors went from 52 to none, tests from 35 to 110, and the stylesheet from 58 stray colour values down to 5. Less glamorous than features, and it is what made the features possible.
Where it is
Colonize reads your journal, works out what each construction site still needs, and gives you a buying list in loads sized to your hold.
The Plan tab now opens first, because that is what you actually want when you launch it: trips sized to your cargo capacity, ordered nearest-first, tickable line by line. If you are docked at a seller, whatever this market has for your plan is pinned to the top. Every station carries a number so a buy card and its stop on the route match at a glance. Build holds the active sites and what is still owed, Search is everything saved from scans and dock history, and Wing splits claims across pilots with cargo synced through EDSM. Sellers come from markets you dock at, from Spansh scans, and from the little browser helper for Inara.
Fix one: I was asking the wrong question
For weeks I thought Spansh’s commodity search was flaky. It was not - I was querying by symbol, which fails much of the time, when querying by name never does. Worse, my cache recorded any failure as “no sellers here” and held that for ten minutes, so one transient error hid a material for the rest of the session. Names lead now, paging works, and every one of the 55 commodities across my own 36 sites has a seller - 54 of them within 30 light years. The lesson I am keeping: when a service seems unreliable, check what you are sending it before you blame it.
Fix two: a folder handle in the wrong place
The browser helper used to keep a handle to the app’s import folder inside the storage that belongs to the Inara site itself. Which meant that, in principle, any script running on that domain could have written into a folder my app auto-imports from. I did not like that once I saw it. It saves through the browser’s normal download mechanism now, which cannot reach anywhere else, and the app watches the download folder instead.
Next
Launch it in Electron for real - it has only ever run from the dev server, which is a slightly embarrassing thing to admit thirty-two commits in. Then main-process performance, and an import from EDAstro once I know the build-cost table it depends on is going to be maintained.