nrgized

Great points. One thing I'd like to point out though. I think everyone understands that the slew rate may not match your heads rate. Its the stuttering that people are pointing out not so much that it lags behind your line of sight. So yes if my eyes are looking at 156 the sensor might be at 123 because its slewing over to 156. But during its translation its stutter stepping its way which is off putting and not visible in the Cosmo video. It translates around at a smooth rate. Its most noticeable if you move your head left to right at a slow pace. One that the sensor could keep up with. I also wonder if VR has some fault in this when its doing frame interpolation. For instance running at 45fps.

I don't see what a track file would provide. Its not mission or map specific. You would need my computer to replicate the problem or tweak your settings to a level where toggling a viewport on/off produces a fps hit thats noticeable. It is known that a targeting pod at the code level is a render viewport which in any game/application incurs a fps hit. Its rendering the scene an additional time. In this case when switching to the TSD page with the map its not toggling the viewport rendering of the video off. Off as in at a code level not a visible to the player level. All other pages will display video as a background so its easy to see how it could possibly be overlooked. This is a ask the devs if the page selection to the TSD toggles the viewport rendering on/off the same way as when you select "No Video". Because it appears at the moment it doesn't. Which as stated can be an oversight because all other pages will show the video as an underlay. Get your game settings to a high level so that turning on a 64 sensor produces a 10ish fps drop In a hover on any map write down your fps Go to the Video page and select TADS as your video source. Select the TSD page with the map visible notice that fps does not increase with video no longer displayed Select video page and "No Video" Select the TSD page with the map visible and notice fps has returned to its value noted in step 2

Go to the video page and select TADS. Then select the TSD page with the map displayed. The video is no longer being displayed to the user because the map is now displayed. However by looking at the frame counter you can tell the video texture is still being rendered on the gpu in background code because the fps loss is still present. Switch back to the video page and select "No Video" and then go back to the TSD page and you will see that the games fps has gone back up to the value before you ever selected a video output.

Yes but in my case it was switching to a page that did NOT display the video in the background. The video image was not displayed in any way and yet was still being rendered in the background, background meaning application code not visually.

I have an empty mission single spawn where fps is a steady known value. Switching to the video page fps drops 5-10 frames which is expected as its another viewport render. Changing to another page however does not recover the fps lost. Going back to the video page and selecting no video regains fps lost and returns to the known value. Appears that the viewport is still being rendered in the background when no longer displayed.

I was able to run at a stable 45 locked fps in mulitplayer before todays patch. After todays patch I'm in the 30s low 40s.

That sounds reasonable as to what I saw. Controls felt very mushy like the Gazelle with SAS off. Becomes a boat ride in a hover. My example video while drastic so as to induce the problem is not how I fly/trim on the ordinary. I normally encountered the issue when going from full cruise trim and essentially coming back to "centered". Centered in this context meaning I had the cyclic centered by any means be that manually positioning or as of today hitting the reset button. Do that enough times and when I'd come to a hover it wasn't near how it felt when I took off. Is recentering currently implemented do you know? Thanks

I noticed this with the initial launch patch but since I didn't use trim in the aircraft because of no reset ability I didn't look into it much when I encountered the phenomenon. After commanding a number of trim inputs it appears as if something behind the scenes slowly adding up and gradually reduces the aircrafts normal flight characteristics when the cyclic is not being manipulated. This is not... Misunderstanding of trim Learn to fly issue Change in aircraft weight Change in weather conditions The example provided is a hover next to a building showing that the flight controls can be released and a stable hover is maintained. After a number of trim commands coming back to the same building it requires more command inputs to maintain the hover. Here is a video recording of the example scenario. If you can get the issue to progress larger over time then the aircraft feels bouncy to inputs and starts to feel like the Gazelle with SAS turned off. current_x_trim = 0.0; current_y_trim = 0.0; void update_trim() { current_x_trim = get_cyclic_x() + current_x_trim; current_y_trim = get_cyclic_y() + current_y_trim; } void trim_reset() { current_x_trim = 0.0; current_y_trim = 0.0; } Somewhere it feels like a residual value is being maintained that gradually its value/error manifests itself. Also having trim forward and then setting trim to a value that is negative to center seems to trigger the issue easier.

I just performed a cold and dark start. Once I lifted the aircraft around 20-40ft off the ground the radar altimeter became visible.

Beings he announced on Facebook that he is going to fireman training, cutting back his DCS time, and beginning a new career its not that much of a stretch.

I’ve had “Need CPG” in my multiplayer name and since launch have had one person join. Where are you leprechauns at!?!?

View distance on uber ultra | Check Terrain shadows | Check Mirrors | Check Yeah I wonder why you're getting those frames Its possible to run around with 90fps locked 90% of the time on the map with proper settings. And if you lock to 45fps you wont ever dip.

The large white hospital/hotel looking building causes the "Simulation" counter to double/triple when hovering/flying over the building. Provided screenshots show a jump from 12ms to 57ms in "simulation" time. approximate coords: 13.62.02 N 144.38.33 E

Lowered the price to $750 USD

I ordered these a year ago and never got around to building a setup. I'm selling both as a set, I do not want to piece them out. If you have a friend and want to split I'm open to the idea. All items needed to get them working are included. Cyclic Stick UH-1 Cyclic Basis Collective Stick UH-1 Collective Base Leo Bodnar Joystick Controller 12-Bit Leo Bodnar Button Box Interface 32 TC Asking $750 USD, shipping not included. (Los Angeles, CA)