Teej

Thanks for the verification folks. I just submitted my tracks directly. Since Tango uploaded his here, I included a link to this thread in case it was overlooked. Teej

We still have the autoexec.cfg "fix" in place, but the formation jitter has returned with the new build. A little different this time. As with the previous build and version of this bug, it's only obvious when you're in close formation with another aircraft while pulling G. What I'm seeing so far is a rapid twitch in the pitch axis. I've already been in contact with the devs and they're asking for tracks again. I'll supply a sample from our team within 24 hours. Teej

Agreed. Very nice to know you're interested in keeping this workable for us!

I'll confirm from my end that the problem is still there in 1.5.4.55584. The net.use_new_fm=false in autoexec.cfg does work autoexec.cfg worked fine created by plain notepad. (Win10 in my case). Did not need the old "if not net then net = {} end" from older autoexecs. I will submit a new file (from 1.5.4.55584). Shows the issue better than previous tracks I've submitted. Please feel free to ask if you need anything else! Teej.

We submitted tracks from flights of 3-4 F-15s in a 3G turn, but we hadn’t been told to trim it down with an airstart - sorry about that. Was the net.use_new_fm=false code removed/readded? I’ve been testing that for the past 2 nights with 1.5.4 with 2 machines on a LAN and that command did not appear to have any effect. Tried it both with and without “ if not net then net = {} end” before it. Teej

Just a heads up from someone on our team...this is certainly not the ONLY cause of this problem, but if you get to the point in the setup where it says "continue in the Rift" (ie it wants you to do the focusing / pupil distance thing) and...your rift is dark... Make sure you don't have "display link" installed. This is often used for people with nonstandard monitors and/or docking stations (certain laptops).

SZ: I'll be glad to submit something tonight on the netcode. Do you want it in the thread Tango started or is there an official one I've missed? Thanks! Teej

So we’ve seen some interesting things… In _1.5.3_… I was never able to properly “view” my own Rift-flown tracks from outside the Rift. As stated before, when I would view with the Rift unplugged the view would always look in the wrong direction…didn’t move properly with camera movement keys (external views)….padlock would point at the wrong point in space, etc. We flew the recent airshow (VBB) with 3 pilots wearing Rifts. We all passed our tracks on to someone else. Mine and Panthers were messed up. The other person’s track played fine. At the time I had my Rift “camera” off my right shoulder. Panther had hers at about 11:00 (also messed up). I’m not sure where Ray had his, but his track worked with no issues. So far in 1.5.4 I have not been able to duplicate the issue on my own…single player, flying with other VTB or flying on the VA server - all tracks play back properly without Rift now. Too bad for the current netcode bugginess with 1.5.4…

So what would it be for these two? ...aside from....very very frightening?

That's not new to VR. That's always been possible...I know TrackIR would do it...pretty sure keyboard and mouse did it as well.

The Virtual Thunderbirds (No connection with the above post) are experiencing the same thing....even with 2 computers on a gigabit lan, with the "lead" flying lazy autopilot circles. We haven't rolled back yet, but it's only a matter of time.

My $.02… Communication on USB 2 is host-driven. No data passes to or from the devices (rift, camera, etc) unless the computer initiates the request. USB 3 allows communication to be initiated by the device. Thus it doesn’t have to wait for the periodic polling from the host. USB 2 communication therefore usually runs on a polling “heartbeat”. The computer will poll the OR camera. The data it receives gets sent to the rift itself on its next scheduled polling cycle. The rift’s response comes back on the following polling cycle etc. There can be “latency” introduced by this waiting for polling. USB3 bypasses that by allowing the devices to communicate as fast as necessary….USB3 has 10 times the bandwidth as well. As to the rift and its camera…. the camera / sensor is definitely responsible for determining the rift’s “location” in 3D space. Orientation and changes thereof, however, are primarily measured on board the rift head unit (with a built in magnetometer / accelerometer / gyro). Something (whether it’s the rift itself or the driver on the PC) is reconciling the two data sources for smoothness/accuracy. While some software will complain if the sensor/camera is unplugged, some others will run anyway - and you still have much, but not all, of the Rift’s positional accuracy/freedom.

