misode

Generating pseudo random numbers

You need to run some commands once (or on every /reload).

scoreboard objectives add random dummy
execute unless score seed random matches -2147483648.. run scoreboard players set seed random 731031
scoreboard players set mult random 1664525
scoreboard players set incr random 1013904223
scoreboard players set #16 random 16

misode

Creating custom items with a datapack and resourcepack

Creating the texture

misode

Orbis 1.13 Technical Details

Orbis works by scanning chunks and performing actions based on certain features of that chunk, like its biome, terrain height and specific blocks in the world. All conditions are based on world generation to make sure everything is seed deterministic.

orbis:main

Every 16 ticks, Orbis does a few things.

• If a player with the gm4_orbis_active tag is in a chunk that has bedrock at y=0, it spawns a marker for that chunk, if there wasn't one already.
• For every player with the gm4_orbis_active tag, it generates the closest chunk that hasn't been generated yet. This calls the orbis:chunk/generate function.
• Kill every chunk that has been generated, but only if all four adjacent chunks have also been generated. This is because chunks use the biome of adjacent chunks to determine the final biome decision.

orbis:chunk/scan

misode

Loot syntax

/loot can be separated into two major parts, target and source. Those two parts follow each other in the command. In snapshots prior to 18w45a, this command was named /drop

loot <target> <source>

Last updated: 18w45a

Target

The target defines where to drop the items. It has several arguments. The first argument is the target type. It's one of these options: spawn, replace, insert and give.

misode

New Loot Table features in 1.14

This gist covers the changes to loot tables introduced in 18w43a, the first 1.14 snapshot. Check out this more in-depth loot table guide.

Last updated: 18w49a

Table of contents

• Loot table types
• Random integers
• Entry types
• New conditions

misode

The purpose of events is to have triggers without needing an advancement for it. This should go hand in hand with the current data driven files. We have been using advancements for a totally different reason than what they were intended for. And that's what we wanted to avoid from 1.13 onwards. A few advantages is they work for all entities, not only for players. They keep triggering, so you don't need to revoke the advancement.

Events are json files put in namespace/data/events Its structure is very similar to the current advancement structure of a criteria.

Event structure

This event would run namespace:foo for every zombie that hurts a player in a plains biome

{
  "event": {