Skip to content

Instantly share code, notes, and snippets.

View dktapps's full-sized avatar

Dylan T. dktapps

View GitHub Profile
@alvin0319
alvin0319 / specifications.md
Created February 7, 2022 14:05
Specifications and explanations for implementing custom items on the server
@Tomcc
Tomcc / client_blob_cache.md
Last active April 9, 2024 08:46
A description of the new Client Cache for server developers

Client Blob Cache

What's the Client Blob Cache

The Client Blob Cache is a new Bedrock optimization - it allows blocks and biomes to be cached on Clients to avoid resending identical chunks over and over. Chunks and biomes make up the vast majority of network traffic in a lot of common cases (eg. login, teleport or dimension switches) but at the same time, they rarely change. Allowing the Client to reuse chunks it has seen in the past can save a ton of traffic and latency!

The Client Cache is a Content Addressed Storage (a bit like git) that stores Blobs and retrieves them based on their full hashes (BlobIds). This means that the cache doesn't actually know about Chunks - in the future, we might start using it for more types of data, like skins or data driven entities.

A nice thing we get from the CAS approach is that the cache is persistent: returning players will be able to reuse content that was sent them in previous sessions or even previous sessions in different servers as long as tha

@Tomcc
Tomcc / blockstate_protocol.md
Last active April 9, 2024 08:42
Block Changes in Beta 1.2.13

Block Storage & Network Protocol Changes

Paletted chunks & removing BlockIDs brings a few big changes to how blocks are represented. In Bedrock, Blocks used to be represented by their 8 bit ID and 4 bit data; this means that we can only represent 256 blocks and 16 variants for each block. As it happens we ran out of IDs in Update Aquatic, so we had to do something about it :)

After this change, we can represent infinite types of Blocks and infinite BlockStates, just like in Java. BlockStates are what is sent over the network as they are roughly equivalent to the old ID+data information, eg. they're all the information attached to a block.

BlockStates are serialized in two ways:

PersistentID: a PersistentID is a NBT tag containing the BlockState name and its variant number; for example

@SOF3
SOF3 / world edit proposal.md
Last active July 21, 2017 07:03
Project Proposal for a world edit plugin

Project Proposal for a World Edit Plugin

This proposal describes a world edit plugin largely based on WorldEditArt's originally-intended features, along with some new ideas.

Plugin Name

This plugin will inherit the development of the WorldEditArt project and bring it to the Epsilon phase (WorldEditArt Epsilon).

About Social Stuff

Owner and Developers

This plugin be continued in the LegendOfMCPE/WorldEditArt repository.

@falkirks
falkirks / SpoonDetector.php
Last active June 17, 2019 21:11
SpoonDetector
<?php
use pocketmine\plugin\PluginBase;
use pocketmine\Server;
/**
* This class is deliberately meant to be silly
* Class SpoonDetector
*/
class SpoonDetector{
42 f1 ff ff ff 9f 34 06 00 01 10 32 56 00 ff ff Bñÿÿÿ?4....2V.ÿÿ
ff ff fe 01 80 02 02 00 00 00 00 00 00 00 00 00 ÿÿþ.?...........
00 00 00 00 00 00 00 00 00 00 83 d1 ba fa 0f 00 ..........?Ѻú..
83 d1 ba fa 0f 00 83 d1 ba fa 0f 83 d1 ba fa 0f ?Ѻú..?Ѻú.?Ѻú.
83 d1 ba fa 0f 83 d1 ba fa 0f 83 d1 ba fa 0f 83 ?Ѻú.?Ѻú.?Ѻú.?
d1 ba fa 0f 83 d1 ba fa 0f 83 d1 ba fa 0f 83 d1 Ѻú.?Ѻú.?Ѻú.?Ñ
ba fa 0f 83 d1 ba fa 0f 83 d1 ba fa 0f 83 d1 ba ºú.?Ѻú.?Ѻú.?Ѻ
fa 0f 83 d1 ba fa 0f 90 a1 c2 fc 0f dc 81 80 f8 ú.?Ѻú.¡Âü.܁?ø
0f 90 a1 c2 fc 0f 90 a1 c2 fc 0f 83 d1 ba fa 0f .¡Âü.¡Âü.?Ѻú.
90 a1 c2 fc 0f 90 a1 c2 fc 0f dc 81 80 f8 0f c3 ¡Âü.¡Âü.܁?ø.Ã
// To subscribe to an event, pass this JSON text to the client through the WebSocket:
{
"body": {
"eventName": "NameOfEvent" // Replace with an event name listed below
},
"header": {
"requestId": "xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx", // UUID
"messagePurpose": "subscribe",
"version": 1, // Protocol version (currently 1 as-of 1.0.2)
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - > Receive: 14 (0x0e): McpeAddEntity
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - McpeAddEntity Entity ID: -51539607504
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - McpeAddEntity Runtime Entity ID: 56
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Entity Type: 2869 - 0xb35
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Entity Family: 11 - 0x0b
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Entity Type ID: 53 - 0x35 EnderDragon
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - X: 57.99719
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Y: 4.06
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Z: 9.940071
2016-11-12 13:48:08,026 DEBUG MiNET.Client.MiNetClient - Yaw: 0
Metadata id Object Description Type Checked
1 Wolf Tail angle int
Boat Health int
Minecart Health int
2 Entity Variant int 👍
FallingBlock fall damage int 👍
Slime size int 👍
3 Entity Color (for sheep in particular) byte 👍
4 Entity name string 👍
@NiclasOlofsson
NiclasOlofsson / helpcommand.js
Created October 29, 2016 16:56
FULL COMMAND /help EXAMPLE WITH VANILLA
{
"commandName": "help",
"commandOverload": "byPage",
"unkown1": 0,
"unkown2": 0,
"unkown4": false,
"unkown5": -1,
"commandJson": "null\n",
"unkown6": "null\n",
"unkown7": 0,