Allow anonymous analytics?

Our cookieless analytics show us which features get used and store nothing on your device. We never sell your data or use it for advertising.

Privacy choices

Choose what ModDex may collect. You can change this anytime from Privacy choices in the footer.

Read the full privacy policy

Strictly necessary Required for the site to work: login sessions, security tokens, and abuse prevention. Always on and cannot be disabled. Always on
Analytics Cookieless analytics through PostHog's EU servers, used only to see which features get used. Nothing is stored on your device, and the anonymous visitor ID resets every day. Needs your consent because usage data goes to a third party. Never used for advertising or profiling. Off by default in the EU and UK.

Unique system: StalDayZ-CoreSystem

Quick rating

Community listing page, reviews may not be monitored by the author.

How listings work Are you the author?

Unique system: StalDayZ-CoreSystem

By Rayman_GC

No reviews yet

StalDayZ-System PROTOTYPE deep alpha

Mod Loaders
Minecraft
Shockbyte server hosting: 35% off your first server with code MODDEX35 (opens in a new tab)

About

Description

StalDayZ-System

A mod for Minecraft 1.16.5 / Forge 36.2.42: DayZ-style inventory and damage system, complemented by STALKER mechanics. Being developed for a public multiplayer server. Status: Early development, version 0.0.1. Not playable yet. See what works and what doesn't in docs/INDEX.md. Please read it before making assumptions about the project's readiness.

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

Bash
<button class="mdc-icon-button mat-mdc-icon-button mat-mdc-button-base mat-badge mat-unthemed mat-badge-overlap mat-badge-above mat-badge-after mat-badge-small mat-badge-hidden ng-star-inserted" aria-label="Завантажити код"></button><button class="mdc-icon-button mat-mdc-icon-button mat-mdc-button-base mat-badge mat-unthemed mat-badge-overlap mat-badge-above mat-badge-after mat-badge-small mat-badge-hidden ng-star-inserted" aria-label="Копіювати код"></button>
./gradlew-j8.sh build
Only use this wrapper, not gradlew directly: it sets JDK 8 and an ASCII directory for temporary files. The reason is explained in docs/AGENTS.md §2. To launch the client: ./gradlew-j8.sh runClient. For the server: ./gradlew-j8.sh runServer.

Documentation

File Description When to read
docs/INDEX.md Project map: what works, what doesn't, where to read about it Start here
docs/AGENTS.md Project rules: platform, build, boundaries, tests, process Before making any code changes
docs/architecture.md Packages, dependency rules, decisions → classes, implementation order When writing code
docs/inventory-design.md Inventory: 23 decisions, error catalog, stages When modifying the inventory
docs/damage-design.md Damage: 8 decisions, wetness, degradation, armor plates When modifying damage
docs/content-dayz-equipment.md DayZ equipment catalog and pack reconciliation When adding items
docs/TODO-audit.md Post-audit debt with priorities and tracking When looking for something to do
docs/CHANGELOG.md Commit-based journal When you need to remember when something was added
Note: The documents are large. Search for sections using grep; do not read them entirely.

Code Structure

Plaintext
<button class="mdc-icon-button mat-mdc-icon-button mat-mdc-button-base mat-badge mat-unthemed mat-badge-overlap mat-badge-above mat-badge-after mat-badge-small mat-badge-hidden ng-star-inserted" aria-label="Завантажити код"></button><button class="mdc-icon-button mat-mdc-icon-button mat-mdc-button-base mat-badge mat-unthemed mat-badge-overlap mat-badge-above mat-badge-after mat-badge-small mat-badge-hidden ng-star-inserted" aria-label="Копіювати код"></button>
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
Four rules that will break the build, not just code review (docs/architecture.md §1.3):
  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.
ArchUnit verifies this, and any violation will turn the build red.

Quality

This project is tested more rigorously than typical mods for a reason: it's for a public server, where a dupe bug or item loss costs more than a month's delay.
  • 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

178 items with 92 armor models. The base is the Extinction-Z pack, used with the owner's permission, supplemented with extracted geometry and custom warm clothing. Items are described by data, not code: staldayz-content/<pack>/pack.json for registration, and profiles in data/<ns>/staldayz/item_profiles/ for sizes, protection, thermal properties, and degradation. An admin can override anything via the config layer without touching the pack.

License and Authorship

Author: rayman.