Useful Slime (NeoForge/Fabric)

Entity Data Accessors should only be ever set by the creator of the entity. Never added to by other mods.

The reason for this is because Entity Data Accessors are order dependent so if multiple mods tries to add these entity data accessors to mobs and on client, they run in a different order than the server did (because mod load order is not guaranteed), the client will get forcibly disconnected from server when the entity spawns.

Instead, this mixin part needs to be removed and migrated properly to a Forge Capability because capabilities were designed specifically for this use case of attaching data to arbitrary entities. It is safer for mods as the vanilla system is designed specifically only for vanilla and unsafe for mods. Then you would use your own packet to send the data to client when needed.

UsefulSlime/Common/src/main/java/einstein/usefulslime/mixin/ClimbingPlayerMixin.java

Lines 26 to 35 in a5831e3

    
           private static final EntityDataAccessor<Boolean> DATA_CLIMBING = SynchedEntityData.defineId(ClimbingPlayerMixin.class, EntityDataSerializers.BOOLEAN); 
        
           protected ClimbingPlayerMixin(EntityType<? extends LivingEntity> type, Level level) { 
        
               super(type, level); 
        
           } 
        
           @Inject(method = "defineSynchedData", at = @At("TAIL")) 
        
           private void defineSynchedData(CallbackInfo ci) { 
        
               entityData.define(DATA_CLIMBING, false); 
        
           }

This is especially a problem in large modpacks where many mods are doing this. Example is TNPLimitless 7 where there's many mods injecting SynchedEntityData onto entities and are getting out of order due to mod load order. Which is causes a lot of reports of people getting disconnected from server due to:

Wow, I didn't know that. Thanks for explaining this me. I'll get right on it. Do you have any suggestions on what to do for fabric? or is it a forge only problem?

The issue exists for all loaders. As for how to fix it, it depends on what you need the data for. Do you need the data to be on the client side?

The equivalent of Forge’s Caps is Cardinal Components library on Fabric. Though some multiloader people are just making a normal field like int or so and inject into the compoundtag read/write. Which works I guess and easier than using the dedicated systems for each modloader.

If needed on client, it depends on if you need the data on entity load on client or not. If not, just send a packet from server to client to set value on client whenever is climbing. If needed on entity load, use the entity spawn/join events on each loader and listen for client side spawn. Then send packet to server asking for data. Server gets data and sends packet to client. Client reads data and sets field

Though now I’m curious, doesn’t the player already have a climbing field that works with ladders and twisting vine? Maybe that could replace your entire mixin

Boy am I stupid sometimes I didn't even need to save anything

	private static final EntityDataAccessor<Boolean> DATA_CLIMBING = SynchedEntityData.defineId(ClimbingPlayerMixin.class, EntityDataSerializers.BOOLEAN);

	protected ClimbingPlayerMixin(EntityType<? extends LivingEntity> type, Level level) {
	super(type, level);
	}

	@Inject(method = "defineSynchedData", at = @At("TAIL"))
	private void defineSynchedData(CallbackInfo ci) {
	entityData.define(DATA_CLIMBING, false);
	}

Share to