Exposing VR variables in menu and using HMD for direction

[VRtinker]

@DrBeef First of all thank you so much for your work! It's really awesome to be able to revisit HL on Quest! Thanks for making it possible!

I pulled a fork of your repo and made changes to create a VR Options menu under the Configuration menu, but I couldn't figure out how to do this cleanly (i.e.: creating an adhoc VROptions.cpp file, properly linked and referenced throughout the project), so I ended up reactivating the Touch menu that I see it's not being used in VR (so ever), and "repurposed" it.

The menu though keeps showing as "Touch" no matter what I try to rename it, but it is otherwise fully functioning.

Could you point me in the right direction regarding creating a specific menu instead of repurposing? Or renaming an existing one?

I'm aware that I'm doing a terrible job (visually at least) at handling the switch between snap and smooth turning, though it does work properly, in real time in-game as well, but switching on the HMD for direction option (vr_walkdirection), not so much

I've noticed this is the case with the release in general, not just my fork, but when I switch to HMD for direction, while it does indeed start using the HMD instead of the off-hand controller, the directions on the thumbstick (left one in my case) go completely out of whack. They get inverted and crossed with each other depending on where i'm looking, so sometimes I would have to push left to go straight up while i'm looking right, something crazy like that :P

So I'm wondering: is vr_walkdirection not supposed to be fully working right now?

Cheers,

[DrBeef]

Hi @VRtinker

First off, great to hear someone else is getting involved!, adding a VR options menu was on my list but not particularly high up, so if you are able to implement it I would be extremely grateful.

I'm afraid that I've not really tried to do much with the menu options though, so your guess is probably as good as mine at the moment. I do know for a fact that a lot of the menu resources come from the xash_extras.pak file which is copied as the application starts up. The reason it continues to say Touch instead of VR Options is probably because it is using the Touch graphic from that pak file. This means you'll need to unpack the pak, modify the resources and then re-pak it in the appropriate format (I think there's a python sctipt to do it, but I just used the default pak with xash so haven't tried it).

As for HMD oriented directional movement, I didn't fully implement that yet, so only controller oriented works correctly for now. Though I am hoping to properly update the HMD oriented movement (vr_walkdirection = 1) soon.

Keep me posted on your progress, would be exciting indeed to accept the first pull request!

All the best @DrBeef

[VRtinker]

So, that was easy :) I followed your advice (thanks!!) and found all those treasures in the extras.pak file. I used PakScape to look inside and easily drag and drop, in and out, the file to modify (btn-touch.tga in this case). I think I might get back in it a little deeper and maybe see if I can update the other existing buttons that are particularly blurry, like the menu banners (like "Configuration" in the screenshot), but first I'll try to make snap turning become disabled (i.e.: turn gray) when smooth turning is active and viceversa (this is already happening anyway, but seeing either one disabled is going to help avoid confusion)

While we are at it, is vr_weapon_recoil working? I had it in the menu in an early revision but I couldn't tell if the variable was doing anything.

I also tried putting a slider for vr_weapon_pitchadjust but couldn't tell as well if anything was happening or supposed to happen. I'm also not sure that the user will want to change that if the default angle is already correct.

Will hopefully get back with more progress!

Cheers,

[DrBeef]

Good stuff!!, you are making good progress indeed. Looking forward to the pull request!

is vr_weapon_recoil working?

Yes, if you turn on the weapon recoil then your whole view jumps with the recoil which would make a lot of people pretty ill

[VRtinker]

Hey!

I continued iterating on this and pushed the changes to my fork. Problem is I synced the fork with your latest commits, up to here, and now the project doesn't build anymore for me. At any rate, if you want to grab the files that add the menu, go ahead (Configuration.cpp, Touch.cpp, extras.pak). In the meantime I'll try to figure out what's wrong with the compiling...

If vr_snapturn_angle could be spilt into two variables (vr_snapturn_angle and vr_smoothturn_speed for example) we could use two spincontrol elements to set them. As it is I'm only using one because otherwise they both control the same variable and the narrower intervals used to change smooth-turning cause the snap-turning changes to also move by the same amount (0.5 instead of 15).

Sadly I couldn't find a way to make anything other a checkbox toggle it's visibility without a restart, but I still have hope

[DrBeef]

Wow, that looks really good!, great stuff!! I could split that cvar into two, but then I would need a third that indicates which of those two cvars is the one to use. Happy to do that, might make things cleaner, but there would be an overhead of a switching cvar too.

