February 11, 201313 yr I've decided I'd like to nail this down once and for all, the mystery why some aircraft can run without issue at 16x acceleration in FS9 and others can't. Three main aircraft I'd love to resolve are the 'Level-D 767', 'PSS 777', and 'CaptainSim 757'. If anyone has some suggestions please let me know. I can't figure out why these three birds have such an issue with in sim acceleration. FS2020 Alienware Aurora R11 10th Gen Intel Core i7 10700F - Windows 11 Home 32GB Ram NVIDIA GeForce RTX 4070 Ti Super OC 16GB - Pimax Crystal Light VR
February 11, 201313 yr I believe it to be an issue related to the FMC. I recall trying on one of those birds and I vaguely recall getting a message indicating a potential problem with the FMC and accelerating the time. Don't blame for my name, my parents were hippies and met in Woodstock
February 11, 201313 yr This is only a guess but is based on my own panel and gauge programming experience. If those aircraft have systems that use counters or iterative formulas, then they will run at the same rate in the sim, regardless of the simulation rate. Only systems that are bound to the default FS variables only, are coded to explicitally take the sim rate into account or are bound to the sim time will work properly at higher sim rates... It is much easier to program complex stuff the iterative way at the expense of high sim rate stability. My guess will be that the more complex the add-on, the less likely it is to be tolerant to time acceleration! An example in my own work is that if I try to climb or descend with a high simrate, my cabin pressure gauges will be messed up because the reported vertical speed will be "normal" but the actual level change will happen much faster so the pressurisation will not cope... Geoff
February 11, 201313 yr Author This is only a guess but is based on my own panel and gauge programming experience. If those aircraft have systems that use counters or iterative formulas, then they will run at the same rate in the sim, regardless of the simulation rate. Only systems that are bound to the default FS variables only, are coded to explicitally take the sim rate into account or are bound to the sim time will work properly at higher sim rates... It is much easier to program complex stuff the iterative way at the expense of high sim rate stability. My guess will be that the more complex the add-on, the less likely it is to be tolerant to time acceleration! An example in my own work is that if I try to climb or descend with a high simrate, my cabin pressure gauges will be messed up because the reported vertical speed will be "normal" but the actual level change will happen much faster so the pressurisation will not cope... Geoff The issue I'm talking about is not a systems issue but rather an FDE issue. During accelerated time systems are normal it's that aircraft will jerk and either roll or bounce and ultimately depart controlled flight. It's like the stability is not solid enough on the roll and longitudinal axis to maintain controlled flight. By contrast aircraft like the Feelthere's Airbus series, PMDG's MD11 and iFly's 737 can operate at 16x sim speed. I'd like to know the reason why these three add-ons can't. FS2020 Alienware Aurora R11 10th Gen Intel Core i7 10700F - Windows 11 Home 32GB Ram NVIDIA GeForce RTX 4070 Ti Super OC 16GB - Pimax Crystal Light VR
February 11, 201313 yr Ahaa, see. Sorry I misunderstood the question. It might still be related to the same problem though - if the add-on aircraft use a custom autopilot (and let's face it, the default one is rather limited at times) then they might still be relying on iterative scripts that are not 'happy' when the movement per cycle is very high, as could happen at accelerated sim rates. Say if the AP lateral mode was using the average movement over the last second to predict the required correction, this could go badly wrong since the movement in the last 'real' half second is actually 8 seconds at 16x..! Geoff
February 11, 201313 yr Author Ahaa, see. Sorry I misunderstood the question. It might still be related to the same problem though - if the add-on aircraft use a custom autopilot (and let's face it, the default one is rather limited at times) then they might still be relying on iterative scripts that are not 'happy' when the movement per cycle is very high, as could happen at accelerated sim rates. Say if the AP lateral mode was using the average movement over the last second to predict the required correction, this could go badly wrong since the movement in the last 'real' half second is actually 8 seconds at 16x..! Geoff I was hoping you wasn't going to say the Autopilot was at play here. I hadn't really thought about that but I remember years ago some developers were going outside of FS's default confines for a more realistic experience (maybe too realistic seeing one has to fly the Level-D 767 in real time from say KMIA to Rio) . I've hangered the Captainsim 757 in favor of the QW757 because of this. I've since rediscovered it and prefer it's VC over the QW version. If the autopilot is the reason for the problem there's really no fix... :( FS2020 Alienware Aurora R11 10th Gen Intel Core i7 10700F - Windows 11 Home 32GB Ram NVIDIA GeForce RTX 4070 Ti Super OC 16GB - Pimax Crystal Light VR
Create an account or sign in to comment