Crashing with Vivecraft non-VR companion
Techjar opened this issue ยท 6 comments
Mixin apply failed mixins.betterportals.json:MixinEntityRenderer -> net.minecraft.client.renderer.EntityRenderer: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException @Redirect ctor invocation was not found in net/minecraft/client/renderer/EntityRenderer::func_175068_a(IFJ)V
This seems weird considering our non-VR client doesn't touch EntityRenderer. Maybe mixins meant for the VR client are mistakenly being applied here? Not sure how you're doing the Vivecraft detection.
I'm enabling/disabling vivecraft mixins based on the existance of one of VC's coremod classes:
However all mixins which are dynamically enabled/disabled have names ending in
_OF, _NoOF, _VC, _NoVC, etc., so that's probably not it.Could you quickly link me to the source for the companion mod? I'll be able to take a look at it in about an hour or so.
Gosh, they were trying to run BP 0.1.1. That's so old, it didn't even support Optifine (that particular crash was fixed in 0.1.4), no wonder it failed to start.
Anyhow, keeping this issue open nevertheless because I just tried running BP with non-VR VC and got this far more reasonable error (exactly what you suspected, applying a VR-specific mixin):
Mixin apply failed mixins.betterportals.view.json:MixinEntityPlayerSP_VC -> net.minecraft.client.entity.EntityPlayerSP: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException @Inject annotation on handler$suppressRoomMoveForCameraEntity$0$zbl000 could not find any targets matching 'setPosition' or 'func_70107_b' in the target class net.minecraft.client.entity.EntityPlayerSP. Using refmap mixins.betterportals.view.refmap.json Method is @Dynamic(Override added by Vivecraft to update room origin on position change.)
@Techjar How would I best go about differentiating VR from non-VR VC at load time? Is there some characteristic class that is (and will continue to be) only present in the VR version?
Also, it appears like the non-VR version is built from the same repo as the VR version but I don't see how/where the build-system determines which classes to skip for the non-VR version?
org.vivecraft.asm.VivecraftASMTransformer also exists in the non-VR client, so you may want to pick something a bit more concrete like org.vivecraft.provider.MCOpenVR if you need to detect the VR client specifically. Though since you mention the suffix thing, that may not be the issue in this case, but still worth considering what effect it might have.
I'll get the patches for non-VR as soon as I can. I don't have them on hand so I'll need to either generate them or get them from jrbudda. In hindsight we should be pushing that to a branch on the GitHub repo.
Oh, my bad on not checking the version (also don't mind this being in the second reply, GitHub didn't show me your second comment until I posted my first one). At least the issue is still valid with a different error.
The non-VR client is built on a separate branch with only the pieces of code needed for VR animations. We use the same build system and just run the different source through it. Here's the patch files if still needed: https://cdn.discordapp.com/attachments/195502278508150784/639531417201672212/patches_1.12_nonvr_9r1.zip