Alot of the blocks morph into another block when another block is placed next to it

I tried placing the blocks and checking the mca files if the issue is server side or client side and it def is client side,

the block's hitbox is same as the original block, the region file has the original block just the client decides to render it something else, tried using AntiGhost to fix it no help, F3+A still the same. Any hopes of fixing this? or any insights as to what could be causing it?

Sorry I didnt read all the backlog but JFYI the initial error happens when the mods on the server side don't generate the same block ids as the client side. Try rebuilding the server pack with e.g. ATLauncher, that helped when I had this issue

Sorry I didnt read all the backlog but JFYI the initial error happens when the mods on the server side don't generate the same block ids as the client side. Try rebuilding the server pack with e.g. ATLauncher, that helped when I had this issue

@BhavyaSingh2611 have you tried ☝️ and please let me know whether the method above has solved your problem.

@Xelbayria i have given up on the mod pack for now and it's now handled by @Skullians

@BhavyaSingh2611
please let Skullians know about this issue if he ran into a similar issue via modpack.

this issue has been tested on three different versions of everycomp v2.2.2 v2.4.0 and v2.4.2 :)

Tested it on singleplayer, its just an issue when playing on a server

I tried disabling Sodium and Indium and launching mc with that and it still has the same issue of morphing into another block

EDIT: i tried disabling all client side mods and still the issue persists

Try removing some mods

@VaelophisNyx did you manage to solve the issue?

@MehVahdJukaar i tried removing all the client side mods, i can't remove any blocks mod cause then i can't connect to the server do you have any clue as to which mod might be causing this?

The log gzip file for previous day i think might help with what mods are there and any conflicts that can be seen in logs

https://filebin.net/geugwgdeow98uf7c

Also this is really weird and whatever it is it's not something that you would see in the logs. Try binary searching starting from the mods that EC adds wood for. If you find one test with just EC and those yo see if that still happens. If it doesn't then it's another mod

You need to remove those too. Just make a test world and see what mod it's conflicting with as I can't fix this until that's found.

I tried removing the mods and adding them back in and these are the final broken ones i found:

With Blockus removed: Palisade, Hedges and Benches morph into another blocks and Macaw's doors and trapdoors have a bugged state when powered by redstone, the model stays the same but hitbox is updated so there is weird collision on moving towards it, with console spamming Trying to set null blockstate,

With Blockus in the modpack: All the Decorative Block mod compat blocks break and if you place any other block like beehive or cabinet next to the morphed block those morph as well while placed in isolation they remain constant, and the above issues persist

@MehVahdJukaar

It can't be neither of those then

Nice job on tracking that down. Could you report this to them?

@MehVahdJukaar report to whom? ChunkDeltaPacket is a minecraft packet and none of the mixins are changing its behaviour so I am thinking of moving up the stack and seeing where the state issues begin

After some serious debugging, the culprit of this whole problem is ChunkDeltaUpdate packet which is sending the wrong state from the server causing the client to render the blocks as something else. Leaving this here for anyone in future trying to fix this issue, although I couldn't find as to why ChunkDeltaUpdate packet is being bugged, tried removing all the mods that added Mixins to it (C2ME, Lithium and Ferritcore) and still no changes, only jank solution I can think of to create a mod that observes the blocks placed and when an everycomp block is placed it requests updates from server in multiple BlockUpdatePacket instead of ChunkDeltaUpdate packets

Oh I see I thought it was a mod. Yeah must be something in the mixins. Definitely mod related

I just want to confirm this bug as I'm having it myself with our server. Single player is fine. Blocks I'm having issues with are from Create. Placing down multiple water wheels will cause them to morph into different blocks. Haven't found a solution as yet but wanted to confirm this as a bug somewhere.

Edit: We also have an issue with Quark doors becoming desynced if someone opens it and another person closes it.

Removing Every Compat fixes both issues.

