Reset XPDR

It has been happening for at least a week. Nonetheless, I will do as you suggest.

I will try editing this fourth broken post with what I want to say. Sorry for the message spamming but the broken forum code is causing it! @cjk28, thanks for testing, and I am glad the change is looking good so far. One suggestion before Sunday: I’d put your three thresholds back to the defaults (96 hold, 98 reduce, 93 recovery) for the next test. With the new Start Max check, AutoFPS reads VRAM just before the boost and skips it if VRAM is already above the recovery threshold less 1% for every 100 of starting TLOD. A high TLOD max therefore gets a stricter limit automatically, so the defaults now have that protection built in. Lowering the thresholds makes VRAM+ hold and reduce earlier than it needs to, which leaves some of your available VRAM unused. The log will show a “Start Max skipped” line whenever the check kicks in. On your point about the hold, it only stops TLOD from increasing, and TLOD only wants to increase when FPS is above target. When FPS is below target, the hold has nothing to block and normal reductions carry on, so it only kicks in when there is spare FPS and VRAM is near the limit, and it needs to be poised to do that. If you post your log from Sunday’s test with the default thresholds, it will show exactly what happened around session start.

Deleted. Why does this forum sometimes post a previous post instead of the one I just hit send on? This is an annoying forum bug!

@cjk28, FYI 0.5.5.1-test4 is ready to try. Implemented from my reply to you: Start Max is skipped when VRAM is already high at session start (log line shows when it happens) VRAM+ dropdown tooltip explains Max and Set, and shows your thresholds Padlock replaced by the limit symbol (⊤) with an explanatory tooltip README updates to follow with the final release Also new for everyone: Monitor only is now a selectable entry at the end of the Flight Type list instead of being buried in the config file. AutoFPS stops changing sim settings and just monitors and logs Your normal flight profiles are left untouched Stays selected until you pick another flight type Same layout in the widget and web page

Hi again, and thanks for the kind words and the detailed feedback. Re your questions: Max reduces all the key settings (trees, buildings, shadows and so on) by up to two levels. Set uses the reduction levels, floor and settings from your profile instead. For hold and reduce: at 96% VRAM TLOD is held and can’t climb. At 98% it is stepped down until it reaches Base Min, and then settings reduction begins. Settings recover once VRAM is back to 93% or lower. I will add this to the tooltip, and the readme will cover it as well. I checked, and Auto Reduce Settings does not need to be ticked for VRAM+ to activate when Set is used. Set just borrows the reduction setup from your profile. The tooltip and readme will both be updated to say this. Fair point on the padlock, as it is really a limit and not a lock. VRAM+ is limiting TLOD, so it can’t go higher while held and is being brought down while reducing. I am considering switching to the same limit symbol I already use when the sim’s maximum TLOD is reached. For now I will add a tooltip to explain it. The default thresholds work well for me in both 2D and VR, so I would look at your graphics settings first, as settings that are too aggressive for your VRAM are the more likely problem. Frame generation in VR adds its own VRAM load on top, which makes it easier to tip over the edge. On the crash, Start Max sets TLOD to maximum straight away, before VRAM+ has a reading, and only holds between 96% and 98%. I would avoid Start Max if your VRAM is already close to full. The next test build will also skip the Start Max boost if VRAM is already high at the start. I can’t say for certain that VRAM caused the dxgi_device_hung crash, so if it happens again please post your log. Good catch, the thresholds are in the simulator specific config files (MSFS2020_AutoFPS.config and MSFS2024_AutoFPS.config), not MSFS_AutoFPS.config. The readme will be corrected, along with a clearer VRAM+ section covering Max and Set, hold and reduce, the limit symbol and Start Max. Thanks again, this is very helpful.

If you prefer the djules version for 3X FG, then go back to that one as it automatically supports the new status.json file without having to enable it in settings. As mentioned, those instructions I gave were if a user specifically wanted to use the new tigermaster version and wanted similar status.json support.

It sounds like you are either not using the tigermaster OFXR Bridge version or if you are you are not on the latest version. The post I made refers to this specific tigermaster version, or later, as shown in the about selection: Which specific version are you running, and who is the developer?

Just switch to the night profile and set Night to Clds-2 like before. It is only with the day profile that you can no longer do night settings because day can never be night. eg. (bottom right red box)

In your System Tray, right click on the OFXR Bridge icon to bring up the context menu then select Settings:

Well obviously not perfect, as it didn’t work properly the first time. 😄 But l am persistent, and we got there in the end. I hope you find this new mode useful!

