~"I want to make a Pack for MTS!",

said the unsuspecting user, full of glee and optimism, not yet aware of the horrors that lie ahead...

You do NOT need to know Java in order to make a Pack for MTS! What do DO need is the following:

• any text editing program, recommended are Notepad++ for Windows & BBedit for Apple devices
• a 3D modelling program such as Blender or Blockbench
  • Blender is a powerful software but the learning curve is very steep. Better for less blocky cars and more realistic shapes.
  • Blockbench is very user friendly and perfect for minecrafty vehicles. Also great for texturing your model. Recommended for beginners.
• an Image editor such as Kleki, Paint.net, Photoshop, Gimp, or directly in the modelling program, if supported

Optional:

• a sound editing program such as Audacity
• a sound recording program like [placeholder] for windows or Audio Hijack for Apple devices.

Great, you have all your tools ready? Let's dive in!

What is important is that you do not start from scratch! Thats called Masochism!

You are going to download the Official Content Pack first. The file comes in a .jar format, all the interesting stuff is inside! If you're on Windows, use WinRar to simply access its contents, if you're on Apple, you need to extract the assets using The Unarchiver.

After opening / extracting, you're gonna see a lot of folders filed away in even more folders. Don't worry if it feels overwhelming at first, that's normal for aspiring pack authors like you ;)

The folder that we are going to focus on is the assets/mtsofficialpack folder. Inside it there are:

• jsondefs - this is where all the fancy code is!
• models - this is only for Java-models, aka. for items that use a 3D model instead of a 2D Image when you hold it in your hand.
• objmodels - the real model folder where all 3D models are in (vehicles, decor, bullets, parts etc.)
• packdefinition.json - this is what gives your pack an identity, although that's not important right now
• sounds - here are all the sounds the pack will use. The format has to be in .ogg!
• textures - as the name implies, this is where all the textures go.

In each folder apart from sounds & models, there are subcategories that split the selected asset into the respective category:

The subcategories are:

• bullets - Code, textures and models for any projectiles shot by guns, aka. bullets. The OCP author Mr.Mulle has also put all particle textures into the textures/bullets folder. This is NOT required, you can also make a separate textures/particles folder. More on that later.
• decors - Code, textures and models for any immobile object you place down such as fuel pumps, beacons, traffic cones etc.
• instruments - Code for instruments behaviour
• items - This one is a bit more complicated.
  • jsondefs/items governs the code for any edible or usable item that is solely an item, like the wrench, repair packs, food or crafting materials.
  • textures/items has another set of subcategories that ONLY governs the item ICON. This is where you put your 2D Images representing the respective vehicle, item, decor etc.
• parts - Code, textures and models for any separate part such as wheels, engines, guns, crate, seat etc.
• poles - code, textures and models for anything related to traffic lights, signs and poles itself. They follow their own logic, that's why they're not in decor
• vehicles - code, textures and models for vehicles, the stars of the show and the thing that makes MTS MTS.

For more advanced info on file structure, head to Pack Making General File Structure

Before we get to code, we must set up the proper environment.

Head to mtsconfig.json in your Minecraft config folder and look for an entry called "devMode". Delete "false" and write "true" and save the document.

Start Minecraft, place a vehicle, sit in it, right click with a wrench. A new GUI will pop up. You will press "Export Pack".

In your Minecraft folder, a new folder called "mts_dev" will appear. If not, create a folder, name it "mts_dev" and hit "Export Pack" again.

You will now find all the .json files (the code) of OCP in a folder titled mtsofficialpack. The file structure is the same like in the exported .jar.

Any coding should be done with the .json from the mts_dev folder because that allows us to immediately import any changes to the code without closing or restarting minecraft. This saves us a ton of time and pain! We want to work with just OCP now, so leave the folder name unchanged and keep it in mts_dev!

Head back to Minecraft, go to settings>controls and look for "mts dev hotkey". Assign a key of your choice, this will be used later to import code with the press of a button.

IMPORTANT! Devmode allows us to import changed codes without any issues, but we can't import assets like new or changed textures / models the same way. Thats why for changes that require new assets to take place, you need to recompile your extracted assets. More on that later.