Are you sure you have all your mods the same exact version that's on the server? Whatever kind of desync it's not due to everycomoat as the mod does not touch any kind of syncing packets and such nor does it have different functionality between server and client. You should be able to verify by using it with just it's dependencies. If you do find which mod causes this pls let me know

I'm doing troubleshooting right now and it seems removing all of the Macaw's mods (doors, windows, trapdoor etc) while keeping Every Compat also fixes the issue. Removing either Macaw's or Every Compat will fix it.

It still seems like a desync of some sort. It might be that there is some discrepancy there. Do you have dramatic doors? Which macaw mod sis you find that cause sthis? I'll investigate

I don't have Dramatic Doors. It's definitely a de-sync issue. The 2 mods that show a de-sync issue are Quark (wooden door) and Create (wooden water wheel). The Quark door only de-syncs if player 1 opens it and player 2 closes it (ie. it stays "open" for player 1 but they can't walk through and if player 1 tries to close it, it won't update for player 2).

I have the whole suite of Macaw's mods (bridges, bridges - bop, bridges - otbyg, doors, fences, fences - bop, fences - otbyg, trapdoors and windows). I have to remove ALL of those to fix the bug. If I have any of them installed with Every Compat, the issue reappears. Strangely, starting a new multiplayer world won't show the issue immediately. It's very hard to pin down what exactly triggers the issue but once it's there, it won't go away without removing either Every Compat or every Macaw's mod.

I just tried disabling all the Macaw's blocks in Every Compat but that didn't fix the issue.

Edit: I agree it's probably not an Every Compat issue but it does go away when Every Compat is removed.

I'll try it out. Very weird indeed. Not sure what could those macaw mods have in common rbh. Block id map must be the same otherwise the server wouldn't have let you in. Blockstate one however might not. I don't really know how that works or why it would be desynced tho

So on a hunch just try to remove a couple big mods while keeping/removing maacw mods. If any of those tests show different results it must be another mod causing it. Maybe removing those mods makes it work just because eby change the registered blocks are enough to shift the blockstate map to have the discrepancy lie right on their specific EC blocks you were testing. This is a wild assumption tho as I don't really know how that works

I had that hunch too because the blocks the water wheel morphed into were different depending on what mods were still installed so that's what I did when I worked out EC was part the issue. I re-added EC and kept working through the mod list to see if anything else would fix it. Macaw's was the only other mod that also fixed the issue.

Well, I feel a little stupid. I've narrowed my morphing issue down to the compatibility mods for Macaw's (Biomes O' Plenty and Oh The Biomes You'll Go), specifically Macaw's Bridges and Macaw's Fences. I had those mods installed before adding Every Compat so never thought about the fact they all add the same things... block compatibility between Macaw's and BOP/OTBYG. If I removed the bridges and fences compatibility mods, it fixes the morphing issue. I'm assume there's a conflict with the way Macaw's adds compatibility with different woods and EC's way.

That'd be the first thing I'd suggest anyone else looking at this problem look at. Look for any mods that add compatibility with different woods for their own items.

I can't test the door issue anymore as my friend is now offline to test it but I'll try it again tomorrow and update.

Hmm interesting that still shouldn't cause a desync. I'll try some

Was just able to test the door and it works perfectly. I'm not sure what it was but it was definitely a conflict between EC and Macaw's BOP/OTBYG compatibility mods.

Links to the mods:

https://modrinth.com/mod/macaws-bridges-biome-o-plenty
https://modrinth.com/mod/macaws-bridges-oh-the-biomes-youll-go
https://modrinth.com/mod/macaws-fences-biomes-o-plenty
https://modrinth.com/mod/macaws-fences-oh-the-biomes-youll-go

The door in question (from Quark) just happened to be made from Biomes O' Plenty's cherry blossom wood.

Absolutely no idea here. Tho if it just happen with these I could get away with overlooking it aas those 4 mods are completely redundant when used with ec

