karn1948

There's already a baseline standard that seems to be developing: OpenVR. It's supported by all three headsets that you can actually buy right now- Oculus Rift, HTC Vive, and OSVR dev kits. I think it's reasonable to assume that any smaller HMD would support OpenVR by default. The Oculus API tries to add some creative features on top of what OpenVR supports, but I've tested games in both modes on my DK2 and if a developer doesn't support the Oculus API it's not that much of a loss. I see the market currently as very similar to the early days of 3d accelerators. Every vendor has their own api that they think is best, but there's also a lot of effort being put into standardization and interoperability. The hardware manufacturers know that they can't survive on their own API island. But thankfully, unlike the early days of 3d accelerators, developers don't have to reinvent the wheel for each API- once you have one working right, supporting another isn't nearly as difficult.

I would really like to hear more about your experience with the X-65!

Well, I guess that depends on what we mean by "kind". Shoot, I remember playing with my neighbors Virtualboy when I was a kid. By "kind" I meant a consumer-marketable product. That requires a whole different development process than industrial products... consumers sure are a finicky group! I wonder how many times marketing kicked back a Rift CV1 design and said "nope, people will look too stupid while wearing it, change it" :doh: That is really interesting to hear about other dual-screen products though. I've heard about some other dual-screen prototypes being shown off, but I don't remember who was making them. Do you think that's where all HMD's need to go in the next few years?

Yeah, I would like to replace it with an actual mouse nipple like IBM / Lenovo laptops..... someday... That's interesting. How did you set it up so that it's usable? Its definitely not a majority of users who experience it. I am not sure exactly what causes it, but have found a lot of complaints online by others about it. Just last night my throttle was randomly sending comma's (I have one of the buttons set to that) and I was really freaking out before I realized the source of them. Yep, with all of it's faults, I still recommend it. For what it is, it's great. I just am sure to tell people to get a cheap powered usb hub, and send them the link to the registry hack for the mouse nipple. It truly is worth the price, but it definitely does not exactly live up to their marketing material. So, I will now always be suspicious of Saitek "feature lists" until I get my own hands on a product to see what it actually does.

Don't discount that part of the long development time on the Rift was that it was the first of it's kind, and a lot of things had to be figured out rather than copied / improved upon. A big part of that was also on the software side- developers had to learn how to develop for VR and get products into the pipeline so that a consumer version would have quality content at release. Now that we've broken ground, new entries into VR don't necessarily need anywhere close to the same development time.

That's really interesting, although I wonder what sort of release date they are expecting. I imagine they will shoot for the holiday season, but that's just speculation, and who knows if they will be on target if that even is their target. I'm sure the extra fov will make a big difference, but even the rift DK2 is convincing enough for me to prefer it over 3x monitors in most cases. As for resolution... so what if it's like watching a DVD on a 4k screen? DVD's aren't nearly as sharp as blu-ray, but I don't feel that I get significantly less out of watching a movie on a DVD. Certainly there are some cases where it would make a meaningful difference, but for most it is superficial. I can't imagine any movies where I would say "oh man, I really wish I had watched that on blu-ray, the dvd quality just didn't live up to my expectations." I would, on the other hand, say that about 3d vs 2d for a few movies (Avatar), and the same goes for games in VR and in 2d. If you have triple 4k 3dtvs... well that might be a different story.

Given the poor disappointing reality of owning the X-55, when I see all of the features and buttons they claim to have, I just wonder which ones they ACTUALLY have and which are either wishful thinking or "we will enable that in the software... someday". I simply don't believe any claimed specs. And for those of you who don't own an X-55 and are wondering what they are: -The "mouse joystick" on the throttle can't be used as an analog axis without a registry hack that some kind person posted on reddit. It's HORRIBLY insensitive and works more like a digital control than analog. I expected a cheap laptop eraser mouse. This isn't even close. Don't expect to use it for anything. -The scroll wheel, which their website still lists as a feature, still does absolutely nothing. It shows up in the X-55 software as a scroll wheel, and lights up when you scroll it... but it still does nothing outside of their software. Still waiting for an update that makes it do... anything. -Ghost button presses experienced to varying degrees by lots of people. Sometimes LOTS of them. Never acknowledged as a problem by Saitek. Fixed by using a powered USB hub (discovered this on my own, as they won't give advice on a problem that doesn't exist).

Hey I have a question for you: I see that you support mouse movement. My understanding of vJoy was that it only supported emulation joystick / gamepad devices. How have you gotten mouse support through it?

Yep, actually I did a lot of reading and digging through their code to see how they do things. It's been really valuable for understanding how I can get what I need to do working. Still hoping not to have to go that route though. That's what I'm hoping I can discover here. If there's were a way in lua to effectively do the same thing as you would do with the mouse- sending click events in screen space, that would probably be ideal. Still, I'd have to be able to load a dll or something because I cannot access my input data with just lua. Completely not necessary, actually. I have a datastream already, and my only issue is turning it into something usable by DCS. The most direct approach would be to simply create a virtual touchscreen device that Windows would read as an actual piece of hardware, write a filter driver for it, and use that driver to pass Windows taps / clicks / etc as though they were being generated by hardware. Then, DCS automatically uses them because as far as it and Windows are concerned, it's an actual mouse / tablet / touchscreen. It's actually exactly how the above-mentioned vJoy (and some other projects) work. The only problem is installing it on a 64-bit system without shelling out lots of money to digitally sign the driver so that people other than myself can install it without jumping through a lot of hoops.

That's a really interesting option. But, I would be a little concerned about latency. Also, I want to distribute this software, and I don't want every user to have to purchase hardware in order to make it work. I can write the virtual device driver myself, I just then run into the issue of getting it digitally signed so that I can distribute it to others. I may go ahead and do that and then make a kickstarter or something to raise part of the funds if there is enough enough interest.

Hey guys, I'm not sure if this is possible within DCS, but I have an input device for which I can access the data via C++. It does not present itself as an HID / joystick-like device. I am trying to figure out how I can interface with DCS, so that my input device can emulate the function of a mouse clicking on interactable elements in cockpits. Ideally, I could get DCS to simply read it as though it were an actual mouse sending clicks. I've already looked into emulating a mouse at the system level, which can be done but requires writing a Windows driver for a virtual device. Distributing this for 64-bit systems would require paying several hundred dollars to have the driver digitally signed before Windows will allow people to install it. Hopefully I can find another way to make this work.

Altering the seasons has no effect, regardless of the season selected. I have also tried Starway's Ground Texture Mod 3.2 and it has no change. I did notice that the folder structure of the mods is a little different than that of the Mods folder though. In the mods folder, I find the terrain texture files inside "DCSWorld\Mods\terrains\CaucasusBase\vfstextures" whereas the folders for these texture packs appear as "Bazar\Terrain\vfstextures". I wonder if this is part of the problem?

I am having the same problem... cannot get any terrain textures to work. Same folder structure, and using JSGME.

*zzzzzOOOOOOOOOOOoooooommm* ... SHOOT SHOOT SHOOT ... **BOOM** :)