I've been trying to add Dynamic Trees compatibility to my own mod, but, even though everything run fine from Eclipse compiled versions crash when trying support Dynamic Trees (every version I've tested, including newest alpha and newest release):

  public PineSpeciesBase(TreeFamily treeFamily) {
  	super(treeFamily.getName(), treeFamily, DynamicTreeHelper.pineLeavesProperties);
  	
  	setBasicGrowingParameters(0.2f, 16.0f, 3, 4, 1.3f);
  	setGrowthLogicKit(TreeRegistry.findGrowthLogicKit(ModTrees.CONIFER));
           ...

Results in no such method exception for setBasicGrowingParameters(), or setGrowthLogicKit(), or TreeRegistry.findGrowthLogicKit() -- as I replace one method with direct variable assignment new errors pop up. It's like mods compiled against you deopf, using classes and methods in your source code, somehow can't find them in your distribution jars. I don't know what you're doing in your compile scripts, but it seems to break compatibility with its own API.

(EDIT: Either that or it's a Forge bug not finding valid methods.)

The latest Dynamic Trees alpha version has undergone some API breaking changes because of so many new features. It might be best to build along with the dev version for the time being. As far as the deobf jar not working properly I'm not really sure what could be going on there. I'm no expert on the build script but as far as I knew I was doing it properly.

Edit: One thing I could think of is to make doubly sure that you're using the alpha version 0.9.1d deobf jar in Eclipse. And that outside of eclipse ensure you're using the 0.9.1d jar. There's API differences between 0.9.1d and 0.9.1c.

Well, I was definitely using the 0.9.1d in both places (except one test with an older version). I may come back to it later, but you'll have to forgive me for giving up on this for now -- this isn't the first day I've cussed and screamed over this.

Maybe I'll try again later when the current version is a stable "release" build.

You could have come to me sooner. No need to stress out over it.

Well, Mangoose gave me a few pointers one registering the branch / leaf models earlier. I don't like asking for help too much -- I don't want anyone to think I'm asking them to make my mod for me (maybe I've read the Forge forums too much).

Yeah, I know what you mean. Sorry about stressing you out with the API changes. I like to use the alpha versions for all of the breaking API changes. I don't change API for beta and releases.

I have wondered if it's related to either the compile script, since I notice all compatibility mods seem to use a similar script that looks quite different from what Forge provides. Mine is basically the one from Forge with just a couple additions: https://pastebin.com/fjQKuvAy

Alternately, I've wondered if it has anything to do with the Forge version I'm compiling with or using, 1.12-14.21.1.2387, since its recommended, though not the latest.

Still, I don't see how that would matter -- if all the classes and methods exist (and aren't somehow obfuscated) Java should just recognize them and find the relevant byte code, if I under how it works correctly.

Are you getting these errors at compile time?

No, the game crashes during launch when I use a version with dynamic trees support -- but only when compiled with the script and installed, never when run from Eclipse. So I guess I'm grasping at straws, trying to find anything that might be different from mods that make it work.

fwiw.. I don't use the dependencies thing like this when I build my add-ons:

dependencies {
        compile files("reflibs/BiomesOPlenty-1.12.2-7.0.1.null-deobf.jar")
        compile files("reflibs/DynamicTrees-1.12.2-0.9.1d-deobf.jar")
}

I simply throw the deobf jar into the ./libs directory then run ./gradlew build

That being said I wouldn't think it would matter since you obviously would have gotten a compile time error if it couldn't find the jar. Might be worth trying anyway.

The BoP add-on has this in it's build script, so it's not using that method.

dependencies {
}

Do you use discord? Might be better if we could chat directly.

Hmmm...

I don't seem to have a ./libs directory (under any project), and never seen one, only the build/lib where the results pop out, and some searching finds a /home/jared/.gradle/caches/minecraft where some things used in deobfuscation (and re-obfuscation?) are. It seems thing are setup very differently. But then, I haven't actually been using the Forge Gradle wrapper in a long time, since I installed Gradle -- maybe that would make a difference? I never really thought of that. I'd still confused if it worked, it doesn't seem like Java would care.

Just a sec, I have it but haven't used it from home in a while.

You'd have to make the libs directory, it's not created automatically. It's a standard though. In the build script right after your dependencies it says:
// you may put jars on which you depend on in ./libs

Ah -- I guess it pays to read the documentation. Of course, I'd have to bring my old code bat to test it.

What is the channel?

Mangoose's Mods https://discord.gg/GZBVVEj
I'll be in the # Dynamic-Trees-Stuff channel. You can PM me from there.

The root problem was compiling against the dev version and running against the latest curseforge release.