It is advised to, before jumping straight to making your own pack, practice a little within OCP in order to get used to how one generally develops content for MTS.

Lets start simple and change the the texture of OCPs wooden crate.

First, you need to locate the crate textures. A crate is a part and since we're looking for a texture, you need to go to assets/mtsofficialpack/textures/parts. Pick the crate.png texture and modify it in the image editor of your choice. You could draw a big X on it for example.

Save the texture and replace the original with it. Thats it!

In order to add a NEW vehicle texture, we're going to have to mess with both code AND textures! To make it easier, you could import a vehicle model, fordmustang69.obj and one of its textures, fordmustang69_red into Blockbench for example. Select all model objects, right click, texture > fordmustang69_red.png.

You may now mess around by painting on the model or squiggling around in the texture sheet itself. For now, vandalising it with random lines and shapes will do.

Save the texture but change the suffix to something else so the vehicle name stays the same. You could call the new texture fordmustang69_ugly.

Make sure to put the texture into the right place. -> assets/mtsofficialpack/textures/vehicles

Now we get to coding! In the mts_dev folder, head to mtsofficialpack/vehicles and look for fordmustang69.json. Open it with Notpad++ or BBedit and search for the "definitions":[...]-component.

Take a look at the way variants are listed and then try to add another entry that references your new texture. When you're done, check the solution below. It should look something like this:

{
    "subName": "_ugly",
    "name": "Ugly Ford Mustang",
    "extraMaterialLists": [
      [
        "minecraft:diamond:1"
      ]
    ]
  }

For more in-depth info on the "definitions" component, head to JSON Definitions

Also make sure your commas are right! The last block of a section is never allowed to have a comma or else the code won't parse!

"Section": [
   {...},
   {...},
   {...},
   {...}   <- last block must be comma free!
]

Copy the modified fordmustang69.json file from mts_dev and head back to your extracted OCP assets. Paste it into the correct folder and replace the old file. The path is assets/mtsofficialpack/jsondefs/vehicles

• For Windows: If you used WinRar to assess the jar, all you need to do to save the changes made and hit "yes i want to update the file in the archive".

• For Apple: For apple devices, recompiling a pack back into a .jar is a bit more complex but still pretty straight forward. Go back in the extracted OCP until you see the following files: vingette.png, assets, data(1.16 only), mtsofficialpack, pack.mcmeta and META-INF. Select all of the files at once, right click and press compress. You will now have a .zip file. Chance .zip to .jar, hit enter and confirm new suffix. Change your .jars name back to its original or pick a new name.

Run Minecraft again and if everything went right, you should now have successfully changed the crates appearance and added your own custom paint job to the game!

As you may have noticed, while your new fancy Mustang paintjob made it into the game perfectly fine, its item texture is a weird purple-black checker box!

This is because we didn't make an item icon yet. The game is trying to find an icon with the same name as your new texture, but is unsuccessful, therefore it returns the purple-black checker box, aka. the missing-texture icon.

Let's fix this issue. In the OCP assets, we are going to go to where all item icons for vehicles are located. The path is assets/mtsofficialpack/textures/items/vehicles

Once you're there, you will see that all the vehicle icons are downscaled images of the respective vehicle itself. There are no rules of how one wants to approach item icons, as they are simple .png images. In theory you could draw your own icon, have text on it or even use a pixelated image of former US President Barack Obama!

In OCPs case and for most other packs however, displaying the vehicle itself is the most common method. The item icons must have a 1:1 ratio 2-squared resolution, meaning you will have to stick to 16x16, 32x32, 64x64, 128x128 etc. 32x32 and 64x64 are the most commonly used resolutions for item icons.

In order to make a downscaled icon of your vehicle, we have to screenshot it first. The best way to get a clean screenshot is by taking it within your 3D modelling program. Import the vehicles model, in this case fordmustang69.obj and its new texture fordmustang69_ugly.png.

Apply the texture to the model, then orient the model in a way that roughly resembles the orientation of the preexisting item icons. As this is for educational purposes, it doesn't have to be perfect.

Take a screenshot of the model (In Blockbench its ctrl+p) and save it in downloads. Converting the screenshot into a proper icon is possible with any image editing program, though this guide will use Kleki to demonstrate the process. The screenshot should have a transparent background as that makes our job easier.