@f.skywalker FYI, 0.5.5.1-test3 is now out. It makes the profile pairing much more tolerant of spacing, capitalisation and language differences, so names like ‘Frank night’ or a space copied from a web page will no longer stop it from working. Could you please update to it and give the pairing another try? Once it’s installed, you should see 0.5.5.1-test3 in the title bar of the app. Let me know how you go.

Very strange. I just checked again with a brand new pair of profiles and it worked fine. The only things I can think of are an extra space or character after the word ‘Night’, or a lower case ’n’ in ‘night’. I just checked the lower case one and it doesn’t create a pairing. It should, so I will fix that in the next version! Accordingly, please double check that you are using “Frank” and “Frank Night”, with a capital N in Night and no spaces or characters after either name. If it still isn’t working, could you open the MSFS2024_AutoFPS.config file in the AutoFPS root folder, %appdata%\MSFS_AutoFPS (not the one in the bin folder), search for “Frank” and paste any profile name lines you find (there should be 2) into a reply here for me to look at. If it’s set up correctly, it will look something like this, although the number after ProfileName may be different: <add key="ProfileName1" value="Frank" /> <add key="ProfileName2" value="Frank Night" />Let me know how you go.

These two questions imply that you have not yet updated to 0.5.5.1-test2 yet, because if you did: On the day profile, the original Night setting would be greyed out like this, because this profile will never be used at night so that setting is irrelevant: and on the Night profile you can make a Night selection, but only Off and Clds-2, because you set TLOD normally in the profile: You would see the pairing markers ↔ and no number to the right of them if this is the first pair you have ever set up: You will also know you have done it right as you will get the following message when the pairing is initially detected after you renaming the second profile correctly: In short, make sure you are using 0.5.5.1-test2 and follow the instructions I provided in the original post.

Do you mean to say you haven't read my lovingly re-crafted readme which tells you exactly how to do this here? 😜😄 It is pretty simple: Profile Renaming: Double-click the profile dropdown to rename. Press Enter or click away to save. Just edit two of the spare User profiles to be "Frank" and "Frank Night".

Good news, 0.5.5.1-test2 is now available and includes Day/Night profile pairing. Since you've already set up IFR and IFR Night, you're most of the way there. To answer your question, yes, Night Clouds/2 still works. On your IFR Night profile, set Night to Clds/2 and clouds will be reduced by 2 levels at night as before. The only difference is that TLOD halving isn't used on paired profiles, as your Night profile already has your night TLOD settings. Please give it a try and let me know how it goes, including any issues or anything that doesn't feel right. Here's a quick guide on how it works: Day/Night Profile Pairing - Quick Use Guide What it does AutoFPS automatically switches between two of your profiles: one for day and one for night. This lets you run completely different settings at night, such as lower TLOD, a different target FPS or different reduction settings, without touching anything in flight. How to set it up Tick Expert (pairing only works in expert mode). Create two profiles with the same name, with one ending in “ Night”. For example, ‘IFR’ and ‘IFR Night’. Both profiles show the ↔ marker in the Flight Type list once they are paired. Set up each profile the way you want it for day and for night. Start your flight on either profile. AutoFPS picks the right one for the time of day and switches automatically as day turns to night, and back again. Night mode on paired profiles The day profile does not use Night mode at all, so its Night setting is greyed out. The Night profile only uses the cloud reduction part of Night mode (Clds). TLOD halving is not needed, as the Night profile already has your night TLOD settings. Set Clds if you want clouds reduced at night, or leave it Off. Your saved Night mode settings are kept and come back if you unpair the profiles. Tips for smooth switching Use the same auto method and the same Manual/Auto/Fixed option on both profiles. AutoFPS then carries your current settings straight over at the switch. If they differ, it does a full reset instead, which you don’t want happening at dusk on short final. The status line and the log show Day or Night when you are on a paired profile, so you can see which profile is active at a glance. Things to know In a flight, the pairing is always enforced. If you select the other profile of the pair to change its settings, AutoFPS will switch straight back. To change it, either exit the flight first, or temporarily rename the Night profile so it no longer ends in “ Night” (e.g. ‘IFR Nite’), make your changes, then rename it back. Use one kind of auto-switch per profile. A profile can only have one auto-switch partner (VR, Night or sim rate), so don’t mix suffixes such as ‘IFR Night VR’ or ‘IFR Night 2X’. If they are mixed, VR takes priority, then sim rate, then Night. eg. Pairs set up then Daytime: Auto-switching at Night time:

