Is it possible to add "inherit from biome" property into biome's config?
So current biome values should be identical to related except overriden here.

Actually, the benefot would be pretty big i think. for instance, the isle and border biomes would only need changed values in their config files, which would make configuration a breeze. From my point of view the initial configuration would be easier for not-experts (juch as me)

I'm sure the benefit will be great.

Would require a lot of work for only a small benefit.

What is with progress, guys :) ?
I have forked project and merged all trees into one and put some my changes but have a lot of errors during compiling =\ will try again :)

Currently, we're trying to prepare TC for Minecraft 1.7. I already wrote a program to change biome ids in an existing map and I rewrote some code of the default setting. @Timethor has improved error logging. @Wickth is looking into creative ways to solve biome id conflicts. After 1.7 is out, we must first try to get TC to run on that. After that, all features of 1.7 must be added to the default settings. We must also try to not break old configs.

That update will keep us busy for some time... Biome inheritance will get added sooner or later, but not now.

@Wickth @rutgerkok

Alright, I was thinking there should be a developer conversation before i/we start implementing this feature. Better here than the forum I think.

I'm thinking the most organized way of implementing this is to break the biome loading / manipulation code out into a Manager/Loader class... Then the WorldConfig class can just call it and it will do all the needed steps. Then the inheritance code can be added on after that is done. I'm not sure if it can be decoupled without creating a lot of mess though. I still need to take a much closer look at everything... Not sure if you guys have an opinion on this or a cleaner alternative?

For the actual algorithm, I'm thinking of letting all files be loaded first. Only then do we start finding parent configs and externally referenced variables for less file I/O.

Other questions to ponder:

• Max traversal for inheritance? (use the maxbiomes variable?)
• Max traversal for external references of config values like: otherConfigValue + constant? (Same as above? maybe 1/2 for both, 128 is pretty good I suppose...)
• Best way of avoiding infi-loops when parsing these types of things? TreeSet with the names of config file+settings that have already been visited?
• Do we want to convert the Default Biomes to inherit from a Base Biome? This is probably a question for later but it popped into my head... This could potentially help with the speculated "transition" biomes.
  Less on topic:
• In issue #74 , one of the points was that the OP didn't want the default biomes generating as files or at least to limit this, perhaps a solution is to have the default biomes be in a GlobalBiomes folder, or in a subfolder within the WorldBiomes so they are kind of out of the way? like /TC/worlds/world/BiomeConfigs/DefaultBiomes/
• Why do we have the CustomBiomes ArrayList in WorldConfig when we already have CustomBiomeIds with the same data. We could just use CustomBiomeIds.keySet()?

There should be a max traversal for inheritance and references in config files, otherwise TC might hang in an infinite loop. In my opinion, there is no need to do other checks for infinite loops.

Eventually, it seems like a good idea if for example JungleHills inherits from Jungle.

You can create a GlobalBiomes folder next to the GlobalObjects folder, which is empty by default. If a BiomeConfig is missing in the world/BiomeConfigs directory, TC goes hunting for it in the GlobalBiomes folder. If it doesn't exist there, the file is created in the world/BiomeConfigs directory.

About your last point: just refactor it so that only one of the two is needed. 😄 .

Ok first and main thing: after all we must have fast accessible classes with values for generation. Primitives is prefer for better performance.

About max traversal for inheritance i am agree with @rutgerkok

About Default Biomes and not used biomes from custom biomes list. Global folder is good idea yes. But dont forget we must load it anyway. Explain : we have old world with some lands generated with default generator - and this territories have some default biomes - we must hook custom trees here and visual things ( if clients have TC forge)

And remove file suffix "BiomeConfig", please =)

Can biome configs be serialized and sent to clients by net in resolved form (inheritance calculated)? Or it is already done in such way?

@rutgerkok @Wickth Sounds good, I agree with what both of you said :)

@SimSonic The "BiomeConfig" suffix is there so that TC and the end-user can determine if a file is a biome config w/o opening it. The only other way to do that is give the biome config files their own extension. i.e. Savana.bc or Savana.biome ... which I would consider if the guys don't have a problem with it... It would just be extra work for an aesthetics thing which is further down the list of things to get done.

@SimSonic @Timethor Good idea about getting rid of the "BiomeConfig" thing. It's really unneccessary clutter. I'd much rather prefer a *.bc or *.biome. My biome names are quite long so the removal of BiomeConfig would be great as it would make them more readable. (in OSX Finder, you get "Fore...omeConfig.txt" instead of the windows default: "ForestHills2Un...") You will agree, that in Win, i know a lot more about the file by looking at it than in OSX...if it didn't have the BiomeConfig added to the name, i'd see nearly the whole thing i suppose. :)

Anyway, i'm really happy that you decided to do something about the biome inheritance. :)

@Dilvish Haha, yea... I can def. see where that could get annoying in OSX. I'll work on adding that towards the end of implementing the biome inheritance feature so you'll get both when the feature release drops 😄

@rutgerkok @Wickth Why is it that we force the user to list the biomes they are using with the biome id in the world config? Is it not something that can be determined at runtime? i.e. load all the biome configs in the biomeConfigs folder and give each the next available biome id? The only reason I can think of for this is that you would want to have a given custom biome have the same id every time the map is saved or the plugin reloaded.

The reason I bring this up is that I was thinking, when the 1.7 update code arrives I am hoping there may be a change from byte to short for biome ids depending on how many biomes @Jeb_ plans on adding. Even if there isn't a change, when you get into the higher # of biomes it becomes cumbersome to list all of them. There has to be a better way of dynamically loading the biome configs w/o making the user deal with id's.

Yes, the biome ids need to be the same every time the map is loaded, otherwise the colors/mobs/weather will be messed up. Of course, for biomes that use ReplaceToBiomeName this is no problem, those can be given a random id.

Offtop: is anywhere biome setting that tells what block is the "main"; to change default stone. I have a lot of biomes in which I do ReplaceBlocks: (STONE,SANDSTONE) or to another one. When moving fast generator I see stone chunk, some little time it is changing to sandstone right before my eyes. Can all these operations be done before generated chunk will be given to Bukkit?
I like extensions .bc or .biome. Global biomes also good idea.

@Timethor As @rutgerkok says main problem is biome ids. Biome list in world config guarantee load sequence and show all ids in one place.

@SimSonic we may add this 😄

@SimSonic Done with your offtop 😄

It's included in 2.6.0!

Super! I will begin to use it immediately from the morning!
Just finishing updating my server to 1.7.x.

Thanks!