How about cloning BiomesOPlenty, add some features that I like but that don't fit to the main branch of the project and publish it with another name, let's say BiomesOPlentyExtended or sth. like that? I'd like to refer to some special classes from that lib to extend my mod, so best way would be to merge both in a new project.

What about the license? Am I allowed to clone the project, rename it, keep all the files (license also) and distribute it here on github? Having read the license I doubt that I can do this...

Ok, so it is not allowed for me to use your mod, combine it with other mods and add my own mod extensions - that is sad. But I respect that due to your wishes, as I can understand your fears about bug reports from cloned versions.

The reason why I am asking is that I don't want to install all new mods when a new minecraft version comes out. I'd prefer to have just one mod that works - and I'd like to throw together from the net what I find and like. This way, I could distribute that one mod to all my friends that play on my own minecraft server - installation would be much easier than now. But it seems not to be allowed to me, too bad.

But maybe you can give me a hand in understanding BoP; I'd like to extend my timber (and auto sapling) solution to the trees from BoP and can't find the correct item from the blocks. If you have a look at https://github.com/jottyfan/JottysMod/blob/master/src/main/java/de/jotty/mymod/timber/TimberEvent.java where I implemented my timber code, I guessed the log variants in line 48 - 64 and use this in line 314 for vanilla variants, but it turned out that BoP uses a different variant structure as the rendered block has no image. Also missing the correct variant information made me comment out line 322 as it didn't work. And at least, I didn't find out what leaves belong to what logs. It would be cool if my mod would be able to cut BoP trees the way it does with vanilla trees, and that is the reason for the idea to clone BoP as you use an extended version BlockBOPLog that contains some more variant information that I cannot refer to using vanilla blocks.

That is the intent of the license, we aren't too keen on there being several publicly available versions of the mod where everything becomes a fragmented disaster. What will ultimately happen is reports for "There are problems in x version of the mod, but it's your fault anyway!". Note that the emphasis here is on publicly, if you want to make a private version that's perfectly fine.

Otherwise, if you wish to extend BoP, I think the best thing to do would be to make another 'addon' mod that references/alters BoP's internals, and make pull requests for any hooks you find that are lacking. Using reflection (and possibly ASM, although pull requests would be much easier) should provide you with most of what you need though without such changes.

As for distributing the project, I wouldn't consider forking on Github alone to be doing that. It's when you start distributing binaries, advertising and otherwise commercialising BoP that things start becoming an issue.

If things ever get to a point where neither Forstride nor I can work on the project anymore we may consider changing the license to one that's much more open, but we haven't reached that point yet at least.

BoP splits its logs across 4 different ids, which is necessary to account for the multiple different rotations logs can have. We have a special setup such that we don't need to create a bunch of boilerplate classes to achieve this.

In your case, it seems something along these lines is what you're after:

Block block = state.getBlock();

 BOPWoods woodType = (BOPWoods)state.getValue(((BlockBOPLog)block).variantProperty)
 BOPTrees treeType = (BOPTrees)state.getValue(((BlockBOPLeaves)block).variantProperty)

We don't current have a method for getting one from the other since we haven't found ourselves needing it, but I suppose you could check if the names are equal for a quick and dirty approach.

We're not the first ones to deviate from Vanilla structuring for our blocks, and I doubt we'll be the last either. It's not really a reasonable assumption that all logs and leaves should conform to that structure, even if some mods do. I believe Treecapitator for example requires specific mod integration, and provides a config file for custom definitions for this very reason.

Thanks for all the explanation. But for using BOPWoods or other classes from BOP, I'd need an api to refer to in my mod. There is no BOP api, it's just the whole mod as is, so it could be a solution for me to depend my mod on BOP. I think that could work.