Files
netease-modsdk-wiki/docs/wiki/meta/style-guide.md
2025-03-20 00:13:44 +08:00

168 lines
5.8 KiB
Markdown

---
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 |