@Dreytac do you think that https://github.com/Brandcraf06/Blockus/tree/1.19.2/src%2Fmain%2Fjava%2Fcom%2Fbrand%2Fblockus%2Fcompatibility can be the issue? Cause i mainly had the issue where blocks who update state on being next to each other change to mainly blockus blocks, and for the fix i really just bruteforced it added a mixin in the mod i have on server that resends the block update packets if you place a everycompat block 8x8x8 around the player xD

I'm not familiar with Blockus but if that compatibility part adds blocks to make them compatible with other mods AND Every Compat has the same compatibility, I think it could (no idea how though).

In saying that, my issue with Create was placing multiple water wheels next to each other caused them to change into other Create blocks but I don't think Create has anything to do with this issue. It's just a by-product that's visible. Same with Quark. The Quark door didn't change, it's just it's block state wasn't updated for all players.

I'm having a hard time figuring out what relates to what in this scenario. All I know for sure is that something either Macaw's compatibility or Every Compat is doing, when combined, causes block states to be sent incorrectly.

If you can find something that Macaw's does that one of the mods in your pack also does, I'll bet that's the culprit.

Hmmm I'll take a look at the mixin stack of macaw's and see what all it is affecting?

I just got confirmation that this kind of issue is caused by a desync in the blockstate map

@MehVahdJukaar so is there any way to fix this issue?

So this means that EC must be registering some of these with different behaviours across server/client or some of those mods is

I don't know. I have no clue what is causing the desync. Maybe I could add some debug packet that asks the server for its maps, compares with the current one and see what the difference is. Thing is that is something that happens really internally in the game and logic is complex so it would take me a while to even figure that out. But just to explain blockstate desync is when you have the same blocks as the server but the server has a different amount of blockstates for each. For example say that for some reason the sever just accepts wheat crops with age of 1 while client form 1-7

So for some reason the blockstates of everycompat blocks aren't getting registered on the server side? Hmm

I don't think it's the mods cause if the block state map was bugged for the mods that would cause the original blocks added by the mod to morph as well? Which i confirmed wasn't the case with me @Dreytac can you confirm?

Must be that. Idk why with jsut those mods or why at all since the same code always does both unless one has different versions

@MehVahdJukaar another interesting thing that i had discovered a few weeks back was that when you placed an everycompat block the server would send BlockUpdate packet and ChunkDelta packet and the BlockUpdate packet would have the correct state, while the ChunkDelta packet had the incorrect state and that overwrite the state sent by BlockUpdate

@BhavyaSingh2611 Using Macaw's Fences on it's own didn't cause any issues. As soon as I add either EC or Macaw's Fences - Biomes O' Plenty mod, the issue with Create water wheels returns. The same goes for Macaw's Bridges.

Is it possible that the combination of Macaw's Fences and Biomes O' Plenty causes whatever mechanism Macaw's BoP mod and EveryCompat uses, to break the blockstates for Create? The fact that 5 mods are involved here tells me a solution is going to be extremely hard to find (although my solution was to remove Macaw's compatibility mods and they weren't required in the first place)...

If it helps at all or you're curious what other mods are in my pack and what versions I run, the list is available here:
https://hobbyhome.net/minecraft/crafthome

@Dreytac i tried fixing the issue and i had gave up on it until one day you just randomly commented on the issue and now i am intrigued again of what it could be 🤔

My knowledge doesn't go much deeper than running a server with a mod pack these days I'm afraid. I used to write mods for 1.12 but haven't really touched anything since then so I don't think I'll be able to help much more.

I wish this wasn't tied to a server. Would be way easier to debug if it wanst

I'm uploading a version with some debugging. if you can help pls download that, turn on the debug packet option in the configs and send me your client long once you logged in

Yeah sure, 😊

edit: checked CF but the .9a is only available for forge not fabric

Hope these help. For comparison, I've posted another log without Macaws where the error doesn't occur. Both were done exactly the same.

