CraftFromContainersEvolved

Craft From Containers Evolved

by KodeMan

> Work in progress: this release has not been fully play-tested yet. Expect rough edges and please report anything you find on Discord.

Craft, build and upgrade using the resources in nearby containers - without letting other players turn your storage into their personal warehouse.

This is an independent reimplementation of the classic "craft from containers" idea for Valheim 1.0 with a security model designed for shared worlds: your chests only work for the people you actually share them with, and servers can enforce the rules.

What it does

• Use resources from nearby containers when crafting, upgrading and building.
• Add ore or wood, fuel, food and ammo to stations from nearby containers: smelters, kilns, blast furnaces, cooking stations, fires, torches and ballista turrets. Stations use everything they normally accept - a kiln burns corewood and finewood too.
• The crafting UI shows the combined amount available in your inventory plus allowed containers, for example 87/40.
• Counters turn amber when a resource is only available in containers, red when it is missing entirely, and white when your inventory alone is enough.
• Containers in range are used automatically - no extra slots, tabs or menus.
• Pull order defaults to the closest container first, and an optional "leave one" rule keeps a single item in every stack (recipes that would need the last item of a stack are treated as not craftable).
• Container type filters for ships, carts, wood chests, reinforced chests, black metal chests, personal chests and tombstones.
• Compatible with personal chests and wards: if a container passes the game's own access checks, it can be used according to the active security mode.

No more crafting-table griefing

In shared worlds, a player can build a crafting station next to (or even against the outside wall of) your storage and, with older container-pulling mods, silently craft with your materials. Craft From Containers Evolved stops that by default:

• Every container must pass the same access rules the game uses when a player opens it. Containers that are in use by someone else, private chests you do not own, and ward-protected containers you have no permission in are never touched.
• OwnerStrict (default): a container is only used if the piece was created by you. Ownership is the creator id the game stores on every player-placed object, so it survives restarts and does not require a ward. A stranger's workbench next to your chests simply finds nothing, because your chests are not theirs.
• Wards remain the sharing mechanism: with IncludeWardPermitted enabled, containers inside an enabled ward you have permission in are also used, so teammates can share storage the same way the base game lets them share doors and chests.

Security modes

| Mode | Behaviour | | --- | --- | | OwnerStrict (default) | Only containers created by you, optionally plus containers inside a ward you have permission in. | | WardStrict | The game's own access checks plus: never use containers inside an enabled ward you are not permitted in, even if the container is public. | | Vanilla | Only mirror the game's own checks: anything you could open manually can be used for crafting. |

Server-enforced policy

Install the mod on the server as well and the server becomes the authority:

• The server broadcasts its security settings when players spawn and whenever the settings change.
• Clients can only ever be stricter than the server, never looser. If the server uses OwnerStrict, a client set to Vanilla still gets OwnerStrict behaviour.
• The pull range is capped by the server value, and container-type ignores are combined so a server can force additional exclusions.
• Server-side write protection: the server validates every container write and container request. Forged messages from modified clients are dropped before they touch a chest, claimed player ids are verified against the real sender, denials are audit-logged, and modded clients are told when a request is denied. World containers (dungeon chests) keep vanilla behaviour.

With Server/EnforceModeOnWrites = true (default) the AccessMode also applies to writes: under OwnerStrict only the creator and ward-permitted players can modify a container. Because the server cannot tell a scripted pull from a manual loot, this also means players without ward permission cannot manually loot a teammate's public chest - share through wards, or set the option to false for pure vanilla looting with privacy and ward enforcement only.

Existing worlds and shared bases

In OwnerStrict (default) a container is usable only by the player who created it. On worlds that changed hands, moved between servers or accounts, or contain chests placed by former members, those chests are blocked even though they may look public. The server log shows the reason for each block, for example Denied container open ...: NotOwner (WardDenied and OpenAccessDenied are the other reasons), and modded clients get a message when an action is refused.

Server owners have three ways to handle this:

• Security/AccessMode = WardStrict - chests outside any ward become open to everyone; only warded chests are restricted.
• Security/AccessMode = Vanilla - only the game's own checks apply (privacy and wards).
• Server/EnforceModeOnWrites = false - manual chest interaction stays exactly vanilla, while the player-set AccessMode still applies to crafting pulls made by modded clients.

Players without the mod are refused silently; only modded clients see the "no access" message.

Compatibility with container mods