Longhouse 2.1.0
20 September 2026. After 2.0.20.
Adds Jafna 1.0.0 and repins Sinka 1.2.0 and Vaettir 1.6.0. A minor bump rather than a patch because the set grew: the pack's version moves when a mod is added, removed or repinned, and the previous release was a repin.
Vaettir 1.6.0
A stowing post is something you improve now rather than something you finish. Three pieces stand beside it, each changing what it does, and the game's own station-extension motes show which post a piece is serving - the same thing a chopping block draws to its workbench.
A creel rail makes the post hold exactly what a reinforced chest holds, 6x2 becoming 6x4, and its spirit carry twenty items a trip instead of ten. 25 fine wood, 10 iron nails and 8 leather scraps: no heartwood, because it is joinery and it should be buildable the same evening as the post. A spirit perch puts a second courier in the air for a heartwood, 25 fine wood, 6 iron nails and 6 silver. Taking either one down hands everything back.
A hod jib is the one that changes how crafting works. While a crafting station stands within 20m of the post, the crafting panel counts what is in the chests around that post and crafting spends out of them - but only materials from a biome whose boss is dead. Eikthyr opens the Meadows, the Elder the Black Forest, and so on to Fader and the Ashlands, so a chest full of black metal is not a shortcut past the Plains. Which biome an item belongs to is derived from where it grows and what drops it rather than from a list, so a mod that adds an ore lands somewhere sensible without being told. Benches only: not the hammer, not smelter or kiln fuel. 1 heartwood, 35 fine wood, 10 iron nails and 2 chain.
Three new prefab names become permanent for anyone who builds one - stow_rail, hod_jib
and stow_perch - the same way stow_post already is. A world that loads without the mod
discards them silently.
Taking a rail down now spills what will not fit rather than refusing to shrink, which is what breaking a chest has always done. And a post remembers its own size, so it opens at the size it really is instead of opening at the widest a post can ever be and settling five seconds later.
Two chests, two players and one craft were the part that had never been exercised. They are now, on a second client against the dev server: a craft paid for out of a chest somebody else owns, and two players spending from one chest with only one craft's worth in it. The material goes down exactly once.
Sinka 1.2.0
Chests stack. Vanilla refuses a chest on a chest outright - the placement test reads the
m_supports flag of the piece you are aiming at, and every chest has it off - and the wear
tick then destroys any piece that ends up unsupported, contents and all. Sinka answers both,
and narrowly: a chest holds up a chest and nothing else, so a wall or a torch on one is still
refused. On this server it is safe because every player here runs the pack. A player
without Sinka standing near a stack computes it the vanilla way and destroys the top chest,
which is why the setting carries that warning and why it is worth knowing before anyone
builds a wall of them on a server that is not this one.
Sharp stakes chain again. They never have: the piece keeps its colliders outside the subtree Sinka measured, so it fell back to mesh bounds, came out deeper than it is wide, and put its snap points on the panel's front and back faces rather than its two ends. Four pieces measure from their colliders now and chain tighter than they did - the black metal, grausten and warderobe chests, and the stakes themselves.
Every standing torch sinks into every pole, where 1.1.0 knew one torch and two poles. How much
of a torch shows is measured off its own fire rather than typed, which is what makes that
possible without standing each one on a pole first. And Gap is per prefab now, so a stake
wall can stand a hand apart in the same world where the chests sit flush.
Levelling with the hoe stops chasing your crosshair. Vanilla eases every point under the tool toward the placement ghost's height, and the ghost sits wherever you last looked at the ground, so two swings a step apart pull their shared overlap toward two different heights - which is the real reason a large flat area is miserable to make, rather than the tool being small. Jafna reads the flag the game already saves per grid point for "a terrain operation touched this", and a swing covering ground an earlier swing shaped takes that height instead. Flat then spreads outward from wherever it started, across sessions and across players.
It also adds a held height on Left Alt, a reach that grows with Crafting on the same curve Skaft uses, the numbers on the build panel while a levelling tool is out, and a ward test against the whole footprint rather than the single point vanilla checks.
Two things about it worth knowing before anyone reports them as faults, both documented in
Jafna's own README. Flattening is capped near a metre per point by vanilla's own clamp, so a
held height further than that is approached and not reached - raise the ground first. And Left
Alt is shared with vanilla's alt-placement key; it tested clean, and HoldKey is configurable
if a ghost ever misbehaves.
What moved · 3
Jafna joins at 1.0.0
1.0.0
First release. Built, played and corrected in one sitting; the "Verified in game" section below is what was actually watched rather than what was argued from the source.
Levelling continues the flat ground it touches. Vanilla's level operation sets every point
under the tool to the height of the placement ghost, which sits wherever your crosshair last
met the ground, so the height a swing aims at follows the camera. Two swings taken a step apart
level their shared overlap to two different heights and the second one wins, permanently. That
is the reason a large flat area is miserable to make, and it is worth saying plainly because it
looks like the opposite problem: the tool feels too small, and every attempt to tidy an edge is
another swing at another height, so working more carefully makes it worse. Jafna reads the
per-point "a terrain operation touched this" flag the game already saves in each zone, and a
swing covering ground that was levelled before uses that height instead of the crosshair's. A
swing covering none is untouched, so starting a new platform at a new height still works.
Where two platforms at different heights meet under one swing the heights disagree by more than
ContinueTolerance and the decision goes back to the crosshair, rather than averaging them
into a ramp nobody asked for.
Reach grows with Crafting, on Skaft's rule and off Skaft's curve, which now lives in
core\shared\CraftingReach.cs so the two mods cannot drift into meaning different things by
the same sentence. Skaft still carries its own copy of the arithmetic and should adopt the
shared file the next time it is opened for a real change; refactoring a published mod is its
own release. Nothing at low levels, 12x12 metres at Crafting 60, and never a discount - a swing
costs the stamina vanilla charges.
A ward you cannot use blocks the whole swing. Vanilla tests the single point under your crosshair and nothing else, whatever the tool covers, so even the stock hoe can already cut ground from under a neighbour's wall from outside their fence with the ghost showing blue. Jafna tests the square footprint. It is enforced where you swing, not where the world is saved, because terrain is applied by whichever client owns the zone with no server-side validation anywhere in that path. It stops the mod and an honest player, not a hostile one, and that was already true of vanilla.
The build panel carries the numbers while a levelling tool is out: reach and the Crafting it came from, the height the swing will use, and whether that height came from your crosshair or from flat the swing is continuing. That last part is not decoration. A tool that quietly overrules your aim is indistinguishable from a tool that has started misbehaving, which is the complaint this mod exists to answer rather than to join.
Corrected during the first play test
Three things this was built on turned out to be wrong, all of them asset data that only the running game could answer.
The hoe does not use a level operation. Its Level ground entry is mud_road_v2, and it is
m_smooth with m_level false, radius 3 metres, power 1, painting dirt over the same 3. Raise
ground is m_raise and Path is paint only; nothing in the hoe's table uses m_level at all.
Every guard in the mod tested m_level, so it correctly decided the hoe was none of its
business and did nothing, with a clean log. Retargeted onto m_smooth || m_level.
The vanilla radius is 3 metres, not 2. The 2 was m_levelRadius, which this op never
reads. That moves the whole curve: with MaxRadius at 6 nothing changes until about Crafting
25, and the top of the curve is double the vanilla radius rather than triple.
The agreement test was asking for something the tool cannot produce. Requiring the whole
footprint to agree within 5 cm refused nearly every swing on ground that was visibly being
flattened, because SmoothTerrain eases from full effect at the centre to nothing at the rim -
a smoothed patch is a shallow dish, not a plateau. It now judges only the eight points nearest
the crosshair, which are the ones an earlier swing centred on and pulled all the way to its
target, takes their median, and defaults to a 0.25 m tolerance.
The hoe's piece table names no skill. So using it raises nothing and GetBuildStamina
skips its discount branch - there is no double dip here, unlike the hammer, and reach is the
only thing Crafting buys. It also means the reach is not self-earning, which is the same shape
as Skaft, where repairing buildings trains nothing either.
Verified in game, 20 September 2026
Continuing the flat holds a height across a working area. Swings metres apart all landed on 32,08-32,10 from crosshairs at 32,66, so over half a metre of drift removed per swing, with the eight nearest points agreeing to within 4-26mm against a 250mm tolerance.
discussHolding a height works in both directions. Standing 1,7m above the held number and 1,9m below it, every swing aimed at the held figure rather than at the player's feet. Toggle on and off both clean.
discussNon-terrain tools are untouched.
discusspiece_repairandwoodwallboth report no terrain op and the mod attaches nothing to them.
Known and open
The ward footprint has never refused anything in a test - there was no ward to refuse it.
discussA held height above about a metre away cannot be reached, and it stays that way. SmoothTerrain clamps its accumulated movement to one metre per point and only a level or raise operation banks that and frees the budget, so holding 32,08 while standing on 33,76 brings the ground down to roughly 32,76 and stops, short of the number the panel is showing. That is vanilla's clamp rather than anything here. Converting a held swing into a true level operation would remove the ceiling in two lines - decided against, because it would turn the hoe into a tool that sets ground to any height in one swing, and every mod in this suite is meant to be narrower than the thing it replaces. Raise ground first, then hold and flatten. Documented in the README so it does not read as a fault.
discussLeft Alt is confirmed double booked: mud_road_v2's piece sets both
discussm_groundPieceandm_allowAltGroundPlacement, which is exactly the conditionPlayer.UpdatePlacementGhostrequires before it readsAltPlace. In practice a tap captured 32,07 on a flat sitting at 32,08-32,10, so the single frame of alt placement does not appear to shift the reading. Left Alt stays as the default, on that evidence and because it is the key that was asked for;HoldKeyis configurable if the ghost ever misbehaves, and a server never takes a keybind over.
discussSmoothTerrainclamps its accumulated movement to one metre per point and only a level operation banks that and frees the budget, so flattening with the hoe is capped near a metre per point however the target is chosen. Whether that ceiling is the real obstacle in practice is untested.The appended reach travels to a Jafna owner and is invisible to a vanilla one, by design. Two players on very different Crafting levels working the same ground has not been watched.
discuss
Sinka 1.1.0 → 1.2.0
1.2.0
Added
A chest can be set down on top of another chest (
discussStackContainers, on). Vanilla refuses this outright and no snap point could ever have changed it, because two separate rules are in the way.Player.UpdatePlacementGhostmarks the ghost invalid whenever the piece you are aiming at hasWearNTear.m_supportsoff, which every chest does - the same reason a torch cannot go on a chest. AndWearNTear.UpdateWearrunsif (m_noSupportWear) { UpdateSupport(); if (!HaveSupport()) num = 100f; }, where 100 is the whole of the piece's health: a chest that ends up unsupported is destroyed with its contents. The field name reads backwards; it means "no support, wear".Both are answered as narrowly as they can be. The support flag is lent to the chest you are aiming at for exactly one frame, and only while another chest is in hand, so every other placement test still runs unchanged. And a chest standing on a chest is counted as supported, rather than made to carry real support, so a chest never becomes load-bearing - a wall, a beam or a torch on a chest is still refused, which is vanilla's answer and not a limit of this. The integrity colours still paint a stacked chest as unsupported, which is cosmetic.
discussTested in game, both halves: a chest places on top of another chest, and it is still there with its contents after leaving the area and coming back. That second half is the one worth proving - placement only needs the ghost to go green, while the wear tick is the path that would have destroyed the chest.
discussOn a server this can destroy a chest. Support is worked out by whichever player's game owns the piece, and ownership follows whoever is nearby, so a player without Sinka finds a chest standing on nothing and destroys it with everything in it. Nothing client-side can prevent that. Safe in single player and on a server where everyone has the mod; on a mixed server, turn it off. It ships on, with the warning next to the setting and in the README.
discuss
discussSockets: what sinks into what, and how much of it shows. One entry per line of pieces,piece, piece : target, target : metres showing, and it replacesSnapTorchesToPoles,TorchPrefabs,PolePrefabsandTorchStickOut. Those four could describe exactly one pairing - every listed torch into every listed pole at one shared depth - and depth is the part that cannot be shared, since a torch's length and the height of its own fire are its own. They are left behind under[Torches]in a config file an older version wrote, where they do nothing.Every standing torch, into seven poles, out of the box: the wood one, the three iron ones and the mist demister, into wood, core wood, darkwood and ashwood poles. 1.1.0 shipped one torch and two poles. Only the wood torch and the two wood poles have been played; the rest of the names come off the game's asset manifest, which lists what is on disk rather than what the game loads, so one may resolve to nothing and be named in the log at startup.
discussA depth left out of an entry is measured off the piece, not defaulted: as deep as it can sink while the zone its fire spreads into stays clear of its own pole. That floor was already being computed to catch a value set too low; it turns out to be the right number to use when nobody has chosen one. On the wood torch it measures 0.21 against the 0.25 picked by eye, and two independent answers agreeing within a centimetre is why the three iron torches are left to measure - they come out at 0.32, clearing a bowl that sits 0.671 to 0.823 above the pivot. A piece with no
discussFireplaceborrows the wood torch's 0.25, which is why the mist demister is typed at 0.27 instead: it has no fire to measure and its ball runs 0.283 to 0.515 under a mesh top of 0.549.A pairing is now per entry. A torch aimed at a pole somebody paired with a different torch comes away with nothing, where one shared pole list could not tell the two apart.
discussTested in game: a standing iron torch sinks into a wood pole at its measured 0.32, bowl clear of the pole, and the pole tiers past wood take a torch the same way. The wood torch is unchanged at the 0.25 it released with.
discuss
discussGapOverrides,Gapper prefab. One number for everything made "chests flush" and "stakes a hand apart" the same decision. Same punctuation asPointOverrides, and a prefab with no entry still usesGap. Two pieces of the same kind meet at exactly that gap; two different kinds meet at the average of theirs, because each piece contributes half. Tested in game atpiece_sharpstakes: 0.3: stakes chain a hand apart while chests stay flush.
discussVerbosenames the gap each piece got, including when it is the sharedGap. A gap that looks like it did nothing had nothing to check against - the corner positions never appear in the log, and the footprint line reads the same whatever the gap is.The startup log now lists every socket and how far it ends up showing, which for a measured depth is written down nowhere else, and
discussGapOverridesjoins the names-that-match-no-prefab check.
Fixed
Sharp stakes could not be chained at all, and the reason was a footprint measured from the wrong thing.
discusspiece_sharpstakeskeeps its colliders as direct children of the root and givesNewnothing but an LODGroup and meshes, so the collider search - which starts atWearNTear.m_newto keep damage states out - came away empty and fell through to mesh bounds. Those include the stakes leaning out in +z, so the piece measured 2.67 deep against 2.40 wide. Deeper than it is wide means the ladder ran along z, which put its rungs on the panel's front and back faces instead of its two ends, and no two panels could ever meet.piece_dvergr_sharpstakesdid the same at 3.81 deep.The search now widens to the whole prefab before giving up on colliders, cutting out
discussm_worn,m_brokenandm_fragmentRootsby askingWearNTearfor them rather than by where the search started. What makes that safe is a layer filter: onlypieceandpiece_nonsolid, the layers the game's own snap search looks on, so a hitbox, a pathfinding blocker or an effect area cannot stand in for the piece. This piece'sHIT AREAis an Aoe box a metre and a half behind it and is exactly the collider that would have replaced one wrong answer with another.A footprint that ends up measured from meshes now says so under
discussVerbose. It printed nothing at all before, which is what made this take a rip to find: the log showed a wrong box with no collider lines above it and no explanation of where it came from.Four pieces change how they chain, because they were on that mesh fallback and are now measured from their colliders, which is what this has always meant to do. Read off the game at load:
discusspiece_chest_blackmetal2.31 x 1.04 x 1.52 becomes 2.06 x 0.92 x 1.35,piece_chest_grausten1.72 x 1.18 x 1.22 becomes 1.31 x 0.72 x 1.13,piece_chest_warderobe1.68 x 2.68 x 1.11 becomes 1.35 x 2.09 x 0.85, andpiece_sharpstakes2.40 x 1.56 x 2.67 becomes 1.80 x 0.84 x 1.51. Each chains tighter than it did in 1.1.0.piece_chest,piece_chest_wood,piece_chest_privateandpiece_chest_barrelare untouched - they already measured from colliders. Checked in game afterwards: the tighter boxes chain without the meshes running into each other, which was the risk of trusting a collider that sits inside what you can see.Tested in game:
discusspiece_sharpstakesnow measures 1.80 x 0.84 x 1.51 with a ladder of 6 along x, and two panels chain end to end.piece_dvergr_sharpstakesmoved from mesh guesswork to its real collider box, 2.40 x 1.70 x 3.94 centred 0.35 off in x - the numbers this file has quoted since 1.0.0 - and keeps its ladder along z, which is the axis it genuinely runs on.
Changed
discussTorchPolesis nowSocketPoints, since the mechanism is "a piece sinks into another piece" and only the config names torches and poles. No behaviour rides on the rename.
Vaettir 1.5.5 → 1.6.0
1.6.0
Three pieces you build beside a stowing post, and the one of them that changes how crafting works.
Three new prefab names become permanent with this release - stow_rail, hod_jib and
stow_perch. Once one is standing in a world, removing the mod or renaming the piece
discards that object's ZDO silently, the same as it would for a stowing post.
Proved by scripted scenarios in a fresh world, including the withdrawal round trip and the one-chest race across two clients. Not played.
Added
Creel rail. 25 fine wood, 10 iron nails, 8 leather scraps, on the hammer's Furniture tab. Built within 5m of a stowing post it makes that post hold exactly what a reinforced chest holds - 6x2 becomes 6x4 - and takes it from 10 items a trip to 20. The grid is read off
discusspiece_chestat runtime rather than written down, so a post is a chest by construction and stays one if the game ever changes what a chest is. No heartwood: this is joinery, and it is the one upgrade that should be buildable the same evening as the post. Leather scraps are the woven part because that is this game's cordage - it is what the cart and the leather armour are strapped with, it is in the chest by the time anybody has iron nails, and it does not drag a storage-room accessory out to the Plains the way linen thread would.Spirit perch. 1 heartwood, 25 fine wood, 6 iron nails, 6 silver. Two spirits fly from the post instead of one. The heartwood is the whole price and the rest is the stand it sits on: a second courier is a second spirit, and a spirit needs somewhere to live. The silver is what puts it a tier above the rail rather than beside it. You can see it in the piece, lit, which is why it is not simply an expensive plank.
discussHod jib. 1 heartwood, 35 fine wood, 10 iron nails, 2 chain. While a crafting station is within 20m of the post, the crafting panel counts the material in the chests around that post and crafting spends out of them. A spirit then flies from the chest to the bench purely for show - it carries nothing and the item is already made.
A material is only served if its biome's boss is dead: Eikthyr opens the Meadows, the Elder the Black Forest, Bonemass the Swamp and the Ocean, and so on to Fader and the Ashlands. A chest full of black metal is not a shortcut past the Plains. Which biome an item belongs to is derived from the world - where it grows, what drops it, what recipes it feeds - rather than from a list, so a mod that adds an ore lands somewhere sensible for free.
Benches only. Not the hammer, not smelter or kiln fuel.
The engine is the Hirsla prototype, folded in rather than shipped beside: one DLL, one plugin, one config file, one version number. If Hirsla is installed the jib switches itself off and says so, so the two cannot count the same chest twice.
discussAll three find the nearest post within 5m, serve exactly that one, and draw the game's own station-extension motes to its heartwood so you can see which. A second piece of the same kind beside the same post says "that post already has one" rather than silently doing nothing.
discuss
Changed
Range for the bench service is measured from the post, not from the player. The prototype searched around whoever was standing there. The post does not move, so the set of chests being counted is the same at the start of a craft and at the end of it whatever you do with WASD in between, and a bench that worked a moment ago cannot stop working because somebody took half a step. With no crafting station selected the whole thing is shut, and there is no fallback to a player-centred search - a feature that quietly widens when its own piece is out of reach is one nobody can predict.
discussA post remembers how big it is. The size is worked out from the pieces standing beside it, as it always was, but the result is now left on the post's own saved object - so it opens at the size it really is rather than opening at the widest a post can ever be and settling down five seconds later. That guess was safe in the direction it was wrong in and still had three costs, all of which are gone: an unupgraded post showed two extra columns and a row on every zone load, a client that never owned a post held it at the maximum for as long as it stayed loaded and then shrank it under an open window, and turning
discussUpgradesEnabledoff did not stop any of it.A post that loses slots drops what will not fit, the way a broken chest does. Anything in a slot that is going away is moved to a slot that is not, first; only the genuine overflow lands at the post's feet. There is no refusal to shrink and no
discusstoo full to shrinkline - a post that quietly kept two rows it was no longer entitled to was a post whose size did not mean anything, and breaking a chest has always spilled its contents.A rail never takes slots away. Lowering
discussRailWidthorRailHeightdoes not narrow a post that still has a rail standing beside it - break the rail and build it again to apply the new number. Without that floor a player carrying their own copy of the file and connecting to a host withEnforceConfigoff could be handed ownership of a railed post and narrow it for everybody, with the rail still standing and nothing anywhere saying why.A post is only narrowed when the ground an upgrade could be standing on is actually loaded. ZNetScene creates and destroys by sector and a zone is 64m across, so a post and its rail either side of a zone line have a whole range of player positions at which the post exists and the rail does not. That looks exactly like a rail that has been taken down and no length of wait fixes it, because the rail is not late, it is absent.
discussA post is not narrowed while somebody has its window open, and not by a client that does not own it.
discuss
Fixed
A machine with
discussHodEnabledoff still served material out of the chests it owned to anybody who asked. The owner side never checked whether the feature was on - and the comment above the network registration said it did.A withdrawal request carried the asking character's id with nothing checking it against the peer that sent it, so a modified client could be served out of a chest locked against it. The id is now cross-checked against the character that peer is actually playing wherever that can be established, and the request is judged as the real character rather than refused.
discussA reply from a build speaking a different wire version was logged as "anything it was carrying is lost" - including the reply a mismatched build sends when it refuses a request before touching the chest, which carries nothing by construction. It read as the version skew destroying items.
discussA placed upgrade decided once, in
discussAwake, whether it was a real piece or a placement ghost, and that answer decided for its whole life whether it counted at all. Anything that left the saved object unset for that one frame made the piece register never: standing in the world, reading "no stowing post within 5m", with no log line and no way to tell it from a piece built out of range. Asked of the object every time now, which is the rule the post itself already followed.A misspelled item in
discussRailCost,PerchCostorJibCostleft the recipe being rewritten - two string splits, a list and a fresh array over the live prefab - sixty times a second for the rest of the session. The warning was already logged once; now the work stops too.A post giving up slots saved itself once per stack moved, which is a whole-inventory serialisation and a network write each. One write now.
discuss
Discussion
Nothing said yet.
Sign in or make an account to join in.