Start client -> Join multiplayer server -> Break Create water wheel -> Place water wheel -> Disconnect -> Close client.

EC w/ Macaws: https://pastebin.com/9xaQZ2DT
EC w/o Macaws: https://pastebin.com/ksQj3AEe

well seems like my logging thing didnt detect anything with the blockstates map :/ back to square one i guess

I uploaded one for fabrictoo. thought this was something that just happened with forge mods

Replaced previous version with the new version of everycomp [1.19.2-2.4.9a], I get a straight up crash during client startup...
See below for crash report, and let me know if you need anything else :)

Description: Initializing game

java.lang.RuntimeException: Could not execute entrypoint stage 'main' due to errors, provided by 'everycomp'!
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.lambda$invoke0$0(EntrypointUtils.java:51)
	at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:49)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke(EntrypointUtils.java:35)
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:52)
	at net.minecraft.class_310.<init>(class_310.java:459)
	at net.minecraft.client.main.Main.method_44604(Main.java:205)
	at net.minecraft.client.main.Main.main(Main.java:51)
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:462)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
	at org.prismlauncher.launcher.impl.StandardLauncher.launch(StandardLauncher.java:88)
	at org.prismlauncher.EntryPoint.listen(EntryPoint.java:126)
	at org.prismlauncher.EntryPoint.main(EntryPoint.java:71)
Caused by: java.lang.NoClassDefFoundError: com/ninni/twigs/block/TableBlock
	at net.mehvahdjukaar.every_compat.fabric.EveryCompatFabric.lambda$onInitialize$19(EveryCompatFabric.java:47)
	at net.mehvahdjukaar.every_compat.EveryCompat.addModule(EveryCompat.java:132)
	at net.mehvahdjukaar.every_compat.fabric.EveryCompatFabric.onInitialize(EveryCompatFabric.java:47)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:47)
	... 11 more
Caused by: java.lang.ClassNotFoundException: com.ninni.twigs.block.TableBlock
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:226)
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:112)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
	... 15 more


A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------

-- Head --
Thread: Render thread
Stacktrace:
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.lambda$invoke0$0(EntrypointUtils.java:51)
	at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:49)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke(EntrypointUtils.java:35)
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:52)
	at net.minecraft.class_310.<init>(class_310.java:459)

I didn't change anything there apart from the log. Did you have 4.9 before? Seems to me either twigs updated today or you got ourltdsted twigs

Might be something else, actually. Put the mod in a modpack and it crashed, but after putting it in a blank 1.19.2 instance with just Fabric API and Moonlight Lib, minecraft fires up fine

Updated twigs as it was 2 updates out, still getting the same crash message (moonlight lib also updated)

Can you send that again plz?

Here's the crash report:

Description: Initializing game
java.lang.RuntimeException: Could not execute entrypoint stage 'client' due to errors, provided by 'moonlight'!
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.lambda$invoke0$0(EntrypointUtils.java:51)
	at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:49)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke(EntrypointUtils.java:35)
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:53)
	at net.minecraft.class_310.<init>(class_310.java:459)
	at net.minecraft.client.main.Main.method_44604(Main.java:205)
	at net.minecraft.client.main.Main.main(Main.java:51)
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:462)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
	at org.prismlauncher.launcher.impl.StandardLauncher.launch(StandardLauncher.java:88)
	at org.prismlauncher.EntryPoint.listen(EntryPoint.java:126)
	at org.prismlauncher.EntryPoint.main(EntryPoint.java:71)
