Changelog

1.0.2 — two QOL fixes, and a third thing they uncovered

$KEY_Use was showing raw

Hover text is not localized for you, and this is worth writing down because the strings vanilla pieces return look identical to the ones a mod writes, so it is natural to assume the game does it. It does not: Hud.UpdateCrosshair takes whatever Hoverable.GetHoverText() returns, does two gamepad sprite swaps, and puts it straight onto the label. Every vanilla piece calls Localization.instance.Localize(...) on its own text first.

Two things fell out of fixing it. Localization lives in assembly_guiutils, not assembly_valheim — so the csproj now references it, and the API lint (which only indexes assembly_valheim) had to be told that is a real type rather than a missing one. And the modifier is now the $KEY_AltPlace token rather than a typed-out "L Shift", which was the same bug wearing different clothes.

The trough told you one thing and did another

The hover advertised modifier + Use to take the feed back, while plain Use actually did it — and there was no way at all to stock without picking an item first.

Now, and the hover says exactly this:

Both come from Wording, which is the only place either is written down, so they cannot drift apart again.

Use now finds the feed for you

Press Use with nothing chosen and the trough looks for the next viable feed: your own bag first, always, then chests standing within Reach (default 8m, set it to 0 for bag-only).

This reaches further than the Smoke Hook does on purpose. The hook takes from your bag and nothing else, and its own note argues for that — what goes on the hook is what you are carrying, same as a cooking spit. A trough is different: it is farm infrastructure, it lives among the chests that feed it, and topping it up from the chest two metres away is the thing you were going to do anyway.

What it will not take from: a chest somebody is using, a chest set to anything other than public, one inside a ward you are not admitted to, or one with nothing in it. Container.CheckAccess is private, so the judgement is made from the public privacy setting plus the ward check — conservative on purpose. "My mod emptied my friend's chest" is the worst report a convenience feature can produce.

A stocked trough only ever takes more of what it already holds, so scrounging can top up but never silently swaps the feed.

1.0.1 — the trough was never in the build menu

Reported plainly and it was three bugs stacked, the first of which hid the other two.

One flag standing in for three jobs

Registration is three separate achievements — a prefab ZNetScene can instantiate, an entry in the hammer, and reading what this install's animals eat — and 1.0.0 tracked all three with a single Built flag that was set after the hammer step ran, whether or not it had worked.

So a failure there was permanent (nothing retried) and invisible (manger reported "in the build menu" about a menu the trough was not in). A readout that cannot report a fault is worse than no readout, because it spends somebody's evening.

The three now succeed, fail and retry independently, and the console reports each on its own line.

ObjectDB was not up yet

That hammer step needed ObjectDB.instance, and the only moment it ever looked was inside a ZNetScene.Awake prefix. ObjectDB is a different object with no guaranteed Awake order, so it was almost certainly null — one look, at the wrong time, with the failure swallowed by the bug above.

Every stage is now attempted from every hook that might be the one where its prerequisite is finally up — ZNetScene.Awake, ObjectDB.Awake, ObjectDB.CopyOtherDB (the one that runs when joining a world) and Player.OnSpawned as a last chance. Each is idempotent. There is also a fallback that finds the hammer's table through Resources without ObjectDB at all, by looking for the table containing the workbench.

The feed list was never read

LearnMenu was written and called from nowhere. Nobody hit it because nobody could build a trough, but it was next: an empty feed list means every item is refused, and a trough that rejects carrots looks broken rather than uninformed.

Smaller

• The donor is now a list of candidates rather than one prefab name, so a renamed or absent prefab costs the trough its looks rather than its existence. manger says which was used.
• manger reports prefab / build menu / diets separately, plus the last thing it was waiting for.

On the tests

The first re-break of this fix passed all 50 assertions — the suite did not cover the exact failure that shipped, because a pure predicate cannot catch a sequencing bug. The seating step now returns whether it succeeded, and there is a regression test that drives the real path with no hammer table available and insists the flag stays down. Re-confirmed by re-introducing the original bug: it fails two assertions.

1.0.0 — first release

A feeding trough for tames.

• Uses the game's own feeding, unpatched. The trough holds a real item where animals can reach it and does nothing else. Hunger, breeding, taming, the eating animation and per-creature diets all work because none of them were reimplemented.
• Tames wild animals that wander in and eat, because feeding a wild tameable is how taming works. TamesWild = false to stop it. Note wolves are tameable.
• Feed is read off your install's animals, not a list written into the mod, so modded creatures' diets work without this mod knowing they exist.
• Cannot duplicate. The item on the trough is the contents — there is no second store.
• Will not stock inside a ward you are not admitted to.
• No dependencies. No Jötunn, no asset bundle.
• manger in the console says whether the piece registered and lists what animals will eat.