No worries. I will have a go at it tomorrow, which will be T-3 days before wife-return panic stations! 😄

@GSalden I've looked into the Night profile pairing idea some more and it is definitely feasible, so I'm happy to add it if it suits what you're after. How it would work: name two profiles the same, with one of them ending in Night, e.g. 'IFR' and 'IFR Night'. When night falls, AutoFPS automatically switches to the Night profile, and back again when it becomes day. A couple of things to be aware of: - Night mode (TLOD halving and cloud reduction at night) will be automatically disabled in both paired profiles for as long as they are paired. Since the Night profile is your night setup, having Night mode reduce things on top of that would double up. Unpair them (rename either profile) and your Night mode settings return as they were. - The switch between profiles happens at the moment day turns to night (or vice versa), so the change in TLOD and settings may be abrupt, much like when switching to VR now. I won't be implementing smooth transitions between profiles, as blending two completely different sets of settings would be a coding nightmare. Also, the Reduce display in Sim Values being hidden by night cloud reduction is fixed in 0.5.5.1-test1 or later. Settings reduction takes priority, with the night cloud reduction shown when you hover over it. Let me know if the Night pairing would work for you and I'll include it in a 0.5.5.1 test release. If it doesn't suit, then the current Night mode is as far as I'll be taking night settings in AutoFPS.

FYI to anyone using tigermaster's OFXR Bridge v0.3.2.0 or later: tigermaster has now graciously added the live status.json feature that djules introduced last week. This allows AutoFPS to obtain live headset FPS data directly from OFXR Bridge, enabling significantly more accurate automation. One important thing to note: the feature is disabled by default after a fresh install or update. To enable it, open OFXR Bridge settings and tick Export status.json under the Display tab. Once enabled, AutoFPS will automatically detect it. You will know it is working when the FPS source icon changes from FS to OFXR after entering VR with OFXR Bridge running. Ignore that I am using 0.5.5.1-test in the screenshot. It works exactly the same in 0.5.5.0 as support for this feature is automatically detected. Enjoy!

Just a general notice. You've probably noticed I've been rather prolific with AutoFPS updates over the last month and have been knocking off quite a few user requests. The simple reason is that my wife has been away travelling, leaving me with far more spare time than usual to work on the app. That all comes to an end on Sunday when she returns home, so expect AutoFPS development activity to slow back down to normal levels. If you have any dormant issues or feature requests you'd like me to look at, now is probably the time to mention them. Anything non-critical raised after this week may take longer than it has over the past month to make it onto the to-do list. On second thought, make that Saturday. I still need to clean the house top to bottom before she gets back! 😄

I am not sure what you mean here. Admittedly, it no longer shows Reduce and the level in Sim Values if Clouds at Night is active which I will address in 0.5.5.1 that is now in its initial development phase, but you can still hover your mouse over that Clouds label or value and the reduction amounts per setting will then appear below as they normally do eg.: If you meant something else, please clarify. The app used to have TLOD min reduce by 50% at night, but it was removed as most users have this set fairly low already and the primary purpose of Night mode is to reduce system load while you are flying, when TLOD Max is the main thing in play. Your suggestion of having a separate TLOD Base and Top at night will add more complexity to this already busy UI and associated config settings arrangement. Nonetheless, I have a cunning plan, which is to offer you what can already be done in the app for auto switching between paired 2D/VR or paired sim rate multipliers by how you name your profiles. eg this is how mine is currently set up for 2 paired 2D and VR profiles, one set for IFR and the other for VFR. If I start my flight on say the IFR profile in 2D and then I switch to VR in MSFS, the profile automatically switches to IFR VR, which has completely different settings. If I did this for Night, it would be a similar arrangement where you would have two profiles with exactly the same name then with one of them you just add the suffix Night eg. 'IFR' and 'IFR Night'. When night falls, it would automatically switch to the IFR Night profile and in the day it would go to the IFR profile. This would be fairly easy to implement as the pairing detect logic is already there and I would just have to add Night and the day/night trigger condition to the mix. Would that satisfy your desire to have completely different night settings than for day?

Not exactly. Per the readme section on the spike protection feature, the specific spike pattern it is looking for can happen at any TLOD level, but the higher the TLOD level is the greater the chance of such spikes. In recent MSFS 2024 releases, those spike patterns are not as prominent, but they can still occur. If you are experiencing stutters at around a 1 second cadence, then it is worth running RTSS to get spike protection and see if it resolves it.

