hammy275 / mc-vr-api Goto Github PK

View Code? Open in Web Editor NEW

8.0 8.0 0.0 375 KB

An API to allow mod developers to see VR player data from Vivecraft.

License: GNU Lesser General Public License v3.0

Java 100.00%

mc-vr-api's People

Contributors

Stargazers

Watchers

mc-vr-api's Issues

Can you add controller velocity to IVRData?

I think that this will make it much easier to code with the API.

Clear playerToVR on Disconnect

Clear playerToVR HashMap of a disconnected player when they disconnect.

NonVR Crashes with ImmersiveMC

https://mclo.gs/xRlY8Gc

was trying to test immersive mc forgot to enable it and found out it was this. im running in nonvrmode for vivecraft, i also tested if it was vivecraft incompatible and found that it wasnt , this is the only other mod enabled.

1.20.4 Support

Crash on Hotswitch

https://discord.com/channels/178567952780623872/194213677560365056/1177725041237037137

Crash on Hotswitch

https://discord.com/channels/178567952780623872/543161829325799426/1165681295687430274

https://discord.com/channels/178567952780623872/194213677560365056/1177725041237037137

Check Dedicated Server

Let's make sure the dedicated server doesn't have a heart attack when we run this.

Dedicated server loads with the mod
Dedicated server functions properly with the mod

1.19.3 Support

Ideally, we make a version 2.1.1 that fixes #23 while simultaneously including 1.19.3 support.

Technically speaking, the API does change, as the API call to IVRData#getRotationMatrix will switch to JOML's Matrix4f, but I'm breaking from SemVer on this because:

JOMLs Matrix4f is the only option as the Mojang-provided one is completely removed. If it was deprecated, this would be another story, but it's entirely gone to my knowledge.
The only real difference is a different import
1.19.3 already isn't backwards compatible with older Minecraft versions, so there's no worry for that breaking things.

Vrapi 2.0 unable to load

https://mclo.gs/fFPRa9e
only mods running are
optifineless vivecraft ver 0.11, architectuary, vrapi 2.0, immersivemc

seems to be complaining about how you removed vrplayer tick event

README Out of Date

The README is extremely out of date at the moment; it needs to be updated!

Connection Lost: Disconnected upon joining singleplayer world

public class PlayerInitHandler {
    @SubscribeEvent
    public void onPlayerLogin(PlayerEvent.PlayerLoggedInEvent event) {
        System.out.println("HANDLE PLAYER LOGIN EVENT");
        LocalPlayer player = getMCI().player;
        assert player != null;
        System.out.println("PLAYER NOT NULL");
        VrJesterApi.VIVECRAFTLOADED = PositionTracker.vrAPI.playerInVR(player);
        System.out.println("CRASHES BEFORE THIS");
    }
}

I register the above handler in the MinecraftForge.EVENT_BUS and it causes the player to disconnect from joining their singleplayer world. I'm trying to assign a flag so I can check throughout my code whether the player is in VR or not. Please find attached gifs and snippet of logs for visual reference.

https://gyazo.com/c2abe794e0a5d21abee8faf94c5a8e22
https://gyazo.com/8674f8a3d827bb3505da4fcb159569d5

-Thanks

Check Vanilla Forge Players

Mod loads successfully
Mod plays fine without creating fake VR data

