Request/Question: Disable random placement in the compat.

[Deightine]

I noticed that for compatibility, you made it so this compat disabled the trees in TC, then replaced them with this compat. I had actually been struggling to figure out how to stop that behavior before I added Dynamic Trees. So it was a relief of sorts. But then I realized... I have no way to stop them in the compat, now. Heh.

Although I know you've avoided adding a config for this compat, is there any way I can disable the compat from spawning Greatwoods and Silverwoods randomly about a world? I am working on a world where I want tree seeds to be incredibly rare treasure because wood is sparse.

Thank you for putting the work into making TC work with DT. :)

[ferreusveritas]

Hey there.. me again :) Same problem here as with the base DT. Like I said earlier I plan to make an add-on or DT feature that lets you fine tune the tree spawn behavior. It's the next feature to be added so when it happens you'll get all the flexibility you could wish for. The feature would be usable in this mod as well.

@the-realest-stu Does TC have an option to disable it's trees from spawning? If so does DTTC respect the setting? Seems like that would be all it takes to close this issue. It should probably work this way anyway.

[Deightine]

@ferreusveritas I shouldn't be surprised to bump into you over here. Heh.

According to DTTC's page over on Curseforge:

"In order to disable Thaumcraft's tree generation, this mod disables tree generation in Thaumcraft's world config file. I'd prefer that I didn't have to do that, but I didn't really have any other options. Thaumcraft's world config will not be affected if tree generation is disabled in the Dynamic Trees config.

I was asking @the-realest-stu because this reads like its tying up the option to turn these particular trees off completely that would normally be accessible in TC's config (i.e. turning them off to replace their generation with gen via DTTC, which doesn't have its own config atm). Not that I've been able to find what config option that is in TC's world config.

[ferreusveritas]

I just started this mod: https://github.com/ferreusveritas/DynamicTrees-Control

I don't expect the dev time to be too crazy so you might have a usable solution after all given a little patience.

As far as the Thaumcraft interaction goes it's possible to read the config option in TC first before ultimately disabling it. So it's possible that a slight change in DTTC could make this right.

[ferreusveritas]

I just made the change. If Thaumcraft is configured to disable it's trees then this mod will also disable it's tree generation.

[Deightine]

Nice. I try to be patient, so no pressure from me on any of this. I've mostly just been asking to get the issue out into the open to see if anyone was amenable to adjusting something at one of the steps in the stack.

Just out of curiosity, which particular config variable in Thaumcraft is this mod looking at? I want to make sure I nail the right one when I go to verify my configuration and test it.

[ferreusveritas]

Just look for something like "generateTrees" in Thaumcraft's config files. I'm getting pretty close to finishing the DynamicTrees-Control mod which would allow you to put dead trees everywhere.

[ferreusveritas]

The new add-on mod is now usable. I just tested it. You can be my guinea pig and test it if you want. Let me know if you're interested. The mod will let you change the species, and density of any biome on a per dimension basis. Pretty rad.

[Deightine]

I... would send you a fruit basket if I could. I'll start testing it immediately (edit: after you push an alpha release on github that is.)

[ferreusveritas]

on github or curseforge?

[Deightine]

Either works for me. My current pack is building via Twitch/Curse with access to Alpha for testing purposes, but any channel that works for you will work for me. You've put in the hard work (and at incredible speed from my perspective).

[ferreusveritas]

Mod DynamicTrees-Control created to fill this need.

[ferreusveritas]

@Deightine Here's your early alpha release. You're my official guinea pig. If you have any questions you can contact me on here or via personal message.

https://github.com/ferreusveritas/DynamicTrees-Control/releases/tag/Hoping

[Deightine]

It'd be a lie by omission if I didn't mention that I just squealed like a little kid at Christmas. I'll get some notes back to you as I kick the tires. I'm one happy guinea pig zero.

[Deightine]

