Since MCP is taking forever to update and I have free time again... I have been working on Biome Inheritance. When implementing these fun features it is very easy for me to get in the zone and start adding sub-features that I think will be fun to implement but they can end up being not so useful to the actual users; you guys! So with that said, I would like some input on what I have so far and what I plan on doing because I want this feature to be solid and useful when it is released! So, without rambling too much, here's what I have:
Current State of Work
Basic biome inheritance is working and can be used by simply filling out the
BiomeExtends: section of the BiomeConfig with a biome name.
(These features can be tested by getting a dev build from the build server, this link gives SUPER unstable versions so never run these on a live server, and always backup your worlds and configs)
When a biome inherits another, the child properties are read from the file and then any remaining empty settings are filled in by the parent, so something as simple as a two line child like:
will produce a copy of the TaigaHills biome with the BiomeSize changed to 5. Pretty simple right?
Additionally, during the development process there were troubles inheriting Resources so I added a setting for myself to disable resource inheritance temporarily. I have since solved these Resource-based troubles but I felt that this disable setting might be found useful by some of you. When
DoResourceInheritance(false) is placed anywhere within a BiomeConfig, Resource inheritance will be shut off. If you do this, you MUST specify the desired Resources in the child config or no resources will be present in that biome.
1.) Basic Inheritance Variables (i.e.
BiomeSize: Inherited + 1, will take the parent value and add 1): Mostly Done
2.) More Intelligent implementation. Additionally, something like the following will also work when i'm done: In Progress
GroundBlock: Inherited + 0:2, will add 2 to the data portion of a block
SkyColor: Inherited + 0x000A0A, if parent is
0x05FFA7 the child will evaluate to
0x05FFB1, notice green's FF didn't overflow into red...
RiverBiome: Inherited + M+, if parent is River the child will evaluate to RiverM+
RiverHeightControl: 0.0, I!+10.0, 0.0, I! , 25.0, I!-45.0, ... will become
RiverHeightControl: 0.0, 160.0, 0.0, 17.5, 25.0, -5.0, ... when the parent is
RiverHeightControl: 100.0, 150.0, 200.0, 17.5, 0.0, 40, ...
ReplacedBlocks: (1,57),(2,110,112,127) from the wiki is the parent, then the child
ReplacedBlocks: (1,I!+0:2),(2,110,I!+15,I!+15) will evaluate to
ReplacedBlocks: (1,57:2),(2,110,127,142), granted diamond blocks don't have a data value like that... but you get the gist.
- I will add multiplications in at a later date if it is highly requested, for now I'm just going to have additions and subtractions.
3.) Inheritance WriteMode. When you write a biome that inherits another, I feel like your goals are two-fold; 1.) Save yourself time from writing configs 2.) Small, easy to maintain, child biomes. Without changing the way child biomes are currently written back to file, you would write a tiny biome config like the two-liner above, and if the
WriteAll setting is set in your WorldConfig, the child biome will turn into a full copy of the parent with the changes in the child when TC is done reading your config. That's no good as it defeats both the basic purposes for having inheritance!
I would like to do something to the effect of an inheritance
WriteMode in your WorldConfig where you have a few options like: 1.)
WriteChildSettings (Write back only the settings that are present in the child config) 2.)
WriteDisable (Inheritance Biomes are not written back to file) 3.)
WriteToInheritedFile (This setting would write the fully evaluated biome config to a new file named .inherited)
I think the last setting will be most useful when you are testing new biomes, that way you see the final product of inheritance but the child config remains unchanged for easy editing. The next problem I see is when people have some large number n biomeConfigs that are inheriting others, there will be n files generated from those with the *.inherited extension. Perhaps an additional setting listing the names of the biomes you want to be treated this way? I'm not sure this is the best solution. Another idea is to have the WriteMode for inheritance be in each biomeConfig. That way each child biome can be individually handled as you like. This then brings up the topic of: Why not just copy the current WorldConfig WriteMode into the BiomeConfig file so that ALL biomeConfigs can be individually handled? The default for the BiomeConfig WriteMode could then be UseWorld so that changes in WorldConfig still yield a global change unless someone specifies otherwise. This sounds like it could be quite useful, especially as our biome cap is now increasing to 1024 or more thanks to Khoorn's VirtualBiomes feature.
As you can see there are a lot of things to consider, especially at the last part. Let me know what you think
Thanks for reading!
-- Timethor --