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)

Open Beta and yes cool down period.

I wouldn't consider it fixed per say. The image is extremely crunched. In black hot mode its extremely dark and white hot mode its almost pure white.

As stated in another thread if you have the RWR turned off the issue does not arise. This started when the hornet was added and looking at the access violation I can probably guess why. While you're at it could you please fix the M2000 RWR icon from "U" to "M2k" or whatever icon its supposed to have as stated in your manual.

He may be talking about similar inertia issues discussed here. Any comment?

Very nice! I miss night flights.

Added new video #7. Strong right stick inputs lock up controls, reducing collective returns control of aircraft

Whats changed: The new flight model removed almost all pitch and roll inertia. This has been confirmed by Polychop themselves and so is not a matter of question. Pitch and roll inertia has very strong dampening in the new FM. Old FM: Pitch and roll had very high inertia. It can reasonably be said that the inertia was probably too high. New FM: Pitch and roll have little to no inertia. Control inputs feel very robotic. Inertia under the new FM is also inconsistent. Where sometimes it will exhibit slightly more falloff while the same maneuver commanded moments later will exhibit none. Right command inputs differ from left command inputs. Polychop feedback: What I would appreciate from Polychop is more feedback on the matter then they have released. In particular more detailed information than "pilots gave it an OK". A few topics that I think would be appreciated may include. What is the roll rate and dampening of the flight model. How did the testers and pilots evaluate the flight model. What type of flying was performed. What type of maneuvers were performed. It is important to know how the FM is evaluated. If FM changes are only being evaluated under very benin conditions that may be room for improvement. Final thoughts: If you are someone that leisurely flys the Gazelle the new FM changes might not be as noticable. Smooth coordinated turns don't exhibit many of the inertia dampening issues. On the other hand if you abuse the Gazelle for everything that its capable of then the new FM is clearly evident. The sort of flying where you are mentally preparing for the next 5 control inputs and also compensating for the previous 5. My series, twitch is down atm, is just that sort of flying. To those that want to provide their thoughts/videos in this post. I ask that you please make sure control input overlays are on in any videos. That you confine maneuvers to flying that is not lazy Sunday R44 flights. Complex chains of command inputs are where you notice the dampening the most. Demonstration flights: Each recorded video and corresponding track demonstrate how the new inertia dampening affects a specific maneuver. A Dropbox link has been provided to download each videos individual track both here and in the Youtube description. 1) Was a combination of videos below and thus excluded 2) Multiple command inputs and cessation of inputs resulting in immediate locking of attitude. 3) Maintaining a direction of flight and yawing the aircraft. Upwards pitch halting immediately. 4) Spinning around maintaining a single direction of flight while releasing controls results in an immediate nose down maneuver. 5) Light to medium right stick inputs result in a continued roll in the aircraft. 6) Something good to end it with 7) Strong right stick inputs lock up controls, reducing collective returns control of aircraft At 3:15 is the best example in this test flight.

I'm running stutter spec. 6700k, 32gb, ssd, 1080ti, vr. I understand you run release candidates but that implies they eventually get released. I've noticed comments by yourself since first Normandy release that it runs better which based on my experience none of the few released patches indicate. Sent from my iPhone using Tapatalk

What magical version are you running because thats not the case for all 3 branches I have.

When you manage geo like the engine does it's a no brainer it would melt things. For instance trees being individual instances of geo instead of blocked into larger chucks as a single object will kill anything quickly. Large object count is its own killer separate of poly density. Cities and trees destroy fps in this game because of the high object count and not so much because of poly count. Sent from my iPhone using Tapatalk