The reason it isn't building for you now is that I had to restructure the projects due to license issues. I have forked the HLSDK project from the Xash3D repo, which has to be separately licensed using the Valve Half Life 1 SDK License (cannot be GPL). Therefore there are now two github repos.

Sounds complicated, but is relatively easy to work with. Once you have updated to the latest code in the Lambda1VR repo, you then need to clone the xash3d-hlsdk repo (just look at my other repositories) into the Lambda1VR\Projects\Android\jni\src folder. Once you've done that, you should be able to build again.

Let me know if you still have issues, if it is all good I'll make sure the readme is updated accordingly.

Thanks for doing this, people will really appreciate a proper VR options menu!

[VRtinker]

So I solved the compilation issues soon after I posted my last message. It was indeed the moving of the HLSDK repo, I missed that in the readme initially, you should definitely make it more prominent :P Another thing I noticed is that when you download a zipped clone of the repo, if you just decompress it in the VrSample folder as is (Lambda1VR-master) it won't work, it needs to be renamed to Lambda1VR (not sure if this is always the case with any other project, but I don't seem to recall having come across something like it before). Also the local.properties file points to: ndk.dir=C\:\Users\Simon\AppData\Local\Android\Sdk\ndk-bundle sdk.dir=C\:\Users\Simon\AppData\Local\Android\sdk so you always get an error about the path being wrong (I guess unless you have a user in your PC named Simon :P)

Anyway, I'm getting some major issues with the latest commits. Both with your version and mine, the left stick is not controlling the direction anymore, the head is! and it's not just the direction, but the movement too. I'm also experiencing a regression inside the menus. Moving a slider has become a hit&miss type of deal. I thought this was my doing, so I tried with your "vanilla" version, but I'm getting the same results when trying the sliders in Audio or Video Options menus.

Help!

[DrBeef]

Don't worry.. i completely buggered the positional tracking with my last commit. I'll get the fix in a bit later hopefully.

On Sun, 4 Aug 2019, 19:30 VRtinker, notifications@github.com wrote:

So I solved the compilation issues soon after I posted my last message. It was indeed the moving of the HLSDK repo, I missed that in the readme initially, you should definitely make it more prominent :P Another thing I noticed is that when you download a zipped clone of the repo, if you just decompress it in the VrSample folder as is (Lambda1VR-master) it won't work, it needs to be renamed to Lambda1VR (not sure if this is always the case with any other project, but I don't seem to recall having come across something like it before). Also the local.properties file points to: ndk.dir=C:\Users\Simon\AppData\Local\Android\Sdk\ndk-bundle sdk.dir=C:\Users\Simon\AppData\Local\Android\sdk so you always get an error about the path being wrong (I guess unless you have a user in your PC named Simon :P)

Anyway, I'm getting some major issues with the latest commits. Both with your version and mine, the left stick is not controlling the direction anymore, the head is! and it's not just the direction, but the movement too. I'm also experiencing a regression inside the menus. Moving a slider has become a hit&miss type of deal. I thought this was my doing, so I tried with your "vanilla" version, but I'm getting the same results when trying the sliders in Audio or Video Options menus.

Help!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DrBeef/Lambda1VR/issues/22?email_source=notifications&email_token=ABPB5MD7TKECI4YGULNKIODQC4N53A5CNFSM4IJBJU72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QHDDY#issuecomment-518025615, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPB5MDEXTDSFJ3GDWD26D3QC4N53ANCNFSM4IJBJU7Q .

[DrBeef]

Should be fixed..

[VRtinker]

The last commits do indeed fix all the movement issues, but I'm getting a strong performance regression across the board. The game is barely ever hitting 50fps, but mostly in the 30s. I think that whatever is causing this is also responsible for the sliders in the menus to be so sluggish, unresponsive. I quickly tried the release build I had uploaded in my fork, and even though it's old now, it runs at a great FPS with uber responsive menus.

I'm not sure if this is due to the lower framerate, but the rotation speed felt like it took a hit too. Previously 2 of 5 in the slider (vr_snapturn_angle=1.5) was my go to speed of choice, getting too fast (for me) with anything above that. Now 5 of 5 (vr_snapturn_angle=3) seems still too slow

Would you like me to change all the other menu-titles as well so that they all look like the ones in the screenshots (like "New Game", "Load Game", etc)?

Let's get those FPS back!

[DrBeef]

Yeah, I'm aware of the performance issues, not sure which of my recent commits introduced it, but narrowing it down when i get the chance. Rotation speed would be affected by the performance, so not surprised is gone bad. Hopefully I'll get a bit of time later to take another look at it.

