Bob Scott

Judging by the numerous YouTube videos and the steady stream of spectacular failures chronicled by guys like Juan Browne (aka Blancolirio) and Dan Gryder (Probable Cause), there is no short supply of guys who *are* actually licensed pilots who do really dumb things--which all too often end up with an airplane-shaped hole in the dirt. Retracting the flaps during a landing as SOP, whether in the flare or just after touchdown is just the sort of pilot...ummmm... "technique" I'd consider worthy of someone wanting their own 15 minutes of attention on Gryder's channel and perhaps a Darwin Award nomination. There's a reason that an hour in a GA airplane is 19 times more likely to kill you than an hour on the road...

Sometimes when a program terminates abnormally it remains loaded and dormant in the background, and its possible that it will be automatically reloaded by Windows after a restart. If that's the case, you can force termination of Pro/ATC in task manager or using a utility like Process Lasso.

FSX does require DX9 (or DX10 for the preview mode). That unified installer should install side-by-side libraries for every version of DirectX. Did you reboot your PC after running the DirectX installer? I'm pretty sure that's needed even if not explicitly directed after the install. If that doesn't work, I'd suspect an antivirus or antimalware program interfering with the DX installer.

This is much ado about nothing. The need to put copyrighted commercial software behind some kind of firewall is pretty obvious--whether it's a store account or a support forum account that's used to download software and get support really is a matter of semantics. PMDG requires their Ops Center, Leonardo requires a support forum account to get Maddog updates, Majestik requires either a support forum account and/or a store account for their updates, Aerosoft requires a store and/or support forum account for updates and most other add-ons require some sort of store account somewhere to download the software and get updates. etcetera...etcetera...etcetera... Who, after all, buys an $80 add-on and doesn't want to download liveries and other support software or peruse the support forums to answer questions or get help with problems? Putting all that in one place makes some sense.

Maybe FSL should release a Neanderthal Edition that installs via stone tablets and doesn't require pesky things like the same dot net runtime that many (most?) other new titles need for ancillary library support. C'mon now, some white-belt level Google-Fu and five minutes of your time and you should be able to get yourself setup with the latest dot net runtime. If you can configure and fly a flight sim, surely you can master something that trivially easy rather than excoriate the dev for trying to make installation and configuration as easy as possible.

You need to run the Microsoft DirectX unified installer https://www.microsoft.com/en-us/download/details.aspx?id=35

Size (particularly length), as mentioned--the ASUS (and most other third-party) GPUs are very big, and don't fit in many older cases that don't allow the drive cages to be removed or moved. If you need a shorter card, the nVidia 4090 Founders Edition is considerably shorter. Also power cable routing is a potential complication--the 4090's 12VHPWR power connectors are located on the top edge of the card, and attempting to place a sharp bend on the thick/stiff commonly-supplied "octopus" adapter cable to keep it within the side of the case risks cracking the board and/or letting the magic smoke out of the card. This can be mitigated with either an aftermarket PCIe 5 cable that terminates in a 90-deg connector or one of the 90/180 deg Cablemod adapters.

My last prolonged visit to MSFS CTD Hell was the result of bugged new nVidia drivers...reversion to 531.29 fixed it definitively. M$/Asobo acknowledged that mutiple users were reporting problems and recommended the reversion. I have not updated drivers since, and have not had any recurrences, either.

I've split this post out of the previous thread, as it was off-topic there.

If you already have the boxed edition installed and working, I see no real advantage to justify the butt pain of switching. If you do switch, make sure to uninstall the boxed edition and delete the registry settings for FSX before installing FSX:SE--if the SE installer finds that registry settings exist for a boxed edition install, it changes the paths where add-ons and config files etc are located, making things very complicated w/r/t add-ons. If there's no boxed edition found, it uses the same file structure as the boxed edition, so add-ons that aren't specifically set up to install into SE will install normally to the legacy boxed edition's locations.

Milt Shupe's freeware Howard 500 comes to mind...powered by a pair of R2800 radials with a max range of ~2200nm.

An affinity mask is unnecessary with SMT disabled. Volumetric clouds aren't compatible with weather radar in any add-on I'm aware of in P3D, so I leave it off and use ASP3D+ASCA clouds, which I like better anyway. EA on or off is your aesthetic choice. EA does significantly limit what third-party shader mods can do, however. As far as VSync and frame rate limiting, I'm not sure what to recommend now. P3D v5.4 appears to have changed the way VSync affects CPU loading in a fairly significant way, so the old wisdom (VSync on, frame limiter unlimited in sim, NCP 30Hz to a 30 Hz monitor) may no longer apply. Threaded optimization -- I have it off, but can't say I've ever noticed any effect positive or negative. Most of the time I run 4xSSAA. I can brute force things with a 4090 and leave it on all the time, but with your 3060Ti, you'll likely need to back AA off to 2x or 4xMSAA when dynamic lighting is in use.

MSFS 2024 will target iOS and the iPhone 15, taking advantage of Apple's "Flame Generation" feature. And before you ask, no, that's not the chinese pronunciation of "frame generation"--it's the parasitic overheat and autocombustion of its lithium-ion battery as it fries tries to attain 10fps using the A16 Probiotic processor's graphics circuitry. But if open flames are a worry, the iPhone 15 Max will ship with a self-contained Halon fire extinguisher cartridge.