Odds are, this should work more than fine (especially in comparison to #3 ), since there isn't any Vivecraft code, and we bail pretty early.

System to Make Optional

If a mod wants to integrate this API, they should be able to do so without making the mod mandatory for players. This way, mods can be enhanced with VR, and the API can be left out if no one is going to be in VR on a server.

Support Hotswitch VR Builds

Looks like they're getting closer to release, we should support them!

Get API Version Function

Returns int[3]{major, minor, patch}.

Some Refactoring

Refactor the forge/fabric packages to be something like forge_vrapi or fabric_api`
Move the Plugin and Plugin Provider to forge

Match Official API

Important!

See #14 (comment) for deprecation plans for MC VR API

Original Comment

NOTE: This is the ONLY other planned major version bump.

The Vivecraft developers plan to release an official API at some point. Once it releases, this API should be updated to match it as closely as possible. There isn't a need to have all the features from the official one, however all of the functions we implement should be named and sorted the same way as the official API.

Until the official API releases, this issue won't be closed

Multiple VR Players Crash

https://github.com/hammy275/mc-vr-api/blob/1.19.x/common/src/main/java/net/blf02/vrapi/client/ClientSubscriber.java#L20 ticks for every player the client sees, not just the client player that we care about, causing a crash when we try to get data of other players. Should do a filter here to only get ourselves.

triggerHapticPulse crash on Latest Vivecraft

Confirmed on 1.18.2 Fabric 0.0.15. Will need to check other Minecraft and Vivecraft versions.

EDIT: Looks like Minecraft_vr_Instance is null for some reason. Will figure out why

Port to Architectury

This should allow for Fabric compatibility.

Note that at the same time, we'll have to remove the VRPlayerTickEvent, since Fabric doesn't have an event system in the same way Forge does, and I'm not keen to force the Architectury API to be installed to use this API.

After the port (including full testing with Vivecraft's Fabric port), this will become release 2.0.0.

Access to `vrdata_world_pre` and `vrdata_world_render`

vrdata_world_pre will only be available client side, and allows for accessing VR data before the tick. No server-side support since, because of latency, having access to it server-side wouldn't help due to latency (you can't take advantage of when in the tick/on what tick it happens like on the client).

vrdata_world_render will only be available client side, and would be used to allow rendering things at an effective framerate higher than the "20 fps" that the tick-based ones provide.

Will be available to 1.18.x-multiloader and 1.19.x

To prevent having to break compatibility and making a 3.y.z we'll be exposing these as IVRPlayer instances. They can be obtained in IVRAPI using the following methods:

getVRPlayerPre: Get player data from before the running tick.
getVRPlayerRender: Gets player data for rendering. Client-side only!

Clients Can Only Retrieve Data for Themselves

Based on the interface, we should either be throwing an Exception here or actually giving the data from other players.

It shouldn't be too demanding to send this info around, so I'll go ahead and do that. Since this changes how API functions work, this is going to require a major version bump, so I'm probably going to break some things while I'm at it.

Switch to LGPL

Didn't catch this sooner, but there are some fun clauses in the GPLv3.0 that make it not work with Minecraft. Will switch to LGPL.

Dev Mode Improvements

Ability to enable/disable it on the fly.
~~Fix rotation bug~~ Rotation isn't wrong and possibly find way to show rotation (small, black particle?)
Document dev mode on wiki

Eye Data

Vivecraft provides VRData instances for both eyes. We should grab those, and expose them to devs.

Docstring VRPlayerTickEvent

Link to mc-vr-playground

It will make a good example mod!

Depends on hammy275/mc-vr-playground#6

MC-VR-API is not found on this server. 1.19.2 servers

So i have this persistant problem where i put the fabric version of this mod and i try to play in a server it says that it cant be found even thought i installed immersive mc and installed mc-vr- api i have no idea what is going on and i am wondering if there is a fix

Rename VRData Functions

VRData functions should correspond to their respective function names in PlayerEntity.

I'm fine breaking the API here, it's not like this is released yet

VRPlayerTick

This should be similar to a Forge event, but won't actually be.

Whenever TickEvent.PlayerTickEvent is called, it should get all of the plugin instances (probably from a variable they're stored into at startup), we should call a VRPlayerTick function, that is passed in all of the parameters from TickEvent.PlayerTickEvent.

The reason we do this over a regular Forge event is so it can be easily used without requiring the API, similarly to the rest of the API.

getVRPlayer() Throws an Exception Instead of Returning `null`

On MC VR API 3.0.6 for 1.20.1

Optionality

If the server has mc-vr-api installed, the client doesn't necessarily need to have it. This way, non-VR users can join. Same vice-versa, so a client can join a server, and just not have VR API functions available.

This will require a new function, and thus will increment the version to 1.2.0, along with some documentation changes. The function is simply titled doesOtherSideHaveVR().

TODO:

Change the SimpleChannel to not check protocol versions.
Upon initially joining the server, the client sends the server a packet containing the network protocol version it's using. If that is not equal on the server side, the server kicks the client for a mismatched protocol version.
Create a HashSet of Strings representing players. When the server receives the network protocol packet, it adds the username to the set if the versions are compatible. It then sends a packet back to the client, which sets a client-only serverHasAPI boolean to true once receiving it.
On disconnect, remove players from the aforementioned HashSet
On disconnect, set serverHasAPI back to false
Implement doesOtherSideHaveVR(), which returns the value from the HashMap server-side, and the serverHasAPI boolean client-side.
Update VRPlayerTickEvent to only run if doesOtherSideHaveVR() is true.
Add the DISPLAYTEST so Forge doesn't display a red X if the API is only installed client-side.
On joining a server, wait 5 seconds. If serverHasAPI is still false (ie. we didn't receive the packet back from the server saying that we have the API) mention in chat that the server doesn't have the API, and VR-specific functions may not be available as a result.

NOTE: We aren't updating the other functions to require doesOtherSideHaveVR(). Mod devs are expected to check this. Not doing a major version bump for this, since before this, the functionality between those with the API and without wasn't possible because of protections from Forge.

isSeated and leftHanded Detection

Fields such as these would be very useful to mod devs

Position Faking

To make VR dev easier, I think it would be cool to have support for placing fake controller and HMD positions while in a dev environment.

The controllers and HMD would be represented in-world by particles, each one would be a separate key to place, and the keys and placement code would only work in a dev environment (in production, you'd ideally just be in VR anyways)

Fix isLeftHanded function.

    public boolean isLeftHanded(PlayerEntity player) {
        if (player.world.isClient) {
            VRDataGrabber.isSelf(player);
            return VRDataGrabber.isLeftHanded();
        } else {
            return ((Tracker.ServerSideVRPlayerData)Tracker.playerToVR.get(player.getGameProfile().getName())).isLeftHanded();
        }
    }

if (player.world.isClient) {
            VRDataGrabber.isSelf(player);
            return VRDataGrabber.isLeftHanded();
}

it returns the function VRDataGrabber.isLeftHanded(); but if the player is not using VR it returns nothing:

    public static boolean isLeftHanded() {
        if (!ReflectionConstants.clientHasVivecraft()) {
            throw new IllegalArgumentException("Cannot retrieve hand status of player outside VR!");
        } else {
            try {
                Object VRSettingsInstance = Minecraft_VRSettings.get(vrHolder);
                return (Boolean)VRSettings_reverseHands.get(VRSettingsInstance);
            } catch (IllegalAccessException var1) {
                throw new RuntimeException("Could not get handedness of local player!");
            }
        }
    }

as you can see here

if (!ReflectionConstants.clientHasVivecraft()) {
            throw new IllegalArgumentException("Cannot retrieve hand status of player outside VR!");
}

ReflectionConstants.clientHasVivecraft() is true only if the player is using VR
if it doesn't the API's funtion will return an error:

	at java.base/java.lang.reflect.Field.checkAccess(Field.java:1141)
	at java.base/java.lang.reflect.Field.get(Field.java:425)
	at net.blf02.vrapi.client.VRDataGrabber.isLeftHanded(VRDataGrabber.java:210)
	at net.blf02.vrapi.common.VRAPI.isLeftHanded(VRAPI.java:206)

now I'm not sure if this is just my code or for everyones' but for me, this is what happens, please fix this
the code where the error occurs:
Vec3d controllerVel = (VRPlugin.apiInstance.getRenderVRPlayer().getController(VRPlugin.apiInstance.isLeftHanded(player) ? 1 : 0).position().subtract(lastControllerPos)).multiply(100d);

fix:

        if (player.world.isClient) {
            VRDataGrabber.isSelf(player);
            try{
                 return VRDataGrabber.isLeftHanded();
            } catch (RuntimeException re){
                return null;
            }
            
            } else {
               return ((Tracker.ServerSideVRPlayerData)Tracker.playerToVR.get(player.getGameProfile().getName())).isLeftHanded();
           }

Game launches successfully with non-VR players
Game functions properly with non-VR players (they don't have magical VR data from somewhere)