On Sun, 4 Aug 2019, 21:12 VRtinker, notifications@github.com wrote:

The last commits do indeed fix all the movement issue, but I'm getting a strong performance regression. The game is barely ever hitting 50fps, but mostly in the 30s. I think that whatever is causing this is also responsible for the sliders in the menu to be so sluggish, unresponsive. I quickly tried the release build https://github.com/VRtinker/Lambda1VR/releases I had uploaded in my fork, and even though it's old now, it runs at a great FPS with uber responsive menus.

I'm not sure if this is due to the lower framerate, but the rotation speed felt like it took a hit too. Previously 2 of 5 in the slider (vr_snapturn_angle=1.5) was my go to speed of choice, getting too fast (for me) with anything above that. Now 5 of 5 (vr_snapturn_angle=3) seems still too slow

Would you like me to change all the other menu-titles as well so that they all look like the ones in the screenshots?

Let's get those FPS back!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DrBeef/Lambda1VR/issues/22?email_source=notifications&email_token=ABPB5MG72N47LHUSR5B6JFDQC4ZZJA5CNFSM4IJBJU72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QIZIA#issuecomment-518032544, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPB5MCSSBMIVP4HKGPLIMDQC4ZZJANCNFSM4IJBJU7Q .

[DrBeef]

Performance issue should now be fixed, scroll bars seem to be working correctly again too.

On Mon, 5 Aug 2019, 12:25 Simon Brown, simonbrown77@googlemail.com wrote:

Yeah, I'm aware of the performance issues, not sure which of my recent commits introduced it, but narrowing it down when i get the chance. Rotation speed would be affected by the performance, so not surprised is gone bad. Hopefully I'll get a bit of time later to take another look at it.

On Sun, 4 Aug 2019, 21:12 VRtinker, notifications@github.com wrote:

The last commits do indeed fix all the movement issue, but I'm getting a strong performance regression. The game is barely ever hitting 50fps, but mostly in the 30s. I think that whatever is causing this is also responsible for the sliders in the menu to be so sluggish, unresponsive. I quickly tried the release build https://github.com/VRtinker/Lambda1VR/releases I had uploaded in my fork, and even though it's old now, it runs at a great FPS with uber responsive menus.

I'm not sure if this is due to the lower framerate, but the rotation speed felt like it took a hit too. Previously 2 of 5 in the slider (vr_snapturn_angle=1.5) was my go to speed of choice, getting too fast (for me) with anything above that. Now 5 of 5 (vr_snapturn_angle=3) seems still too slow

Would you like me to change all the other menu-titles as well so that they all look like the ones in the screenshots?

Let's get those FPS back!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DrBeef/Lambda1VR/issues/22?email_source=notifications&email_token=ABPB5MG72N47LHUSR5B6JFDQC4ZZJA5CNFSM4IJBJU72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QIZIA#issuecomment-518032544, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPB5MCSSBMIVP4HKGPLIMDQC4ZZJANCNFSM4IJBJU7Q .

[VRtinker]

Sadly, I'm not getting good framerate from the latest commits! The highest it gets to seems to be 48FPS when facing a corner while looking at my feet :(

EDIT: I synced my fork with your repo, then added my changes and posted a build if you want to check it out. If you say that performance are fixed, I'd appreciate if you could see if you get the same results with my build. I don't think I'm doing anything that could affect the framerate, so I'm curious to find out if I am really getting worse performance than you are.

I took the liberty of rearranging the controls a bit, mainly for two reasons:

1) NO chance of rotating while ducking with the current layout (unless you have a second right hand that is :P) 2) More often than not, I would trigger the inventory overlay unintentionally, causing death, depending on the situation, or either way, frustrating every time

I wrote all the details in the commit comments

I will hunt down when the regression started, at least for me and let you know.

[DrBeef]

Turns out I had over egged the super-sampling, so as soon as there was a decent amount going on the framerate dropped. I have changed it to 1.25x (applied to both horz and vert directions, so would be the equivalent of a 1.56x Steam VR super sample for example). Give it a try.. there really isn't anything else in there that would be affecting the framerate after this.

[DrBeef]