Open Kleki and drag the screenshot into the site. Let it drop onto the "import as new image" section.

On the right side click the "Edit" tab, then select the "Resize" button. An interface will appear in which you can edit resolution sizes. Look for the higher pixel count and change that value to 16, 32, 64, 128, 256 [...] or any desired resolution. Before pressing OK, change Smooth to Pixelated in the dropdown menu as to prevent blurriness. Hit "OK" to confirm.

The image has been resized, but its height and width are still not 1:1, aka. of identical resolution. Press ctrl+c and press To Clipboard in the appearing interface.

After copying the downsized screenshot, look to the top right. Right next to the Kleki logo, there's a button with a blank white square. Pressing it will result in the "New Image" interface. In this interface you want to change the resolution to be the same on both width and height. Input your previously chosen resolution into both boxes. Then change the background to be transparent, you do this by pressing the small rounded button with the grey checker marks.

Press ctrl+v to paste your screenshot, import it "As Layer", then hit "OK". All that's left to do is to download the finished product. You can do that by either pressing ctrl+s OR pressing the blue download button at the top right, also positioned next to the Kleki logo.

Rename your item icon to have the vehicle name, just like you previously named your new vehicle texture. If you went with the given example, you'd have to name it fordmustang69_ugly.png. Add it to the other vehicle item icons.

Save the changes to the jar (Windows) / recompile the assets (Apple), reboot Minecraft and if everything went well, you will now have a proper item icon for your new vehicle texture!

Lets step it up by adding our own part! For this, we will be doing some modelling, texturing and coding.

Lets start simple and add a new crate/storage type part.

Any new vehicle, part or decor you want to add starts with a model.

Making a crate is pretty straight forward since it lacks any complex shapes. In this lesson we are going to make a crate that looks like a Minecraft chest. If you feel a little adventurous, feel free to model whatever you like! A suitcase, a grocery bag, a tin can, a trash bag, anything goes!

We are going to model in Blockbench: Open Blockbench and select "Generic Model" at the top of the list.

Once you are in the modelling space, add a new cube.

Resize (press S) it so its dimensions are: X:10 Y:7 Z:10. This is our main chest body.

Add a new cube, resize it to X:10 Y:3 Z:10 and move it (press V) onto of the bigger cube. This is out chest lid.

Add another cube, resize it to X:2 Y:3 Z:1 and place it onto the front of the chest so it overlaps both the lid and the chest body. The result should look like this:

Select all cubes on the list on the right, then look at the left side of Blockbench where it says "Textures". Press the second icon from the left (Create Texture).

In the new window, leave pixel density at 16x and Enable padding. Leave everything else as it is. Press "OK".

Your chest will now have colours, though those are far from what a MC chest looks like. On the top right of BB, head to the Paint tab. Experiment around with the tools and paint your chest however you like. To paint faces obstructed by other cubes, you can simply hide them with the little eye icon next to the cube in the model object list.

If you're done, the result could be something like this. Because I'm a a very funny comedian, I've added an Amogus too.

Now we have a model and a texture, though we are not quite done yet. Select all the cubes, right click and press "Convert to mesh". All the cube icons should be diamonds now.

Select the lid and the hinge thing, right click and press "Merge Meshes". Both model objects are now merged. Rename the lid cube to "lid" and the main chest to "chest".

Right-click the texture and press "Save As". Save it to any desired place and give it a name, testchest.png for example. Move testchest.png to OCPs part textures, path is: assets/mtsofficialpack/textures/parts

On the top of BB, next to the BB logo, there is a section called "File". Press it and select "Export" > "Export OBJ Model". Give your chest model the same name you gave your texture. This is important, names have to match across models, code and textures! If you went with the example name, name your model testchest.obj Move the exported OBJ model to OCPs part objmodels, path is: assets/mtsofficialpack/objmodels/parts

If you want to make an item icon for your chest is up to you, as its not required for the part to be functional.

Now we bring the chest to life with the power of json! Go to OCPs part jsons, path is: assets/mtsofficialpack/jsondefs/parts

Take any .json file there, duplicate it and name it testchest.json. Open the json file and delete everything so you're left with a blank document. Paste in the code provided below:

{
  "generic": {
    "type": "interactable_crate",
    "width": 1.0,
    "height": 1.0
  },
  "interactable": {
    "interactionType": "crate",
    "feedsVehicles": true,
    "inventoryUnits": 1.0
  },
  "definitions": [
    {
      "subName": "",
      "name": "Test Chest",
      "extraMaterialLists": [
        []
      ]
    }
  ],
  "rendering": {
    "animatedObjects": [],
    "lightObjects": [],
    "particles": [],
    "sounds": [],
    "modelType": "obj"
  },
  "general": {
    "name": "Testchest",
    "description": "This is a Testchest! A chest! For Testing!",
    "materialLists": [
      [
        "minecraft:chest:1"
      ]
    ]
  }
}

Lets look at what we've got:

The first JSON component is "generic": {...}.

• It defines what type the part is. This is so it can fit to corresponding part slots on a vehicle that accept the inputted type. Think of a lock & key principle. ("type": "interactable_crate",)
• It also defines the width and height of the crates hitbox. Clicking the hitbox ingame is what will later open the chest. 1.0 is about a Minecraft block in size, which is a bit large for now, but we will tweak it later using DevMode.

The second JSON component is "interactable": {...}.

• it defines what logic this part should run. In this case we want our part to be a storage container, so "crate" is inputted.
• "ÌnventoryUnits" define how many item slots the crate has. One unit (1.0) = 9 item slots.

Third Component is "definitions": [...] As we learned, definition govern the color / texture variants of this part. In our case, there's only one variation, and that one's your lovely texture. "subName": "" can be left empty, as we don't have a texture variant such as "testchest_blue". If you do have multiple color variants, make sure to make a new definition for each one and name them accordingly! Important, Definition is one of the few JSON elements that have to be pasted into the assets directly, as they do not apply via devmode. New textures & definition entries mean remapping the texture atlas, or in simpler terms, require a game restart.

Fourth JSON Component is called "rendering" and is the most interesting one. It governs what particles the part should spawn, which sounds it plays, what model objects are supposed to be animated, which parts should act as lights, what text objects it should display and many more. For now, we focus on getting our part in game first.

Lastly, there's the JSON component called "general". Its role is it to give the part a name, a description, a crafting recipe, health points and several additional parameters that aren't part of this particular example but can all be found in this wiki or other OCP Json files.

Save the new code. Copy the JSON file and head to mts_dev/mtsofficialpack/parts and paste it there too. This is so we can further add code based features via DevMode without having to reboot the game later.

We now have made a model, a texture and have the necessary code to make it functional. Lets test it out! Save / Recompile your changes to OCP and reboot Minecraft.

You should now have a chest that can be placed on vehicles that accept crates, the Scouts back for example.

If you open it, you will see that it only has one row of storage space. Let's change that! Open the testchest.json from the devmode folder you pasted in earlier. To make sure your devmode works properly, change the "inventoryUnits": to 3.0, save the document, go back to the game and hit your choose import key. The game will freeze for a second and then confirm the successful import. Your chest should now have 27 slots instead of just 9!

Right now, clicking the chest opens it, but neither does the lid move nor does it make any sound... Lets fix this!

If all is good, lets get to adding our first animation! Head to "animatedObjects":[], and paste the following code in-between the brackets:

      {
        "objectName": "",
        "animations": [
          {
            "animationType": "visibility",
            "variable": "player_interacting",
            "clampMin": 0.0,
            "clampMax": 0.0
          }
        ]
      }

These entry blocks reference one model object of the corresponding model the json is linked to, in this case to testchest.obj. "objectName": currently has no name inputted into it. Head to Blockbench and check the name you gave the lid. Write that name inbetween the quotation marks. It should look something like this: "objectName": "lid",.

Save the file, head to Minecraft and import the saved code with the devmode hotkey. If you attempt to open the chest now, the lid should disappear.

You will notice that its difficult to check that if there's a GUI in our face! Go back to the code and copy-paste "reverseDelay": 20, under "variable": "player_interacting",. Reverse delay adds a delay that keeps the animation going, even after its variable has changed. It is measured in ticks, 20 ticks = one second, meaning we added one second of delay to the animation.

