Version Info

• Minecraft Fabric 1.19.2
• Wormhole 1.1.13b-fabric-mc1.19.2
• supermartijn642corelib-1.1.12a-fabric-mc1.19.2
• supermartijn642configlib-1.1.8-fabric-mc1.19

Description of the Bug

I've been working with this mod before on forge version 1.16.5, so now I immediately noticed that something is wrong. On the current version, almost everything does not work or works very unstable.

• After stabilizing the portal and adding a new location to the target cell from the target def. device, it cannot be moved, deleted or change color
• When the location is selected, then when you click the "activate" button, nothing happens. Multiple targets causes spaghetti-like behaviour, everything is entangled in some unpredicted way.
• Minor UI bugs present

I recorded a video trying to set up and use the portal.
Also below is a (pretty large) list of mods that are present in my modpack:

https://pastebin.com/RGNUFmdw

Steps to Reproduce

Attempts to set up and use the portal at all

Screenshots

Screenshots in motion:
https://www.youtube.com/watch?v=h5QRY7r7XLI

After some research, I was able to pinpoint the exact mod that causes the problem. It was Lithium (lithium-fabric-mc1.19.2-0.11.1). Deleting it alone completely removed this buggy behavior. I think it would be good to indicate in the relations that they are incompatible with each other.

• After stabilizing the portal and adding a new location to the target cell from the target def. device, it cannot be moved, deleted or change color
• When the location is selected, then when you click the "activate" button, nothing happens. Multiple targets causes spaghetti-like behaviour, everything is entangled in some unpredicted way.
• Minor UI bugs present

I cannot reproduce these points nor the behaviour in the video. Even with Lithium installed, everything seems to work just fine.

Just to be sure, I now also tested outside of my dev environment and indeed I can now reproduce the issue 🤦‍♂️ Not sure why it works fine in dev, but breaks outside of dev.

Welp at least I can now investigate what's going on. Also, indeed it seems it works fine without lithium.

• After stabilizing the portal and adding a new location to the target cell from the target def. device, it cannot be moved, deleted or change color
• When the location is selected, then when you click the "activate" button, nothing happens. Multiple targets causes spaghetti-like behaviour, everything is entangled in some unpredicted way.
• Minor UI bugs present

I cannot reproduce these points nor the behaviour in the video. Even with Lithium installed, everything seems to work just fine.

This is curious, because for me things are getting broken behaviour even with only these mods installed:

