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.

What a plugin looks like

Diamond ore below Y=16 is reserved to players with a permission. That is the whole file, nothing omitted:

{
  "specVersion": 1,
  "name": "Diamond guard",
  "rules": [
    {
      "name": "Diamond ore below Y=16 is permission-only",
      "trigger": { "type": "block.break" },
      "conditions": [
        { "type": "text.equals", "params": { "text": "{block}", "value": "DIAMOND_ORE" } },
        { "type": "number.compare", "params": { "left": "{y}", "operator": "<", "right": "16" } },
        { "type": "player.has_permission", "params": { "permission": "mine.diamond" }, "not": true }
      ],
      "actions": [
        { "type": "cancel_event" },
        { "type": "player.send_actionbar", "params": { "message": "&cThat ore is reserved." } }
      ]
    }
  ]
}

Save it as plugins/NimBlock/specs/diamond-guard.json, run /nimblock reload, and it is live. No build, no restart, no jar of your own.

The one everybody asks for first

When a player joins for the first time, give them a diamond and welcome them. Since 1.1.0 that is a rule, and this is the whole file:

{
  "specVersion": 1,
  "name": "Welcome gift",
  "rules": [
    {
      "name": "First visit",
      "trigger": { "type": "player.join" },
      "conditions": [
        { "type": "player.first_time" }
      ],
      "actions": [
        { "type": "player.give_item", "params": { "material": "DIAMOND", "amount": 1 } },
        { "type": "player.send_message", "params": { "message": "&bFirst time here. Take this to get started." } }
      ]
    }
  ]
}

player.first_time invents no storage of its own: it asks Paper whether the server has ever saved that player. So it is true for their whole first session, until the first save, and under player.join that is their first join.

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, 11 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". Three limits worth knowing before you spend an evening on it:

• Conditions don't nest. all / any, plus a not per condition. No boolean tree.
• The engine keeps no memory of its own. It reacts to what just happened and stores nothing: no counters, no "how many times has this player done that", no cumulative anything. The one exception is not its memory but the server's: player.first_time reads Paper's own player data, so it stays true for a player's whole first session, until the first save.
• Player checks are limited to the published conditions. A rule can read permission, op status, current world, current health, the current position of the player's feet (player.position) and the material in their main hand (player.holding, AIR for an empty hand). player.first_time reads Paper's own player data, with the first-session limit described above. Trigger values describe the event: under block.break, {x}, {y} and {z} are the block's coordinates. No block lookups, player counts, full-inventory or armor checks.

If you need a guild system with its own database and GUI, this is the wrong tool and it always will be.

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.

Which Paper versions

Paper 1.21.4 or newer, on Java 21 or newer. Declared: 1.21.4, 1.21.6, 1.21.7, 1.21.8, 1.21.10, 1.21.11, 26.1.2, 26.2.

Below 1.21.4 the engine refuses to load, and that is deliberate: two catalogue actions have nothing to bind to there (player.give_effect needs Registry.MOB_EFFECT, which lands in 1.21.4, and player.heal needs Attribute.MAX_HEALTH, which lands in 1.21.3). A plugin that loads quietly and throws the day a rule fires is worse than one that refuses on startup, so api-version is 1.21.4 and Paper does the refusing itself.

Version 1.2.0 was tested with a connected client on Paper 1.21.4 and 26.1.2. The position and main-hand checks were exercised with an empty hand and a pickaxe, at the surface and below Y=0. Earlier compatibility tests covered the other declared versions; those earlier runs are not new tests of 1.2.0.

1.21.5 and 1.21.9 are not declared here. At the compatibility review for 1.0.1, PaperMC offered no stable build for either version. Use one of the versions listed above.

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/en/ : 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 1.21.4 or newer, on Java 21 or newer. Not an official Minecraft service. Not approved by or associated with Mojang or Microsoft.