daemotron
-
Posts
322 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Latest X-Plane & Community News
Calendar
Downloads
Store
Posts posted by daemotron
-
-
When switching of the strobes, they go from flashing to constantly lit instead of constantly dark:
-
As the title says, the NEAREST AIRPORTS list on the G1000 also shows helipads (zero runway length). Iirc the G1000 could be set up to filter airports with insufficient runway length. The shortest possible TO ground roll according to the POH (ISA -15, SL, 1100kg TOW) is 280m (919ft). The shorted possible landing distance (ground roll) under the same conditions is indicated with 255m (837ft). Maybe (and only if XP really supports this) it would make sense to filter out airfields with less than 250m of runway, or with a "margin of despair" anything with less than 200m.
-
Just a minor visual thing, when turning the BARO selector knob (outer knob), the turn animation for the inner knob is triggered, and vice versa. It's just a visual thing, using the outer interaction zone correctly changes the baro setting, and the inner the course.
-
The Windows installer doesn't launch from within the zip file. Just unpack the zip file somewhere on your disk (with its folder structure!), and the installer should work.
-
The main tank indicator (and fuel test) only works when the main inverter is switched on. The outer and tip indicators work as soon as there's battery power.
-
It's been a while... my Moo-venture continued; after a trip around Australia (including a short hop over to New Zealand), I finally reached Point Barrow, Alaska on October 31. Here's the complete route with all stops:
The GC distance of the route legs add up to 22,215 NM, and the flight log shows a total block time of 101:38 h.
Utqiagvik is a bit too cold for my liking in winter, so I saddled the Moo once more and started moving south, this time headed for Santa Fe, NM. So far I flew back to Fairbanks, and then on to Yakutat and Prince George.
The FBO at Yakutat wins the price for the best slogan:
-
2
-
-
Hi Tom, not on a Mac, this is on a Windows 11 machine.
-
This one seems to be tricky to nail down. It doesn't happen regularly, but just once out of 10 X-Plane shutdowns with the MU-2 (which embeds the G500). I'm not even sure the crash condition comes from the g500 code itself, but the stack trace points to it, so maybe there's something which under certain circumstances can produce a CTD:
2023-11-24 20:40:41 OpenGPWS[xplane.c:344]: OpenGPWS disabling --=={This application has crashed!}==-- --=={FILE: D:\X-Plane 12\Log_ATC.txt}==-- 2023-11-24 20:40:41 OpenGPWS[xplane.c:348]: OpenGPWS disable complete 2023-11-24 20:40:41 G500[Main.cpp:131]: XPluginDisable 2023-11-24 20:40:41 G500[g500.cpp:109]: Disable G500 2023-11-24 20:40:41 G500[g500.cpp:111]: Disable Popup System 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G500 MFD Bezelless 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G500 PFD Bezelless 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G500 Combined Bezel-less 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G500 Combined 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini GDU620 (Heli) Combined 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini GDU620 (Heli) Combined Bezel-less 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G500 Combined Bezel-less (G500 Hardware) 2023-11-24 20:40:41 G500[popupSystem.cpp:800]: Fini G620 (Heli) Combined Bezel-less (G500 Hardware) 2023-11-24 20:40:41 G500[g500.cpp:113]: Disable PFD 2023-11-24 20:40:41 G500[g500.cpp:115]: Disable MFD --=={UUID: 61a9851d-30aa-4e8e-91cf-808c4d1665fb}==--(full log and crash report attached)
telemetry_0.zip 61a9851d-30aa-4e8e-91cf-808c4d1665fb.zip Log.txt
-
Ah, that would explain it - I installed the update and tried to load the DC-3 first. After the crash, I loaded XP with a different aircraft, entered the X-A credentials, and now I can load the DC-3.
-
As the title says, I get a bizarre CTD with 2.0.3 - when loading the aircraft, X-Plane crashes, and I find this in the log:
2023-11-15 17:05:50 [LES DC3 Systems]: [dr.c:135]: assertion "dr->writable" failed: dataref "sim/flightmodel/weight/m_fuel_total" is not writable (dc3.c:153: &fuel_qty_total) --=={This application has crashed because of the plugin: LES DC3v2}==--AFAIR this data never was writable in any X-Plane version before; the writable one is sim/flightmodel/weight/m_fuel (array with 9 floats, one for each tank).
-
Well, this is what you sign up to when installing a beta. Laminar has always been transparent about this. You can't demand payware developers provide immediate updates for every beta Laminar tosses out. 12.0.8b1 has introduced a number of issues with a number of addon aircraft - some of them will likely need fixing on aircraft dev side, some will require Laminar to fix their beta code. Let's wait until 12.0.8 turns final, and then HS will be able to tell if they really have to update the Challenger, and if yes, what exactly they have to update. Anything else is just a waste of precious dev time by chasing a quick moving target.
-
1
-
-
@Coop maybe it's an option to remove the FSE override in future versions, to avoid any confusion. The latest iteration of the FSEconomy client allows to exempt a specific aircraft model from loading fuel and/or payload, which is particularly useful for aircraft coming with their own W&B management. The only thing that needs to remain in place is that the following data refs read appropriate values:
sim/aircraft/overflow/acf_tank_rat sim/aircraft/weight/acf_m_fuel_tot sim/flightmodel/weight/m_fuel sim/flightmodel/weight/m_fuel_total
The FSEconomy client will need these to determine the fuel spill and fuel burn, but when automatic loading is switched off, it won't attempt to write them.
If you need more details, just holler me (I'm the author and maintainer of the current FSE client).
-
There are two commands defined for the DC-3:
les/dc3/cmd/controls/L_mixture_up les/dc3/cmd/controls/R_mixture_up
I bound both to hardware keys. R_mixture_up works and moves the right mixture lever up to the next position. The L_mixture_up command doesn't do anything. Ticking the checkbox in the settings dialog doesn't seem to have any influence.
-
Sure, only talking about the chime when switching it on. Hm, that one's hard to nail down - on some flights, no chime at all, on some flights, it works all the time, and on some, it works at the beginning, then stops. I can't really tell yet what I have to do to break it, seems completely random.
-
That's a really minor one - I noticed that when switching on the FSB and NS signs for the first time, a chime sound plays - but not when switching them on later down the flight.
-
I was flying a short descent in cruise, using VS mode and ALT SEL armed, altitude pre-selected on the G500. When reaching the selected altitude, the VS and ALT SEL lights on the AP panel went off, and altitude was (at least seemingly*) captured, but the green ON light on the ALT button didn't light up. De-pressing and re-pressing the ALT button itself made the green ON light come up.
This seems to concern only the glass version, never had this in the GNS version.
*tbh I didn't wait long enough to determine whether it had really captured or not; my VS for the descent was pretty low (-200fpm).
-
I suppose it hasn't XP12 style load stations yet.
If you want to brute-force adjust your ZFW, you could use Data Ref Editor and write something into sim/flightmodel/weight/m_fixed (the numeric value represents payload in kgs).
-
Dug out the G500 version for the first time in XP12. I noticed the clickspot for the MFD knob is (still) missing in the XP12 version - cf.
so putting this here as reminder for whenever is the Moo's next turn for a patch
-
Cruise power isn't too far off (though it depends a bit on altitude, and not all parameters will hit the POM values):
Getting those all dialed in will possibly not work - there are also tables for ISA +/- 10, 20 and 30, and then the same for max range power (the one above is for recommended cruise, i.e. pretty much the maximum you can get from those TPEs). In total there are nearly 1,300 different altitudes, temperatures and power settings to be dialed in (108 table lines * 3 weights * 2 different power settings * 2 different props (4 & 5 blade)), and for each you'd have to align four data points (torque, ITT, fuel flow, airspeed), so a total of over 5,000 data points.
With the way X-Plane's engine, prop, lift and drag models work, I don't see this is close to possible - you can nail one setting by tweaking the fuselage shape, airfoils, engine and prop parameters and curves, but that will most likely throw you off course for another data point. So Tom's dilemma here will be that he has to chose which data points to align to, and accept that others will be somewhat off.
If I understood Isaac correctly though, he was more addressing the engine limits in climb (first they're torque limited, later on they're temperature limited) - that'd be the next >5,000 data points to pin down...
Finally, I'd like to say these discussions here sometimes come across as if we only had to criticize the Moo - we're so much quicker in reporting issues and bugs than being grateful for how great a Moo model Tom created here. Tom, if you read this, the MU v2 is great and deserves more visibility in public (and more sales). It is by a huge margin the aircraft model I fly and enjoy the most ever since it released for XP12.
-
Thank you Tom, these commands are just perfect! I understand that initially you didn't want those single event commands - for keyboard & mouse they're not too suitable and oversimplify. I'd see them only useful for people trying to bind stuff to hardware.
Yeah, I didn't attribute this to code on your end, I thought that XP's behaviour changed - but my memory may be leaking, I hope I'm not confusing things...
-
It works with buttons and also keyboard assignments (sending the command repeatedly), but before it also worked with switches (sending the command only once). Tbh I only noticed it since I had those assigned to the engine fuel flow switches on my Warthog throttle (simple two way switches).
-
1
-
-
In older versions, the command to move the engine fuel levers used to be mixture up / down.
With XP12 and the IXEG v1.5, these commands still make the fuel levers move a tiny bit, but not slide up/down entirely between the IDLE and CUTOFF position.
-
Three weeks later, I'm now (virtually) in Jakarta, Indonesia. As planned, I flew the Moo via Kathmandu (VMKT) and Paro (VQPR), and then on to Lilabari (VELR), Momeik (VYMO) and Thandwe (VYTD):
From Myanmar I had to fly a deadhead leg and relocated to Bangkok (VTBS). Not the best weather down there currently...
Yesterday I started moving further south, delivering a well-paying VIP transport job to Jakarta. Due to time zoning, it was an all-night flight. The distance of more than 1,200NM was quite a stretch for the Moo, so I made a fuel stop at Kota Bharu (WMKC). Arriving in Jakarta, I was greeted by a thunderstorm, surrealistically lighting up the city (on final into Halim Perdanakusuma, WIHH):
The next assignment will indeed take me again further south to Australia - got a bunch of VIPs headed from Jakarta to Paraburdoo (YPBO). Again that leg is too much of a stretch for the Moo (at least when observing legal reserves and some margin for weather), so I'm planning to fly this with another fuel stop - hoping to meet Santa on Christmas Island (YPXM)...
-
3
-
-
When playing around with the RXP GNS units, I noticed that there is indeed a distinction with regards to electrical buses. The 530 (primary unit) is hooked to Bus #1, the 430 (secondary unit) to Bus #2. Now the quirk: The GPU powers only Bus #1, while the battery powers both buses:
The RXP units allow to be hooked up to one of 8 different buses (the default avionics and battery bus plus one of the 6 custom buses):
The MU-2 uses three of X-Plane's buses (not sure what Tom's code does in addition to that, so there might be more):
This would (theoretically) leave 3 potential "spare" buses (understood by the RXP units) which could be used to fake a set of dedicated radio buses for the RXP units - I guess that would require some custom plugin-driven logic (to link bus power to the radio switches), so probably a lot of effort for little effect (in the end, it's just RXPs turn on/off with battery vs. RXP units turn on/off with radio switches).
[1.0.2] Persistence Issues
in DA40NG
Posted
I'm observing a few smaller issues with persistence:
Would be great if these could be fixed; e.g. by providing a menu "store this state", forcing to write the current state (if XPs shutdown process isn't reliably triggering the save state function or not leaving enough time for it to finish what it's supposed to do).