alexander.nutz/barecopper
1
0
Fork 0
forked from EXTERNAL/bareiron
Code Pull Requests Activity

document important configuration options for real servers

Browse Source
This commit is contained in:
p2r3
2025-09-12 15:09:36 +03:00
parent ba11d121cf
commit 46a808152a
1 changed files with 8 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@@ -15,14 +15,20 @@ For microcontrollers, see the section on **compilation** below.
Before compiling, you'll need to dump registry data from a vanilla Minecraft server. Create a folder called `notchian` here, and put a Minecraft server JAR in it. Then, follow [this guide](https://minecraft.wiki/w/Minecraft_Wiki:Projects/wiki.vg_merge/Data_Generators) to dump all of the registries. Finally, run `build_registries.js` with `node`, `bun`, or `deno`.
- To target Linux, install `gcc` and run `build.sh`
- To target an ESP variant, set up a PlatformIO project and clone this repository on top of it. Set your WiFi credentials in `include/globals.h`.
- To target an ESP variant, set up a PlatformIO project and clone this repository on top of it. See **Configuration** below for further steps.
- There's currently no streamlined build process for Windows. Contributions in this area are welcome!
## Configuration
Configuring the server requires compiling it from its source code (see section above).
Configuring the server requires compiling it from its source code as described in the section above.
Most user-friendly configuration options are available in `include/globals.h`, including WiFi credentials for embedded setups. Some other details, like the MOTD or starting time of day, can be found in `src/globals.c`. For everything else, you'll have to dig through the code.
Here's a summary of some of the more important yet less trivial options for those who plan to use this on a real microcontroller with real players:
- Depending on the player count, the performance of the MCU, and the bandwidth of your network, player position broadcasting could potentially throttle your connection. If you find this to be the case, try commenting out `BROADCAST_ALL_MOVEMENT` and `SCALE_MOVEMENT_UPDATES_TO_PLAYER_COUNT`. This will tie movement to the tickrate. If this change makes movement too choppy, you can decrease `TIME_BETWEEN_TICKS` at the cost of more compute.
- If you experience crashes or instability related to chests or water, those features can be disabled with `ALLOW_CHESTS` and `DO_FLUID_FLOW`, respectively.
- If you find frequent repeated chunk generation to choke the server, increasing `VISITED_HISTORY` might help. There isn't _that_ much of a memory footprint for this - increasing it to `64` for example would only take up 240 extra bytes.
## Non-volatile storage (optional)
This section applies to those who target ESP variants and wish to persist world data after a shutdown. *This is not necessary on PC platforms*, as world and player data is written to `world.bin` by default.