StalDayZ-System

About the Mod

• Inventory without an inventory. There is no global "vanilla-style" grid. Items have a cell size and are stored inside equipped gear: a backpack provides a grid, a tactical rig provides a grid and quick-access slots, a belt provides its own slots. A naked player has exactly two hands and nothing else. An assault rifle takes up several cells and won't fit in a pocket.
• Zone-based damage. The hit zone is determined by a raycast with a slight conical spread, not just a point of contact. Nine types of damage instead of vanilla armor: bullet, tear, blunt, explosion, burn, shock, chemical, radiation, and psi. Each clothing item has its own protection and degradation for each damage type individually—a hazmat suit blocks chemicals almost entirely, but any tear compromises its seal.
• Survival. Clothing wetness, thermoregulation, nine status bars, twenty-two conditions ranging from bleeding and fractures to hypothermia and radiation sickness.

Quick Start

./gradlew-j8.sh build

Documentation

Code Structure

stdz.core.util      · grid · hit · data · persist    pure Java, tested without the game
stdz.core.reload    · config · audit · tick · net    Forge layer on top of the core
stdz.core.equipment · hooks · access                 shared between inventory and damage
stdz.inv.*                                           inventory: model, capability, engine, tick, death
stdz.client.*                                        everything that does not exist on the server
stdz.content                                         163 content-pack items
stdz.mixin                                           vanilla intervention points

1. The core has absolutely no knowledge of Minecraft.
2. The inventory and damage systems cannot see each other; shared code lives in core.equipment.
3. No shared class can see client classes: otherwise, the dedicated server won't start.
4. Every dependency edge is explicitly encoded, not just implied by the absence of cycles.

Quality

• Every new invariant is secured by a test, and every change is verified via mutation: break it, see the test fail, revert it. A test that passes with any implementation is worse than no test at all.
• Every piece of code undergoes a five-axis review: the code itself via diff, interaction with the rest of the system, architecture, playtest readiness, and document compliance. The review is not done by the author.
• A data error from the author always results in a readable rejection with the file and field name, never just an exception.
• Where the code diverges from the document, the document is corrected, and the edit is marked as "as implemented".

Content

License and Authorship