How to install and configure MuchStuffPack on a DayZ server
Load MuchFramework before MuchStuffPack on the server and clients. Add the furniture economy files to the active mission, then inspect placed objects and their contents in a separate world. Look under MuchFramework for the shared lock, display-proxy and storage controls when following older MSP instructions.
Author support ended at DayZ 1.26, according to the current MuchStuffPack listing, item 1991570984 and MuchFramework, item 3171576913. Use this source-based procedure to prepare or maintain a Steam PC installation. Confirm the installed game and mod set on a test instance before changing a live service. Console hosting does not load these Workshop packages.
Prepare the package and recovery set
Section titled “Prepare the package and recovery set”List the game build and each package revision, including the storage, clothing, placement and lock mods used with MSP. Preserve the mission, world persistence, profiles, packages, keys and launch arguments in a stopped backup. Include deployed containers and their contents when preparing recovery.
Begin an installation rehearsal on a fresh world. An existing MSP community also needs a rehearsal using its recovery copy to cover saved classes and cargo. Resolve an unsupported-script startup error for that release, then repeat the acceptance checks before admitting players. The author prohibits repacking these packages; check a proposed compatibility addon’s declared dependencies and release support before adding it to the test set.
Search the two IDs in VXPanel Mods and confirm that each binding points to Helkhiana’s item. Install the dependency ahead of MSP with server-and-client scope; panel mod controls explain those bindings. On a manual host, deploy the package folders where the launch settings expect them and place the supplied signing keys in keys. Extend the existing argument with your actual folder names:
"-mod=@MuchFramework;@MuchStuffPack"Keep signature verification and the rest of the required load list. Match the client releases to the deployed server copies. If a player cannot join, follow the missing-PBO procedure before testing furniture actions.
A 5 April 2026 local-server report shows two different startup failures: a World script cannot resolve ActionDismantleItem, and an addon requires InventoryFixSolo. A script compilation failure needs a release and load-list investigation; changing loot XML cannot repair the missing script type. Check the required-addon message against the installed MuchFramework revision and its dependencies. The author’s June 2024 notes describe moving the inventory-fix code into MuchFramework. Check that revision before installing a separate Workshop fix in response to the message. Preserve the failed log and test any proposed change before continuing.
Register the furniture economy once
Section titled “Register the furniture economy once”Select the economy files supplied with the installed release. The author’s types document provides a comparison copy: the reviewed revision contains 294 unique definitions for kits, placed objects and other items. Verify the installed file rather than treating that source count as a requirement for later releases.
Confirm the selected mission with the test service stopped. Save the complete chosen <types> document there as muchstuff_ce/msp_types.xml. Add its registration within the existing <economycore> root of cfgeconomycore.xml:
<ce folder="muchstuff_ce"> <file name="msp_types.xml" type="types" /></ce>Create those local directory and file names yourself, preserving Linux filename case and the mission’s other registrations. Reconcile earlier MSP entries in db/types.xml or supplemental files to retain one intended definition per class. Before transferring the files, complete the modded-loot registration checks and run the XML diagnosis command.
Keep both kit and placed-object definitions during the initial rehearsal. The item list pairs Msp_Greenhouse_Kit with Msp_Greenhouse and Msp_Gunwall_Kit with Msp_Gunwall. Inspect the resulting structure’s retention and cargo after deployment and restart, even when the kit’s natural spawn has passed.
Review the MuchFramework profiles files
Section titled “Review the MuchFramework profiles files”Use one restricted startup to inspect loading and obtain the generated configuration, then stop before editing it. Find MuchFramework inside the active -profiles directory. The author’s loader builds this path and writes defaults when files are absent.
| File | Review |
|---|---|
MF_CodeLockConfig.json |
Set supported lock attachment, raid actions, tools and lock removal |
Proxies_Config.json |
Select the weapon, clothing and other display proxies to hide |
Settings.json |
Inspect virtual storage, automatic close behavior and fridge preservation |
The author moved the lock and proxy files into MuchFramework in the March 2024 migration notes. Save the old configurations for comparison and merge their supported choices into the generated files. Confirm the active loader path before editing a file left under an older MSP directory.
Preserve string-valued lock switches
Section titled “Preserve string-valued lock switches”For Code Lock integration, change the existing MF_CodeLockConfig.json with its field types retained. The author loader uses strings for CanAttach, CanRaid and DeleteLockOnRaid. Keep values such as "true" and "false" quoted. A parser can accept a JSON boolean even though this loader expects a string.
Test the lockable object as its authorized owner and as a player who should be denied. Attempt the chosen raid action and record the result. Include the active Code Lock rules when reviewing these shared framework settings.
Compare the generated settings with the source version
Section titled “Compare the generated settings with the source version”Compare schema versions before using the public extras sample: it carries version 1.0, while the reviewed settings loader expects 1.1 and adds ContainerBlacklist. Use the installed release’s generated configuration as the edit baseline, preserving its version and supported fields.
Begin cargo acceptance with the generated virtual-storage choice. Enabling that feature requires identifying its storage paths and including mod-owned data in recovery. Rehearse storing and retrieving a disposable item, rejection of disallowed classes and repeated open/restart cycles. Check that the backup contains the separate storage data as well as the world.
Test placement, cargo and displayed items
Section titled “Test placement, cargo and displayed items”Choose test objects from the installed item list: a kit, lockable container, greenhouse and display item. Save their classes, positions, attachments and cargo in the acceptance record.
| Check | Record |
|---|---|
| Deploy a kit | Identify the placed class and check orientation and deployment rules |
| Transfer inventory and attachments | Compare accepted slots and quantities, then repeat on a reduced storage-mod set |
| Open and close a greenhouse | Observe each door action and its resulting state |
| Change proxy visibility | Compare item displays across one chosen proxies_settings change |
| Normal stop/start of the same saved world | Confirm the saved object, lock, attachments and contents |
| Dismantle an empty test object | Record the tool/action and recovered kit or materials with cargo removed first |
To investigate a base with many weapon displays, alter one proxy setting and compare the same client view under the same workload. Inspect cargo separately; looking at the display won’t tell you whether the saved inventory changed.
Collect new server logs for a failed action. Trace the selected mission, loaded definitions and saved world before editing persistence. Keep the failed state and follow the loot workflow to diagnose disappearance.
Recover or remove the package
Section titled “Recover or remove the package”Restore a mistaken profiles or economy edit with the service stopped. A release rollback needs the matching packages, keys, configurations and world from the recovery set. Before mod removal, export required contents and plan the handling of placed MSP objects.
Source and verification scope
Section titled “Source and verification scope”This guide used AI-assisted research and drafting. On 3 October 2026, we reviewed the visible original Workshop items, author loaders and configuration paths, and XML/JSON working copies. Those checks did not start DayZ, establish script compatibility, complete a client join or observe recovered cargo. Run the listed acceptance steps against your installed game release before changing a live world.