Reimport and check. The lid should stay hidden for a second after opening and closing the chest.

Great, you came in contact with the first and simplest type of animation. The visibility animation! The visibility animation determines whether the targeted model object is visible or not. The animation ONLY plays out if its variable is true.

What the heck does that even mean? Lets look closer at our animation code:

The variable used to trigger the animation is called "player_interacting". It returns a 1 if the chest is opened, and a 0 of its closed. Since we want the lid to only disappear when the chest is open, we need to set the value conditions/clamps. In simpler terms, we need to tell the animation which numbers the variable has to return before it is allowed to play.

We do that by having clamps in the code.

• clampMin defines the minimum value a variable has to have in order for the animation to play
• clampMax defines the maximum value a variable has to have in order for the animation to play

In our animation, both clamps are set to 0. This is so the animation is only allowed to play (having the lid be visible) as long as "player_interacting" is 0. If a player opens the chest "player_interacting" flips to 1 and since the variables value is then outside of the clamps, their output is false, meaning the animation that keeps the lid visible is deactivated, finally making the lid disappear.

There are many variables that can be used to make complex animations and behaviour happen, but we don't want to go ahead of ourselves here. If you're interested nontheless, all animation variables can be found in JSON Animation Variables

Usually, the lids of containers we open don't vanish into thin air... because that's boring! Let's make the lid float up instead!

This is where the translation animation comes in. No, it unfortunately doesn't translate any languages, instead it translates the targeted object along a chosen axis, aka makes it move from point A to point B.

Go back to your json file and to our animated object. In "animationType":, replace visibility with translation.

But how does MTS know to what position to move the lid? Thats right, it doesn't! We need to tell it! We do that by using "axis": [0.0,0.0,0.0]

Axis has three numbers separated by commas. These numbers always stand for the X, Y and Z axis. The variable value gets fed into Axis and multiplies the numbers inputted. This means that if our "variable": "player_interacting", returns 1, and our "axis": [0.0,2.0,0.0]s Y number is 2, the model object will translate two blocks on the Y axis, aka move two blocks upwards.

Lets try it out! Paste "axis": [0.0,2.0,0.0] under "variable". You also have to change the clamps to 1, since we now only want the lid to move when the player looks into our chest.

Additionally, add "duration": 15, under "reverseDelay": 20,. Duration defines how many ticks it takes the lid to go from its initial position to its defined position. Without duration, the lid would instantly snap to the destination! 20 tick = one second, so with a value of 15, the lid will take 0.75 seconds to open/close fully.

Watch out for any missing commas and then import ;)

Works? Awesome! "axis": [0.0,0.0,0.0] can accept any number you want, so "axis": [-2.0,5.0,-10.0] for example will make the lid move two blocks to the right, five blocks upwards and ten blocks backwards. Think vectors!

Welcome to the fanciest of all animations, the rotation animation. Fittingly, this is the one animation we need to make our lid actually behave like a perfectly normal chest lid and not like a possessed creature of the dark!

In "animationType":, replace translation with rotation.

"axis" now no longer represents blocks moved per unit, but rather degrees rotated on the respective axis. Since we want our lid to rotate towards the back, that means it pivots back on the X axis. Input the amount of degrees the lid should rotate into the X axis section. The result should look like this: "axis": [-90.0,0.0,0.0],.

But there is another problem. Without any defined pivot point, how does the lid know where its hinges are? Our pivot point is defined by "centerPoint": [0.0,0.0,0.0],. Paste it below "axis".

To figure out our pivot point, we go back to Blockbench and press the Edit tab next to the Paint tab. Press P and move the small pivot point indicator to the back of the chest where the hinges would be. You can test if the lid opens correctly by pressing R and rotating around the red slider.

This should look like this:

Below "Size", there are the coordinates of the "Pivot Point".

WARNING! Blockbench calculates coordinates with Pixels but MTS calculates them with Blender-Metres! One blender meter = 16 pixels! That means we're gonna have to do some quick maths! Divide the Pivot Point coordinates by 16 ([x,y,z]/16) and input the results into "centerPoint": [0.0,0.0,0.0],.

