Think of events like setting up a doorbell. You don't stand at the door waiting all day - you set up a doorbell, and when someone presses it, it rings and you know to go answer.

Events work the same way. You write a function (your code), and the game automatically runs it when something specific happens - like a player joining, chatting, or breaking a block.

The stuff in parentheses like (playerId) are values the game gives you automatically. You don't have to figure out who joined - the game tells you by putting their ID in that variable.

The => arrow is just a way to write a function. Everything inside the curly braces { } is what happens when the event fires.

This event fires the moment someone enters your world. It only fires ONCE per player - when they first join, not every second they're in the world.

The playerId is like a unique name tag the game gives each player. You use this ID to do things TO that specific player - like sending them a message or giving them items.

This is perfect for welcome messages because you want to greet someone when they arrive, not randomly throughout their visit. You can also use it to give starter items, set up their player data, or announce to everyone that someone new joined.

This fires when someone leaves your world - whether they clicked "leave", closed their browser, or lost internet connection.

You still get their playerId so you can do things like save their progress, announce they left, or clean up any game data related to them.

The let name = api.getEntityName(playerId) part gets their actual username (like "CoolGamer99") instead of the ugly ID. Then we use + to combine the name with our message text.

This is useful for goodbye messages, saving player data before they're gone, or updating scoreboards when someone leaves mid-game.

When a player types something starting with / in chat (like /help), this event fires. The game strips the slash, so if they type /help, your command variable will just be "help".

The if (command === "help") checks if they typed exactly "help". The triple equals === means "is exactly equal to".

The return true at the end is important! It tells the game "I handled this command, don't show an error." If you don't return true, the player sees "Unknown command" even though your code ran.

You can add more commands by adding more if statements - one for each command you want to create like /spawn, /heal, /kit, etc.

This fires every time someone sends a regular chat message (not a /command). You get their playerId and the actual chatMessage they typed.

The .includes("badword") checks if their message contains that text anywhere. So "hello badword bye" would trigger it.

The return false is the magic part - it BLOCKS the message from being sent to everyone. The player typed it, but nobody else sees it. You can warn them privately with sendMessage.

