xiaokun/netease-modsdk-wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

搬运一批Bedrock wiki内容，完善翻译

Browse Source
This commit is contained in:
boybook
2025-03-20 00:13:44 +08:00
parent ead7392a76
commit 4896c1a4f2
163 changed files with 33930 additions and 1464 deletions
Download Patch File Download Diff File Expand all files Collapse all files

218
docs/wiki/meta/addon-performance.md Normal file
View File

@@ -0,0 +1,218 @@
---
title: Addon Performance
mentions:
- SirLich
- Joelant05
- MedicalJewel105
- TheItsNameless
- SmokeyStack
---
::: warning
This page was compiled primarily using community feedback from multiple sources. As a result, some information may be generalized, subjective, or conflicting. Always use your own best judgment when optimizing your addons. This page is not a substitute for testing your addon on a wide range of devices.
:::
Performance in addons is crucial, as the most technically fantastic addon is mainly useless if the majority of the player base cannot experience it. When developing addons, it should always be considered that many Bedrock players will be experiencing your addon on a significantly lower power device than you are developing on. This is especially true for mobile users. Therefore, addons should be developed with performance in mind and tested for performance on lower-end devices when possible.
This guide is a non-exhaustive list of specific performance considerations separated by the various subsystems of Bedrock Edition. No single point should be taken as a hard and fast rule. Instead, these performance considerations should help you to recognize potential areas for improvement.
## Biomes and Features
### Biomes
- The biome system is generally efficient
- Large values for heightmaps are usually handled gracefully
- The component `climate` creates large particle storms
### Features
- Biomes generally cause less lag than feature generation.
- Hundreds of iterations per chunk of a multi-block feature have been achieved at a low-performance cost.
- Thousands of iterations per chunk of multi-block features negatively impact gameplay.
- Hundreds of thousands of iterations per chunk of a single-block feature have been achieved at a low-performance cost.
- Thousands of instances of features *per chunk* comes at little cost.
- Tens of thousands of feature instances *per chunk* yields a noticeable impact on chunk loading.
- Hundreds of thousands of instances of features *per chunk* slows chunk loading to an unbearable crawl.
## Blocks
### Materials
- The minimum needed material type with regards to rendering should always be utilized
> `alpha_blend` performance is worse than `alpha_test`, which is worse than `opaque`
### Quantity and Type
- Flowing liquids should be avoided and minimized
### Updates
- Block updates should be minimized
## Commands
### Quantity and Type
- Minimize the number of commands run per tick
> `/effect` and `/gamemode` run every tick are avoidable and have a significant performance impact
- Large clones, fills and structure loads during runtime should be avoided
> Breaking these more extensive operations into multiple commands distributed over multiple ticks will avoid lag spikes, consider using structure loading animations
### Selectors
- Care should be taken to ensure a function is not executed on too many entities, and therefore too many times
- Executing a scoreboard command outweighs the cost of running an entity selector multiple times
- Using c=1 to ensure the selector stops when it finds one entity may improve performance
- When executing multiple commands with the same selector, use a function instead to avoid repeatedly resolving the same selector
### Tags vs. Scoreboards
- Scoreboards perform better at a large scale than tags
## Entities
- Entities generally have one of the most significant performance impacts by subsystem and thus should be minimized where possible
### Components
- Pathfinding on flying mobs has a significant performance cost
- Flying mobs in general encounter performance problems
> Faking flying mobs via animation should be considered if possible
### Dummy Entities
- Dummy entities generally have equal performance impact to proper entities, except when excluding heavy components like pathfinding
### Geometry
#### Bones
- No performance impact has been observed regarding bone count
#### Elements
- Element count is not generally an issue, except in extreme cases when thousands of elements are reached
### Materials
- The minimum material required to achieve the desired effect should always be used
- When in doubt, refer to the material definition files to get an idea of the costs of various materials, taking the material inheritance system into account
### Quantity
- Loaded entities at any given time should be minimized
> Below 30 is optimal
## Lighting
### Map Considerations
- Hollow areas will cause lag due to lighting calculations even if you don't see them
> Avoid this by filling in unused enclosed areas
- Keeping the map set to day or night will avoid lighting recalculation
### Sources
- Bedrock lighting is calculated dynamically, meaning different light sources have different performance costs
> Light blocks are the most performant because they lack particles, rendering, and particular state logic
> Torches are a minor performance issue because they emit particles, render, and have particular state logic dependent on what block they connect to
> Custom light blocks with minimal components are a reasonable compromise between performance and aesthetics
#### Comparison Table
| Light Source | Score | Redstone Updates | Animted Texture | Light Updates | Tick Updates | Particles | Renders |
| ---------------: | :---: | :--------------: | :-------------: | :-----------: | :----------: | :-------: | :-----: |
| Light Blocks | 1 | False | False | True | False | False | False |
| Lanterns | 4 | False | True | True | True | False | True |
| Custom Blocks | 2 | False | False | True | False | False | True |
| Mushrooms | 3 | False | False | True | True | False | True |
| Redstone Lamps | 3 | True | False | True | False | False | True |
| Glowstone | 3 | True | False | True | True | False | True |
| Sea Lanterns | 4 | False | True | True | True | False | True |
| Torches | 4 | False | False | True | True | True | True |
| Redstone Torches | 5 | True | False | True | True | True | True |
## Molang
### Recursion
- Minimize use of recursion when possible
- Intense nested loop structures will cause performance issues
- Use break to escape loops when possible
### Structs
- Avoid making structs too deep, as there is a performance cost with each layer
### Variables
- Use temp variables when possible to minimize variables loaded in memory
- Consider how often variables are calculated based on script type
## Textures
### texture_list.json
- Tons of textures badly affect game performance. Create a [`texture_list.json`](/concepts/textures-list) file.
### Quantity
- No more than 3000 textures should be used
> This is due to limits imposed by Render Dragon
> Render Dragon has a 4096 texture quantity limit, and there are 800 vanilla textures as of 1.16
### Resolution
- The maximum texture resolution is 16384x16384
- The recommended maximum texture resolution is 4096x4096 to maintain compatibility with low-end devices
- Keep in mind that textures are atlased, and larger textures can mess with atlas generation on lower-end devices
- Only make textures as significant as needed to convey the detail needed at the needed distance
## Trades
Villager trades cause performance issues and even crashes on all devices at 60 trades or greater. Avoid tons of trades for one entity.
Your best bet to resolve this issue is to split your trades in half and move them to another villager or custom entity/npc, 30 trades is a good safe number from testing.
*probably JSON UI issues*
## Sounds
### Count
- Total registered sounds are reported to have an impact on performance
### Compression
- Sound compression is exceptionally beneficial to pack size
- This is especially noticeable on older and low power devices, such as the Switch
- The FMod simple API utilized by Bedrock decompresses all sounds into WAV before loading into RAM, meaning no CPU performance improvement in this respect
> If audio is streamed, this does not occur
### Streaming
- As general guidance, sounds over 500kb in size or 1 minute in length should be streamed
## Redstone
### Chunk Boundaries
- Crossing chunk boundaries with Redstone should be avoided
### Command Blocks
- When creating large command blockchains, stack vertically and in a single chunk
- Minimize command block use in favor of functions and behaviors where possible
## Ticking Areas
- Total chunks are of more significant concern than ticking areas
- Dynamic areas should be avoided unless necessary
- Best practice is to minimizing the ticking area to one chunk if possible
> All always-on Redstone should fit in this ticking chunk
- Unload ticking areas when they are no longer needed, testing via /testforblock
## Files
- Tons of files can badly affect game performance. Create a [`contents.json`](/concepts/contents) file.

