Skip to content

Documentation

Help and policy

AXION is a reading room, not an executor. Nothing published here is run on our servers — every command you use runs on your own world. These guides explain where each format goes; they cannot confirm a build works on your version.

01

Quick start

Find work that matches your edition first, then read the compatibility block. Every creation records an edition, a version range, a tested version and an install method. If those are missing or marked untested, treat the creation as experimental.

  • Copy a command with the copy control on the creation page — it copies only command text.
  • Save a creation to keep it in your library, and group saved work into collections.
  • Back up your world before installing anything that changes blocks, entities or scoreboards.

02

Your first command

A command is a single instruction with a target and arguments. This one gives the nearest player a diamond:

/give @p diamond 1

@p selects the nearest player. ~ ~ ~ means “relative to the executor”, so /tp @s ~ ~5 ~ lifts you five blocks. Selector arguments inside square brackets filter entities: @e[type=zombie,distance=..10].

Most world-changing commands need operator permissions or cheats enabled on the world. AXION records that requirement on each creation rather than assuming you have it.

03

Editions and versions

Java Edition, Bedrock Edition and Education Edition are separate targets with different syntax and different file formats. They are never treated as interchangeable here.

  • Edition — which game the creation targets.
  • Minimum / maximum version — the range the creator expects to work.
  • Tested version — the build the creator actually verified.
  • Untested — the creator has not verified the build. Compatibility labels are declarations, not guarantees.

AXION never claims a submission is compatible because an author selected an option. The label always names the creator as the source.

04

Java Edition commands

In Java Edition, open chat with T or / and type the command beginning with a slash. Commands that change the world need operator status or cheats enabled on the world.

  1. Back up the world save folder before running anything destructive.
  2. Paste the command into chat and press Enter.
  3. If the game answers “Unknown command” or refuses it, check the edition, the version and your permission level first.

Syntax changes between releases. Commands written for 1.20 may not parse on 1.21 or the other way round, particularly around item components, selectors and scoreboard criteria. The creation page shows the version the creator tested — treat anything else as unverified.

Java and Bedrock selectors are not identical. Do not paste a Java command into Bedrock expecting it to parse.

05

Bedrock Edition commands

Bedrock commands run from chat, command blocks or behaviour packs, and require cheats to be enabled in the world settings. On consoles and mobile, the chat bar is opened from the pause menu or by tapping the chat button, depending on the device.

  • Cheats must be on. Worlds created without cheats cannot enable them later.
  • Some target selectors and argument names differ from Java Edition.
  • Bedrock command blocks support a tick delay field that Java does not have.

Where a creation ships a command block system, the setup instructions name block types, conditions and activation mode. Read them before placing anything.

06

Command blocks

Command blocks are placed by an operator. Obtain one with /give @p command_block, then place it and right-click to open the editor.

  • Impulse — runs once when triggered.
  • Repeat — runs every tick while active.
  • Chain — runs after the block pointing into it.
  • Conditional — only runs if the previous block succeeded.
  • Always Active / Needs Redstone — whether the block runs without a redstone signal.

Chain blocks face the order they run in, so relative positioning matters. Creators describe the intended order in the setup instructions; follow it exactly, and switch the system off before removing blocks.

07

Java datapacks

