v0.7.0 — pakset profiles measured against the real pakset
Install: download simutrans_blender_kit.zip below, then in Blender go to Edit → Preferences → Add-ons → Install…, pick the zip, and enable "Simutrans Blender Kit".
Pakset profiles measured against the real pakset, not transcribed and hoped — and the one measurement that changes the artist's advice put in front of them.
The numbers now come from the pakset, not from us
core/paksets.py carries numbers that belong to the pakset — tile_height, and now height_conversion_factor — read from its config/simuconf.tab. The old test proved those numbers were self-consistent; consistency is not correctness, and it cannot catch a transcription that is self-consistent and simply wrong, nor a pakset that changed the value in a new release. The module's own docstring named the failure: "the sort of wrong number that waits" until something reads the field.
So a new profile test suite reads the real simuconf.tab of every mounted pakset — the demo pak in the engine source, the pak128 testbed — with the engine's own parsing (# a comment only at column 0, values read strtol-style) and asserts our profile equals it. It skips when nothing is mounted, so CI stays green while a local run verifies against the artefact. tools/measure_pakset.py is the instrument.
The fact it surfaced: pak128's hills are double by default
pak128 declares height_conversion_factor = 2. With factor 2 the engine turns a terrain step into a double-height slope (slope_from_slope4, grund.cc / tunnelboden.cc / brueckenboden.cc), so pak128's ordinary hill is double. That makes the double-slope way image (imageup2, the way_slope2 model) the common case for pak128 — not the optional decoration it is for a single-height pakset.
So the panel now says so: render a way for pak128 with a single ramp but no way_slope2, and it warns that the single-height slope image will be stretched over every ordinary hill (way_desc.h:176), and to model way_slope2. It stays silent for the demo pak, where the double slope is genuinely rare, and once the double ramp is modelled — no crying wolf.
Grounded and verified
Every number is read from the real pakset with the engine's own parsing, and the double-slope rule is read off way_desc.h, grund.cc, settings.cc and environment.cc. The profile suite was proved adversarially — forge a wrong profile (the historical tile_height = 16, twice too steep) and it fails and names the drift; it is not a tautology. The panel warning is tested both ways: the pure decision without Blender, and a panel test that models a pak128 way with way_slope but no way_slope2 and asserts the warning reaches the panel, then adds way_slope2 and asserts it goes quiet.
No sprite the kit produces changed. This is reference data made trustworthy, and one measured fact turned into advice the artist actually sees.
Not measured, honestly: pak192 and pak256 are not mounted here, so they carry the engine default; the profile suite will measure them the day they are.