Previously you added tag support so I could throw in logs at ease to help the compatibility with HT TreeChop, however, when I put a tag in, it gets erased in the config as if its invalid.

i tried
"#tag:name",
"c:tags"

each at different times, both were overwritten. what is the correct format here?

The changelog gives a literal example?

It's

"minecraft:logs": true,

in the bannedBlocks section. I have just now tried adding some nonsense values, and Gson sorted the file for me, but didn't delete anything:

{
"blockRegenerationEnabled": true,
"initialBlockRegenDelayMillis": 5000,
"blockRegenIntervalMillis": 1000,
"debugMode": true,
"bannedBlocks": {
"minecraft:crafting_table": false,
"minecraft:stone": false,
"derpderp": false,
"minecraft:sand": false,
"minecraft:spruce_log": false,
"minecraft:deepslate": false,
"minecraft:dirt": false,
"#tag:name": false,
"minecraft:podzol": false,
"minecraft:logs": true,
"minecraft:coal_ore": false,
"minecraft:grass_block": false
},
"bannedItems": {
"minecraft:air": false,
"minecraft:spruce_log": false,
"minecraft:dirt": false,
"minecraft:wooden_pickaxe": false,
"minecraft:stick": false
},
"disableForAllTileEntities": false
}

I tested it, and yeah, adding "minecraft:logs": true works great. Even better, use "treechop:choppables", which includes more than just logs. The root of the problem is that MultiMine usually causes two BreakEvents to trigger due to this line:

So, I expect that any mod that changes BreakEvent behavior would have conflicts. It sounds like this line was added to fix client-side visuals; maybe something can be done on the client instead to address the "pop" delay? Or duplicate BreakEvents could be caught and canceled with highest priority on the server side?

You know, in the last MultiMine versions this piece of code should no longer be needed as the client "legally" breaks the block. What MultiMine does is basically trick the clientside progress from "oh you just started mining this block" to "you have been mining this block for a while now". A quick local test showed no adverse effects in removing it in MC 1.19

e55548a

However, the same test for 1.18 shows the "delayed pop", which i find extremely annoying. So i will not be removing this for 1.18.

No problem, sounds reasonable. Good to hear that about 1.19! I'll let the folks on my side know.

Hi @itsdinkd, I've had a few reports of conflicts between TreeChop and MultiMine. If you were able to get the MultiMine config sorted out, did it help with the conflicts?

@AtomicStryker the player.gameMode.destroyBlock(pos); line is still there on 1.19 and 1.20 versions, are you still all right with removing it?

I do quick tests on a dedicated localhost server and unless i see a problem, i leave the code as it is, so yes.