Add setting to disable tree specific plank variants

[j-r]

Useful for games like Voxelgarden that have only one plank type with a generic plank crafting recipe.

Disabling the planks implicitly disables stair and fence variants depending on these planks as well as the log to plank crafting recipe.

[j-r]

Thinking about it now, it actually is a setting to enable planks that defaults to true:-)

[j-r]

Sorry, accidentally deleted the branch:-(

Is there a way to revive the PR?

[j-r]

Thank you!!

(I was missing push.default=current in my local repo, so my a bit too fragile automatic sync scripting didn't know that branch was important and promptly deleted it)

[wsor4035]

not sure how i feel about this. for context, think moretrees already has to many settings people dont use at all/if they care can make a mod to override and disable/change stuff. not sure if this falls into the previous category or not

[j-r]

Understandable. This PR does require the user to actually find and flip the switch, a better OOB experience would be great.

It does seem better to me to not define the nodes/recipes in the first place instead of removing them afterwards when perhaps another mod has already added other things depending on them.

One could add a small settingtypes.txt that exposes a carefully chosen subset of available settings, but perhaps it would be preferable for moretrees to automatically detect the base game has just one plank type? E.g. by adding an optional API that games can provide to expose relevant information?

Additional context: (note I'm not Voxelgarden's maintainer)

Voxelgarden (aka VG) is currently focusing on improving compatibility with mods not originally designed for it (see https://codeberg.org/voxelgarden/voxelgarden/issues/1). Mods are tested, bugs get fixed, APIs get adjusted, nodes get added, stuff gets wrangled after the mods have been loaded.

But obviously not much is gained if VG turns into an MTG clone during this process, so there will be cases where VG can't fix a discrepancy alone, e.g. VG has no trapdoors by default (it supports MTG's register_trapdoor API, though), while mesecons_doors assumes the MTG trapdoors exist. So there needs to be a better mechanism for mesecons to determine which doors to meseconify.

In this case VG has two distinct gameplay features: only one type of planks and a generic crafting recipe that gives 2 planks from any log. But it has similar tree variety to MTG and a comparable sapling mechanism, so adding moretrees isn't unreasonable and it runs fine on top of VG technically (since a leafdecay bug was fixed in git yesterday:-) But especially the crafting recipe conflict breaks immersion to some extent.

[wsor4035]

Understandable. This PR does require the user to actually find and flip the switch, a better OOB experience would be great.

given https://github.com/mt-mods/moretrees/pull/37 and being game agnostic, i think i agree a OOB experience would be better, once that pr is merged, could add in some detection for voxel garden specifically and handle the use case without adding yet another setting

[wsor4035]

alternate pr at https://github.com/mt-mods/moretrees/pull/40 - please comment with thoughts for/against

[j-r]

Looking good (the tuning branch). I'll close this PR.