Caused by: java.lang.UnsupportedOperationException: Base block cant be null (board_slab for architects_palette module)
	at net.mehvahdjukaar.every_compat.api.SimpleEntrySet.registerBlocks(SimpleEntrySet.java:195)
	at net.mehvahdjukaar.every_compat.api.SimpleEntrySet.registerWoodBlocks(SimpleEntrySet.java:180)
	at net.mehvahdjukaar.every_compat.api.SimpleModule.lambda$registerWoodBlocks$1(SimpleModule.java:67)
	at java.base/java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:647)
	at net.mehvahdjukaar.every_compat.api.SimpleModule.registerWoodBlocks(SimpleModule.java:67)
	at net.mehvahdjukaar.every_compat.EveryCompat.lambda$registerWoodStuff$6(EveryCompat.java:168)
	at java.base/java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:647)
	at net.mehvahdjukaar.every_compat.EveryCompat.forAllModules(EveryCompat.java:64)
	at net.mehvahdjukaar.every_compat.EveryCompat.registerWoodStuff(EveryCompat.java:168)
	at net.mehvahdjukaar.moonlight.core.set.fabric.BlockSetInternalImpl$LateRegQueue.lambda$registerEntries$1(BlockSetInternalImpl.java:68)
	at java.base/java.util.ArrayDeque.forEach(ArrayDeque.java:888)
	at net.mehvahdjukaar.moonlight.core.set.fabric.BlockSetInternalImpl$LateRegQueue.registerEntries(BlockSetInternalImpl.java:68)
	at net.mehvahdjukaar.moonlight.core.set.fabric.BlockSetInternalImpl.registerEntries(BlockSetInternalImpl.java:45)
	at net.mehvahdjukaar.moonlight.api.platform.fabric.RegHelperImpl.lateRegisterEntries(RegHelperImpl.java:80)
	at net.mehvahdjukaar.moonlight.fabric.MoonlightFabric.commonSetup(MoonlightFabric.java:43)
	at net.mehvahdjukaar.moonlight.fabric.MoonlightFabricClient.onInitializeClient(MoonlightFabricClient.java:17)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:47)
	... 11 more
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Thread: Render thread
Stacktrace:
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.lambda$invoke0$0(EntrypointUtils.java:51)
	at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:49)
	at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke(EntrypointUtils.java:35)
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:53)
	at net.minecraft.class_310.<init>(class_310.java:459)

That's a different error. Is your architects palette updated?

Oh, my bad. It's not updated, trying it now.

Thanks for bringing that up, I completely missed that. Minecraft has started up now 😄

@MehVahdJukaar the fabric mod doesnt output anything to the console even after enabling debug packets option

That means the blockstate I'd map is exactly the same. No idea where to go from here

@MehVahdJukaar i need a small help, can you tell me a way to get all recipe json for all the blocks created by everycomp, since after having way too many issues with the blocks bugging out, i am gonna hard code all the blocks we need :P

Go inconfigs, turn on save debug assets, boot up the game and they'll be in a debug folder in game folder

Well with the current theory I feel like dynamic registration on runtime is overwriting the block states or the mapping order is different for client and server and hence the issue happens, with the hope being hardcoding the blocks in would mean that the mapping order is same for client and server

Which I know is a pretty stupid approach but if it works it works

@MehVahdJukaar another quick thing how do i dump resources from v_slab_compat mod cause it too has a bug where if you place vertical slab on top of a path block it changes to a random trapdoor and upon flicking the trapdoor it transforms to 2 vertical slabs

Pretty sure all this block morphing issue has nothing to do with models it's just blockstate I'd desync so doing that wouldn't solve anything. It's server that says it has some Id maples to some blokcstate and client had another one. Maybe there's a config for vslab too but I'm not sure

@Xelbayria yes it is unresolved till this date

yes it is unresolved till this date

Have you also tried the latest version, v2.5.10 for EC and Moonlight lib, too?

Is this problem still unresolved?

@Xelbayria it still happens with the latest version of the mod on 1.19.2

I'll be closing this since there is no reply.

Apologies for the late reply, @Xelbayria.
I have been very busy and also did not see your comment.

We have installed https://www.curseforge.com/minecraft/mc-mods/block-limit-fix which has fixed a significant portion of our issues.
To what extent I am not exactly certain

No worries. that's what happens when a person gets so busy. "Block limit fix", that make senses.