The root README was written when none of this was published, and it showed.
The install block was BROKEN in the same way the registry README's was, and I
fixed that one without looking here:
bunx vibe3d init
bunx vibe3d add @medieval-kit/wooden-barrel
`init` seeds `models.json` with `@scifi-kit` only, so the second line stops with
`Registry @medieval-kit is not configured in models.json`. The registry entry
and the two dependencies are now in the block, in the order they have to be run.
The npm link pointed at a file in this repository rather than at the package,
because when it was written there was no package to point at. There is now.
Neither document linked the live viewer at all — the one thing a stranger
landing here can use without installing anything. It is the second thing on the
page now.
REFERENCE's "publish your own registry, you need nobody's permission" section
gets the receipt: this registry is live and vibe3d was not involved. It also
gets the warning I would have wanted before doing it — npm stamps the
publishing account's email into the packument per version and later account
changes do not rewrite it, so the address on the account at that moment is
public permanently.
Checked every outbound link in both documents as a logged-out stranger: bun.sh,
vibe-stack/vibe3d and medieval.crt.fyi all 200. npmjs.com answers 403 to a
scripted request, which is its bot protection and not a broken link — the
registry API serves 0.1.1 as latest.
Still 404 for a stranger, and deliberately: github.com/CRTkafa/medieval-kit and
its /issues, which npm renders as the Repository and Issues links on the
package page. They come back the moment the repository goes public.
Found by installing 0.1.0 from npm into an empty directory and doing exactly
what the README says, which is the first time anyone has done that — until an
hour ago there was nothing on npm to install.
Everything held except one line. `bunx vibe3d init`, the `models.json` registry
entry, `vibe3d add @medieval-kit` (46 files), `three` and `@types/three`: all
correct. `@types/three` is genuinely not optional, confirmed by removing it and
watching three TS7016s land on the runtime files init had just written.
The Project setup block was wrong. I wrote it by copying this repository's own
`tsconfig.json`, which carries `"baseUrl": "."` — and this repository pins
typescript at ^5.9.2, so it never sees that a fresh `bun add -d typescript`
installs 7.0.2, where the option has been REMOVED:
error TS5102: Option 'baseUrl' has been removed.
So the one instruction on the page that a reader cannot check against anything
else was the one that stopped them. `paths` resolves relative to the tsconfig
on its own and has since 4.1, so the block just loses the line; the same config
now typechecks the installed source clean on 7.0.2.
The lesson is the one this repo keeps relearning in a new costume: a setting
copied from a working project is evidence about THAT project. This one was
right here and wrong in the only place it was published to.
Verified after the change in the same clean project: tsc silent, and
`createModel()` from the npm-installed hand-cart builds 2044 triangles with its
floor at y = -0.0000 — so the wheels that started this whole thread are on the
ground in the published package too.
Two things, both found by pulling on the handcart's thread.
THE LADDER. I said three models had parts floating a few millimetres. One did.
The other two readings were my own measurement error and worth writing down,
because it is the same error as the vertex-sampling ones: I measured each part
against the model's BOUNDING BOX minimum, and a part deliberately bedded into
the ground drags that datum below the floor, so every correctly placed part
beside it appears to float by exactly the bedding depth. The forge's base
stones settle 6.8 mm and the well's drystone kerb 9.3 mm, both on purpose, and
the bellows and the well frame sit exactly on the floor their own source
declares. Nothing wrong with either.
The post mill's tail ladder was real: 14.5 mm clear. It already carried two
analytic corrections for the same corner, both correct about what they
describe, and neither accounting for the chamfer — the corner they compute the
drop of has been cut off, so the residual was very nearly the chamfer itself.
Rather than add a third derivation to a spot that has now been got wrong three
times, the assembled ladder is measured and put on the floor. A bounding box
cannot be wrong about this the way arithmetic can, and it stays right when the
chamfer or the rail section changes.
`restsOn` now covers the mill's trestle and ladder too, and its doc comment
carries the bedding caveat, so the next person to reach for it knows the datum
is the bounding box and knows what that costs.
THE ANIMATED COLUMN. `catalog-table.ts` decided it with `built.action`, which
is the VIEWER's hand-registered button and exists for five models. So the
generated table published the grindstone, the stone well, the post mill, the
cauldron, the forge and the handcart as static — six of the eleven models that
carry actions, including three of the most animated things in the kit.
The obvious replacement is worse. `core/kit.ts` wraps update as
`update: (dt) => options.update?.(dt, runtime)`, so it is a function on every
model whether or not that model does anything with it, and switching to it
marked all thirty-seven animated. One flag too narrow, its replacement too
broad.
So the generator now runs each model — a second of frames, then its action if
it has one — and asks whether anything moved. That catches what moves by
itself. What moves ON DEMAND it cannot catch, because the motion is behind an
interface the catalogue never exposed, so `Entry` now carries `actionNames`
from the model's own actions. Eleven models, and both documents list them.
Worth keeping: this table is generated precisely so it cannot go stale, it says
so in its own prose, and it was wrong for months. Generated is not the same as
correct — it only moves the mistake into the generator, where nobody looks.
Also in the npm README, which is the page npmjs.com renders: `vibe3d init` is
now the first line rather than unmentioned, `@types/three` is called out (three
ships no declarations, so without it the installed source does not typecheck),
the `@/` alias and `allowImportingTsExtensions` have a Project setup block, and
the one relative link is gone — npm resolves those against the repository, and
this one pointed at a directory the package deliberately does not ship.
`homepage` now points at the live site instead of a repository that is private.
