Forum Discussion
The "Player" settings...
Ok, so at first I was scratching my head as to why in the world that little launcher wouldn't come back no matter what I did since I went up to 0.4.0. Problem being, for the most part, that I count on that launcher for my input settings. I have the capability of offering dual stick controls, so it's kind of great to have.
Now, I finally got what this ShimLoader script was doing - not the easy way - I recently lost my project's unity database (ProjectSettings, Library, etc) and had to rebuild; prior, the preference setting for some inexplicable reason would always be true while the "optimize for rift" box was unchecked. Sure enough at first I would re-enable the player not minding to notice it would snap back via the ShimLoader script. Finally having noticed the setting snap back, before the repair I commented out the ShimLoader lines that would snap the setting back... not optimal. After the repair the checkbox worked normally and I could get my launcher without touching the OVR scripts.
Now... what we want ultimately is the OVR optimized build WITH launcher. Why? Input. Us one man shows have a severe time squeeze and we don't always get to make an in-game input menu - it' s just a plain reality. We kind of rely on that little input tab that's pre made and ready to go.... but I understand where Oculus stand: between a rock and a hard place that sucks. I can't build one that produces a launcher that offers only the one correct resolution. This thing really wants to give the user variety that will cause things to not work at all.
The key here is to get the launcher back on by default, with a mod that forces it to only offer one res. So far no luck, so I guess that's why Oculus opted to diable it. Can't blame you, but we're a little stuck too here. Hope it can be resolved on the long run.
Now, I finally got what this ShimLoader script was doing - not the easy way - I recently lost my project's unity database (ProjectSettings, Library, etc) and had to rebuild; prior, the preference setting for some inexplicable reason would always be true while the "optimize for rift" box was unchecked. Sure enough at first I would re-enable the player not minding to notice it would snap back via the ShimLoader script. Finally having noticed the setting snap back, before the repair I commented out the ShimLoader lines that would snap the setting back... not optimal. After the repair the checkbox worked normally and I could get my launcher without touching the OVR scripts.
Now... what we want ultimately is the OVR optimized build WITH launcher. Why? Input. Us one man shows have a severe time squeeze and we don't always get to make an in-game input menu - it' s just a plain reality. We kind of rely on that little input tab that's pre made and ready to go.... but I understand where Oculus stand: between a rock and a hard place that sucks. I can't build one that produces a launcher that offers only the one correct resolution. This thing really wants to give the user variety that will cause things to not work at all.
The key here is to get the launcher back on by default, with a mod that forces it to only offer one res. So far no luck, so I guess that's why Oculus opted to diable it. Can't blame you, but we're a little stuck too here. Hope it can be resolved on the long run.
7 Replies
Replies have been turned off for this discussion
- *update*
Ok.... now the unchecked/checked problem is back.... whether I check the box or now ShimLoader snaps the player settings back. I'll have to do this in the script. So note to the Oculus guys... the checkbox setting starts acting up after you build a fresh project... it started behaving like this again after the first build following my repair.
The other problem I'm facing is the launcher res options are still relevant for the non-vr build of my game. Sooo.... gonna have to stick to editing ShimLoader after all.
So there... I'll leave most the code just comment out the one setting I want to change. Others are fine. Notice the debug output in the last screenshot with the setting apparently disabled.
static void Update()
{
// Suppresses the resolution dialog and sets Rift-optimized launch settings.
if (_isEnabled)
{
Debug.Log("Dude, it's enabled");
//PlayerSettings.displayResolutionDialog = ResolutionDialogSetting.HiddenByDefault;
PlayerSettings.defaultIsFullScreen = false;
PlayerSettings.defaultScreenWidth = 1920;
PlayerSettings.defaultScreenHeight = 1080;
}
}
- +1 I want the resolution dialog window too.
For now if you play demos that use hidden by default you can hold ALT while opening the game to get into the settings. - I would much rather see someone make an input mapping UI script that works in VR. The launcher one is pretty poor even if you discount the fact that it requires you to leave VR to use it. The default mappings are also terrible for those games that try to use the mapping system. If you have any input device other than a gamepad plugged in you are likely to spin in circles constantly.
From a user perspective, it will be absolutely critical to make sure that you can launch a game from within VR, without having to take off your HMD to click on a window button. - Here is a workaround for forcing the configuration dialog in Unity builds.
Hold Ctrl while launching to enable the configuration dialog.
This should work for both direct and extended mode exe's on Windows. No idea if this works for Mac's.
But Id rather prefer the Oculus SDK .4 didn't lock the option in Unity. It's up to the developer if he wants to enable the dialog or not. I want my demos/games to launch the dialog by default, so the end-user can set resolution and tweak input config if he needs to. - Holding keys when launching takes time to explain to less savvy users and is NOT a solution let's just make that very, very clear. I'll take it as a work around but it's really a trashy way to get around the problem, nothing more. The thing eats up a whole paragraph in my game instructions, it's ridiculous. (Double click the exe then hold ALT but make sure you hold ALT at the speed of a greek lightning god)
So short term, all good.... long term? No, that's not a solution.
Right now the way the lib is written looks like the library decides, not the developer. Unless said developer can modify ShimLoader.cs and fix its bugs, something some may actually not be able to do. I noticed some folks making Unity games with almost no programming.... i didn't even know that was possible, but it apparently is. Those folks won't have it so easy editing ShimLoader.
I made myself my own boolean in ShimLoader that I edit manually. OVR's own boolean setting is broken and I frankly got lazy when I found out and replaced theirs with mine instead of fixing theirs. "owenwp" wrote:
I would much rather see someone make an input mapping UI script that works in VR.
That's .... seriously I don't even know what to say. Do you know how fucking LONG that takes?
Sorry for the language but really man... I'll stop here. That statement made me angry."owenwp" wrote:
The launcher one is pretty poor even if you discount the fact that it requires you to leave VR to use it.
The launcher options are wretched I agree but bloody hell, for us one man shows do you have any idea how it's one extremely annoying part already done for us? At this stage in my programming experience I'll take it with open arms."owenwp" wrote:
From a user perspective, it will be absolutely critical to make sure that you can launch a game from within VR, without having to take off your HMD to click on a window button.
Well many games have launchers, Rift games are doubly likely to have one because said launcher would contain the code to force the game's output to show up on the Rift. Thing is at the launcher moment you don't have your Rift on yet... if you do you're too excited! :) Click Play, then put on.
Neeway we already have the delightful health warning which is not annoying at all Oculus. Please have it display twice even I also love how it kicks the mouse pointer out of the extended window. :) (Seriously hehehe that thing needs work it's right now broken)"budwheizzah" wrote:
We kind of rely on that little input tab that's pre made and ready to go.... but I understand where Oculus stand: between a rock and a hard place that sucks. I can't build one that produces a launcher that offers only the one correct resolution. This thing really wants to give the user variety that will cause things to not work at all.
Sorry for the trouble here. As you pointed out, we suppress the resolution dialog because most aspects of it need to be locked down for VR to work. We chose to suppress it rather than let the user pick settings that would be ignored by _DirectToRift.exe. Is there any chance you could lock down your input mappings for VR builds or use a third-party input manager from the asset store? There are a number of free ones that may work for your app. It's definitely not a good long-term solution to have your users hold ALT at startup (or modify OVRShimLoader) and tell them their display settings will be ignored."budwheizzah" wrote:
The other problem I'm facing is the launcher res options are still relevant for the non-vr build of my game.
For now, I would recommend separate builds for VR and non-VR versions of your game."budwheizzah" wrote:
So note to the Oculus guys... the checkbox setting starts acting up after you build a fresh project.
Thanks, we will get that fixed for the next release. For now, does it work to toggle the checkbox twice after creating a new project?