3
docs/wiki/meta/index.md Normal file
View File

@@ -0,0 +1,3 @@
---
title: Meta
---

154
docs/wiki/meta/jq.md Normal file
View File

File diff suppressed because one or more lines are too long

167
docs/wiki/meta/style-guide.md Normal file
View File

@@ -0,0 +1,167 @@
---
title: Style Guide
mentions:
- SirLich
- solvedDev
- MedicalJewel105
- ChibiMango
---
This document will present the officially supported Bedrock-Wiki style guide for addon-creation. This guide aims to promote best practices while creating addons and create a consistent format for everyone to follow.
:::tip
The style guide is a living, breathing document, which will evolve as addon-creation evolves. Please get in touch if you think something needs to be updated or changed!
:::
## Folder Structure
- No spaces in your file paths. `use_underscores`.
- No `CAPITALS` in your identifiers, file names, or folder names.
- The total character length of any path must not exceed 80 characters (console limitation).
- Content folders should use consistent pluralization: Don't mix and match.
## Identifiers
Do not use identifiers that begin with a number, and especially don't use an identifier that is _only_ a number. This applies to entities, component_groups, events, and anything else that takes a `namespace:name` pair.
## File and Folder names
| Concept | Example Identifier |
| -------------------- | -------------------------- |
| Behavior Pack | dragons_BP |
| Resource Pack | dragons_RP |
| Geometry | dragon.geo.json |
| Animation | dragon.animation.json |
| Animation Controller | dragon.ac.json |
| RP Entity | dragon.ce.json |
| BP Entity | dragon.se.json |
| Item 1.16.100+ | dragon_tooth.item.json |
| BP Item | dragon_tooth.item.bp.json |
| RP Item | dragon_tooth.item.rp.json |
| Render Controller | dragon.rc.json |
| Loot Table | dragon.loot.json |
| Recipe | dragon_saddle.recipe.json |
| Spawn Rules | dragon.spawn.json |
| Trade Table | dragon.trade.json |
| Particles | dragon_magic.particle.json |
| Texture | dragon.png |
| Gametest | dragonTest.js |
## Namespaces
A suitable namespace should be unique to you or your team. Something like `mob` or `cars` or `content` or `custom` would be a **bad** namespace since another developer might come up with the same namespace as you.
`minecraft` and `minecon` are reserved. Don't use these.
For personal projects, use a convenient version of your player name, and for team projects, use a suitable version of your team name.
When multiple developers work on a project together, the namespace should always be shared. If credit is required, use sub-indexing: `minetite.sirlich:dragon`
Where to use name-spaces:
- entities
- particles
- component-groups
- events
When not to use namespaces:
- do not include your namespace in any folder path or file-name
## Sub-indexing
Sub indexing is the use of `.` to separate chained concepts. Sub-indexing should go in descending order from big to small:
✔️ `animation.controller.dragon.flying.taking_off`
❌ `animation.controller.dragon_take_off_flying`
When using sub-indexing, use `_` as space, not another `.`.
✔️ `animation.controller.dragon.flying.taking_off`
❌ `animation.controller.dragon.flying.taking.off`
You can use sub-indexing in your entities:
`sirlich:dragon.drake`
## Groups and Events should complement each other
| Group | Event |
| ------------ | ---------------------- |
| sirlich:wild | ✔️ sirlich:become_wild |
| sirlich:wild | ❌ sirlich:wild |
| sirlich:tame | ✔️ sirlich:on_tame |
| sirlich:tame | ❌ sirlich:tame |
## Short-Names should be Generic
Short-names are file-specific identifiers, which are used to map between an identifier and a pretty name. They are handy because they allow us to re-use animation controllers and render controllers. For this reason, your short-names should be generic.
✔️ `"sit": "animation.dragon.sit"`
❌ `"dragon_sitting": "animation.dragon.sit"`
When we make short-names of this form, we can use a generic "sit" animation controller for all of them since we can use the `sit` short-name to play the sit animation.
## Functions should be nested
You can put functions in folders to achieve this.
✔️ `function teleport/zone/hell`
❌ `function teleport_hellzone`
## Group animations files when possible
Example:
<CodeHeader></CodeHeader>
```json
{
"format_version": "1.8.0",
"animations": {
"animation.dragon.sit": {...},
"animation.dragon.fly": {...},
"animation.dragon.roar": {...},
}
}
```
## Split textures by path, not name
✔️ `textures/dragon/red`
❌ `textures/dragon_red_skin`
✔️ `textures/npc/dragon_hunter/archer`
❌ `textures npc/dragon_hunter_archer`
## .lang File Comments
Comments intended for the localizer should always be in-line, in the following format:
`the.key=The string<\t>## Comment, intended for the one localizing.`
`<\t>` represents a tab-character.
Own-line comments can be used for organizational purposes but should not store localization-critical information.
## Acronyms when discussing
| Acronym | Concept |
| ------- | ---------------------------------- |
| BP | Behavior Pack |
| RP | Resource pack |
| VRP | Vanilla Resource Pack |
| VBP | Vanilla Behavior Pack |
| AC | Animation Controller |
| RPAC | Resource Pack Animation Controller |
| BPAC | Behavior Pack Animation Controller |
| BB | Blockbench |
| BDS | Bedrock Dedicated Server |
| FPV | First Person View |
| RD | Render Dragon |
| VSCode | Visual Studio Code |

