Code Documentation - Team-RTG/Realistic-Terrain-Generation GitHub Wiki

Biome decoration

Welcome to the new & improved (yet still not ideal & still not finished) biome decoration system!

I'm your host, WhichOnesPink, and I'm going to explain how the new system works. In just a few short minutes, you'll be on your way to decorating the biome of your dreams!

But first, let me give you a bit of background on how the old system worked because the new system still works pretty much the same way - it's just easier to manage.

The old system

Right, so basically... the old decoration system's default behaviour was to let the base biome handle most of the aesthetic decorations (trees, flowers, grass, etc). For biomes that wanted some extra special RTG flavour, you had to override the biome's rDecorate() method and procedurally decorate the biome yourself (whilst also remembering to enable/disable ore generation, depending on whether or not you let the base biome handle some of the decoration).

Whilst this approach worked well back when it was RWG and only a dozen or so custom biomes managed by one person, it is not very suitable for RTG and its 350+ biomes managed by multiple developers.

The new system

As mentioned earlier, the new decoration system still works the same way, but now instead of procedurally decorating the biome yourself, it's simply a matter of adding the relevant deco objects to the realistic biome and configuring them as necessary.

However, there are a few things you'll need to keep in mind when decorating biomes:

Order matters

Even though we're not writing procedural code, the order in which you add deco objects to the biomes is extremely important. Why? Because every time you add a decoration to a biome, there is less real estate for the other decorations to generate. For example, if the first decoration you add is a high frequency of cobblestone boulders, all subsequent decorations would not be able to generate where the boulders were placed. So a good general rule is to start with the most aesthetically important decoration (usually trees) and working your way down to the least aesthetically important decoration (usually grass or flowers).

It's like Photoshop

If you've ever used Photoshop (or GIMP, or any other image manipulation software), then you're familiar with the concept of layers. Well, decorations in RTG are just like layers in Photoshop. To get a better understanding of this, try commenting out all but the first deco object in a biome and see what it looks like in-game. Then close down Minecraft, enable the next deco object and take another look. That's all we're doing: stacking decorations on top of each other like layers in Photoshop.

Using some Deco settings disables others

There are some deco objects that contain multiple settings to achieve different effects of the same overall theme. For example, sometimes you want to loop through tree gen based on the 'strength' variable, and other times you want to loop based on some noise calculation. If one is used, the other is ignored, and so are any other settings related to the ignored setting.

Trees are complicated in RTG

In retrospect, we probably should've refactored and standardised RTG's tree system before the decoration system because not only are there a lot of individual trees, but there's also a lot of vanilla 'tree collections' (like WorldGenTrees or WorldGenForest) that get used as well. And not only that, but the circumstances under which the trees get generated vary a lot from biome to biome. The short-term solution to this is the TreeType enum in DecoTree. There are a few settings in there which should make re-use somewhat possible, but a lot of times, it will just be a case of adding another enum value to accommodate yet another set of tree-generating conditions.

Conclusion

The end.

##All things Porting

###IBlockState and Block/metadata In 1.8 Block and a byte metadata field have been replaced with IBlockState. Never use BlockState for anything basically. ####1.7 -> 1.8:

  1. Is there a meta value associated with the block? then it should DEFINATELY be IBlockState.
  2. Could there in theory be a meta value associated? then you should probably use IBlockState.
  3. The only place you are actually going to want to use Block, is if you are doing special calculations on the meta value (see VillageMaterials preserveMeta functionality), or when checking for a certain block, where metadata is irrelevant.

Byte values for blocks are about as illegal as it gets (Except in config files, until we may include a specific syntax for that) Also a few specifics:

  1. All Surface classes should use IBlockState for top/filler blocks and the like
  2. All features should use IBlockState in constructors and inside classes.

####1.8 -> 1.7 Most of the time you’re just going to want to split up IBlockState into a Block and a metadata byte value. However, in a few cases you may want to only get the block. (Pretty self explanitory, any case where you would not need the metadata).