Hand Controller Positions Do not Match in Build SteamVR

Hello all, I came here today because we recently ran into a bit of a bug when packaging our game on unreal 4.26.2. Basically, when we use VR preview in the editor our hand positions are perfect(in other words the position of our hands accurately reflects where the controllers are located). However when we package for windows and run the build our hands are like 5 feet out in front of us. We do edit the rotation and offset for Vive and index controller in the player pawn controller; however, this was done so the hand match up correctly in the editor, but once packaged its not even close. Would anyone know a good fix for this?

For additional information, a standalone game from play settings has same issue as build. So VR preview also differs from standalone game

8 days later and we finally found the issue. First of all, I would like to premise this by saying that if the packaged game differs from the VR preview then it is most likely an issue with load order or tick dependency(in fact as far as I am aware this is the only thing that can cause differences unless the discussion is around rendering than that could change a lot between build and VR preview). Essentially we had our game instance, player pawn, and level blueprint all communicating and sending information to and from each other. The past dev team handled this execution of communications by using delays at various parts of the code; however, delays should never be used to control the execution of code under any circumstance and this is the case and point. These delays worked well enough in VR preview; however, in the slower-running standalone game and build these delays were not acceptable. The solution for us was that we set up a series of event dispatchers and made it so the game instance BP finished before the Player Pawn began to load(pawn depends on instance), and finally, after the pawn is loaded we allowed the level blueprint to load(level BP needs pawn). Once again this issue only reared its head on the build because the rate of code execution was slower on the build than in VR preview. The obvious takeaways from this are to make sure your blueprints are being executed in the order that you want them to execute, and do not under any circumstances use a delay to control the execution of code, instead use sequencing or event dispatching. Delays have a very specific and obvious purpose and controlling the rate of code execution is not one of them