157
docs/wiki/meta/useful-links.md Normal file
View File

@@ -0,0 +1,157 @@
---
title: Useful Links
mentions:
- SirLich
- MedicalJewel105
- MetalManiacMc
- rebrainertv
- jasonjgardner
- MADLAD3718
- cda94581
- Luthorius
- NhanAZ
- AndreasHGK
- mark-wiemer
- Noruaric
- JaylyDev
- zheaEvyline
---
There is loads of helpful information about Bedrock Development online, but sometimes it is hard to find! We will do our best to keep this list up to date as we continue to find useful content.
Important links have a ⭐.
## Discord Links
- ⭐ [Bedrock Add-Ons](https://discord.gg/46JUdQb)
- ⭐ [Bedrock OSS](https://discord.gg/XjV87YN)
- ⭐ [Minecraft](https://discord.gg/minecraft)
- ⭐ [Blockbench](http://discord.gg/fZQbxbg)
- ⭐ [bridge.](https://discord.gg/NxKuWuA)
- ⭐ [Minecraft Commands](https://discord.gg/QAFXFtZ)
- [Snowstorm](https://discord.gg/W9d78Z8AvM)
- [Amulet & MCEdit](https://discord.gg/dSnwqQf)
- [Amethyst](https://discord.gg/Cxrj9UXnDB)
- [Artists Refuge](https://discord.gg/aVXbPCdRr3)
- [BDSX](https://discord.gg/8UhbaDwFMh)
- [Bedrock Commands](https://discord.gg/vV29d6rJcj)
- [Dragonfly Server Software](https://discord.gg/U4kFWHhTNR)
- [MCBE Realm Hub](https://discord.gg/pCkYPvSGC8)
- [MCBE Utilities](https://discord.gg/9S4aKh684W)
- [MCPECore](https://discord.com/invite/N3e6exUQGs)
- [Minecraft Education](https://discord.gg/7fSQBdx)
- [Minecraft RTX](http://discord.gg/vNWc3Hh)
- [Mojang Bug Tracker](https://discord.gg/rpCyfKV)
## Software (installed)
- ⭐ [Blockbench: A boxy 3D model editor](https://blockbench.net/)
- ⭐ [bridge. Addon Editor](https://bridge-core.github.io/)
- ⭐ [VSCode Editor](https://code.visualstudio.com/)
- ⭐ [Regolith](https://github.com/Bedrock-OSS/regolith)
- [CoreCoder [Code Editor]](https://hanprog.itch.io/core-coder)
- [Feature Rule Generator v2 (paid version)](https://machine-builder.itch.io/frg-v2)
- [Feature Rule Generator v2 (free version)](https://drive.google.com/file/d/1rwQTtzgpWiqCS9ecO_j-qcxjdQvWSXgi/view)
- [Add-on JSON Generator (paid)](https://kaifireborn.itch.io/add-on-json-generator)
- [NBT Editor](https://www.universalminecrafteditor.com/)
- [World Converter (paid)](https://www.universalminecraftconverter.com/download)
- [Chunker (World Converter)](https://chunker.app/)
- [NBT Studio](https://github.com/tryashtar/nbt-studio)
- [BedrockLauncher (Bedrock version switcher)](https://bedrocklauncher.github.io/)
- [ResourcePack Converter [App]](https://converter.bedrockhub.io)
- [BedrockConnect [App]](https://bedrockconnect.bedrockhub.io)
## Bedrock Tools Websites
- ⭐ [Snowstorm Particle Generator](https://jannisx11.github.io/snowstorm/)
- ⭐ [Loot Table Generator](https://bedrock-oss.github.io/bedrock-loot-gen/)
- [Apply Loot Tables to Structures](https://mcbe-essentials.github.io/structure-editor/loot-tabler)
- [Structure Editor](https://mcbe-essentials.github.io/structure-editor/)
- [Convert MCSTRUCTURE to MCFUNCTION](https://mcbe-essentials.github.io/structure-to-function/)
- [Crafting Recipe Generator](https://crafting.thedestruc7i0n.ca/)
- [Trade Table Generator](https://mcbe-essentials.github.io/trade-table-editor/)
- [World Packager](https://mcbe-essentials.github.io/world-packager/)
- [Manifest Generator](https://bedrock-manifest.web.app/)
- [Foxynotail Tools](https://www.foxynotail.com/tools/)
- [.lang File Generator](https://solveddev.github.io/AnyLanguage/)
- [behavior-builder (beta)](https://stirante.com/behavior/index)
- [controller-builder (beta)](https://stirante.com/controller/index)
- [MCPACK Generator](https://mcbe-essentials.github.io/instant-pack/)
- [Molang Grapher](https://jannisx11.github.io/molang-grapher/)
- [Molang Playground](https://bridge-core.github.io/molang-playground/)
- [Dialogue Generator](https://mcbe-essentials.github.io/dialogue-editor/)
- [Selector Generator](https://mcbe-essentials.github.io/selector-generator/)
- [Addon Obfuscator](https://tools.pixelpoly.co/obfuscator)
## Documentation
- ⭐ [bedrock.dev](https://bedrock.dev/)
- ⭐ [Minecraft Creator Portal](https://docs.microsoft.com/en-us/minecraft/creator/)
- ⭐ [Minecraft Community Wiki](https://minecraft.wiki)
- [Mcbehub](https://mcbehub.com/category/realmdocs)
- [Bedrock Texture Pack Template](https://github.com/Brennian/BedrockTexturesTemplate)
- [Documentation Graveyard (removed components)](https://gist.github.com/destruc7i0n/ea1a6a7f97f0986d9326c58246f96fa3)
### Getting Started With Your First Add-On
- [Getting Started with Add-On Development for Bedrock Edition](https://learn.microsoft.com/en-us/minecraft/creator/documents/gettingstarted): These guides show you exactly how to build your first resource pack and your first behavior pack from start to finish.
- [Molang: a Beginner's Guide](https://learn.microsoft.com/en-us/minecraft/creator/documents/molangbeginnersguide): Molang is a Minecraft programming language that can be useful for writing some advanced add-ons.
- [Introduction to the GameTest Framework](https://learn.microsoft.com/en-us/minecraft/creator/documents/gametestgettingstarted): This is the best way to test games, and it uses JavaScript, the most popular programming language in the world!
- [Build a gameplay experience with TypeScript](https://learn.microsoft.com/en-us/minecraft/creator/documents/scriptinggettingstarted): TypeScript is Microsoft's copy of JavaScript. Writing add-ons in TypeScript allows you to add any functionality you can imagine!
- [@minecraft/server Module](https://learn.microsoft.com/en-us/minecraft/creator/scriptapi/mojang-minecraft/mojang-minecraft): This module and the others near it are how we can access Minecraft values with our TypeScript code. It's technical, but a great resource.
- [List and summary of commands (Unofficial Minecraft wiki)](https://minecraft.wiki/w/Commands#List_and_summary_of_commands): Most add-ons will run some commands. This community-supported wiki is the best resource for learning each and every command.
## Sample Behavior & Resource Packs
These packs are maintained and published by Mojang.
- ⭐ [Vanilla Resource Pack](https://aka.ms/resourcepacktemplate)
- ⭐ [Vanilla Behavior Pack](https://aka.ms/behaviorpacktemplate)
- [Vanilla Resource Pack (BETA)](https://aka.ms/MinecraftBetaResources)
- [Vanilla Behavior Pack (BETA)](https://aka.ms/MinecraftBetaBehaviors)
- [Pack Archive (old versions)](https://bedrock.dev/packs)
These packs are published by the open-source community
- [wiki-addon](https://github.com/Bedrock-OSS/wiki-addon)
- [Enchantment Details](https://github.com/supercam19/EnchantmentDetails)
- [BC developer-packs](https://github.com/BedrockCommands/developer-packs)
## Scripting Resources
- [GameTests API Wrapper](https://github.com/notbeer/Framework-Wrapper)
- [GameTests Plugin-API-Starter-Pack](https://github.com/MajestikButter/Plugin-API-Starter-Pack)
- [Useful for Block Tags](https://mcpedl.com/debug-stick/)
## Raytracing Resources
- ⭐ [Ray Tracing and PBR Texturing guide](https://docs.microsoft.com/en-us/minecraft/creator/documents/rtxgettingstarted)
- ⭐ [Minecraft with Ray Tracing and Advanced Graphics FAQ](https://help.minecraft.net/hc/en-us/articles/4408865164173-Minecraft-with-Ray-Tracing-and-Advanced-Graphics-FAQ)
- [r/minecraftRTX Getting Started Guide](https://www.reddit.com/r/minecraftRTX/comments/iq3lkl/getting_startedhelpful_guidesresource_packs/)
- [RenderBender](https://github.com/SpeedyCodes/RenderBender)
- [RTX Presets](https://discord.com/channels/691547840463241267/919021996271108108)
- [`.texture_set.json` Adobe Substance 3D Painter plugin](https://github.com/jasonjgardner/painter-plugin-texture-set-json)
## Addon Marketplaces & Links
- ⭐ [Minecraft Marketplace](https://www.minecraft.net/en-us/catalog)
- ⭐ [MCPEDL](http://mcpedl.com/?cookie_check=1)
- ⭐ [Bucket of Crabs (Marketplace joblist)](https://www.bucketofcrabs.net/)
- [MCDLHub](https://mcdlhub.com/)
- [CubitosMC](https://www.cubitosmc.com/)
- [Modbay](https://modbay.org/)
- [Minecraft Marketplace Stats](https://mcmarketstats.miste.fr/globalStats/)
- [Minecraft Marketplace Partners](https://www.playthismap.com/partners)
## Other useful Links
- [UUID v4 Generator (online)](https://www.uuidgenerator.net/version4)
- [Minecraft Marketplace partner Twitter list](https://twitter.com/i/lists/1191945551853629442?s=09)
- [Minecraft.net Official Add-ons page](https://www.minecraft.net/en-us/addons)
- [Run Bedrock on Linux](https://github.com/Element-0/ElementZero)
- [Linux Packaging Scripts](https://github.com/ChristopherHX/linux-packaging-scripts)
- [Block Models](https://blockmodels.com/)
- [Bedrock Addons Reddit](https://www.reddit.com/r/BedrockAddons/)
- [Windows 10 Non-renderdragon install](https://support.playhive.com/windows-10-installing-non-renderdragon-clients/)
- [Bedrock Edition Realm Protocol](https://github.com/NobUwU/BeRP)
- [Java & Bedrock Client](https://github.com/kennyvv/Alex)
- [Skin Pack Generator](https://github.com/MedicalJewel105/bedrock-skin-pack-generator)

63
docs/wiki/meta/using-schemas.md Normal file
View File

@@ -0,0 +1,63 @@
---
title: Using Schemas
mentions:
- SirLich
- MedicalJewel105
- 7dev7urandom
- KalmeMarq
---
A JSON schema gives you two things: validation to be sure that your JSON has the correct structure and (depending on editor support) IntelliSense to help you write your JSON correctly, to begin with. Schemas are nice because they give you instant feedback when you screw something up, but they can't catch everything.
JSON schemas are just JSON files themselves and don't do anything on their own. You can write your own or use somebody else's. There's a handful of schemas for Bedrock out there already. Since none of the schemas are "official" (that I know of), and since Bedrock is a moving target, there will probably be some inaccuracies in any schema that you find. So keep that in mind: sometimes the issue will be in your code, sometimes the schema may be wrong. If you find a wrong schema, consider improving it and giving the author a pull request to our collective benefit.
To get the validation working, you'll need a validator. You have many options here, including editor-specific options.
## Schemas
Many schemas exist, with many minor differences. Try out different schemas and see which one works best for you:
| Author | Supports | Note |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| [Assassin](https://github.com/aexer0e/bedrock-schema) | Behavior pack entity file | The original Schema this article was written for |
| [Tschrock's](https://github.com/bedrock-studio/bedrock-json-schemas/) | Manifest, Actor Animation Controller, Actor Animations, Actor Resource Definition, Render Controller, Geometry | |
| [stirante](https://github.com/stirante/bedrock-shader-schema/) | Shaders | |
| [KalmeMarq](https://github.com/KalmeMarq/Bugrock-JSON-UI-Schemas/) | JSON UI files (including _ui_defs.json and _global_variables.json) | |
## VSCode
To use this schema inside your JSON file in VSCode, simply add this line to your root object:
`"$schema": "https://aexer0e.github.io/bedrock-schema/"`
It should look like something like this:
<CodeHeader></CodeHeader>
```json
"format_version": "1.14.0",
"$schema": "https://aexer0e.github.io/bedrock-schema/"
```
### Adding Schema to Workspaces
If you want to utilize this schema to work with all of your files inside your Workspace, you can add it to your VS Code Workspace's settings.
To do this, make sure you're in your Workspace, then press `Ctrl+Shift+P` and type and select `>Preferences: Open Workspace Settings (JSON)`. After that, add this to the root object
<CodeHeader></CodeHeader>
```json
"settings": {
"json.schemas": [
{
"fileMatch": [
"*.json"
],
"url": "https://aexer0e.github.io/bedrock-schema/"
}
]
}
```
To test if it works, create a `.json` file, open an object, and see if you get the auto-completion options. (You can also press `Ctrl+Space` to force it into showing the available options.)

89
docs/wiki/meta/version-control.md Normal file
View File

@@ -0,0 +1,89 @@
---
title: Version Control
mentions:
- SirLich
- sermah
---
Version control is the concept of backing up your code iteratively, so you can roll back to specific versions as needed. Version control could be achieved at the most basic level by taking a `.zip` of your addon every day and uploading it to google drive. This isn't unreasonable, but it has three significant difficulties that proper VCS (version control systems) fix:
- It isn't easy to compare versions
- It isn't easy to _actually_ roll-back to a previous version
- It doesn't do anything to help in team-collaboration
This tutorial will teach the basics of a tool called `git`, and a free, online git storage service called `GitHub. Anyone may follow along, but you will receive the most benefit if you are working in a team environment or often lose your work because you forget to back up.
This tutorial will not be focusing directly on teaching `git` or `GitHub`, as outside knowledge sources better do this. The focus will be on setting up these tools for Minecraft once the basics have been learned.
## Git
`git` is a tool installed locally on your machine and allows you to version your files. You can `commit` changes to your files with a small message (ex. "Fixed issue where dragons couldn't fly after being tamed"), view the full change-list, and quickly jump back to specific changes.
Git is insanely powerful and the de-facto tool for all major programming projects. The most significant drawback for MC work is that it is _complicated_. Be patient while learning.
For a complete walkthrough of `git`, you should follow the following [git tutorial.](https://www.atlassian.com/git/tutorials/what-is-git)
## GitHub
GitHub is a version of your git project (`repository`) that is hosted online. This allows multiple people to work on the same project at the same time and collaborate. This is very helpful for map-making. By hosting on Github, you can also (optionally) make your code public, making it easier than ever to share your addons with the world.
For a complete walkthrough of using `Github`, you should follow this [github tutorial](https://guides.github.com/activities/hello-world/).
## Vocabulary Quiz
If you've gotten this far, hopefully, you have a GitHub account and are familiar with `git` in a small way. The following terms will be used in this tutorial. If you don't know them, please google :)
- repository
- branch
- commit
- github
- git
# Setting up Git
This assumes you are adding an _existing_ project to git. The steps are similar if you are starting from scratch.
## Structure
The big issue with using `git` for addons is that `git` generally works by encapsulating a _single_ folder and managing it. Of course, in Bedrock Addons, assets are spread across two folders: The `BP`, and `RP`. To get around this issue, we will place our repository outside of the `com.mojang` folder entirely and then use window `junctions` to "copy" the folders in.
There are many advantages of placing our project in a separate location:
- We can include additional files as needed, such as config files, tools, notes, .bb files, etc
- We can combine the RP and the BP into one repository
- All of our projects can be easily viewed in a simple location, instead of nested deep within com.mojang
## Creating a Git Repository
Pick a convenient location for your projects. I placed mine at `C:/sirlich/projects`. Make a new folder with the name of your map. We will be using `wiki` as the name of our mock project.
Right-click the folder, and click `"Open git Bash"`. If this option doesn't appear, you can open `git bash` from the start menu and navigate your project folder. If you don't have `git bash` installed, you should do so now.
Type: `git init`. This will create a blank repository in your project.
## Linking your existing RP and BP
The next step is to make the repository aware of your RP and BP folders. We will be using window symlink "junctions". When we create a junction, we essentially create a wormhole in our file system that will make it appear like your files are in two places at once. Deleting/editing/adding files is perfectly copied over.
Type: `mklink /J wiki_RP "C:/path/to/RP/in/com/mojang"`
Type: `mklink /J wiki_BP "C:/path/to/BP/in/com/mojang"`
When you are finished, you should see `wiki_RP` and `wiki_BP` in your project folder, containing all your assets, existing files, etc.
You can now push this repository to `github`, following the tutorial above.
## Extra Files
Because we created our repository based on symlinks, we can add anything we like into the project folder without worrying about breaking the com.mojang folder. I like to track `.bb` files, cover-art files (`.kra` etc.).
You can also add notes, video files, or anything else you want to track.
## Working with your VCS
The main things to remember about working with VCS:
- Always `pull` before starting work
- Commit and `push` often
- Always `push` before stopping work
- If you screw up your files super bad, you can always reset to the last working version. If you commit/push often, hopefully, this wasn't too long ago.
- Always, and I mean `always` make good commit messages. It's vital when you have to roll back.