1. Modlet Structure
Identify the folder, config files, and what the mod changes before writing instructions.
ModletThis entry page turns modding, modlets, ModInfo.xml, XPath edits, and server-side mod questions into a checklist before any future generator or template tool is built.
Mod Template
7DTD Signal should use original templates for future tools and should not copy external author code or package downloads.
Identify the folder, config files, and what the mod changes before writing instructions.
ModletRecord name, author, description, version, dependencies, and compatibility notes clearly.
MetadataXPath changes should be small, readable, reversible, and tied to the game version being targeted.
XPathExplain install scope, server-side support, save risk, permissions, dependencies, and test status.
Publish| Keyword | What this page should answer | Risk boundary |
|---|---|---|
| 7 days to die modding | Where to start, what files matter, and what needs version review. | Do not promise full API coverage in MVP. |
| 7 days to die modlet | What a modlet is used for and how to document scope. | Do not publish untested templates as safe. |
| 7 days to die xpath | Why XML patching can be fragile after updates. | Mark version-sensitive edits as Needs Review. |
| 7 days to die modinfo.xml | Which metadata should be visible before players install. | Do not hide dependencies or permissions. |
| 7 days to die server side mod | Whether players need client files or only the server needs the mod. | Always confirm multiplayer scope. |
Author FAQ
Not yet. The MVP creates a safe checklist and future tool entry point. A generator should come after template scope and version rules are reviewed.
Version support, install scope, dependencies, permissions, changelog, save risk, multiplayer notes, and original author contact or source page.
Server owners need clear server-side mod notes, pack requirements, update checks, and player instructions before a season or event starts.