If you return true (or don't return anything), the message goes through normally. This is great for chat filters, custom chat formatting, or chat-based minigames where typing certain words does something special.

Think of tick like a heartbeat for your world - it beats 20 times every second, forever, as long as your world is running.

The ms value tells you how many milliseconds passed since the last tick (usually around 50ms). You probably won't need this much.

This is your "game loop" - perfect for things that need to happen constantly, like checking if players fell into the void, running timers, or checking if players are in certain zones.

WARNING: Because this runs 20 times per second, any slow code here will lag your entire world! Keep tick code fast and simple. Don't do heavy calculations or loop through tons of data here.

This fires whenever a player places OR breaks a block. You get the exact coordinates (x, y, z) and what the block changed from and to.

fromBlock is what the block WAS before. toBlock is what it's becoming. When someone BREAKS a block, toBlock will be "Air" (because the block is now gone). When someone PLACES a block, fromBlock will be "Air" (because there was nothing there before).

The return "preventChange" is super powerful - it cancels the action completely! The block stays exactly as it was. Use this to protect certain blocks or areas from being changed.

Great for build protection (can't break blocks in spawn), logging who changed what, or making special blocks that do something when broken.

Simple one - this fires every single time a player presses the jump button. You just get their playerId.

This is perfect for making custom jump mechanics like double-jump (track how many times they jumped, give them an extra boost), jump counters for minigames, or triggering abilities when jumping.

Note: This fires when they PRESS jump, not when they land. So even if they're in the air, pressing jump again will fire this event.

This fires repeatedly while a player is standing on top of a block. You get their position (x, y, z) and what block they're standing on (blockName).

Important: This fires VERY fast - potentially 20-80 times per second per player! So if you're dealing damage, use small amounts (like -2) or it'll kill them instantly.

The y coordinate is the block BELOW their feet. So if they're standing on lava at y=10, you get y=10 and blockName="Lava".

Perfect for: pressure plate effects, lava/poison damage zones, speed boost pads, checkpoint systems, or any "step on this block to trigger something" mechanic.

Think of this like sending a private DM or text message. Only that one person can see it - nobody else in the world will know you sent it.

The first thing you put in is playerId - this is like the phone number of who you're texting. You get this ID from events like when someone joins or types a command.

The second thing in quotes is your actual message - whatever text you want them to see in their chat.

This is like making an announcement over a loudspeaker - EVERYONE in the world hears it at the same time.

Notice you don't need to say WHO to send it to (no playerId) because it goes to everybody automatically.

The + symbol joins pieces of text together. So if the player's name is "Steve", then name + " joined!" becomes "Steve joined!"

The let name = ... part creates a little storage box called "name" to hold the player's username so we can use it in our message.

The curly braces { color: "red" } are like extra settings you can add to your message.

You can use simple color names that everyone knows: "red", "green", "blue", "yellow", "orange", "purple", "white".

Or you can use hex codes like "#ff0000" for red or "#00ff00" for green if you want a specific shade. Google "hex color picker" to find codes!

This works on both sendMessage (private) and broadcastMessage (everyone) - just add the color part at the end.

Players have two things: an ID (like "player_abc123") which the computer uses, and a NAME (like "CoolGamer99") which humans see.

You can't show the ID in chat because it looks ugly and confusing. This function converts the ID into their actual username that looks nice.

Always use this when you want to mention a player's name in any message!

This gives you a number - how many people are in your world right now. If 5 people are playing, it returns 5.

You can use this to show player counts, or check if you have enough players to start a game (like "need 4 players to start").

Store it in a variable like let count = ... so you can use the number in messages or comparisons.

This gives you a list of everyone currently in your world. Think of it like getting a class roster - you get everyone's ID number.

The for (let p of players) part goes through the list one by one. For each person in the list, do something to them.

This is super useful when you want to affect EVERYONE at once - like healing all players, checking if anyone is in a zone, or giving everyone an item.

Every player has two things: an ID (like "player_abc123") and a NAME (like "CoolGamer99").

The ID is what the computer uses internally - it's ugly and confusing for humans.

The name is what everyone sees - it's their actual username.

This function converts the ugly ID into the nice readable name. Always use this when you want to show a player's name in chat or on screen!

This is the opposite of getEntityName! Instead of ID → name, this goes name → ID.

You give it a username like "Steve", and it searches through everyone online to find that person's ID.

If they're not online, it returns null (nothing). That's why we check if (targetId) - to make sure we found someone before trying to use their ID.

Perfect for commands where players type someone's name, like "/tp Steve" or "/kick BadPlayer".

Sometimes you save a player's ID for later use. But what if they left the game? Their ID becomes invalid!

This function checks: "Is this player ID still good? Are they still connected?"

Returns true if yes (they're still playing), false if no (they left or the ID is bad).

Use this before doing something to a saved player ID to avoid errors.

Mobile players have touchscreen controls which can be harder than keyboard/mouse. This lets you detect which type of player they are.

You can use this to make your game more fair - like giving mobile players extra help, showing them different instructions, or adjusting difficulty.

It's a simple yes/no check: mobile = true, computer = false.

Position is stored as 3 numbers in a list (called an array): X, Y, and Z coordinates.

X is left/right, Y is up/down (height!), and Z is forward/backward.

The tricky part: arrays start counting at 0, not 1. So pos[0] is the first number (X), pos[1] is the second (Y), and pos[2] is the third (Z).

Think of it like a list where the first item is #0, second is #1, third is #2.

This instantly moves a player to wherever you want - like a teleport command.

The format is: setPosition(playerId, X, Y, Z) where X, Y, Z are the coordinates you want them at.

In Bloxd, Y = 1 is the default ground level. Y = 10 is a safe spawn height above ground.

The player doesn't walk there - they just instantly appear at that spot!

This is different from teleporting! Instead of moving them instantly, you're PUSHING them like a shove or a jump pad.

The three numbers are how hard to push in each direction: (X push, Y push, Z push)

(0, 30, 0) means: don't push sideways (0), push UP really hard (30), don't push forward/back (0). Result: they fly straight up!

(10, 10, 0) would push them sideways AND up at the same time - like being launched at an angle.

Bigger numbers = stronger push. Negative numbers push the opposite way (so -10 on Y would push them DOWN).

Velocity means how fast something is moving. This tells you the player's current speed in each direction.

If they're standing still, you get [0, 0, 0] - zero speed in all directions.

If they're falling, the Y velocity (vel[1]) will be a negative number because they're moving downward.

Useful for things like: checking if they're falling fast (fall damage), seeing if they're moving (AFK detection), or speed-based mechanics.

This sets their exact speed instead of adding a push. It's like saying "you are now moving at exactly this speed."

The difference from applyImpulse: impulse ADDS to their current movement, setVelocity REPLACES it completely.

Good for consistent effects where you want them moving at an exact speed, not faster or slower based on what they were doing before.

tick is a special event that runs over and over - 20 times every single second. It's like a heartbeat for your game.

api.getPlayerIds() gives you a list of everyone currently in the world.

for (let playerId of players) goes through that list one person at a time - "for each player, do this..."

We check if their Y position (height) is below 0 - that means they fell into the void below the world!

If they did fall, we set their health to 0 which kills them. This runs constantly so it catches anyone who falls.

The direction is a vector with three numbers: [X, Y, Z]. Think of it like pointing an arrow in 3D space.

[1, 0, 0] = look right, [-1, 0, 0] = look left

[0, 1, 0] = look up, [0, -1, 0] = look down

[0, 0, 1] = look forward, [0, 0, -1] = look backward

You can combine them too! [1, 0, 1] makes them look diagonally (right and forward at the same time).

Think of zoom like how far back the camera sits from the player. Bigger number = camera further away = you see more of the world.

Default zoom is around 5-6. That's the normal third-person view.

Zoom 15 = way zoomed out, like a bird's eye view

Zoom 2 = super close, almost first-person

Great for vehicles (zoom out so you can see the whole vehicle).

This tells you everything about where the player is looking and facing.

camPos is where their camera (eyes) are in the world - useful for spawning things from their viewpoint.

dir is the direction they're looking as a vector - where their crosshair points.

Perfect for shooting games - you need to know where their camera is and what direction they're aiming!

This is like asking "what block is your crosshair pointing at?"

position gives you the coordinates of that block.

normal tells you which face of the block you're looking at (top, bottom, side).

adjacent is where a new block would appear if you placed one - the empty space next to the block you're targeting.

Super useful for custom building mechanics or interaction systems!

Crouching (also called sneaking) is when players hold the crouch button. They move slower and their character gets shorter.

This function just checks: "Is this player currently holding crouch?" Yes = true, No = false.

You can use this for stealth games (crouching makes you harder to see), special abilities (crouch to activate something), or movement mechanics (crouch to fit through small spaces).

Opacity is how see-through something is. Think of it like a ghost - fully solid or partially transparent.

1 = completely solid, normal player (100% visible)

0.5 = half transparent, you can see through them a bit (50% visible)

0 = completely invisible, can't see them at all (0% visible)

This affects how EVERYONE sees that player. If you set someone to 0, nobody can see them!

Players have many customizable parts: head, body, legs, shoes, eyebrows, eyes, skin (color), cape, and nameColour.

For full character skins like "wizard" or "zombie", use them on head, body, and legs.

For individual parts, use codes like "head_1_0", "body_2_3", "legs_0_1" etc.

Skin names are lowercase: "wizard" works, "Wizard" doesn't.

This overrides whatever skin the player chose. Great for team uniforms or class systems!

This is the "undo" button for skin changes. It removes any skins you forced on them with changePlayerIntoSkin().

After calling this, they go back to whatever skin THEY chose in their settings.

Use this when a transformation ends, they leave a team, or you want to reset their appearance to normal.

Poses control the player's animation - how their character model looks.

"sitting" makes them look like they're sitting down, even if they're walking around!

"sleeping" makes them lie down flat.

"gliding" gives them the flying/gliding animation.

The pose stays until you change it. If you set someone to "sitting", they'll stay sitting even while moving until you set them back to "standing".

Great for chairs (sit when they stand on a block), beds (sleep pose), or vehicles (driving pose)!

This lets you stretch or shrink individual body parts. Each part has three scale values: [X, Y, Z].

[2, 2, 2] = double the size in all directions (twice as big)

[0.5, 0.5, 0.5] = half the size in all directions (tiny)

[1, 2, 1] = normal width, double height, normal depth (stretched tall)

IMPORTANT: You must pass ALL the parts you want scaled at once! If you call this function again, it forgets previous scales. So if you want a big head AND long arms, put both in the same call.

The body part names must be spelled exactly right with capitals!

This gives you a number from 0 to 100 representing how much health the player has.

100 = full health, 0 = dead, 50 = half health.

Store it in a variable like let health = ... so you can check it or show it to the player.

This sets their health to an exact number - whatever you put in.

setHealth(playerId, 100) = full health, completely healed

setHealth(playerId, 0) = zero health, they die instantly

setHealth(playerId, 50) = half health

It doesn't matter what their health was before - it gets set to exactly what you specify.

This is different from setHealth! Instead of setting health to an exact number, this ADDS or REMOVES from their current health.

Negative number = damage. -5 means "take away 5 health" (deal 5 damage).

Positive number = healing. 10 means "add 10 health" (heal them).

So if they have 15 health and you do applyHealthChange(playerId, -5), they end up with 10 health.

Normally when players die, they see a "Click to Respawn" screen. This skips that and brings them back to life instantly.

Without any location: forceRespawn(playerId) - they respawn at the world's default spawn point.

With a location: forceRespawn(playerId, [0, 10, 0]) - they respawn at those exact coordinates. Notice the square brackets around the coordinates!

Great for fast-paced games where you don't want players waiting on a death screen.

This returns true if the player is alive and playing, or false if they're dead (on the respawn screen).

Use it in an if statement to only do something when they're alive - like you can't heal a dead player!

Useful for checking before doing things that only make sense for living players.

This completely removes someone from your world - they get disconnected and have to rejoin if they want to come back.

The text in quotes is the reason they'll see when they get kicked, like "You have been kicked for cheating".

Use this for admin commands (like /kick PlayerName) or automatic systems that detect rule-breaking.

Be careful with this power! Only use it when really needed.

This is an EVENT, not a function you call. It runs automatically whenever one player kills another.

The game gives you four pieces of info:

attackingPlayer - who did the killing

killedPlayer - who died

damageDealt - how much damage the final hit did

withItem - what weapon/item was used (like "Diamond Sword")

You can use this for kill feeds, tracking scores, weapon-specific bonuses, or anything that should happen when someone gets a kill.

A killstreak is how many kills someone has gotten in a row without dying. The game tracks this automatically for you!

This returns a number - if they've killed 5 people without dying, it returns 5.

Use it for announcements like "Steve is on a 5 killstreak!" or rewards for high streaks.

This resets their killstreak back to 0, like they just started fresh.

Normally the game resets it when they die, but you might want to reset it manually - like when a new round starts, or as a penalty for something.

This puts items directly into a player's inventory - like giving them a gift!

The format is: giveItem(playerId, "Item Name", amount)

IMPORTANT: Item names must be spelled EXACTLY right, including capital letters! "Wood Sword" works, but "wooden sword" or "WoodSword" won't work.

Common items: "Apple", "Diamond Sword", "Iron Pickaxe", "Gold Coin", "Arrow", "Wood Sword", "Stone Pickaxe"

This is a yes/no question: "Does this player have at least one of this item?"

Returns true (yes they have it) or false (no they don't).

Use it in an if statement to check before doing something - like "only let them in the VIP area if they have a VIP Pass".

Note: This only tells you IF they have it, not HOW MANY. Use getInventoryItemAmount if you need to know the quantity.

This returns a NUMBER - exactly how many of that item they have in their inventory.

If they have 50 apples, it returns 50. If they have none, it returns 0.

Perfect for money/currency systems! Use "Gold Coin" as your game's money, then check how many coins they have before letting them buy things.

You can compare it with numbers: if (coins >= 10) checks if they have 10 or more coins.

This takes items OUT of their inventory - the opposite of giveItem.

Format: removeItemName(playerId, "Item Name", amount)

IMPORTANT: Always check if they have enough BEFORE removing! The shop example shows the right pattern:

1. First, check how many they have

2. If they have enough, THEN remove the items and give them what they bought

3. If they don't have enough, tell them they need more

Don't remove first then check - that's backwards and will cause problems!

This wipes their entire inventory clean - EVERYTHING is gone. Use carefully!

Good for: starting a new game round where everyone should begin fresh, entering an arena with specific loadouts, or as a punishment.

Often you'll want to use this together with giveItem - clear everything, then give them the items they should start with.

This tells you what item is in their hand right now - the one they have selected in their hotbar.

It returns an object with information about the item. Use held.name to get the item's name.

If they're holding nothing (empty hand), it returns null. That's why we check if (held) first - to make sure they're actually holding something before trying to use it!

Useful for: special abilities when holding certain items, checking if they have the right tool, weapon-specific effects.

The hotbar is the row of item slots at the bottom of the screen (10 slots total).

This forces the player to switch to a specific slot - like pressing the number keys 0-9.

Slots are numbered 0-9. So slot 0 is the first slot, slot 9 is the last slot.

Useful for: forcing them to hold a specific item, switching their weapon automatically, or game mechanics that require holding certain items.

Every position in the world has a block - even if it's just "Air" (empty space).

The three numbers are X, Y, Z coordinates. Y is height - so Y-1 means one block below.

This returns a string with the block name like "Stone", "Grass", "Wood", etc.

You can also pass coordinates as an array: api.getBlock([10, 5, 10])

This instantly places a block - no animation, no item needed, just appears.

Format: setBlock(x, y, z, "BlockName")

To remove a block, set it to "Air": setBlock(x, y, z, "Air")

Block names must be exact - double check the name and make sure the casing matches!

You can also use array format: setBlock([10, 5, 10], "Stone")

The world is divided into "chunks" - sections that load/unload as players move around.

If a chunk isn't loaded, you can't get or set blocks there - the game doesn't have that data yet.

Use this to check before doing block operations in far away places.

Usually you don't need this for blocks near players since those chunks are always loaded.

Solid blocks are ones you can stand on and can't walk through - like Stone, Dirt, Wood.

Non-solid blocks you can walk through - like Water, Ladders, Air.

Useful for checking if a spot is safe to teleport to, or if there's a floor below.

This fills a 3D box with blocks. You give it two corners and it fills everything between them.

Format: setBlockRect([x1, y1, z1], [x2, y2, z2], "BlockName")

The corners can be in any order - it figures out which is min/max automatically.

Example: [0, 0, 0] to [5, 5, 5] creates a 6x6x6 cube (coordinates are inclusive).

To clear an area, use "Air" as the block type.

This creates the WALLS of a box, not a solid cube. The inside is hollow/empty.

Format: setBlockWalls([x1, y1, z1], [x2, y2, z2], "BlockName", hasFloor, hasCeiling)

hasFloor: true = adds a floor at the bottom

hasCeiling: true = adds a ceiling at the top

hasFloor: false, hasCeiling: false = just the 4 walls, no floor or ceiling

Perfect for making buildings since you don't waste blocks filling the inside!

This makes ONE specific block unbreakable/unplaceable for ONE specific player.

Format: setCantChangeBlock(playerId, x, y, z)

The player can't break it if it exists, and can't place a block there if it's air.

This is per-player - other players can still change that block unless you protect it for them too.

Warning: Protecting thousands of individual blocks can cause lag. Use setCantChangeBlockType or setCantChangeBlockRect for large areas.

This is the opposite of setCantChangeBlock - it ALLOWS changing a specific block.

Useful when you've disabled building globally but want to allow specific blocks to be changed.

Example: Building disabled everywhere except in designated build zones.

This protects ALL blocks of a certain type, everywhere in the world, for one player.

Format: setCantChangeBlockType(playerId, "BlockName")

Much more efficient than protecting individual blocks if you want to protect a whole block type.

Example: Protect all "Diamond Ore" so players can't mine it.

Block names must be exact - double check the name and make sure the casing matches!

This allows changing all blocks of a specific type, even if building is restricted.

Useful for allowing specific materials while blocking others.

Example: Allow breaking "Dirt" and "Stone" but nothing else.

This undoes any setCanChangeBlockType or setCantChangeBlockType you did for that block type.

The block type goes back to normal behavior - following the global canChange setting.

Use this to remove restrictions you set earlier.

When multiple permissions conflict, the most specific one wins:

1. setCanChangeBlock / setCantChangeBlock (specific position) - HIGHEST priority

2. setCanChangeBlockRect / setCantChangeBlockRect (area) - MEDIUM priority

3. setCanChangeBlockType / setCantChangeBlockType (block type) - LOWEST priority

Example: If you protect all "Stone" but allow one specific Stone block, that one block can be changed.

Format: attemptSpawnMob("MobType", x, y, z)

Mob types must match exactly - double check the name and make sure the casing matches!

Returns the mob's ID if successful - save this to control the mob later!

Returns null if spawn failed (invalid position, mob limit reached, etc.)

Always check if the result is null before using the mob ID.

The options object lets you customize the mob when spawning:

name - Custom display name above the mob

playSoundOnSpawn - Play spawn sound effect

mobHerdId - Make mob part of a herd (see createMobHerd)

spawnerId - Track which player spawned it

This instantly removes a mob - poof, gone!

You need the mob's ID (the value returned from attemptSpawnMob).

No death animation, no item drops, no death event - it just vanishes.

Use this for cleanup, not for killing mobs in gameplay (use damage for that).

This gives you a list of every mob currently alive in the world.

Each mob has a unique ID - this returns all of them in an array.

Use for (let mobId of mobs) to loop through and do something to each mob.

Great for clearing all mobs, counting them, or applying effects to all of them.

Simple counter - how many mobs are currently in the world.

Faster than getting all IDs if you just need the count.

Useful for wave systems: "Wave complete when mob count reaches 0".

A herd makes mobs move together as a group, like a pack.

First create a herd ID, then spawn mobs with that herd ID.

All mobs with the same herd ID will follow each other and move together.

Great for making groups of animals or coordinated enemy packs.

This changes ONE specific mob's settings. You need the mob's ID from attemptSpawnMob.

Format: setMobSetting(mobId, "settingName", value)

Common settings:

"walkingSpeedMultiplier" - Walking speed multiplier (1.0 = normal, 2.0 = double speed)

"runningSpeedMultiplier" - Running speed multiplier

"attackDamage" - How much damage the mob deals per hit

"maxHealth" - Maximum health

"initialHealth" - Starting health (set this when spawning)

"attackRadius" - How close mob needs to be to attack

"chaseRadius" - How far mob will chase players

This reads a mob's current setting value.

Useful for checking mob health, seeing if it can attack, etc.

Returns the value of that setting for that specific mob.

This changes the DEFAULT for a mob type - affects ALL future spawns of that type.

Format: setDefaultMobSetting("MobType", "settingName", value)

Example: setDefaultMobSetting("Draugr Zombie", "walkingSpeedMultiplier", 2.0) makes ALL future Draugr Zombies twice as fast.

This does NOT affect mobs that are already spawned - only new ones.

Great for difficulty modes or making all mobs of a type behave differently.

This reads what the default setting is for a mob type.

Useful for checking current defaults or resetting to original values.

Returns the default value that new mobs of that type will have.