A datapack is a folder placed inside a world's datapacks directory. AXION downloads published datapacks as a real .zip that preserves the folder structure your project uses.

  1. Back up the world folder first.
  2. Drop the downloaded .zip into world/datapacks/ (or the world's datapacks folder on a server).
  3. Run /reload in game, then check the pack is listed with /datapack list.
  4. Remove the archive and reload again to uninstall.

The pack_format in pack.mcmeta must match the game version. Minecraft 1.21 and later read singular folder names (function/, advancement/, loot_table/), while older versions use plural names. AXION warns when a project mixes them but never rewrites your paths.

The pack format table AXION uses is verified through Minecraft 1.21.6. Newer releases may need a value we do not know yet — set it manually and check the game's log if the pack does not load.

08

Minecraft Education scripts

Education Edition uses MakeCode. AXION stores the source text of MakeCode Python or JavaScript and shows it read-only, with copy and download controls.

  1. Open the Code Builder in Minecraft Education and create or open a project in MakeCode.
  2. Switch MakeCode to the same language the creation was written in (Python or JavaScript).
  3. Paste the source into the editor and run it in the world.

Copying source code does not create a directly installable Minecraft package. AXION does not compile, execute or import scripts, and cannot place a script inside your world.

09

Bedrock add-on packages

Bedrock add-ons are behaviour or resource packs described by a manifest.json. AXION downloads them as a .mcpack archive built from the manifest and files you published.

  1. Open the downloaded .mcpack with Minecraft (double-click or share it to the game on mobile).
  2. Apply the imported pack to the world in the world's behaviour or resource pack settings.
  3. Keep the UUIDs in the manifest unique. Two packs sharing a UUID conflict.

These packages can run code through behaviour packs and scripts. Treat an add-on like software: read what it contains, and test it in a copy of the world before using it in one you care about.

10

Publishing rules

Creator Studio asks for what another player needs to actually use your work:

  • A title, a summary and a description that say what it does.
  • At least one category, the edition and the project type.
  • A tested or supported Minecraft version, plus any permission requirements.
  • Installation instructions, and setup instructions for command block systems.
  • A confirmation that you have the right to publish the work.

Project files are text: .mcfunction, .json, .mcmeta, .txt, .md, .py, .js, .yml and .lang — up to 128 KB per file and 1.5 MB per project. Executables and archives are not accepted, and paths are checked for traversal.

Publication states

  • Draft — private to you.
  • Unlisted — reachable by link, not listed in Explore.
  • Published — listed publicly.
  • Under review / Hidden — set by moderators only; editing is locked.
  • Archived — kept privately, removed from public view.

11

What you download

  • Single commands and command sets — a .mcfunction text file, one command per line, with labels as comments.
  • Datapacks, add-ons and technical projects — a real .zip or .mcpack archive built from the released files, with folders preserved.
  • Education scripts — the source text (.py or .js).
  • Structure metadata — JSON notes only; no buildable structure file is produced.

Older releases can be viewed and downloaded from the version history. A release is frozen when it is published, so the files you download match what the creator released.

12

Community guidelines

Publish work you have the right to share

Credit original authors. Do not repost someone else's system as your own, and do not publish paid work you did not create.

Describe compatibility honestly

If you did not test a version, leave it marked untested. A wrong version claim costs other players their worlds.

No destructive or deceptive content

Do not publish commands designed to destroy worlds without warning, steal data, or mislead players about what they do.

Keep it readable

A title, a summary and install instructions beat a wall of unexplained commands. Explain anything non-obvious.

13

Reporting content

Every creation page has a report control. Reports are stored with the reason, details and target, and reviewed by moderators. Signed-in users can report.

Reasons include stolen work, malicious or destructive content, misleading compatibility claims, unsafe instructions and spam. You can archive or delete your own creations from the creator dashboard.

Back to the archive

14

FAQ

Does AXION run my command to check it?

No. Commands, scripts and packs are treated as untrusted text and are never executed on our servers. Validation covers structure and required information only.

Can I publish a Bedrock add-on?

Yes — choose Bedrock Add-on, keep a manifest.json at the archive root, and the download is a .mcpack you import through the game.

Who can see my drafts?

Only you. Drafts and their files are excluded from every public listing and from other users' requests.

What do the numbers on my dashboard measure?

Page views (once per page session), confirmed copy actions, downloads and saves. They cannot prove that a command was used in someone's world.

Is AXION affiliated with Mojang?

No. AXION is an independent community project, not affiliated with or endorsed by Mojang Studios or Microsoft. Minecraft is a trademark of Mojang Synergies AB.