Yves; You can remove the stair truck by disabling stairs with the checkbox in the parking customization menu, and you can remove the baggage carts by selection "none" in the forward and rear baggage cart dropdown menus also in the parking customization menu. You cannot remove the pushback tug, but you can move it--you can place it inside a building where it will not be visible, or you can just move it to a point far away so that it's not on the parking spot.

Most importantly, the ipc.sleep function suspends execution of the script rather than going into a tight timing loop, which is a potentially important consideration when coding real-time processes. There's a lot of useful functionality built into the Lua library for FSUIPC. I never cease to be surprised at how much one can get done with simple Lua scripting using the FSUIPC library.

I'd think adding a 1/4 sec sleep delay between the controls should fix that: ... ipc.control(66587,71008) -- command for pushing the Baro knob ipc.sleep(250) ipc.control(66587,71011) -- command for releasing the Baro knob ...

Is the use of different variables (CabinTempPAST vs CabinTemp) intentional?

OK, we're on the road to Abilene here. Locked.

I'd do it by putting the state flag into a user offset, which persists across lua script executions. For your example to work, you'd have to keep the script running in a loop (to keep the state variable "i" alive) rather than just executing it once each time the button is pressed. e.g. (using user-area offset 66C0 as an example) btnstate = ipc.readUB(0x66C0) if btnstate == 2 then ipc.control(66587,71008) -- command for pushing the Baro knob ipc.control(66587,71011) -- command for releasing the Baro knob ipc.writeUB(0x66C0,1) else ...etc That said, I think it would be better to code your "pull" action for something like a press-and-hold > 1 sec rather than alternating the press-pull actions.

You better run, Manuela run and supply some love, or it's gonna be goodbye girl, goodbye right before they shoot you in the back with your own gun!

There's already a thread on this topic started by the same OP, so this one is now closed.

I just checked, and yes indeed, this is still the XPlane forum. Those who desire to have a MSFS discussion in the XP forum should expect their prose compilations to disappear, and those with a habit of going there to be disinvited from further participation in this forum altogether. And, seeing as this discussion left the reservation some time ago, this one is locked.

Yes--VSync on, 30 Hz set in NCP to a 30 Hz display. As far as the OP's question, my opinion is that the behavior he's experiencing is a feature, not a bug--he's having temp issues because the CPU is being heavily loaded, and in a broadly parallel manner which differs from versions up through 5.3HF2. With previous versions, concurrent loading of all the cores only occurred intermittently during texture loads...now the duty cycle of all of the cores (% of the time they're doing work) is much higher. w/r/t use of HT on a 24-core 13900K to run P3D: my understanding is that the OS will task the P-cores first, then the e-cores, and then the HT virtual processors. I'm still of the opinion that need of processor cores beyond the 24 physical cores on the 13900 is questionable, and I've kept HT off (and disabled 4 e-cores, and masked off two of the 12 active e-cores to P3D) to minimize unnecessary heat, not split the cache available to the P-cores and preserve the ability to clock all the P-cores up (and one to 6 GHz). Running P3D on the 8 p-cores (with the main thread at 6 GHz) plus 10 e-cores works so well I haven't really had the inclination to tinker as much as I have in the past.

I just did the update from 5.3HF2 to 5.4 this last weekend. CPU utilization does indeed seem to have taken a markedly different path in this version. I have been running P3D with VSync on to a 30Hz display for years, which has limited CPU utilization on the heaviest tasked core running the main thread to down around 70%. With 5.4, that core is pegged at 100% pretty much all the time, and the other cores (including the 10 e-cores enabled for P3D via the affinity mask) are also being fairly heavily tasked, especially when airborne. So the temps and voltages are indeed averaging higher than before, but it's not causing a problem--in fact, the opposite. It raised my eyebrows when I first saw it, but the sim is running very smoothly like this without any of the stuttering I would have expected from keeping the main core loaded up like that. I just flew the FSL Scarebus into FlyTampa's KBOS, which has always been a challenge performance-wise, and it was very smooth despite the main thread's core being firewalled at 100% the whole way in. I suspect that if your cooling isn't up to having most of your CPU's cores getting a real workout a lot of the time, it might cause CPU temp issues where 5.3 did not due to its much less aggressive usage of multithreading. On my water-cooled 13900K, with 20 cores active and 18 allocated to P3D (AM=262143), I'm seeing temps venturing into the mid 70s C on the core running the main thread, which is about 8-10 deg C higher than I saw with 5.3. Some of the other cores are occasionally bumping into the high 60s and low 70s. The cores specifically allocated to the render thread and frameworker thread are not being tasked noticeably higher than the others like they used to...most of the cores are getting hit concurrently now, and fairly often. It's anyone's guess as to whether the thread scheduler masks are now being ignored, or if their workload has been redistributed in such a way as to make their load levels indistinguishable from their peers.

The pic you posted there shows the SafeDock, a pushback tug, and there is no marshaller on the spot, which is exactly what should be there based on your parking spot config. Is it the pushback tug you're trying to remove? Just in case this is a language issue, a "marshaller" is a ramp worker with orange wands who directs the pilot into the parking spot with hand signals.