[Conflict with Identity mod]

[Neo-Qwerty]

Minecraft version information

1.20.1

Mod loader information

Fabric

Mod loader version information

0.15.0 (Fabric)

Mod version information

Flowery Mooblooms 2.0.0

Expected Behavior

I expected Identity (version 1.7.1) to load the menu on the server, like it does on the exact same setup on clientside.

Actual Behavior

The client crashed on trying to load the menu, giving this error:

Error: java.lang.NullPointerException: Cannot invoke "com.faboslav.friendsandfoes.api.MoobloomVariant.getName()" because the return value of "com.faboslav.friendsandfoes.api.MoobloomVariantManager.getDefaultMoobloomVariant()" is null

The server simply "sees" a disconnection, and generates no error logs.

(Note: I know the behavior is Identity's fault and not Flowery Mooblooms', but a compatibility fix for servers, even if it's to tell Identity not to render Moobloom variants, would be nice, or even an incompatibility warning on the mod's page, as usually Identity can render modded mobs fine.)

Reproduction Steps

1. Set up a multiplayer server with Friends & Foes (2.0.2), Flowering Mooblooms (2.0.0) & Identity (1.7.1)
2. Try opening the Identity menu (default key is ` )
3. Crash!

Screenshots & files

Error message:

The game crashed whilst unexpected error Error: java.lang.NullPointerException: Cannot invoke "com.faboslav.friendsandfoes.api.MoobloomVariant.getName()" because the return value of "com.faboslav.friendsandfoes.api.MoobloomVariantManager.getDefaultMoobloomVariant()" is null

Crash log:

crash-2023-12-06_17.52.20-client.txt

[Faboslav]

I just tested this on client and on server:

[09:19:50] [main/INFO]: Loading Minecraft 1.20.1 with Fabric Loader 0.14.23
[09:19:50] [main/INFO]: Loading 48 mods:
    - architectury 9.1.12
    - fabric-api 0.91.0+1.20.1
       |-- fabric-api-base 0.4.30+7abfd51577
       |-- fabric-api-lookup-api-v1 1.6.35+4d8536c977
       |-- fabric-biome-api-v1 13.0.12+215bbe9677
       |-- fabric-block-api-v1 1.0.10+92a0d36777
       |-- fabric-block-view-api-v2 1.0.0+92a0d36777
       |-- fabric-blockrenderlayer-v1 1.1.40+b3afc78b77
       |-- fabric-client-tags-api-v1 1.1.1+97bb207577
       |-- fabric-command-api-v1 1.2.33+f71b366f77
       |-- fabric-command-api-v2 2.2.12+b3afc78b77
       |-- fabric-commands-v0 0.2.50+df3654b377
       |-- fabric-containers-v0 0.1.63+df3654b377
       |-- fabric-content-registries-v0 4.0.10+57aed33f77
       |-- fabric-convention-tags-v1 1.5.4+a1a980da77
       |-- fabric-crash-report-info-v1 0.2.18+aeb40ebe77
       |-- fabric-data-generation-api-v1 12.3.3+d7b148e077
       |-- fabric-dimensions-v1 2.1.53+8536527b77
       |-- fabric-entity-events-v1 1.5.22+b3afc78b77
       |-- fabric-events-interaction-v0 0.6.1+e91849a877
       |-- fabric-events-lifecycle-v0 0.2.62+df3654b377
       |-- fabric-game-rule-api-v1 1.0.39+ae9f657a77
       |-- fabric-item-api-v1 2.1.27+b3afc78b77
       |-- fabric-item-group-api-v1 4.0.11+d7b148e077
       |-- fabric-key-binding-api-v1 1.0.36+fb8d95da77
       |-- fabric-keybindings-v0 0.2.34+df3654b377
       |-- fabric-lifecycle-events-v1 2.2.21+b3afc78b77
       |-- fabric-loot-api-v2 1.2.0+96dfa95977
       |-- fabric-loot-tables-v1 1.1.44+9e7660c677
       |-- fabric-message-api-v1 5.1.8+d7b148e077
       |-- fabric-mining-level-api-v1 2.1.49+b3afc78b77
       |-- fabric-model-loading-api-v1 1.0.2+709a987177
       |-- fabric-models-v0 0.4.1+9386d8a777
       |-- fabric-networking-api-v1 1.3.10+eeb8eb3677
       |-- fabric-networking-v0 0.3.50+df3654b377
       |-- fabric-object-builder-api-v1 11.1.2+4ee0bc6077
       |-- fabric-particles-v1 1.1.1+201a23a077
       |-- fabric-recipe-api-v1 1.0.20+b3afc78b77
       |-- fabric-registry-sync-v0 2.3.2+4df89eb277
       |-- fabric-renderer-api-v1 3.2.0+39a511ba77
       |-- fabric-renderer-indigo 1.5.0+39a511ba77
       |-- fabric-renderer-registries-v1 3.2.45+df3654b377
       |-- fabric-rendering-data-attachment-v1 0.3.36+92a0d36777
       |-- fabric-rendering-fluids-v1 3.0.27+b3afc78b77
       |-- fabric-rendering-v0 1.1.48+df3654b377
       |-- fabric-rendering-v1 3.0.7+b3afc78b77
       |-- fabric-resource-conditions-api-v1 2.3.7+29de845d77
       |-- fabric-resource-loader-v0 0.11.9+132c48c177
       |-- fabric-screen-api-v1 2.0.7+b3afc78b77
       |-- fabric-screen-handler-api-v1 1.3.29+b3afc78b77
       |-- fabric-sound-api-v1 1.0.12+b3afc78b77
       |-- fabric-transfer-api-v1 3.3.3+c81d263177
       \-- fabric-transitive-access-wideners-v1 4.3.0+6c31357e77
    - fabricloader 0.14.23
    - flowerymooblooms 2.0.0
       \-- com_github_llamalad7_mixinextras 0.2.1
    - friendsandfoes 2.0.2
       \-- com_github_llamalad7_mixinextras 0.2.1
    - identity 2.7.1-1.20.1
       \-- omega-config 1.4.0+1.20.1
    - java 17
    - minecraft 1.20.1

No crash here, not sure what can i do.

[Neo-Qwerty]

You're using Fabric Loader 0.14.23, the bug occurs in Fabric Loader 0.15.0 (and only when Flowery Mooblooms is installed, the base Friends & Foes loads like a charm on the exact same environment)

Other mods also have problems with Fabric Loader 0.15.0 fixing a Loader bug that wound up breaking mods, examples here: Extra Origins Tale of Kingdoms BCLib (though that one is rude and doesn't explain much)

I know 0.15.0 isn't the stable release but from what I can understand of Fabric these aren't experimental and will show up in the next stable loader too.

[Linguardium]

the Environment annotation was ignored for fields due to a bug in Fabric Loader. This led to people improperly using it in their mods. Now that it has been fixed, those mods that were improperly using it are crashing.

The best option for mod devs is to actually separate client only code instead of trying to jam it all into a common file.

an alternative is to remove the annotation on the fields. since they were being included in both sides anyway, this would not be a functional change from previous behavior (though it would not match intended behavior)

[Faboslav]

I checked the code and i cant find any @Environment(EnvType.CLIENT) (this is used with architectury on yarn mappings) in my code on the fields, i am using it only with classes. If there is any such case, can you please link it?

[Linguardium]

I dont see an issue with your code. The only thing i see that might be an issue is that the variants are stored on the serverside via datapack. I havent looked into the code deep enough to check if you sync that data with the client. if not, the client would have an empty list of variants and always return null when doing a lookup (on servers)

[Faboslav]

Yeah, that should be the case? But i do load the variants on the client and server (in the common side of the mode) It's first time i am doing that kind of thing, also while testing i cant get anything like this at all.

[Linguardium]

there is physical server and logical server https://fabricmc.net/wiki/tutorial:side

you have the loading happening on the logical server, on both the physical client and physical server. If you aren't sending data from the logical server to the logical client, then the logical client wont ever have the datapack files loaded while the logical client is connected to a physical server.

basically, in single player (physical client, logical server, logical client) , datapacks load on the integrated server (logical server, physical client).
when connecting to a server, datapacks load on the dedicated server (logical server, physical server) but not on the client

[Faboslav]

That should not be the case, since fabric is handling this stuff for me https://github.com/Faboslav/friends-and-foes/blob/95c9e24123e6ea554f1a142e523ccd574437bdf5/fabric/src/main/java/com/faboslav/friendsandfoes/fabric/FriendsAndFoesFabric.java#L33

[Faboslav]

Or maybe it is, i am not sure right now, but i tried this on the dedicated server, it worked as expected without any errors, so i dont understand the reproduction case.

[Linguardium]

the logical client never reloads server datapacks

[Faboslav]

So i basically need to call the same with CLIENT_RESOURCES instead of SERVER_DATA?

[Faboslav]

Or something like that, i get it, only thing is it would be good to have specific reproduction steps, so i can actually check, that it is fixed.

[Faboslav]

Probably will need to create sync packet then for this thing.

[Linguardium]

syncing is definitely the best option.

what seems to be happening is Identity is creating a new moobloom on the clientside. During initialization of the moobloom, Entity calls initDataTracker

your moobloom initDataTracker will call MoobloomVariantManager.getDefaultMoobloomVariant() MoobloomVariantManager.getDefaultMoobloomVariant() calls getMoobloomVariantByName(DEFAULT_MOOBLOOM_VARIANT_NAME)

getMoobloomVariantByName is nullable, getDefaultMoobloomVariant is not which is the start of the problem. your IDE would have warned you to do a null check if you had marked it. getMoobloomVariantByName will fail on the client because buttercup is never loaded to the list (datapacks are loaded at world load not at game load, you may want to initialize the list in the clinit with buttercup, it already wipes the list at datapack load)

you take in a possibly null value and try to call getName() without a null check, causing a crash

I would suggest, that you check for null or initialize to "buttercup" since the data tracker is a string. you may need some rework.

[Faboslav]

This should be fixed with the 2.0.3 version of the main Friends&Foes mod.

[Neo-Qwerty]

Can confirm that everything now runs in peace and harmony on the server, thank you for fixing it!