FWIW...you list 2 980Ti and 22.5 fps. I'm running a single 980Ti and with no pixel density adjustment I spend most of the time locked in at 90 fps. turning it up close to 2, I get drops down to 60fps or so. Neither DCS nor the Rift are very good about SLI support AFAIK...not sure if that's throwing you off.

Dunno why it took me so long but the other day I did my first probe & drogue refueling with the rift. So much cooler than 2D :D

No worries man. I know some people have given you crap on other threads about wanting to use KB/mouse to fly DCS. My opinion is..well...I agree in that I'd rather see someone use real controls, but I also know that some people are really limited on space and budget. I have friends in Japan who chose between game consoles (Xbox vs PS2) based on the bulkiness of the console / controllers :D If someone has monetary / living space / personal mobility issues....or even flat out choice... that make dedicated controllers a problem, why should that stop you? :D

Here's my thought process on Nevo's question at least...still haven't had time to turn this into more than a thought... First I'd wanna look at a handfull of files (key/mouse/joystick LUAs, plus the device/device_init scripts) to figure out what capabilities were there that might be exploitable. Assuming the worst, I'd set the mouse Z axis up to something unused (ie 7000 like I did with Lucifer's question). Then in the LUA device I'd create, I would: 1: Initialize a local throttle variable and set to minimum 2: "listen" for throttle changes made the regular way (auto throttle, moving a joystick, whatever). Any time a change is received update the local variable above. 3: "listen" for the mouse-Z changes. When one is detected, increase/decrease the local throttle variable by some predetermined amount and issue the mod's ASM throttle command to match. T

FWIW, I'm still here and following and planning to dig into stuff for the guy looking for the help on using the mouse...I've just been really busy with both real and virtual life. We're definitely looking forward to having some fun at Virtual Beach Blast tomorrow. :D

Part of the rifts initial calibration takes care of this. Green cross hatch lines. Adjust rift up and down until one set of lines is clear then slide IPD lever until other set is clear...simple.

If you use a USB port that always stays powered, the lights MAY stay off for you. However, the reason it doesn't (otherwise) work for you is that unlike the old Cougar software, TARGET does not actually "load code" onto the Warthog units - it runs only in Windows. When the device loses all power, it "boots up" and reads its firmware again, which says the lights come on.

Slightly off topic I guess...but Last night I was bored for a few minutes and went flipping through the Rift Videos....facebook...trending videos... and happened across one labeled "PC-7 Team". Great "360" cockpit video from the PC-7 and Patrouille Suisse teams. Gorgeous aircraft and worth a look for any of us around here.

+1! That will mess you up. :D To the OP: I never had that happen with TIR (aside from the fact that playbacks are often not 100% perfect to begin with...) and I see no difference in that regard with Rift. That said, what I don't like is I can't (currently - they may be working on this) take a track from a Rift flight and watch it without rift, if I expect to be able to padlock/zoom on things. The track itself plays fine but viewing...doesn't. I started a thread about that the other day and had a bit of an exchange with Skatezilla over it.

Yup. Having a blast. It was so cruel to have my OR arrive with one night's flying time before I left the country for 10 days hah.

Playing back the track with the Rift works fine with the following caveats: 1: I couldn't zoom/FOV change at all. I could of course (when in appropriate views) move the camera around with keys / mouse wheel...but no FOV zoom. 2: You can padlock...but in order to designate, you have to be looking "normal" with the Rift - I can't look over my shoulder and padlock something - it will padlock based on where I'd be looking if I were looking straight ahead. 3: Wanna know a fast way to get disoriented / vertigo / sick? Start watching a track where the pilot is looking all over the place and then try to move your own head. Whoa. :D

That can be done of course, but no padlock or zoom (ie can't watch a pass from show center - looks like ants marching across the screen :D )

That could well be it - can't play back at the same resolution since Rift's resolution isn't in the list. All 3 of my multiplayer tracks behave the same way.