@ferreusveritas Looking through the config json (which is serious business), I noted the use of '...' as a placeholder. I'm guessing this is used to affect all of the databases of which it is a member. Would that be a correct assessment?

Also noted that there are asterisks in one of the examples ("biome" : "minecraft:.jungle.",) which suggests access to wildcards. How many layers of this can I throw wildcards on? Is it just against the biome entries? Can I throw out the biomesoplenty/minecraft and just hit every biome with one *?

To seriously test it, I'm going to unlock every biome I normally restrict in my pack (vanilla, BOP, Thaumcraft, etc) and set every single tree to Dead. Then see if I can find a single tree that isn't dead anywhere on the planet. That seems like a good way to find outliers and crashes.

[ferreusveritas]

The "..." means "default". I thought that the "default" tag might want to be used by admins for their settings. For the databases section the "..." means populate with the default world gen data. If there's a populator after that.. ie: "extraoverworld" then that populator will overwrite the already populated data. If you only use the "..." then the dimension will work as if nothing changed. If you omit the "..." then the default populator won't be run so you can have a blank slate.

When you see the "..." in a random species selector that means to drop to the next layer. For instance:

{
    "biome" : "minecraft:plains", <--  Select plains biome
    "species" : { <-- Add a species selector for this biome
        "method" : "before",  <-- Splice this selector before the stack of existing selectors
        "random" : {               <-- Create a random weighted selector(add weights for denominator)
            "dynamictreesphc:pear" : 4,  <-- Select pear trees 4/6 of the time
            "..." : 2  <-- The other 2/6 of the time use the next selector in the chain(regular worldgen)
        }
    }
},

The above will select pear trees 4 out of the total of 6 times. The other 2 times it will drop down to the next selector in the chain and run whatever is there. This is used if you want to add some trees to a biome but you still want the default trees to also show up.

The wildcards are actually just regex expressions to match the biome names. You can do a lot with these. You can just use ".*" for every biome or "minecraft:.*" for just the vanilla biomes, etc. Refer here for more info: regex info

[Deightine]

So it's a full regex! That's exciting. I much prefer that over isolated wildcards, so that'll be quite valuable.

I'd recommend giving DT its own config subfolder, then having DT-C puts its JSON and a basic config file with comment notes about this aspect in there. It would head off a lot of people asking about this particular element.

Notes so far --

I've noticed a serious slowdown on initial worldload, right before the Building Terrain stage. It's almost hanging but nothing goes sideways so I don't have any log to offer from it. Considering the nature of the mod, this may be unavoidable (it's going through a lot of trees). But I figured I'd note it.

I've seen trees generate around DTC's interference, but it's due to other worldgenerator tools having tree placement options. This is a good thing because it shows they're playing nice. Although it might be nice to have a 'master override' over all trees that are placed in any stage of generation, like a hot-swap that puts in a DT instead of the one the other generator wanted to place. I just don't know if that would be feasible. Right now it'd require configuring the other worldgen tool to change out which trees its using, and that's fine. No toes stepped on.

I'll keep poking it with a sharp stick.

[Deightine]

Alright, so this is awesome. The dead trees I'm putting in to test are taking on the height characteristics of the trees they are replacing. So it's creating tall, super skinny dead trees in the Mega Taiga.

Meanwhile in other areas where it's replacing normal oaks, they're branching out the way I would expect. I don't know if this is working entirely as you intended, but if so, kudos to you! The biomes still look the way they otherwise wood (heh), only... well... dead. If this is a neat accident of the worldgen, then... well, still. It's neat.

So far it's working perfectly. Once I had the JSON figured out, I haven't seen DTC pop in the logs anywhere and it isn't prompting crashes. I'm still checking another 20 biomes or so, but it's looking stable.

This was a magical forest biome before DTC got to it:

[ferreusveritas]

Nice screenshots. I'd like for you to post your config file also. The reason why the trees are taking on the height is because you didn't override the biome density. So it's still using the default forest density for the biomes. That's configurable also.

