In these instructions we're only modifying the Example Spell Pack. You should be familiar with JSON and the raw JSON text component (as in /tellraw). You can find a tutorial here.

Creating your own namespace

1. Start by giving the folder of the example spell data pack a different name and modify the description in the pack.mcmeta file inside that folder.
2. Open up data/minecraft/tags/functions and in each of the files you see, replace "steve" with your own username. Note that only a-z 0-9 . _ - are allowed (so no capitals or spaces). Modify the "steve" replacement to fit that constraint.
3. Now rename the data/steve folder to what you entered before.
4. Open all functions in data/<username>/functions/mpp/ starting with "spells_" (except spells_register) and replace "steve", like you did in step 2 and 3.
5. Run /reload and check if the example spell is still working.

Creating your own spell item

1. Open data/<username>/functions/mpp/spells_register.mcfunction. This is where you describe your spell by giving it a color, name, description and more. At the top of the file you'll see descriptions of all the fields that you can fill in and the possible values for the color fields.
2. Modify the last group of lines in that file to your own likings. All fields should be modified to describe your spell, not the example spell.
3. Make sure to generate a new id and paste that in the Id field. If you don't generate a new id, other data packs will target your spell and prevent it from functioning correctly.
4. Open all functions in data/<username>/functions/mpp/ starting with "spells_" (except spells_register) and replace the id on each line with the id you generated.
5. Run /reload, press the reload button in a spells chest and make sure your custom spell item shows up. Try using it and confirm that the example behaviour is still working.

Adding your own spell behaviour

1. In the same function files, replace "floop" with anything that could identify your spell (again, only a-z 0-9 . _ - are allowed). And rename the "floop" folder accordingly.
2. You can now modify the function files in that folder with your own custom commands. Open the "Available States" spoiler for more info on implementing these functions.

The function files starting with "spells_" represent certain states. For example, the spells_travel function is called when the spell is travelling. Each function file contains commands that run a certain function if the spell id matches. A typical command looks like this:
execute if entity @s[tag=<id>] run function <function> The following states are available:

State	When	Variables
spawn	Once when the player casts a spell.	Spell marker: @s Player that cast the spell: @p Location of players head: ~ ~ ~
travel	Multiple times per tick, while the spell is shooting forwards. Tip: Use ^ ^ ^forwards coordinates to position along the spell path.	Spell marker: @s Location of spell marker: ~ ~ ~
miss	Once if the spell did not find a block or entity in time.	Spell marker: @s Location of spell marker: ~ ~ ~
hit_block	Once if the spell hits a block.	Spell marker: @s Location of block that has been hit: ~ ~ ~
hit_entity	Once if the spell hits an entity.	Spell marker: @s Location of spell marker: ~ ~ ~ Entity that has been hit: @e[​type=!#bertiecrafter:mpp/spell_ignored,limit=1,sort=nearest]

Of course, there's the spells_register function that you use for specifying spell meta data and you can still use the vanilla minecraft tick and load functions.

The following steps will prepare your arena to welcome players in a lobby and let them equip in peace in an armory. From there, they will be able to press a button to teleport to the arena.

Quick introduction to command blocks: Command blocks are triggered by redstone and can run any command you put in it. Use /give @s command_block to obtain one. Besides the text box for the command, you'll see a couple buttons when you click the block, don't worry about them for now.

You're going to use commands with coordinates. Copying them from F3 is fine, but you can get the coordinates faster by typing /setblock in chat, using tab autocomplete and copying the coordinates that appear.

1. Once you've created your arena, install the Magic PvP and example spell data packs and run /reload.
2. Create a separate area in which you set the world spawn (/setworldspawn), we'll call this the lobby.
3. Run /defaultgamemode adventure. This makes new players automatically join in that gamemode and will allow them to respawn at the exact world spawn block. Otherwise players will spawn at the highest block at the world spawn.
4. Create at least 2 rooms where players will be able to equip themselves, we'll call these armories.
5. Slap buttons on walls with command blocks behind them that teleport the nearest player (/tp @p <x> <y> <z>). There should be buttons in the lobby teleporting to each armory and buttons in each armory teleporting to the arena.
6. In each armory, store a wand item, hat item and a spells chest. Obtain these things using the commands below. Other PMC creators will help texture the items, but untextured they are just a fungus on a stick and a carved pumpkin.
   # Place a chest at your feet in the direction you're looking
/function bertiecrafter:mpp/items/spawn_chest
# Get wand and hat
/loot give @s loot bertiecrafter:mpp/wand
/loot give @s loot bertiecrafter:mpp/hat
   
7. Disable command block output with /gamerule commandBlockOutput false
8. You might want to consider setting other gamerules. For example, freeze time (/gamerule doDaylightCycle false) or freeze the weather (/gamerule doWeatherCycle false). Use tab to autocomplete the others.
9. Well done! Your map is now ready to be published. If you want to stop here, make sure to remove the data packs before publishing.

After completing this level, players will be able to get new wands and hats. Players will also be able to teleport back to the lobby whenever they want.

More command block info: Command blocks can be chained, so that you only have to power the first command block. To chain command blocks, place them behind each other. Use the buttons in the interface to switch modes, the first one should be Impulse - Unconditional - Needs Redstone, the others should be Chain - Unconditional - Always Active. The arrows on a command block indicate where the next command block should be in order to be triggered.

1. Wire up each button in the lobby to a command that kills all items./kill @e[​type=item]
2. Add two more command blocks to each of those buttons that give the player new wands and hats. The simplest is using the commands above, but with @p (nearest player) instead of @s. However, you can also modify the command to spawn the items on the floor or insert them into armor stands, item frames or chests. Either way, you should remove the wand and hat that were already there from the previous instructions.
3. There should be a way for the last standing player to return to the lobby. One way of doing that is teleporting all players without a wand back. To do this, place a command block at the center of the arena, set it to Repeat - Unconditional - Always Active with the command:
   /tp @a[distance=..<radius>,nbt=!{Inventory:[{tag:{bcmpp_wand:1b}}]}] <x> <y> <z>Replace <radius> by the amount of blocks from the center of the arena to the furthest edge (without modifying the two dots in front) and use <x> <y> <z> to teleport players to the lobby.
4. Congrats on making your map reusable! If you want to stop here, make sure to remove the data packs before publishing.

You might want to synchronize players to create some concept of rounds. In the following instructions, we'll be making the buttons in the lobby (that teleport the player to the armory) disappear after a player presses them and come back after all players have left the arena. Also, we'll prevent the players from entering the arena until all players in the armories have pressed a button.

You're going to create commands that place and remove blocks. You can do this easily by placing the block that the command should create, looking at it and pressing F3+I. You now have a /setblock command on your clipboard that will place the exact block you were looking at in that position.

1. Make each button in the lobby delete itself by adding yet another command block with the command below. /setblock <x> <y> <z> air
2. Place a command block at the center of the arena and set it to Repeat - Unconditional - Always Active, enter the command: /execute unless entity @a[distance=..<radius>] and attach a comparator facing away from the command block. It will power on when there is no player in the radius. Use the redstone output to power command blocks that place the buttons back in the lobby.
3. Now create a redstone line running into a block with a redstone torch on the side of that block. Connect the torch to a simple command block. Enter the same teleport command that teleports the player from the armory to the arena, but with @a (all players) instead of @p.
4. Make each of the buttons in the lobby also place a redstone block besides the redstone line (using /setblock). The torch and the redstone output to the command block should turn off.
5. Make each of the buttons in the armories remove the associated redstone block from the line instead of teleporting the nearest player to the arena. When the last redstone block is removed, the torch should come on and the command block should teleport everyone to the arena.
6. You can make the buttons in the lobby and armories remove and place another redstone block behind a redstone lamp in the armory. This way the player gets a visual confirmation that you registered their button press.
7. Congrats on synchronizing players and rounds! Make sure to remove the data packs before publishing.

Only applying your textures based on "Custom Model Data" allows you to only apply textures to items that have a specific meaning within the Magic PvP Framework. Use the following steps to add textures with custom model data, assuming you have basic knowledge of creating resource packs:

1. Start by creating an empty resource pack: A named folder, the pack.mcmeta file and optionally the pack.png file.
2. Now open up .minecraft / versions / 1.18.1 / 1.18.1.jar with any zip file reader like 7-Zip or WinRar.
3. In the resource pack, create 2 folders: assets/minecraft/models/item and assets/<namespace>/models/item, where namespace is usually your username, but only use the characters a-z 0-9 . _ - (no capital letters)
4. In the version .jar, open up assets/minecraft/models/item. Copy the .json file of the item you want to retexture to both folders you just created.
5. In the resource pack, open up assets/minecraft/models/item/<item>.json in your editor and add the following:
   {
<existing content> ,
"overrides": [
{
"predicate": {
"custom_model_data": 300000
},
"model": "<namespace>:item/<item>"
}
]
}
   Make sure to add the comma at the end of the last item that was already there (before "overrides") and fill in the namespace and item names you have used before. Using the above model path (identifier) results in the following file path: assets/<namespace>/models/item/<item>.json
6. In the resource pack, open up assets/<namespace>/models/item/<item>.json
7. Replace the identifiers under "textures" in the file you just opened. The identifiers should look like this <namespace>:item/<item> which results in the file path: assets/<namespace>/textures/item/<item>.png. You should choose your own namespace and item name. For example, I can use the identifier "bertiecrafter:item/wand".
8. Now create the texture file(s) for the identifiers you used earlier. In the case of "bertiecrafter:item/wand", I would create the "assets/bertiecrafter/textures/item/wand.png" file.

That's it! The texture should now only be applied based on custom model data.

To recap:

• assets/minecraft/models/item/<item>.json should match the file name that is in the version .jar in order to override it (just like you would with normal textures)
• The file contains a special overrides function that selects a different model if the item has custom model data.
• The override model should be in your own namespace folder and be a copy of the original model from the version .jar.
• The override model has custom texture identifiers that map to image paths that are not originally known by Minecraft.
• Finally, you create the image file(s) that are targeted by the identifiers in the override model.