NimBlock

NimBlock runs plugins that are written as **JSON rules** instead of compiled Java. You drop one jar on your server. Your plugins are `.json` files in `plugins/NimBlock/specs/`. The engine reads them and executes them: when this happens, if these conditions hold, then do that. ## Why this isn't a code generator Nothing generates Java anywhere. There is no compilation step, no jar to rebuild, nothing to recompile when the server updates. Your rules are data; the engine is the only thing that ever needs to change. The consequence that actually matters: when a new Minecraft version lands, it isn't your plugin that breaks, it's the engine that takes the hit once, for everyone. ## What it can do, exactly The grammar is **closed and published**: 9 triggers, 8 conditions, 14 actions. Every one of them, with its parameters, is on a public page before you download anything: - Grammar: https://nimblock.com/en/grammar - JSON Schema: https://nimblock.com/spec/plugin-1.schema.json Anything outside that catalogue is impossible, not "on the roadmap". Conditions don't nest either (all/any, plus a `not` per condition, no boolean tree). If you need a guild system with its own database and GUI, this is the wrong tool and it always will be. If you need "when a player joins for the first time, give them a kit and announce it", that's a ten-line file. ## Compatibility promise Specs declare `specVersion`. It is **1**, and the engine refuses outright a spec whose `specVersion` it doesn't know, rather than running half of it. A spec written today keeps running on later engines of the same `specVersion`. That is the whole point of freezing the grammar. ## Installing 1. Drop the jar in `plugins/`. 2. Start the server once. It creates `plugins/NimBlock/specs/`. 3. Put a `.json` spec in that folder. 4. `/nimblock reload` re-reads specs without a restart. `/nimblock list` shows what's loaded. A **command** created by a spec only appears after a **restart**: Paper only accepts new command names during startup. The contents of a command reload live. A spec is accepted or rejected **as a whole**, never rule by rule: a protection plugin missing the rule that protects would be invisible in game. Rejections are one red line in the console. ## Network use None. No telemetry, no stats, no license check, no outbound connection of any kind. The only compile dependency is `paper-api`. ## Where the specs come from You can write them by hand against the schema, or build them in a visual editor at https://nimblock.com : same grammar, same file. The editor is a convenience, not a requirement: the engine only ever reads the file you put on your server. Requires Paper 26.1.2 and Java 25. Not an official Minecraft service. Not approved by or associated with Mojang or Microsoft.