On the image above, the BB pivot point coords are 0.0, 7.0, -5.0. Divided by 16, this equals 0.0, 0.4375, -0.3125.

Great! Now MTS knows where the lid has to pivot from, on which axis it has to rotate and by how many degrees!

Make sure the commas are right! If you're done, the animation code should look like this:

"animatedObjects": [
      {
        "objectName": "lid",
        "animations": [
          {
            "animationType": "rotation",
            "variable": "player_interacting",
            "axis": [-90.0,0.0,0.0],
            "centerPoint": [0.0,0.375,-0.3125],
            "reverseDelay": 20,
            "duration": 15,
            "clampMin": 1.0,
            "clampMax": 1.0
          }
        ]
      }
    ],

Moving on to sounds. In principle, sounds are structured similar to animations in animatedObjects:[...]. In the sounds case, the animations in "activeAnimations": [...] determines what conditions have to apply in order to play the sound.

Typically, only visibility animations are used in the "activeAnimations": [...].

Go to "sounds": [], and paste the provided snippet below into the brackets:

      {
        "name": "mtsofficialpack:crateopen",
        "pos": [0.0,0.0,0.0],
        "activeAnimations": [
          {
            "animationType": "visibility",
            "variable": "player_interacting",
            "clampMin": 1.0,
            "clampMax": 1.0
          }
        ]
      }

So, what does what?

• name - defines which sound should be played by inputting its name. Structure is: "PACK-ID:SOUND-NAME".
• pos - defines where the sound plays, relative to the object spawning it.
• "activeAnimations": [...] - holds one or multiple animations that all have to be true in order to play the sound
• "animationType": "visibility" - is the animation type typically used for sounds.
• "variable": - Is the variable that has to be true (or false, depending on your clamps) so the sound can play
• "clampMin/Max" - As previously described, clamps define what value the variable must have in order for it to return "true"

What we define is: Sound "crateopen" must play when player_interacting is true / 1, aka the player interacts with this part, aka the player opens the chest.

Save, import and check. The sound should now play when opening the chest.

This is pretty much it for basic sounds. You can of course, add more visibility animations to create more complex conditions, for example a wind sound should only play if the vehicle is moving faster than X blocks per second, and is higher than Y blocks in the air.

Lets look at additional functions of a fully decked out sound entry:

      {
        "name": "mtsofficialpack:crateopen",
        "pos": [0.0,0.0,0.0],
        "activeAnimations": [
          {
            "animationType": "visibility",
            "variable": "player_interacting",
            "clampMin": 1.0,
            "clampMax": 1.0
          }
        ],
        "volumeAnimations": [],
        "pitchAnimations": [],
        "looping": true,
        "isExterior": true,
        "minDistance": 0.0,
        "minDistanceVolume": 1.0,
        "middleDistance": 0.0,
        "middleDistanceVolume": 0.0,
        "maxDistance": 32.0,
        "maxDistanceVolume": 0.0
      }

Quick basics:

• volume & pitch animations are covered below
• "looping" - defines wether the sound should loop as long as the activeAnimations return "true"
• "isExterior" / "isInterior" - defines wether a sound is only heard from the outside or the inside of the vehicle.

The big fat block of distance values may look intimidating, but is relatively simple.

You have three distance values, defining what the minimum range, the middle range and the maximum range from the source one has to be to hear the sound. In meters / blocks. For example, "minDistance": 0.0, means the sound played directly from the center of the source, "minDistance": 5.0, means the sound will only start playing as soon as the player is more than 5 blocks away from the source.

"maxDistance": 0.0, is self explanatory, this defines the maximum range of the sound. If you're outside of this range, it will no longer play.

"middleDistance": 0.0, is not important for simple sound behaviour, but can be very useful when you need a sound to fade in and fade out again based on distance or if you want a sound to fall off / gain non linearly.

The Volume defines how loud the sound is at the defined distances. 0 = Silent 1 = Maximum volume

Here is a small visualisation of how these values work in conjunction:

If all values are left at 0, the default is minDistance 0 blocks, maxDistance 32 blocks, with volume at minD = 1 and maxD = 0