MSFS_AutoFPS v0.5.5.0, created from the final v0.5.4.5 test version, has just been formally released, available either through auto update in the app or from here. My thanks goes out to all who provided valuable feedback during the test phase. This major update introduces a comprehensive rewrite of the readme for vastly improved readability, alongside a next-generation In-Game Toolbar Widget and Web Interface with camera-based auto-hiding, interactive FPS controls, and full desktop visual parity. Other key highlights include dynamic graphics mode management, native MSM and VectorXR frame generation integrations, enhanced OFXR telemetry, dual-layer VR conflict protection, unified Night Mode cloud controls, and refined fixed FPS configuration warnings. Please review the redesigned readme here, which provides a detailed description of the app, installation, features and settings, before asking any questions or raising any issues about the app. For this release, the original format readme is also bundled alongside the new version.

It is an interesting suggestion on paper, but in practice linking OLOD to ground speed introduces a few technical snags that usually make performance worse rather than better in MSFS. The biggest issue comes down to how MSFS handles asset loading. If OLOD is tied to a speed threshold like 30 knots, decelerating below that mark on rollout or runway exit would cause the sim to suddenly request hundreds of extra models, apron clutter, parked vehicles, and ground gear. In MSFS, sharp increases in object counts cause noticeable main thread hitches, so crossing that speed threshold would almost certainly introduce a heavy stutter right as you are clearing the active runway. The same problem would happen in reverse during takeoff, or repeatedly during stop and go taxiing. Another consideration is that taxiing near terminals is often where system load is at its absolute peak, rather than its lightest. At complex payware hubs, having maximum OLOD on the apron spikes draw calls and saturates VRAM because of high-detail jetways, terminal interiors, and ground equipment. Moving at low speed reduces the rate of new scenery streaming, but it does not reduce the rendering cost of having thousands of high-poly airport objects on screen at once. AutoFPS already handles this scenario pretty well through its reactive target frame rate logic. If your system begins to struggle on approach or while moving through a heavy airport, the app dynamically steps down the LODs to protect your target FPS and smooth out frame pacing. Instead of tying OLOD to ground speed, the most reliable setup for heavy hubs is to keep the ground OLOD capped at a sensible, steady value (such as 100 to 150). Maintaining a consistent OLOD avoids asset streaming spikes entirely and preserves vital headroom when manoeuvring around dense terminal gates.

The most likely reasons TLOD is staying that low are: Your Target FPS is set too high, so AutoFPS is keeping TLOD low in an attempt to reach it. Your default MSFS TLOD is set fairly low. For example, when using the IFR profile, an AutoFPS TLOD of 18 corresponds to an MSFS TLOD of 72, which is quite conservative for a 7800X3D/4090 system. To fix it: 1. Review your Target FPS configuration: If using Fixed Target FPS, set it at, or no more than about 5% below, the FPS your system can normally sustain. If using Manual Target FPS, set it at least 5% below the FPS your system can normally sustain. In practice, a little more margin can help, as settings-reduction recovery requires FPS to remain at least 5% above target for several seconds before recovery begins. Alternatively, use Auto Target FPS, which will choose a suitable target automatically and also provide a higher starting TLOD. 2. Review your MSFS TLOD setting: When AutoFPS is not running and you are not in a flight, increase your MSFS TLOD setting. For your hardware, I would recommend at least 100 as a starting point. If you're still seeing TLOD around 18 after that, let us know: Which Target FPS Type you're using (Auto, Fixed or Manual) Your Target FPS value The approximate FPS you normally achieve in the aircraft and airports you typically fly Your MSFS TLOD setting That should be enough information to quickly identify what's keeping TLOD so low.

FYI, in the just-released 0.5.4.5-test17 version, widget v1.5.6 introduces an Auto-Hide dropdown in the header, essentially replacing the old show/hide hotkey setup with a fully automated solution for external and VR flying. You can set it to Off (default and always visible), Chase (hides only in external chase view), or All Ext (hides in chase, drone, and all exterior views, popping back within 1 second in the cockpit). Any previously configured hotkey will still work in the background, but the toolbar button has been retired to keep things clean. You will also notice you can now collapse the General controls section by clicking its header chevron. This tucks away all the dropdowns, steppers, and checkboxes when you don't need them, giving you a much more compact, minimalist widget focused purely on your live Sim Values and status telemetry. Edit: 0.5.4.5-test18, rolling the widget to 1.5.7, was released shortly thereafter as I found a way to make the widget window hide/show much more responsively to the view change, after collaboration with MajorDad from WeSimGlide over on Discord. Behaviour is otherwise the same as Test17.