Regarding the control scheme, part of the reason I split left and right into separate implementation files was so it would be easy to add further control schemes that are similar but different in some way. I think your control scheme could be alright (haven't tried it yet), but it should be in addition to the existing scheme for those that are used to it. Also I can't see what you have done with the screen layer button (for enabling the big screen for cinematics)?

Configuring this could be something for the VR Options configuration perhaps. I was going to add a new cvar which controls which scheme was being used (which would also change the r_efthand cvar if needed). I would suggest control scheme changes are held off on until the basis for adding further schemes easily is in place.

[DrBeef]

I just committed the change for the control scheme enumeration which should allow adding of new control implementation files that can be used for different schemes. Hopefully it makes sense (it's pretty trivial tbh)

[VRtinker]

I haven't had the chance to test the latest commits, but honestly I have very low hopes that the supersampling setting is the issue. It was still set at 1.2 when I first reported the issue (I now realize that when I initially reported about the menus being sluggish and the later reported fps drops are actually the same issue). The supersampling was changed to 1.5 on this commit, while I think the issue started on or around this commit

I've left the screen layer button untouched, btw

Regarding the controls remapping, while I'll try to figure out how to use the new scheme selection feature, I just wanted to mention (perhaps reiterate) that the current scheme makes it impossible to duck while using the thumbstick, so it's not so much about trying to push a personal preference, as much as fixing maybe an oversight, and the griptrigger is the only candidate for the task since it's the only one you can reach, having already your index on the trigger and your thumb on the thumbstick.

The relocation of the Reload button was necessary because if left on the griptrigger when ducked you couldn't select a weapon from the inventory due to the condition in place for the use of the trigger when the griptrigger is pressed.

The relocation of the Use button as the long-press version of the Reload button made sense since you need to long-press it anyway to recharge, and so the only thing to remember is to hold it more than 1/5 sec to activate a switch.

The inventory related remap is a QoL change as if you use smooth turning (so you pretty much always have your thumb on the thumbstick) you are bound to launch it inadvertently, and also, even more annoying, the current scheme would pretty consistently glitch out on me switching weapons on it's own while shooting and moving both thumbsticks at the same time, like when you are retreating while sweeping and shooting left and right. The thumbstick click + thumbstick up/down, not only prevents all of the above, but also feels right ! Ok that might be my personal preference getting in the way, but clicking down the stick while also pushing up/down gives a more solid feedback than flicking the stick alone (if that make any sense at all)

EDIT: From a build with the latest commits

:(

[DrBeef]

On the performance thing.. I just tested the very latest from the repo and I was getting circa 56fps in the room you show above.. the last released version (1.0.3) I'm getting the same FPS, so I'm not seeing any performance degradation with the way things currently are. Hopefully if you update you see the same?

[VRtinker]

Hey, so I updated but still get the same crappy FPS :(

But I have "good" news! When I compile a build from this commit I get this result:

When I compile from the commit that follows the aformentioned, now known as the infamous Some CVAR changes I get this result:

Now why in the world do I see such a sharp decrease in performance when you don't? Are you sprinkling your apk with some extra magic after it's compiled? :p

I looked at the changes of "Some CVAR changes" and it's all essentially largely related to "vr_stereo_side", so I'd imagine the problem lies there. But again, how and why would my Quest underperform? :((

EDIT: Now here is the crazy part! I just tried the latest commit INCLUDING my changes and the framerate is great again (but not without them)!!! On another note, switching to left-handed in my menu doesn't work anymore. I switched from "hand" to "vr_control_scheme", but I'm not getting what else I need to do. As soon as I flip vr_control_scheme in menu, the controls are switched to the left hand, but no pointer comes out of the left controller, so all I'm left to do is push the Oculus Home button to exit. Do I need to assign 1 to "hand" (or r_lefthand) and "vr_control_scheme" at the same time?

[baggyg]

The mentioned commit did introduce performance trouble. I think Dr Beef is aware of that (as you say vr_stereo_side). The problem with your logic is that this was then fixed by this commit: https://github.com/DrBeef/Lambda1VR/commit/b615b5c2e4b226ff83a2eec5404b9df799ebda2f So the performance after that should match what was before the commit you mention.

[DrBeef]

Hi, apologies for the radio silence for a while. Was wondering how your changes were coming along (or if they had stalled as I hadnt got back to you?) as I would be keen for them to be included in the next update (will be v1.1.0). Regarding your query on the control scheme.. when you say you:

As soon as I flip vr_control_scheme in menu

what value are you setting it to?, not sure I mentioned that 0 is right handed default, 10 is left-handed default.. if you were switching it to 1, then it wouldn;t work (and might do as you are seeing). Now the hand cvar is being set automatically depending on the control scheme selected, so you shouldn't need to do anything with that cvar at all now. Good to hear your performance is now mysteriously correctly.. by the way, did you ensure that the sub-project hlsdk was up to date?, I wonder if that might have been the cause of the issues you were seeing. I would be keen to pick up your alternative control scheme too, but I still think it would be better as an alternative to the default. I don't play with smooth turning turned on, so don't have the issue with it accidentally switching weapons.. and whilst I see your point about not being able to switch weapons while crouching, I do intend to add a physical crouch mechanic in the future, which would sort of work around that. Hit me back, eager to hear how things are progressing if at all. Simon / DrBeef

EDIT: the reason 0 is right-hand and 10 is left-hand is so that additional control schemes for each hand can be inserted between, right-hand-2 (ID: 1) could be better for smooth turning for example and the left handed version would be left-hand-2 (ID: 11), they are defined in an enumeration in the main Lambda1VR c file

[VRtinker]

Hey Doc,

I'm really sorry for MY radio silence! "Unfortunately" a few days after your last message I bought a house! All my digital life took a toll because of that :P

But aside from that, I did get very sporadic opportunities to jump on the project a few times and completed the update to the menu titles everywhere (SP and MP). I couldn't, for the life of me, figure out how to create more control schemes to use the new Lhand/Rhand slots (I could definitely use a left or right hand there to get me started :P A "template" would be awesome). If I had that under my belt on the other hand, getting a slider to pick your selection in the menu would be a pretty trivial task to complete.

In anticipation that the solution will somehow manifest itself and land on my lap, I toyed around with displaying an image of the Touch controllers that shows the button bindings (I haven't tried to hook it to a slider to see if the image can change on the fly when you change selection though).

Since I got a chance to test a few mods (and enjoyed them), I looked (very briefly) into porting from the Vita version of Xash3D its mod menu launcher and/or activating the custom game menu that's already in the game, but I struggled finding sufficient documentation to grasp what's needed to be done (maybe I didn't look long or hard enough).

If you can provide me a snippet of what a control scheme should look like, I can definitely build from that and most importantly, try to find the time to do so! Jammed as I am with house moving stuff right now, I simply can't afford the luxury of devoting time to research :-(

Cheers

[DrBeef]

Hi!

Woohoo!!, it's good to hear from you! Firstly, congratulations on the house purchase, having done it a couple of times I understand how much effort and time it requires, so totally understand the radio silence, no need to apologise. I hope the move went smoothly and things settle down quickly.

In anticipation that the solution will somehow manifest itself and land on my lap

Absolutely.. I'll make a change to add an extra left/right hand controller configuration slot (will be the same as the default implementation, I'll let you fill in the details..) so you can see what I meant. Hopefully then it is simply a case of updating the new control config slot with your implementation and it is good to go. An image showing the controllers and their button mappings would be fantastic if you are able to get that going!, I'll drop a message on this thread once the additional control config sources are committed.

Whilst I was hoping to do some sort of release within a couple of weeks (people keep asking), I am happy to wait a bit more if you need time to wrap things up your end, especially given how busy I imagine you are, your proposed changes would be a big quality of life improvement for a lot of people unwilling to mess about with cvars directly.

Cheers Simon

On Mon, 2 Sep 2019 at 09:36, VRtinker notifications@github.com wrote:

Hey Doc,

I'm really sorry for MY radio silence! "Unfortunately" a few days after your last message I bought a house! All my digital life took a toll because of that :P

But aside from that, I did get very sporadic opportunities to jump on the project a few times and completed the update to the menu titles everywhere (SP and MP). I couldn't, for the life of me, figure out how to create more control schemes to use the new Lhand/Rhand slots (I could definitely use a left or right hand there to get me started :P A "template" would be awesome). If I had that under my belt on the other hand, getting a slider to pick your selection in the menu would be a pretty trivial task to complete.

In anticipation that the solution will somehow manifest itself and land on my lap, I toyed around with displaying an image of the Touch controllers that shows the button bindings (I haven't tried to hook it to a slider to see if the image can change on the fly when you change selection though).

Since I got a chance to test a few mods (and enjoyed them), I looked (very briefly) into porting from the Vita version of Xash3D its mod menu launcher and/or activating the custom game menu that's already in the game, but I struggled finding sufficient documentation to grasp what's needed to be done (maybe I didn't look long or hard enough).

If you can provide me a snippet of what a control scheme should look like, I can definitely build from that and most importantly, try to find the time to do so! Jammed as I am with house moving stuff right now, I simply can't afford the luxury of devoting time to research :-(

Cheers

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DrBeef/Lambda1VR/issues/22?email_source=notifications&email_token=ABPB5MBL422E7QN2OXJOOOLQHTGCRA5CNFSM4IJBJU72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5VEDBI#issuecomment-527057285, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPB5MH7CAKI3UVNE2U6QO3QHTGCRANCNFSM4IJBJU7Q .

[DrBeef]

OK, so I just committed the changes required to add an alternative control scheme for left and right handedness. This is the commit: https://github.com/DrBeef/Lambda1VR/commit/84d113618eac57de8265a0c3bd56894ab7548f1d

You can find the control scheme enumeration in L1VR_SurfaceView.c. enum control_scheme. But you won't need to do anything with that as I have added the two additional control scheme source files which just need your alternative implementation added to them.

Then when you implement the selection of control scheme, it just needs to pick the appropriate values from the enumeration:

enum control_scheme {
    RIGHT_HANDED_DEFAULT = 0,
    RIGHT_HANDED_ALT = 1,
    LEFT_HANDED_DEFAULT = 10,
    LEFT_HANDED_ALT = 11,
    GAMEPAD = 20 //Not implemented, someone else can do this!
};

Hope that makes sense!, if not, then just hit me back and I'll try to be a bit clearer.

[VRtinker]

FINALLY I think i see now what needs to be done, thanks! Sorry it took me 3 days, just to check-in again, but this moving is absolutely killing me! The only upside is that I get to play real-life Tetris everytime i load the car, so at least I'm keeping my gaming going :) I only got 2 more days of struggle ahead of me (today and tomorrow), as only the real heavy stuff is left to be moved (and got movers coming tomorrow to help out).

This is all to say that I'm relatively confident that I should be able to be back on this by tomorrow night/Sunday morning. I've got a good picture of what I need to do in my head, so if that pans out, I should have something working by Sunday night (I don't have internet in the new place yet, but that might be a phone call away - dunno, haven't called the ISP yet). Either way, between mobile data and neighbor's piggybacking I should still be able to push the commit.

More later

EDIT: Just a quick update, I tried to merge the new commits into my fork, but it says I can't, so i need to hunt down the conflicting changes (hopefully it won't turn into a major ordeal). This may or may not delay me a lil...just wanted you to know. OK, back to packing

[DrBeef]

Hi!

Just wondering how things are going?, hope the house move is now pretty much sorted.

I made some structural changes lately which is probably what broke the merge, sorry about that! Let me know if you need any pointers.. looking forward to merging your changes into the main branch when you/they are ready.

Cheers Simon

[VRtinker]

Hey,

I'm pretty much done with moving and got a spanking new internet connection at the new place, last thing missing is hooking up the PCs in their rightful spot (currently in progress) I should be back online and on half life duties tonight. Looking at the changes, it will probably just be easier/faster to re-mod your source then attempting a merge. I'll update you in the next 12-18hrs.

Cheers

[DrBeef]

Hi, did you get anywhere re-modding the updated source?, was also wondering if you were planning on adding the button-mapping-controller images you had mentioned, or if you'd decided against that? Cheers Simon

[VRtinker]

Sorry man, I hit a snag immediately after I sent my last message (still moving relatedo). For whatever reason, I need to underclock my cpu to keep my pc on. The wall plug seems to not be able to feed enough power to run my setup at full capacity :-( it took me several hours to come to this conclusion (that I honestly never heard of), so that's why I missed my initial estimate to get back with results. But everything is up and running now, and i'm getting on it once I sent this message. I'm still shooting for porting every and all changes I made, and also saw you added a few cvars so I will also plug those into the menu.

As usual, more later (but for real this time, short of lightning striking the house! But it's clear sky right now, so we should be good :-) )

EDIT: taking a closer look at the commits, seems like the available cvars have increased considerably, so it might get a little crowded. I might split the controls related cvars into a separate menu, like "VR Controls" and keep the rest in "VR Options", or something along those lines, just so you know

[DrBeef]

Hi!

Don't know if you saw (I expect you did) that we went ahead with a release of 1.1.0, people were chomping at the bit to get it, and we figured that any further updates could easily follow on in a incremental release. On that subject, have you had any luck with your changes assuming that the house move is now mostly sorted?

Just seen your edit on your last message, not sure when you added that, but an extra menu for controls sound like a good idea to avoid overcrowding!

Hit me back when you have a chance, keen to hear how you're getting on, Cheers Simon