There are more advanced functions that involve dynamically adjusting volume and pitch with translation or even rotation animations. These are "volumeAnimations": [], and "pitchAnimations": [], respectively. For more in-depth info on the "sounds" component, head to Sounds

Bla bla bla snussy snildo

Aaah Particles... I love particles. You can do so much with them! They are addictive. Be careful with particles.

For our crate, lets make some dust pop up when you close it!

Go to "particles": [] and paste in the following:

      {
        "type": "generic",
        "spawningOrientation": "entity",
        "renderingOrientation": "player",
        "quantity": 5,
        "duration": 100,
        "movementDuration": 6,
        "transparency": 0.3,
        "toTransparency": -0.001,
        "scale": 1.9,
        "toScale": 3.5,
        "hitboxSize": 0.2,
        "ignoreCollision": false,
        "textureList": [
          "mts:textures/particles/big_smoke_0.png",
          "mts:textures/particles/big_smoke_1.png",
          "mts:textures/particles/big_smoke_2.png",
          "mts:textures/particles/big_smoke_3.png",
          "mts:textures/particles/big_smoke_4.png",
          "mts:textures/particles/big_smoke_5.png",
          "mts:textures/particles/big_smoke_6.png",
          "mts:textures/particles/big_smoke_7.png",
          "mts:textures/particles/big_smoke_8.png"
        ],
        "randomTexture": true,
        "colorList": [
          "8D867D",
          "BAB0A7",
          "B9B4AD",
          "E8E6E3"
        ],
        "randomColor": true,
        "pos": [0.0,0.5,0.0],
        "spreadRandomness": [1.0,1.0,1.0],
        "initialVelocity": [0.0,0.0,0.0],
        "movementVelocity": [0.0,0.0,0.0],
        "terminalVelocity": [0.0,0.0,0.0],
        "activeAnimations": [
        {
            "animationType": "visibility",
            "variable": "player_interacting",
            "clampMin": 0.0,
            "clampMax": 0.0
          }
        ]
      }

"WHOA ITS HUGE", is what she said and what you probably thought. Yes, particles can become quite large, especially if you want to give it complex behaviour. But since I am a particle fetishist, I see it as my responsibility to explain particles in a more detailed manner. So, what are we working with in this case?

• "type" - Most of the time you are going to use generic. There are also default presets for flame, smoke or bubble types, but those are for very very lazy people with a deficient taste for aesthetics and I will judge you if you use anything else than generic
• "spawningOrientation" - Relative to what the particle spawns. May be the entities coordinates spawning it or the worlds coordinates. More details on the particle wiki page.
• "renderingOrientation" - determines where the particle is orientated towards. Player means it always faces the player, fixed means it does not rotate at all etc.
• "quantity" - Defines how many particles is spawned per operation.
• "duration"- how long the particle lives, in ticks.
• "movementDuration" - After how many ticks the particle should stop moving.
• "transparency" - Transparency at the beginning of the particles lifetime. 1 is solid, 0 is fully transparent.
• "toTransparency" - Transparency at the end of the particles lifetime.
• "scale"/"toScale" - Scale of the particle at its birth / death. In blocks.
• "hitboxSize" - Its collision box size. Collides with blocks.
• "ignoreCollision" - if true, particles no longer collide with any bocks.
• "textureList" - A list of textures this particle chooses from. Is used to either randomise textures or create animations for the particle.
• "randomTexture" - if true, makes the particle choose a random texture from "textureList"
• "colorList" - same like textureList, but for colours
• "randomColor" - if true, makes the particle choose a color from colorList
• "pos" - position of where the particle should spawn
• "initialVelocity" - Velocity the particle should have on spawning, xyz
• "spreadRandomness" - amount of Velocity randomly added or subtracted to/from "initialVelocity", xyz
• "movementVelocity" - How much velocity should be added to the particle per tick. Used to make particles float up / fall down etc.
• "terminalVelocity" - Maximum velocity on all defined axis. Particle cannot go faster than the given values, no matter the circumstances. If 0, it's ignored.

Now all of this is giga fancy, but what odes it actually do. It basically spawns five smoke particles with a random velocity on all axis with random textures and colours as soon as the player is no longer interacting with the crate. You can do a lot with particles, more info can be found on the Particles wiki page.