[ferreusveritas]

Also. You'll get the leafless dead trees if you use the "decayed" species instead of the "dead". You can assign them to generate randomly dead and decayed at your preferred ratio. Might make it look even better.

[Deightine]

I'll take a run at feeding decayed back in. I saw that in the base config, but I wanted to eliminate any confounding variables at the start. Here is my current config, as literally barebones as I could get it:

{

"dimensions" : {
    "-1" : "defaultdatabase",
     "0" : "customoverworld",
     "1" : "customend",
     "5" : "defaultdatabase"
},

"databases" : {
    "defaultdatabase": [ "..." ],
    "customoverworld": [ "...", "deadoverworld" ],
    "customend": [ "endpop" ]
},

"populators": {

    "deadoverworld" :
        [
            {
                "biome" : ".*",
                "species" : {
                    "method" : "replace",
                    "static" : "dynamictreesbop:dead"
                }
            }
        ]
    }
}

[ferreusveritas]

Remember you can always blacklist the magical forest biome in bop's config file if you don't think it fits in the world. You can always make a rule to rarely spawn the magical tree wherever you wish though.

You can eliminate a lot from your json file since it still has a lot of example stuff in it.

[Deightine]

I'll keep it in mind. I'm just trying to keep from doing too much fine tuning, else I might eliminate a conflict where the worldgen tools bump heads. As I change more and more, I'll be moving from testing how it works with its neighbors and seeing if I can break it internally. Maximize the chance I help you find any bugs to stomp from the getgo.

Sidenote - The theme of the pack I'm building is that the world was pretty high tech, cyberpunk, etc, and is experiencing a magical apocalypse. I'll probably be turning the magical forest biome down to an rate of like... 1-3/100, in Thaumcraft and setting up Lost Cities to refuse to build cities in it, constraining it to tiny sections at the center of parks wrapped in city. Like Strawberry Fields in Central Park in Manhattan. A place where the magic is taking hold. The goal is for wood to be the hardest commodity for a player to come by without going into a haunted building to salvage the furniture, and the buildings are formidable. It also makes the brightness of the mushrooms so much starker when they pop up.

[Deightine]

New config change:

"deadoverworld" :
        [
            {
                "biome" : ".*",
                "species" : {
                    "method" : "replace",
                    "random" : {
                        "dynamictreesbop:dead" : 6,
                        "dynamictreesbop:decayed" : 4
                    }                   
                }
            }
        ]

Examples in play:

The randomness ratio is looking solid.

[Deightine]

I am noting a lot of trees taking root in buildings, but I suspect that'd be from DT itself, wouldn't it? It's not putting them down to replace any kind of 'worked' blocks (stone bricks, for example) but it is replacing Terracotta blocks with rooted dirt. I think it was happening before but I just hadn't narrowed it down.

Edit -- They also seem to be spawning in Deserts, which I hadn't expected. I haven't added any biome-specific generation, so that'd be outside the realm of my config changes so far.

[ferreusveritas]

If you don't want the trees to spawn in the desert then make another populator rule after your dead trees in all biomes rule for desert biomes and set it to cactus or none. Decayed trees will spawn in clay since the species has it configured as a valid substrate for mesas. I might be able to do something about configuring species substrate validation in time.

[ferreusveritas]

This config may be more appropriate since you'll only create 1 database instead of 3. The databases can have a decent memory footprint(each contains all of the biomes, used or not) so only create one if you need it.

{

"dimensions" : {
    "0" : "deadworld"
},

"databases" : {
    "deadworld": [ "...", "deadoverworld" ]
},

"populators": {

    "deadoverworld" :
        [
            {
                "biome" : ".*",
                "species" : {
                    "method" : "replace",
                    "random" : {
                        "dynamictreesbop:dead" : 6,
                        "dynamictreesbop:decayed" : 4
                    }                   
                }
            }
        ]
    }

}

