aurel42

So... what does the Cloud Recovery TLOD "+" do?

My mistake, I tried to condense the description of the issue, instead it became incoherent. I've opened an issue on Github explaining the details of the issue I'm seeing. Also, sorry for posting in the wrong thread. For some reason, Google sent me here when I googled "AutoFPS avsim". Now, it doesn't. Perhaps it eventually indexed the other thread. I'll direct my follow-up questions about fps settings and locking to that thread. Thanks for your advice!

Hey, new AutoFPS user here. I'm flying in VR (in SU15) and I try to keep up with the daily 0.4.1 releases. Forgive me if this is a frequently asked question, but my forum-search-fu is weak and I only browsed through the last couple (of 80) pages. So far, my experience has been generally good (apart from a few instances when AutoFPS seemed to forget what it was doing, e.g. in low fps situations it would refuse to lower cloud quality from high to medium to low, instead it stopped at medium). My goal is a rock-steady (as far as possible) 30 fps with the maximum available eye candy. I set up SteamVR to cap the frame rate at 45 fps (so AutoFPS has "room to work"), AutoFPS is trying to maintain 35 fps with 10% tolerance. In my head, this totally makes sense. But I'm also not confident my understanding of the inner workings of AutoFPS is correct. 😄 Is there a recommended way to achieve a "locked" (in SteamVR) framerate? Should I use "auto throttling" instead or lock the framerate to the framerate I actually want (30 fps)? Thanks for your advice!

Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity." This is where I totally agree with you, though. Another very obvious and easy to understand example are tail numbers: people were complaining that the sim didn't remember the tail numbers, so Asobo made a half-assed attempt of providing a "solution". Now the sim remembers exactly one registration for all aircraft, which is Good Enough<tm> for the people who want to see their name on the plane, but no solution at all for the people who want to use "realistic" registrations for individual aircraft in their hangar. I still have to change the registration whenever I switch planes, because in my home country, part of the registration depends on aircraft classification (single engine vs. twin engine, weight). And there's a good chance we in the second group will never see a "real" fix for this issue now, because it has been fixed "for the masses", and a new wishlist request by the "suckers for reality" would never get enough votes. Did you notice that, in their Dev Q&A streams, they only go into detail when they're talking about the Asobo graphics engine or when they can put the blame on Blackshark or the Bing team? In contrast, I don't think they've ever gone into detail regarding aerodynamics or the simulation of aircraft systems, except for making the meta argument "we don't want to be too realistic, so we don't take business away from the developers of study-level aircraft"... ignoring the basic fact that everybody has to depend on core systems being simulated correctly in the first place, unless they want to run major parts of the aircraft simulation outside the sim (which, of course, is not even possible at the moment, because of limitations of the SDK and/or SimConnect, as I understand it).

And maybe this one: Improvements to flight model and systems behaviour and their impact on existing aircraft - MSFS Forums ...which is more generic about the impact it would have if those issues aren't fixed soon, because they might not be fixed at all, if someone decides that "extra" realism isn't worth breaking all the aircraft that will exist in a couple of months.

While this seemed like a great idea when I tested it quickly with the key already at "Both", it turns out that this isn't really a good solution: when I set the control to repeat, as soon as I press the switch, the key will turn in one swift movement from "Off" to "Start". That's not what I want. I'll just use the mouse for the time being, and the alternate engine.cfg when Rob releases v3.

Actually, this is incorrect. The key animation seems to be of fixed length and does not reflect how long I hold the switch. I guess my assumption that this switch would work in MFS/FSUIPC7 in a similar way to P3D/FSUIPC6 was wrong. No, it was not, that's what I meant when I said "without 'repeat' option", at least I assume we're both talking about "control to repeat while held". And, yes, this option solved the issue, tyvm!

While this is a very good point, I don't think it's applicable to my case: I'm using the "Ignition" switches on the Warthog, they are spring-loaded switches (not buttons) configured via FSUIPC (without "repeat" option) that will send the "button down" event when I move them to the up position and the "button release" event when I let go (and the spring will return them to the center position). If the key animation is anything to go by: I press and hold the switch and the key stays in the "Start" position until I release the switch, then the key will return to "Both".

So, after my other issues are kinda resolved, I would love to get an explanation for this so I can finally fly the Bonanza in peace. 😇 (I'm referring to the checklists in Rob's "Bonanza G36 Turbo.pdf".) edit: oh geez, this was a language barrier thing. I understood "lower" as "the tank with the smaller amount of fuel left". I now realize it probably means "the tank in the wing that is lower when banked during a turn"… correct?

