Forum Replies Created
-
Posts
-
For vorpX to work with Virtual Desktop you have to set it to ‘SteamVR’ in the config app, Virtual Desktop only grabs SteamVR games not native Oculus.
vorpX’s native Oculus mode only works with Quest if it is connected to your PC with a Oculus Link capable USB3 (or dedicated Link) cable.
BTW: The wired connection via Oculus Link is better in terms of latency.
Will work again in the next vorpX version. Surprisingly compiling the font library directly in the vorpX code instead of linking it in already solved the issue for whetever reason. Just wanted to try that for better debugging originally…
Incidentally I have a maintenance release planned next week, so you won’t have to wait long.
Confirmed. In DX11 games vorpX uses an external font rendering library, which fails when creating fonts with the latest FO76 version. No promises, but I’ll look into it.
The choppiness is probably caused by the vorpX logfile getting flooded with error messages due to the failing font renderer calls. Feels like before to me when I skip the font rendering code altogether for testing purposes.
Looks perfectly fine as far as I can tell. Again, you can safely ignore the positional scan if it fails on your machine for some reason. The default positional tracking is almost as good. All UE3 scanner profiles (Bioshocks, ACM, etc.) have been individually optimized and finetuned to death for hours and are as good as possible.
There isn’t really much else to say than I said in my first reply (or what the scanner screen says already for that matter). In a nutshell: scanning through a game’s memory to find a specific location is a rather complex matter and may fail depending on a plethora of factors. There is no 100% guarantee. The scanner may even fail entirely on a specific machine. There also may be situations were the scanner ‘thinks’ it succeeded, but in fact didn’t. In such a case, just run it again ideally from a slightly different spot.
Since it worked before and now suddenly doesn’t, it would also make sense to check whether you made any changes to your system since then (e.g. additional background applications running) and if so revert them to check whether that makes a difference.
The base stations don’t affect the memory scanner.
Probably the scanner is just a bit more picky in the level you are currently in. Just checked it at the beginning, works perfectly fine here. You really don’t have to care much about the position scan in ACM, rotation and FOV are the important ones. DirectVR position gives a little bit more leeway in regard to walking around, but otherwise the default positional tracking is perfectly fine in ACM, well suited for playing standing in place.
Did you check the message that is shown during the scan? Admittedly it’s only visible for a few seconds in older games since the scan usually is pretty fast, so it might be hard to catch.
In a nutshell: scanning through a game’s memory to find a specific location is a rather complex matter and may fail depending on a plethora of factors. There is no 100% guarantee. The scanner may even fail entirely on a specific machine. There also may be situations were the scanner ‘thinks’ it succeeded, but in fact didn’t. In such a case, just run it again ideally from a slightly different spot.
If only the position scan fails, but the profile has default G3D positional tracking, there is no real need to repeat a scan. The default positional tracking works almost as good.
Unlikely. The only things stored under Documents are background images for cinema mode.
I’m pretty sure that the first one you posted will be gone with the next version, that one is almost certainly related to the potential temp folder glitch outlined above. Until the next update you should be able to work around it by restarting the config app before downloading a profile from the cloud.
The second one however… Judging from your event log entry executing the database command (which in this case would be adding the .exe name) causes an exception in the SQL library. I haven’t been able to reproduce that though. Do you maybe have some exact steps to reliably reproduce it?
Not sure if I understand the issue. Do you mean the launcher window or the ingame menu? If it’s the latter, you can also navigate that with cursor keys + enter.
Didn’t recall that anymore, but that’s a side effect of disabling some pseudo 3D HUD element that is supposed to be disabled. The same shaders are used for the weapon, hence that is also invisible. Should still be perfectly playable.
Run/start OpenTrack before starting the game, otherwise OpenTrack will reinitialze the headset runtime after vorpX. Better to let vorpX do it after OpenTrack to avoid any potential issues.
BTW: The next vorpX will come with fully automated TrackIR handling for F1 2019. Nothing to setup/configure anymore. Just launching vorpX and the game.
vorpX has to be run as admin since the game also requires admin rights for some reason. Normally vorpX shows a warning if it doesn’t have sufficient rights to hook a known game. Unfortunately that’s broken in the current public build, sorry for that.
There is a checkbox labeled ‘Run vorpX Control as admin’ in the config app on the ‘General’ page. That will do the trick.
BTW: Not really good practice for a game released 2020 to request admin rights, makes me wonder why they do that.
That wasn’t the point. You can still play with higher than 1080p resolutions on a 1080p monitor with an AMD card. AMD drivers are just more limited in which resolutions are available above the monitor resolution, nVidia is way more flexible in that regard. More an annoyance than a real issue though, just something one might want to consider when choosing between AMD and nVidia with a 1080p monitor.
Thanks guys. The only one from the games you mentioned that has an official profile is X3 I think, so I’ll stick to the popular ones from the original post as far as turning on the feature per default is concerned. For these games vorpX will auto enable TrackIR in the game options if possible (or tell you how to do that if not).
I’d very much liked to have everything automated even for untested games, but since in many games TrackIR has to be enabled in the game options, just checking whether it is present is not enough to be sure that it’s actually active unfortunately.
You will however be able to easily enable the feature yourself in any game where vorpX can detect TrackIR support. Whenever that is the case, there will be a notification about TrackIR being available and an according option on the ‘Head Tracking’ page of the vorpX menu. So in untested games you’ll basically just have to turn on TrackIR in the game and in vorpX and in the majority of cases you should be good to go. Still way, way more streamlined than having to configure everything manually for TrackIR as before.
I’ll try that, thanks. Should definitely not happen unless mouse acceleration was turned on when you started vorpX. vorpX normally reads the current state on start and then resets it after exiting a game if it was foced off by the profile.
On a sidenote: you can exclude programs in the config app. Might make sense to add s3pe/s4pe to the exclude list.
Huh? The only time vorpX would ever touch the system wide mouse acceleration is when it is set to off in a profile for better head tracking. vorpX on exit would then switch it back to the original state. I’ll check whether there is something wrong with that all of a sudden, but that doesn’t sound overly likely. The related code hasn’t been touched in years.
BTW: Forcing the global mouse acceleration off via vorpX isn’t necessary for most newer games. Only makes sense for older games that use the standard Windows mouse input pipeline. Most newer games use the raw input API and aren’t affected by the system wide mouse acceleration. Games may have their own though. Profiles with DirectVR auto settings handle that automatically whenever possible, but in non DirectVR games any potential mouse acceleration setting should best be turned off for consistent mouse based head tracking.