[Deightine]

I have now switched from Lost Cities, to Biomes-o-Plenty, to Vanilla, and I've not seen so much as a whisper of a conflict anywhere. I've probably generated ~300 chunks on each of the three generators. It looks pretty stable and there hasn't been a single stray tree of the non-dead variety when all of the other worldgen tools had their trees turned off.

Are there any particular areas of the JSON changes that would be something you'd like me to stress test for you as another pair of eyes? A particular variable like 'scale' or some form of math change? So far everything is running really smoothly.

My personal next step will be to feed the new version of the config back into the actual main pack (I spun off a testpack for the worldgens), but once I do that all of my bug seeking will be cross-compatibility stuff where I need to kick any stray trees or leaf blocks that might drop a sapling out. I have Lost Cities generating content from other mods into the world, cross-mingling with DT and other large mods.

I'm also trimming down the config per your suggestion about the databases. Any place I can cut processing overhead is target number one for me.

[ferreusveritas]

You can give this ultra simplified version a try.. You'll notice that this one contains no dimension mapping. Instead it modifies the default database("...") and writes over it with your populator that uses the "replace" method. The difference here is that if you load up any dimension it will use the modified default database. Even if you use JED and make a dimension on the fly.

{

"databases" : {
    "...": [ "deadworld" ]
},

"populators": {

    "deadworld" :
        [
            {
                "biome" : ".*",
                "species" : {
                    "method" : "replace",
                    "random" : {
                        "dynamictreesbop:dead" : 6,
                        "dynamictreesbop:decayed" : 4
                    }                   
                }
            }
        ]
    }

}

You can test this and if you want to test any of the math functions or the scale function that's up to you. The math functions are:

• const A constant value from 0.0 to 1.0.. just use the number itself like 0.67
• noise A value from 0.0 to 1.0 that is pulled from the perlin noise map. no arguments.
• rand A random value from 0.0 to 1.0 that is not location or time dependent. no arguments.
• add Add two or more values
• sub Subtract a value or multiple values from the first value
• mul Multiply two or more values
• div Divide a value or multiple values from the first value
• mod Get the modulus(remainder of a division) of 2 values
• max Get the greater of two or more values
• min Get the lesser of two or more values
• ifgt Conditional.. if arg1 is greater than arg2 then get value of arg3 otherwise value of arg4
• species If the species regex matches the argument then get value of arg2 otherwise get value of arg3

These can be nested together kinda like a programming language..

"math" : {
    "add": [
        "sub": [
            "rand",
            0.5
        ],
        "noise"
    ]
}

The scale function works like this: val = ((noise * arg1) + arg2) * arg3 All 3 of the arguments are optional. If there's no arguments then it's just the perlin noise value for that location. This function is generally all you need for most density calculation purposes.

[Deightine]

I'll give your ultra-cut config a try and see how it does.

The difference here is that if you load up any dimension it will use the modified default database. Even if you use JED and make a dimension on the fly.

Oh, nice. So in the event that NetherEx or a dimension mod decided to add DT support, it'll scale. That's really cool. So could that be used with 'before' and 'replace' to change out a single tree type across every dimension, then?

[ferreusveritas]

Before, After and Replace are just selector methods for the whole biome, not individual trees. If you're modifying the default database that was created with the default populators then you won't be able to filter out a certain tree. You can however replace the selector for the entire biome and add the trees you do want. If you just want to add a tree you can splice a selector "before" the existing.. add your trees or optionally default down to the next selector in the chain and have it do it's work. If you made a generic selector that provides a default ("...") then you can splice after it too using "after".

I know it's kinda weird but it's how it works :)

[Deightine]

It actually makes sense, but I won't trust my feeling that it makes sense until I've monkeyed around with it a good bit. Heh. If I've learned nothing programming off and on over the years, it is to never trust my feeling that a thing makes sense. It's like when code compiles on the first try, a sure sign something is wrong.