I investigated this the other day,
the issue is seemignly caused by the dolphin having a client entity tracking range of 5, which is less then that of item which is 6
this means that when the dolphin picks up the item and the client attempts to find the dolphin to render the animation, it fails and falls back to rendering the animation to the player instead
potential fixes include removing this fallback behaviour or increase the tracking range of dolphins
i used a simple mixin in a fabric mod to acchieve this for my own use
@Mixin(EntityType.Builder.class)
public class EntityTypeMixin<T extends Entity> {
@Shadow private int clientTrackingRange;
@Inject(method = "build", at = @At("HEAD"))
private void injected(String string, CallbackInfoReturnable<EntityType<T>> cir) {
if ("dolphin".equals(string)) {
this.clientTrackingRange = 6;
}
}
}i should add that if you play other games that use openal you may have these hrtf data files present on your system
and depending on the version of openal those games use they may or may not be usable by the game
but openal will always try and load these files first the current working directory of the process is just one of the places it searches for these files it also searches some system wide folders
so people who have this working may just have the data present on there system from something else
More context, from searching in code i tracked down to PlayerSpawnFinder::findSpawn(ServerLevel, BlockPos)
the very first if condition checks if the biome has skylight, or if the server gamemode is not adventure and if that is true follows through using a method that will issue chunk loading tickets, but the secondary path instantly resolves the spawn location, and the chunks may not be loaded yet allowing this bug to happen