BO4's are not placed based on seed, but rather plotted and generated as the world is being explored. This approach is intentionally different from vanilla and BO3 structures, so as to allow for different features. BO4 structures support fine control over placement and distribution and can blend in with terrain. Any number of BO4 structures can be spawned in a biome, and use collision detection so as not to overlap. Advanced branching features support structures of any shape or size, and allow for randomised structures that can shape to fit any available space.
BO4 creation[edit | edit source]
BO4's can be created via the /otg export command with the -bo4 flag, or can be converted from .schematic files. BO4's can be max 16x16 blocks per file, and can include Branch() tags to connect them to other BO4's. When an object larger than 16x16 is exported to BO4 or converted from .schematic, multiple BO4 files are created, with Branch() tags included to connect them.
A single master BO4 file acts as the start of the structure and its branching pattern. For example, "/otg export RuinedCity -bo4" for a 32x32 WorldEdit selection would create:
The master BO4 file contains settings that apply to the entire structure for placement, distribution, blending with terrain etc. Users can edit these settings to make the structure spawn as they like. The master BO4 does not contain any blocks or branches, these are stored in the BO4's in the accompanying folder, ending with C0R0, C0R1 etc. C0R0 indicates column 0 row 0, each of these BO4's has a Branch() that spawns the BO4 in the next row or column. This is a simple pattern used when exporting large objects, users can also create their own branches and branching patterns. The master BO4 does not contain any blocks or branches, but inherits them from the C0R0 BO4, so users can re-export a structure and override all files in the accompanying folder to update blocks, while preserving their master BO4 to keep their spawning settings.
Branching[edit | edit source]
Exported or converted BO4's use a static branching pattern, meaning their branches always spawn in the same configuration with a 100% success rate. This is useful for spawning large structures that must either spawn in their entirety, or not at all. Static BO4's are easy to use and can be added to a BiomeConfig's resourcequeue after configuring placement, distribution and blending settings in the master BO4.
BO4's also provide features for creating randomised branching patterns, using collision detection and rollback mechanics to create branching patterns according to chance and available space. Randomised BO4's require manual editing of individual BO4's to configure Branches() and settings. Randomised branching mechanics are a complex subject and still under development, documentation will be written a.s.a.p. See the Dungeons preset for an example of what can be achieved (infinitely branching dungeons), ask us on the Discord for help making your own randomised BO4's.
Plotting / Placement[edit | edit source]
Unlike BO3's and vanilla structures, BO4's use collision detection to plot structures neatly inside biome borders and make sure none overlap. Instead of using rarity, BO4's use Frequency and BO3Groups/BO4Groups in the master BO4 file to define a minimum distance between each BO4 and each group of BO4's. This allows fine control over structure distribution. Unlike BO3's, BO4's cannot use block checks to determine spawn location eligibility, they can only check for biome, water vs land, or use height bounds. This is offset by the ability to use smoothing areas and replace blocks to biome-specific blocks, effectively allowing BO4's to make the terrain suit them.
BO4's allow any number of structures to be added to biomes. When multiple BO4 structures are configured for the same biome, OTG tries to plot the largest first, if it doesn't fit, it tries the next, and so on, until a structure is found that fits in the available space (or the end of the queue is reached). This means BO4's will fill available space as efficiently as possible, but their placement depends on the order chunks are generated in while exploring. In other words, when using the same world seed to generate multiple worlds, BO4's may appear in different places, depending on the order of chunk generation.
When adding a BO4 to the resourcequeue of a BiomeConfig:
- Use CustomStructure(BO4Name,100.0) to allow the structure to start here, or spawn branches here if it started in a neighbouring biome.
- Use CustomStructure(BO4Name,0.0) to forbid the structure from starting here, but allow it to spawn branches here if it started in a neighbouring biome.
- When a CustomStructure() is not present in the resourcequeue, the structure may not start or spawn any branch here.
Add as many CustomStructure() resources as you like to each BiomeConfig, but keep in mind that more structures has an impact on performance. Also, the more attempts that have to be made to plot certain structures, the more time plotting will take. So try to make sure structures have a good chance to fit and spawn in biomes you add them to, and don't add so many (large) structures that they'll just get in each other's way.
Blending / Smoothing[edit | edit source]
The master BO4 file can be used to configure terrain smoothing/blending settings for the entire structure, although settings can be overridden for individual branches. Smoothing areas can be configured that attach to structure edges and create a slope to surrounding terrain, blocks can be replaced to biome-specific blocks. See a BO4 file for settings and descriptions, a wiki article will be written a.s.a.p.
BO4Data[edit | edit source]
BO4Data are optimised files that are much smaller and faster to spawn than BO4 files, but they cannot be edited with a text editor. Before shipping a preset to users, use /otg exportbo4data to export any BO4's (or BO3's with IsOTGPlus:true) in the WorldObjects folder to BO4Data files. Make sure to ship only the BO4Data files and remove the BO4 files. If both a BO4 and BO4Data file are present with the same name, the BO4Data file is used.
Note: We'll look at adding things like sourceblocks in the future, and removing the 16x16 size/grid limitation.