As of today's release (1/6/25) for 1.21.4 Fabric, shooting a bow with roomscale archery on doesn't shoot in the correct direction. The arrow actually shoots in the direcion your dominant hand is facing. If you shoot an arrow to your left, but your dominant hand isn't facing the bow, the arrow shoots in the direction your right hand was pointed. For example if your hand is pulling the bow string from the side but your hands are positioned to make the bow face forward, and you release the trigger, the arrow shoots to the side instead of the direction the bow was facing when the trigger was released. This seems to not happen sometimes, shooting correctly as intended, it seems like a 50/50 whether it shoots in the bow direction or the dominant hand direction. I don't know if this bug affects servers with the vivecraft server mod, or if it affects servers without the vivecraft server mod, but it does affect singleplayer. I don't know if it affects modded bows or just the vanilla bow.

Here's some info that might help:
Computer OS: Windows 11
VR Method (how i'm playing in vr): Steam VR on computer, Steam Link on headset.
Headset: Meta Quest 3S
Minecraft Version: 1.21.4
Platform: Fabric
Fabric Loader version: 0.16.9
Vivecraft Version: 1.21.4-1.2.0-fabric
Java Version: 21.0.4 (Windows x64)

Video of the issue found here (because it's larger than 10 mb, thanks github for being annoying): drive.google.com
as you can see, the issue happens most of the time, with only a few shots being in the correct direction.

Things I think might cause the issue:
Lag (although I wasn't getting much lag and the issue started happening on this version of vivecraft, vivecraft 1.21.4-1.1.14-b4-fabric and earlier didn't appear to have this issue)
Some wrong check or something

Things I think could possibly solve the issue:
a slight lag before the arrow shoots to give time for everything to update (but let's be honest nobody likes input lag)
a slight delay when the arrow shoots before setting the values for if the bow is being pulled so it gives the arrow time to shoot before resetting values
Make the crosshair point in the bow's direction when using the bow instead of the dominant hand's direction (it might already be doing this)

hm

it works fine for me.
1.1.14 works for you?

can you post a latest.log, with you producing the issue

it works fine for me. 1.1.14 works for you?

The bug happens on 1.2.0, and 1.1.14 does work fine for me.

can you post a latest.log, with you producing the issue

latest.log
nothing relating to the bow in the log, yet the issue happened during the session.

hm I somehow thought you said it happended with just vivecraft, can you try with just it?

hm I somehow thought you said it happended with just vivecraft, can you try with just it?

Yeah give me a second, even though none of the mods should be impacting it from my knowledge

hm I somehow thought you said it happended with just vivecraft, can you try with just it?

Yeah just confirmed, still happens even with no other mods, not even fabric api

hm, would you be willing to test a version that logs what happens?

hm, would you be willing to test a version that logs what happens?

sure

hm I somehow thought you said it happended with just vivecraft, can you try with just it?

Yeah just confirmed, still happens even with no other mods, not even fabric api

Also here's the latest.log for when I did it with no other mods:
latest.log

vivecraft-1.21.4-1.2.0-bowlog-fabric.jar.zip
can you try with that, and send the log,, need to unzip it

vivecraft-1.21.4-1.2.0-bowlog-fabric.jar.zip can you try with that, and send the log,, need to unzip it

Yeah i'll test it now, sorry for responding late I was busy mining for diamonds in VR

latest.log
Here's the log. I know for sure the 6th bow shot was one where the issue occurred. Seemed to happen less often that time, which leads me to believe it's a lag issue.

Though it didn't appear to log any direction info, and mainly just spammed the logs with "Vivecraft: not sending hand, since it is the same as last sent"

I logged that just in case, it's the other parts that are relevent, the sent draw 0.0 should always be after the direction logs

oh ok

and yeah, the 6th one is in the wrong order

Vivecraft: sending draw 0.91082966
Vivecraft: sending packet 'DRAW'
Vivecraft: resetting draw to 0
Vivecraft: sending packet 'DRAW'
Vivecraft: player is in vr, get aim dir
Vivecraft: using aim dir of 'MAIN_HAND'
Vivecraft: using aim dir of 'MAIN_HAND'
Vivecraft: AndrewGaming587 sent draw 0.91082966
Vivecraft: AndrewGaming587 sent draw 0.0

oh yeah

as are some others

the thing is, that nothing really changed in that regard, the packets are still processed the same as before

I'm actually going to do some testing of my own, to see if it's a lag issue by changing my minecraft settings to make it laggier or smoother to see if it affects it at all

Yep definitely a lag issue. Set my vanilla settings to the max and shot the bow 5 times with all 5 being bugged
latest.log

Yep it's absolutely a lag issue. any doubt in my mind is gone because i just set minecraft to the lowest settings, and shot i think 15 times and none of them broke
latest.log
I think a good solution is to just add some lag handling by making the server/internal server respond to the draw packet and making the client wait for the server/internal server to respond before resetting draw to 0. Might cause some issues with servers/clients with bad ping and lag, but it shouldn't be too much of a problem because if you're playing Minecraft in VR you've likely got a decent-ish PC if it supports SteamVR, which most people likely use

the issue here isn't the reset, is that the draw packet is processed after the vanilla item release packet for some reason

and you are 100% sure it doesn't happen with 1.1.14?

Just checked 1.1.14-b4 with the laggiest settings, yeah it just doesn't happen on previous versions of vivecraft.

the issue here isn't the reset, is that the draw packet is processed after the vanilla item release packet for some reason

would it be possible to delay processing the vanilla item release packet until the draw packet is processed?

not really, since the server doesn't know if a draw packet will come

not really, since the server doesn't know if a draw packet will come

My next idea is to have the server skip the vanilla release packet entirely and just include the vanilla release functionality in the draw packet and have it come after the draw packet functionality if the vanilla release packet was sent. Only real downsides are that it might be difficult to do and that it might break mods that use that packet as well.

nah, I just need to figure out why it isn't processing them in the right order, when it worked fine in the last version

nah, I just need to figure out why it isn't processing them in the right order, when it worked fine in the last version

Maybe the bow changes that 1.2.0 introduced somehow messed with it

shouldn't really, that is just the additional hand packet, which doesn't get sent when the hand is the same, which it is here

Idea, just make the client never send the vanilla release packet if the player shot a bow and it’s on a server with vivecraft installed and make the vanilla release packet functionality run after the draw packet functionality on the server

vivecraft-1.21.4-1.2.0-bowtest-fabric.jar.zip
can you check if this one works reliably?

that is fine

okay, I rechecked the fabric documentation, and this one should defeinetly work now, ignore the version I sent before
vivecraft-1.21.4-1.2.0-bowtest-fabric.jar.zip

Just checked, yeah I can't reproduce it anymore with that jar