AMVI_Rider

I will add this feature in the next version. Surface should be touch, so, you can use pinch-to-zoom and double tap to un-zoom, why do you use the gesture?

I'm waiting for some reports on other things then I will deliver a new public version with this fix. A little note on versioning: in the scheme I'm using 1.1.3.08 is 1.1 build 08. The 3 is the development stage with 3 meaning release (2 is RC, 1 is beta, 0 is alpha). https://en.wikipedia.org/wiki/Software_versioning#Designating_development_stage

The resolution thing is now ok and it is stopping later on, seems because you have steamvr installed on the surface but no hmd connected (this is because of a new piece of code). Additional fix is on the way. As the software is starting you don't need to stop AV and firewall anymore.

I don't know how the numbers I see in the log are generated, but there was a bug in that piece of code which may cause your issue. I sent you a PM with a link for a test version.

Some basic advice in case of this problems: Check that .NET Framework apps runs properly. VRK is targetted to .NET 4.7.2 which should be available in any properly updated windows machine. To check if 4.7.2 applications runs in your machine you can try this tool from MS: .NET Framework Setup Verification Tool (run it, select ".NET Framework 4.7.2" and click "Verify Now"). Disable antivirus or check ativirus log . I tested VRK with Windows Defender, but other AVs may not like it. Disable windows firewall or any firewall you may have running (or be sure that VRK is allowed). Send me VRK log and I will look for problems. The file is vrk.log located in C:\Users\<windows_user_name>\VRK\Logs. You can attach to an email (my address is in the quick start guide), or google drive / we transfer it. I know that some people installed it on Surface tablets and I own a Windows tables less powerful than yours, so, it should be "environmental".