wormhole-1.1.13b-fabric-mc1.19.2
supermartijn642corelib-1.1.10b-fabric-mc1.19.2
supermartijn642configlib-1.1.7-fabric-mc1.19 (not updatet to the latest version, but that's make no difference)
fabric-api-0.76.0+1.19.2 (updating this one also didn't help)
lithium-fabric-mc1.19.2-0.11.1

wormhole-1.1.13b-fabric-mc1.19.2
supermartijn642corelib-1.1.10b-fabric-mc1.19.2
supermartijn642configlib-1.1.7-fabric-mc1.19 (not updatet to the latest version, but that's make no difference)
fabric-api-0.76.0+1.19.2 (updating this one also didn't help)
lithium-fabric-mc1.19.2-0.11.1

Could you share the latest.log file from when you try the things you mentioned (preferably with just those mods installed)?

wormhole-1.1.13b-fabric-mc1.19.2
supermartijn642corelib-1.1.10b-fabric-mc1.19.2
supermartijn642configlib-1.1.7-fabric-mc1.19 (not updatet to the latest version, but that's make no difference)
fabric-api-0.76.0+1.19.2 (updating this one also didn't help)
lithium-fabric-mc1.19.2-0.11.1

Could you share the latest.log file from when you try the things you mentioned (preferably with just those mods installed)?

Man, it got huge. Almost 40 mb, over 180k lines of strings like
OpenGL debug message: id=1280, source=API, type=ERROR, severity=HIGH, message='Error has been generated. GL error GL_INVALID_ENUM in (null): (ID: 173538523) Generic error'

Here it is:
https://www.mediafire.com/file/h1jz2vxrnbwq0eb/latest.log/file

Steps i made:

1. Move all mods aside except five listet above;
2. Start new game, new world creative;
3. Place basic portal, coal gen., try to use it, get broken behaviour;
4. Save and exit immediately.

wormhole-1.1.13b-fabric-mc1.19.2
supermartijn642corelib-1.1.10b-fabric-mc1.19.2
supermartijn642configlib-1.1.7-fabric-mc1.19 (not updatet to the latest version, but that's make no difference)
fabric-api-0.76.0+1.19.2 (updating this one also didn't help)
lithium-fabric-mc1.19.2-0.11.1

Could you share the latest.log file from when you try the things you mentioned (preferably with just those mods installed)?

Man, it got huge. Almost 40 mb, over 180k lines of strings like OpenGL debug message: id=1280, source=API, type=ERROR, severity=HIGH, message='Error has been generated. GL error GL_INVALID_ENUM in (null): (ID: 173538523) Generic error'

Here it is: https://www.mediafire.com/file/h1jz2vxrnbwq0eb/latest.log/file

Steps i made:

1. Move all mods aside except five listet above;

2. Start new game, new world creative;

3. Place basic portal, coal gen., try to use it, get broken behaviour;

4. Save and exit immediately.

I should note that after the removal of Lithium, the latest.log does not have any significant differences from what I presented above, as it seems to me. But just in case, I'll attach the second version too:

https://www.mediafire.com/file/67gugi3csanjf0p/latest.log/file

Same exact steps were made: new creative world, basic portal 4x4 and no broken things at all as the result.

Not sure what those OpenGL messages are about. The OpenGL messages start before even loading a world, so I doubt that has anything to do with Wormhole.

After clearing all the OpenGL messages, the log (the one with Lithium) is pretty much empty. There is no errors or really anything in there sadly.

Not sure what those OpenGL messages are about. The OpenGL messages start before even loading a world, so I doubt that has anything to do with Wormhole.

After clearing all the OpenGL messages, the log (the one with Lithium) is pretty much empty. There is no errors or really anything in there sadly.

Sadly indeed. Broken and moreover irreproducible behaviour is ugh.
Last things I can mention is that I use Legacy Launcher and I use i5-7500 iGPU Intel UHD630 (but my friend with laptop gtx 1650Ti, who hosts the server have the same issue, so that's rather unimportant detail)

Well, at least I hope that this rare issue ticket might be useful for somebody else in the future. It will be strange if it turns out that I am the first person to encounter this phenomenon and no one will ever encounter it again after me :D

wormhole-1.1.14-fabric-mc1.19.2
supermartijn642configlib-1.1.7-fabric-mc1.19
supermartijn642corelib-1.1.10b-fabric-mc1.19.2
And all the rest of my modpack mods

Everything works as it shoud 👍🏻

The PortalShape class stores information about the blocks which are part of the portal. Whenever a client joins a game, the PortalShape for portals is serialized, send to the client, and then deserialized. In order to serialize it, it stores the block positions of all the blocks in a CompoundTag. When deserializing, it requests the same CompoundTag and iterates over the positions stored in it.

In vanilla CompoundTag maintains the order in which things were inserted into it, thus the client ends up with the list of blocks in the same order as the server. The following mixin from Lithium replaces an internal map in CompoundTag with one which is more efficient, but which does not maintain the order in which things were inserted: https://github.com/CaffeineMC/lithium-fabric/blob/develop/src/main/java/me/jellysquid/mods/lithium/mixin/alloc/nbt/NbtCompoundMixin.java
This means that the client may end up with the blocks in a different order than the server.

Now when a portal looks for a target at an index n, it simply iterates over the blocks in the portal until it has encountered n-1 target slots and then returns whatever is in the next one. Since the block order may be different between the server and client, the targets may now also be in a different order.
When you try to change something about a target, the client sends a packet to the server with the target's index. Since the order is different, the server then finds an empty slot at that index and simply ignores the packet.

Since the order of blocks will be essentially random, it may just happen that they are in the same order as the server. Since there's only two target holding blocks in the portals you and I build, that could very well happen and is likely what happened when I first tried to reproduce the issue.

I have now rewritten the way PortalShape is serialized in a way which doesn't depend on CompoundTag maintaining order, thus it should now also work when Lithium is installed.
The changes are available in Wormhole version 1.1.14, let me know if you still encounter issues.
Thank you for reporting the issue and helping me investigate!