It is [edit: no, it was] a silly problem, so everything goes. 😄 When loading the Bonanza at a parking spot, the left tank is selected by default. The left tank is not empty. During priming, the fuel-flow-o-meter shows 16.3 GpH with the throttle fully open. I tried switching tanks, to make sure the fuel valve knob isn't in some uninitialized state after loading the aircraft. While re-testing this for the umpteenth time, I finally had the idea to go through the startup using just the mouse. And, voilà, the engine started. I have buttons on my throttle quadrant assigned to "Magneto 1 Decr" and "Magneto 1 Incr". They appear to be working: they move the key in the expected direction. They work in other aircraft: I can, for example, start the C172 just fine using these buttons. Using these buttons has become part of my routine whenever I start an aircraft with a "magneto key" – I'm using hardware buttons whenever possible, because, when flying in VR (or, in the case of MFS, TrackIR), I find it cumbersome to have to reach for the keyboard or mouse, and it often takes me multiple attempts to hit the correct spot with the mouse (best examples: wedding cake-style rotaries on the G1000, or the icing system switch on the DA62), unless I lean in (to "zoom") and pause TrackIR to freeze the camera position. Anyway, somehow, the hardware buttons behave differently than turning the key with the mouse in the Bonanza. Perhaps the mouse event that turns the key to "Start" has another assignment besides triggering whatever "Magneto 1 Incr" triggers. Or the SimConnect function "Magneto 1 Incr" is just broken in some weird way for the Bonanza. This feels good. I can now start the Bonanza properly. And I don't feel stupid any longer, just because I expected a button assignment that works in one plane to work in another… Oh. Wait. Asobo. Okay, yeah, I'm stupid. 😆

Control settings: ✅ display of USB game controllers restored by forcing the Steam Input layer back to "off". I forced it to "on" while trying to get rid of the 1.10.7.0 inputprofiles CTD, and forgot about it. Brakes: ✅ after sim restart, they still didn't work, but they didn't work in the C172 either. It took a restart of FSUIPC to restore functionality. I should've tried that as the first step, but I didn't even consider FSUIPC as the source of the problem. Open questions: This is what my settings look like after following the checklist, incl. priming (and verifying fuel flow). When I switch the magnetos to "start", the prop starts turning and immediately spins down again. Voltage seems good, cowl flaps are open, props full forward, throttle cracked, I tried with full rich mixture and with mixture leaned for altitude. When I start the engine using CTRL+E, shut it down by cutting the mixture, and then turn the key again to the start position, the engine does start up. Apart from the mixture lever moving to a lean setting (and AV master being switched to on), I cannot see anything in the cockpit move when I press CTRL+E. It's baffling. The only time I've been in a similar situation was in a jet aircraft that needed full rich mixture despite not having a mixture lever, apparently some idiosyncrasy of P3D that checks mixture even for engine types that don't have it. Obviously this isn't the case here, but I wonder if there could be some other parameter that does not have a visual representation in the cockpit, yet could be affected by my controller setup and is only rectified when I let the sim start the engine.

Thanks for confirming that they're still supposed to work. For me, they weren't too weak, they didn't have any effect at all. They don't even trigger the pedal animation (the parking brake does). If the issue persists after a sim restart, I will try assigning them in the MFS controller settings instead of FSUIPC, if I can figure out a way to do that (since 1.10 arrived, the Controls settings in MFS only show keyboard, mouse and TrackIR, and none of my USB game controllers; I'll check the official forums to see if other users have that problem and found a solution; until now, this just didn't bother me, because FSUIPC kept working).