A little update about compatibility. I started checking low(er) cost WinTab devices and today I got a new Huion H950P. The active area is exactly the size needed for the kneeboard, but the tablet is bigger and not suited for everybody IMHO: And now the bad news: their driver is quite good in terms of options for the average creative use, but the WinTab implementation is not complete enough to be used with VRK. Too bad I really liked the device at that pricepoint :( I'm trying to contact their support in the hope that they have some developer support.

So you need dynamic content after all. You won't notice in the current state, but I removed the browser in 1.1. I will keep this feature away until the implementation of VR controllers because, without them, interacting with the browser disturbs DCS (due to the focus change I mentioned in my previous post).

Yes, as far as you can strap it to your leg :smilewink: Configure VRK in server/client, disable WinTab mode and it should operate like in the first video. Oh I got them, sorry for not having replied. I decided to stabilize the last release before entering so now I can focus on the matter.

It has two modes of operation. At the current state, both will require some hardware, mostly for writing. Full featured tabled (Windows, Android to come) in client/server. This will use the tablet touch and pen as a slave device (first video) and some pictures in the post. Standalone with a pen tablet which is a "recent" name for digitizers a.k.a graphic tablets. These are cheap USB or Bluetooth devices that brings pen input to any PC. What VRK does different to any other VR overlay is: Writing, of course Minimal CPU usage because VR is updated only when needed (and not at constant rate) Not requires to take the window focus away from DCS when you write or navigate On the other side you can't put any application in it. But as soon as you don't need dynamic content and you can generate a PDF of the content you may not need that complexity. In my experience it is the 99% of what you need in flight and it is the closest thing to reality. Still, other type of tabs may be added in the future. Future plans include the support for VR controllers to navigate "documentation", BTW without any pen you will lose the big feature IMHO. Going back to your question: it's unclear to me what you mean with controlling via chrome tab. Can you describe the use case you have in mind?

Not yet. Since today my full attention is to bugs and problems and yours is on top of the list.

May I add my project to the list? https://forums.eagle.ru/showthread.php?t=246970 Also, I'm looking for people willing to test and report troubles and ideas.

Version 1.1.1.04 is out In this version I did a major overhaul of the Ink Canvas and WinTab support. Now the digitizer is not interacting with the mouse cursor that means that DCS will not loose focus due to writing in standalone mode. Also, I completely changed the detection of Focused mode which become more responsive. I also recorded another video that shows the operation in standalone+digitizer mode. Sorry for the quality, but I'm not a professional youtuber :smilewink: Now the tool is usable (in terms of features) and I would like to take some time to stabilize it as is before adding major things. Android project will follow if I find a proper HW. Frankly, the digitizer is so usable that I'm not using the tablet anymore. Thank you for any trouble report.

Exactly. So I think it's time to bring my HTC back to life ... For the time being I suggest to put the Default Alpha to 1.0 and maybe increse the Default size (at your discretion). So the non focused mode will be more readable.

Version 1.1 is out. I have a Rift S and an old Vive which is stored in a box. If the changes made in 1.1 and the increased logging doesn't point to a cause I will take it out of the box and try HTC here.

So seems that detection fired at least once but in your case is critical. Mind that there is a delay between the time you focus the kneeboard and the time it increases, There's a detection setting which I changed in 1.1, frankly it should not make any difference but maybe the Pro is somewhat different. I also added a video in the first post which shows how VRK is expected to look and operate. Let me know if something doesn't fit with what you see.

I never touched any OVRSteam settings. What kind of Oculus do you own? The "Focus" logic is mostly provided by OpenVR APIs. One thing I would like to check is the VRK log file that should report Focused state if the conditions are detected. It is located in C:\Users\<username>\VRK\Log. You may delete everything, start VRK, look at the kneeboard then close everything and send the file so I can check if it is the detection or the parameter switch that is not taking place. In the upcoming version (which will be 1.1) I added some debug information to try debug your situation.

Well, the options are not supposed to help for the alpha problem. They are there just to start the application. Can you post a screen shot of the settings and the VR? Are you changing VR settings in the server side of the application?

I created a new DCS link thet points to DCS.exe and then addded --force_enable_VR and --force_steam_VR to the target. The first forces DCS to start with VR enabled regardless the options and the second forces SteamVR mode. In this way I have two links: one for start DCS in regular monitor mode and the second to start it in VR withouth the need to switch options manually. On the alpha issue, does the size changes when you look at the kneeboard? Well for the sake of simplicity I'm considering only three scenarios: client/server with windows tablet standalone with a pen tablet (which is only a digitizer, not a "tablet") client/server with an android table The 1 and 3 full support touch and stylus as far as the stylus is a "proper" stylus and not a capacitive pen. Otherwise the option 2 is the best one. Naviganting the documents with buttons and gestures is really easy. Proper styluses, which I'm aware of, are Microsoft Surface Pen(Win), Samsuns SPen(Android), Huawei M-Pen(Android) and all of them require dedicated hardware on the tablet side. I don't know if there are active capacitive pens with the capability to work like a digitizer and letting the application to discriminate between pen and touch input. In that case let me know and I will have a look on how to support them.

I agree about the Android version. The fact is that the only pen based I have now is the Windows and that's why I started with it. In those days I almost completed the implementation of Wacom tablet for the standalone which has some pretty nice advantages over the client/server: Cost: the Intuos S is really cheap compared to a tablet, the size is OK to me Precision: the pen is far more accurate that the tablet one (at least the one I have) Two buttons on the stylus and 4 on the tablet The drawback is that the tablet is not touch so page switching is done with the buttons, zooming and panning with the pen. That brought the need of programmable actions for the buttons and, in the meanwhile, some code optimization of the writing panel. Also, the tab bar is now left of the main content to gain some area for the page itself. Anyway, I'm pretty happy with the feeling so far. Coming back to Android: any suggestion for a 8" class device with an acceptable stylus which doesn't cost much? As you may imagine, this project is heavily limited in budget.

Version 1.0.1.37 released Many fixes and client/server discovery implemented

Sure it will

Thank you, I hope so and that's why I released to the community. I felt the need of paper in the cockpit and that's one of the two reason that made me slight VR for flying, the other is readability-resolution and I see big improvements, so I thought it was the time to sole the paper thing. You are right about the keyboard, no support, but for a reason: I found it impractical in every scenario I tried it. In standalone mode the keyboard is captured by DCS and giving it to VRK means loosing control on the cockpit (also switching focus in VR is a nightmare IMHO). In server/client it is not expected that you have a keyboard attached (and easily accessible) to the client. Moreover, unless you connect also a mouse, the stylus is the only device that can move the cursor (and show where you are about to write) without acting on the application. So I feel that it is better to ask pilots to use a stylus tablet or buy a stylus pad rather than providing a bad solution. The standalone mode, at the current state, is of little use. It will became handy in conjunction with an USB or Bluetooth digitizer like Wacom ones (the Intuos w/ touch support seems interesting) or cheaper alternatives like Huion, XP-PEN and other chinese brands. The only concern I have is about their sizes: small devices seems too small while medium size are slightly big in my opinion, but I need to test first.

Have you been able to run it on the surface? I just added a link for the Quick Start Guide in the first post.

The intention is to keep a closed source for the core, but opening the protocol as soon as it will became stable (in between RC and Release). Not because I want to protect anything (no rocket science used) but just to avoid the proliferation of forks typical of the opensouce. Don't get me wrong on this: I fully support the opensource concept in many domains. I just think that the flight sim community is "too small" to take a real advantage from opensource. Modularity is the key. I may be wrong, and other people are following different paths (thank you Ciribob for SRS). I will open the source the day I will not be able to support it anymore. Going back to helping: any experience with iPad development? Android is not a problem, but Apple ecosystem is far from my area of expertise.

The client/server mode uses you home network (LAN). It is supposed that both are connected to your "home" network via cable and/or WiFi. I will be back with some instructions very soon, maybe with a video if I manage to get the overlay recorded too. Frankly I'm thinking of completely changing the network setup part with some kind of automatic discovery of the two machines (for many good reasons). For the connection, the only parameter you have to change is the network address field on the CLIENT machine. In this field you have to put the LAN IP address (a.k.a internal network address) of the SERVER machine. If you don't know how to obtain it follow these instructions: https://www.digitalcitizen.life/find-ip-address-windows These address are usually in a form like 192.168.x.y (usually x = 0 and y is an "arbitrary" number from 1 to 253). Once you put this address in the "Network Address" field of the CLIENT configuration, click OK. Don't change the port unless you absolutely know what you are doing. In any case, put the same number in both CLIENT and SERVER. Everything else is fine for your first test. Once the configuration window closes, the CLIENT tries to establish the connection with the SERVER. As you will see, when the connection goes up the big red cross in the server application (which indicates that the connection is down) will go away. Also, the CLIENT title bar will change showing the "CONNECTED" indication. Re-connection in case of connection loss is automatic. Meaning of the other parameters Virtual Reality checkbox: enables the VR rendering on the helmet (if availabe). You have to set it on on the SERVER. Setting it off on the CLIENT is not required unless you have a visor installed on the client too. Yaw, Pith, Roll, X, Y, Z is the pose (position+orientation) of the kneeboard in the virtual world. The zero is your head. Default values is approximately on top of your right leg. Default/Focused Width is the width of the kneeboard in the VR. Default is when you are not looking directly at it. The application will switch to the Focused value when you are directly looking at the kneeboard. Default/Focused Alpha is the opacity of the kneeboard with 0 meaning completely transparent and 1 completely opaque. Also in this case the two values are switched automatically when you look at the kneeboard. Focus delay It is not used at the moment. In the future it will let you change the delay between the switch from Default and Focused representation. When I say "look at the kneeboard" I mean that the kneeboard is in front of your eyes. Thank you, yes the URL is that one. Hope to have some feedback from you guys! The application lacks of some polishing and maturity because I'm focused more on the behavior and use cases, time will bring all the little things.