September 18, 20187 yr 23 minutes ago, AnkH said: That's why I would only replace the .exe string inside the add-on.xml as suggested by bully. Basically something like this: <AddOn.Component> <Category>EXE</Category> <Path>C:\PROGRAM FILES\FLIGHT ONE SOFTWARE\ULTIMATE TRAFFIC LIVE\UTstartup.bat</Path> </AddOn.Component> <AddOn.Component> <Category>SimObjects</Category> <Path>C:\PROGRAM FILES\FLIGHT ONE SOFTWARE\ULTIMATE TRAFFIC LIVE\utLive Aircraft</Path> </AddOn.Component> That should work, no? Or does the add-on.xml need to have an .exe executable to work properly? I guess no... Hi Chris, Interesting 'solution'. I suspect the answer to your question will be no as I'm not sure xml syntax allows for bat files. You've come this far so why not try it and let us know what happens. Either it will work or it won't. Either way you're not likely to do any harm. Make sure you have a backup of the add-on.xml to allow you to recover the original situation! Regards, Mike
September 18, 20187 yr Ok, I see my problem, it is declared as .exe in <Category>EXE</Category>, probably this needs to be adjusted. I will try, typical try and error approach ;-) Greetings, Chris AMD Ryzen 7 9800X3D, 2x32GB DDR5 6000MT/s RAM, MSI RTX 4090 Ventus 3X, Windows 11 Home, MSFS2024
September 18, 20187 yr Ok, this does not work, as expected. So far, this is not too bad for me, as I am happy with the performance I have now. Back to flying again 😉 Greetings, Chris AMD Ryzen 7 9800X3D, 2x32GB DDR5 6000MT/s RAM, MSI RTX 4090 Ventus 3X, Windows 11 Home, MSFS2024
September 20, 20187 yr What if one creates a .EXE that calls a batch? Or make all the needed calls inside the program.EXE itself, hmmmm... I'm not (yet) messing with these things, but one setting that seems to be working great here is: 1) Set NVI to limit at 30 FPS 2) Set internal P3D v4.3 lock at 40 FPS This way apparently I'm combining the smoothness of NVI FPS limitation together with good anticipation of textures and autogen loading but still not falling into that "mid-frames" thing which cause microstutters. I was using previously NVI 30 + unlimited inside, albeit I never saw blurries (not with the 8700K 5 but yes with the 4770K 4.5) I was having some moderate delays loading the autogen. Best regards, Wanthuyr Filho Instagram: AeroTacto
September 20, 20187 yr 2 hours ago, Wanthuyr Filho said: 1) Set NVI to limit at 30 FPS 2) Set internal P3D v4.3 lock at 40 FPS Oh my... Are you sure your system can churn out 80 FPS if set Unlimited in the areas where you fly normally? Otherwise you may have missed the point of locking FPS in P3D extensively discussed in this thread. It shouldn't work well on my system at least. Edited September 20, 20187 yr by Dirk98
September 20, 20187 yr What?! Nobody ever stated that the frame lock inside P3D should be set at a frame rate exactly half of what you would achieve with "unlimited", where did you get this info from? Greetings, Chris AMD Ryzen 7 9800X3D, 2x32GB DDR5 6000MT/s RAM, MSI RTX 4090 Ventus 3X, Windows 11 Home, MSFS2024
September 20, 20187 yr You may put your exclamation marks as much as you want but who said "exactly"? Otherwise you might want to go through this thread again starting from this suggestion by SteveW: See, "two frames" and "one frame" - do your math. Edited September 20, 20187 yr by Dirk98
September 20, 20187 yr Steve talks about the looking ahead frame buffer, this can not be translated into double or half FPS numbers. Otherwise, activating tripple buffering would result in three times lower FPS, no? And surprise, this is never the case. This is simply not how graphics engines work. Sure, you did not say "exactly", but you stated that one should reach 80FPS for a limit of 40 to work, which is not true even if you were thinking about a range of FPS instead of exactly 80FPS. In my case, I get about 30-33FPS using unlimited on my home base LSZH. With a frame limit of 30, those numbers go down due to this looking ahead buffer, but not down to 15-17, only to about 25-27. Basically, I would say that you should put your frame limit to the lowest FPS number you can achieve on your heaviest scenario. That's what I did and it works perfectly. Translated to Wanthuyr's post: if he gets 40+ FPS on his heaviest scenarios, a frame limit of 40FPS is legit. Simply the additional fact regarding refresh rate of his monitor might alter this and probably he would be better off with a 30FPS limit, but only assuming he uses a 60Hz monitor. Greetings, Chris AMD Ryzen 7 9800X3D, 2x32GB DDR5 6000MT/s RAM, MSI RTX 4090 Ventus 3X, Windows 11 Home, MSFS2024
September 20, 20187 yr Commercial Member Locked fps slider: Each next frame is derived for that exact period ahead. There's a look ahead buffer can hold more frames ahead, normally limited to three frames in total. As soon as one frame is drawn the next is started, there's no pause, it's just like unlimited. If there's no time to make the look ahead frames then it's not running locked it's running unlimited. So in effect you need more performance to complete a frame in hand for a dropout. In fact you need more than a frame in hand more like two. However you don't need to make those to see the sim you just see the current frame and never see the part built frames. So once you have a frame or two in hand you can ride out a dropout, but then it's got to rebuild the look ahead and if you're still getting dropout then they never rebuild. So better to stick to limiting with VSync. So if you can get 40 fps in unlimited vsync=off then that would be OK for 20 - 25 locked, maybe 30 at a push. With higher frame rates the time diminishes between frames gives rise to less wobble and the need for less look ahead. The triple buffer is little understood. Sometimes with a back buffer and a display buffer the backbuffer is completed before the display buffer is done with. And so by introducing a second back buffer means that the renderer can continue drawing frames in a more timely fashion. Giving rise to a more consistent frame to frame output period - where the objects are displayed is more accurate. Steve Waite: Engineer at codelegend.com
September 20, 20187 yr Ok, then I apologize to Dirk98, seems that you indeed need the double performance, roughly. Greetings, Chris AMD Ryzen 7 9800X3D, 2x32GB DDR5 6000MT/s RAM, MSI RTX 4090 Ventus 3X, Windows 11 Home, MSFS2024
September 21, 20187 yr 18 hours ago, Dirk98 said: Oh my... Are you sure your system can churn out 80 FPS if set Unlimited in the areas where you fly normally? Otherwise you may have missed the point of locking FPS in P3D extensively discussed in this thread. It shouldn't work well on my system at least. It doesn't give 80 FPS no way, maybe during cruise yes, but normally far from that. In any event I don't need 80 FPS, I need 30 (limited by NVI, remember?) and even when it doesn't cope with that (clouds, heavy airport, etc) it's still pretty smooth unless it falls down to single digits. Best regards, Wanthuyr Filho Instagram: AeroTacto
September 21, 20187 yr 7 hours ago, Wanthuyr Filho said: It doesn't give 80 FPS no way, maybe during cruise yes, but normally far from that. In any event I don't need 80 FPS, I need 30 (limited by NVI, remember?) and even when it doesn't cope with that (clouds, heavy airport, etc) it's still pretty smooth unless it falls down to single digits. Didn't you mention: Quote 2) Set internal P3D v4.3 lock at 40 FPS ? No matter what you set elsewhere (NVI or others) soon as you lock internal P3D's FPS to a certain number, you should expect that your system, if set @ unlimited FPS, can cope OK with double that number. You can set to unlimited first, fly and see what the counter shows. I.e. if you see circa 40-50 FPS around an airport @ unlimited fps in P3D, there's a good chance your system will struggle badly in the same areas with fps set to 40 in P3D. Capisce? )) However if you see your own settings work good for you, just disregard all this balderdash and go fly. Dirk. Edited September 21, 20187 yr by Dirk98
September 21, 20187 yr Personally, I am amazed that some people use locked frame rate at 25 or 30..... Computer's tittles with this low level of FPS dosen't looks good for me, especially if You are user of Track IR. Everything below 40-50 fps looks for me odd and noticeable stutters are present. Here is example 25 fps vs 60 fps. Locked frame rate has benefit for textures (no blurries in P3Dv4.3 so why I use locked, right but on the level of refresh rate of monitor = 144. The level of more than 60 (default) is in cfg, You can edit it manually. [DISPLAY] UPPER_FRAMERATE_LIMIT=144 Example (here it was 80-100 fps in P3Dv4.3): Edited September 21, 20187 yr by YoYo Webmaster of yoyosims.pl.Win 10 64, i9 9900k, RTX 3090 24Gb, RAM32Gb, SSD M.2 NVMe, Predator XB271HU res.2560x1440 27'' G-sync, Sound Blaster Z + 5.1, TiR5 [MSFS, P3Dv5, DCS, RoF, Condor, IL-2 CoD/BoX] VR fly only: HP Reverb G2
September 21, 20187 yr Moderator What some people are trying to say is that taken by itself, FPS have no real bearing in P3D. I've seen 60+fps systems that are a choppy mess and 20FPS systems that are smooth as silk - and the exact opposite. You are saying you can tell between 25fps and 60fps. Of course you can *IF* there are stutters, etc. The problem is that the stutters are usually NOT the result of low FPS but poor settings. If you lock at 25 and if your sim is smooth <-----(IMPORTANT) - you will not be able to tell the difference. If it's not smooth - all bets are off but again, the reason it is not smooth is not due to fps. Each system and viewer is different and we all have certain things we look for - a good rule of thumb to get in the ballpark of quality vs performance is to set up your system so that it is smooth to your eye on your system and then start reducing the FPS down towards 20. Adjusting settings as necessary to keep both the visuals and performance you want. Try the find the lowest FPS that give the smoohest performance on your system with your way of flying. That will be your sweet spot. There is no "one size fits all" answer to this question. Vic RIG#1 - I9 14900K MSI Pro z790 RTX 5070Ti 40" 4K Monitor 3840x2160
Archived
This topic is now archived and is closed to further replies.