Is it possible that 1.10 affected the brakes? Just doing my first flight in the Bonanza since 1.10 arrived, now with 1.10.8.0 (not even sure when I got that hotfix, I didn't see the usual update dialog). During taxi, braking did not have any effect whatsoever. Only the parking brake was still working. Could be a fluke, could affect all aircraft after the hotfix, could just be me being stupid in some new & improved way. I was too eager to get into the air to do the whole "reset/restart everything" shpeel. I will, once I land. My pedals are set up using FSUIPC and according to the FSUIPC axes dialog, they're working. It would be cool if someone could confirm the brakes still work for them in 1.10.8.0. Unrelated to that, there's something that puzzles me about the checklists: why am I supposed to select the "lower tank" during climb, cruise and descent? This doesn't make any sense to me at all. And, finally, following the checklist, I still have to CTRL+E to get the engine going, and I don't know why. [Note to self: try to be quicker between turning on the battery and starting up the engine, keep an eye on Bus Volts. Maybe my preparations are taking so long that the battery is depleted by the time I try to start her up.]

You must realize that is the "why do they release Japan while the AP is broken" fallacy, so I assume you just need to be right here. Okay, you're right.

The operative word in this sentence is, for me, "new". Supporting legacy hardware/drivers/standards in addition to the "hot ****" is not unheard of. Think of games that support DirectX and OpenGL (back in the day), or DX11 and DX12, or DirectX and Vulkan. It's most definitely a lot harder to include support for DirectX and Vulkan, than to support two different (but similar) VR ecosystems.

I accept as a fact that WMR headsets will use OpenXR, and as highly likely that other VR headsets will, too. I hesitate to accept "no support for SteamVR" as a fact at this point, though, mainly because of three questions to which I don't know the answers: Is the "developer preview" of Valve's OpenXR feature-complete, so it would be able to run MFS? Is it a significant amount of work to support SteamVR in addition to OpenXR? (It could just be a matter of including a compatibility layer. So far, developers supporting one VR ecosystem seemed to have little trouble adding support for other VR ecosystems, which might indicate that it's quite easy to support different hardware when you've got the basics down. Actually rendering the world in VR is probably only a small part of the effort, compared to e.g. designing a user interface that is VR friendly.) Is Asobo willing to exclude a significant share of "the niche" from the experience until Valve releases their OpenXR drivers in the stable branch of SteamVR?

Is that a fact or speculation? While I agree that open standards are always the way to go, I have no idea whether OpenXR is ready for prime time yet. As far as I'm aware, the SteamVR drivers so far only include a subset of OpenXR in the beta branch? The one thing I miss after switching headsets from Oculus to Valve is the easy and comfortable way to pin any desktop window in my virtual space. Do I understand correctly that there are tools that allow me to do the same thing using SteamVR? Can someone recommend a tool like that?

Except, of course, and I have to point this out, because it's a pet peeve of mine, that screenshot looks like the sim forgot to turn on the rain effects. My hypothesis: when you fly from the dry into the rain in "Live Weather", you will never see rain effects in MFS (until they fix this). Rain effects are present when you take-off in the rain, or when you land at an airport where it's raining, and I sometimes (rarely) see snow flakes on the windows (no, not talking about icing here) while flying through clouds. But I've never seen rain effects below rain clouds when flying from an area without precipitation into an area which is supposed to have precipitation. Not even in areas where wx radar or Nexrad display solid red or purple. (The usual responses I get when I point this out are "I've seen rain at this or that airport" and "Not every cloud produces rain". I know. And I'm aware that I can sometimes trigger the missing rain effects manually by switching to any other weather preset and, after a bit of waiting, back to Live Weather, but that's obviously not how it's supposed to work.)

I flew that challenge twice, on the 2nd attempt, VSI and Altimeter were stuck. I don't have any mods installed that would affect the C152. I think that means the C152 realism mod isn't the culprit here. Thanks, Asobo! [edit: People speculate that the frozen instruments are parts of the event. In that case, I would expect them to be frozen on every run. This is a landing challenge with a leaderboard after all, so the conditions should be identical on every run for everybody attempting it.]

Hey Rob, funny story, I just wrote a 500+ word fan mail, including a 🥰 smiley and some thoughts regarding Github, but then… …so please imagine receiving a message full of love, praise and gratitude.

Perhaps I didn't make clear enough that this happens on every turn, under any wind condition, and in all my GA aircraft. There is nothing random to it. And at no point does it feel anything like a real turbulence (which obviously should have some random element). So I never even considered AS16 as the cause of the problem. For me, this is clearly unexpected behaviour, aka a bug. But, to be fair, the explanation for the feature in AS16 states that it can affect aircraft handling. And there's always the possibility that a combination of factors lead to this broken behaviour, and I just got rid of it by changing one of the factors, so this feature might work as expected under other circumstances.

Solved by disabling AS16's "Enhanced turbulence"

Hey Mick, Correct, I don't have any duplicate assignments (controllers are turned off completely, and I also removed all the axis and button assignments to be sure, I only left the keyboard assignments untouched). Also I did intentionally not touch any controls, neither the yoke nor the rudder, while recording the video. If I had shown "manual" turns, it would have been hard to tell whether I just was too clumsy on the rudder.

Roger, wilco!

Yes, I'm running AS16. There's a small, yellow pointer at the top of the map on the left (provided by Little Navmap) that shows the current wind conditions. While recording the video, the wind was at a mere 3 knots.