rosseloh

Thanks! You could potentially consider licensing libturbine from Saso if you decide a custom engine model is the way to go - but I don't know what that would entail to implement, what it would cost you, or if it would be worthwhile! Just that it would be a good call for the overall simulation if you went that way.... Another thing I noticed is that when above 25,000 or so, the engines can't put out enough air to keep the cabin pressurized, and above 26k/27k you start to get into the cabin alt warning area. The manual makes it seem like the thing should be able to hit 30k/31k at max diff with a cabin alt of around 10k, but what I've observed is the differential pressure can only get to max when below 25k-ish. This was on a very standard day (ISA was somewhere around 0 to +1 IIRC) This could be related to the engine changes I made as part of Crash's mod, however, so don't focus too hard on that one until we're sure it's a problem with the actual engine model and not my mods.

The HSI does still display the information - or at least it's supposed to. This is the same issue the Entegra SR22 has. It won't display the waypoints on the map but the CDI should display navigation information. I have not shot an RNAV approach in the MU yet so I cannot confirm or deny if this happens here, though if it does I would expect 50/50 whether it's the MU's fault or the G500 addon itself (I've found a few bugs with it myself as this is the first plane I've bought it to use with, so it very well could be the G500)

Finally got around to doing a few flights with the MU-2 in XP12. For clarity, I am using CapitanCrash's modified airfoil configurations and tweaks, so I *have* modded the ACF file - that shouldn't invalidate these observations, but if it does, so be it (none of them have anything to do with the flight model, which for the most part feels fine). Of course, as always, I apologize for any of these that have already been reported! (I did look through the first six or so pages of the forum to check) Here's what I've seen thus far. Things that may not be bugs but seemed off to me: 1. With Continuous Ignition set to off (as per the procedures in the real manual; I don't see anything about what to set it to in the TOGA Sim checklist), the engines will never light off. I've thus far only tested this while doing the NTS check during start, as I have not done a "second flight of the day" yet. I will check the next time I fly. What happens is, per the normal NTS check startup procedure you hold Unfeather, then hold Start the starter spins, fuel flow comes in, EGT comes up ever so slightly (if it's simulated I assume just from compression heating) but the starter light never engages and the fuel never ignites - *until* you release the Unfeather button. At that point the light comes on, and the start continues seemingly normally. As far as I've gathered I'm pretty sure ignition is supposed to come on on its own during the startup sequence - that's one of the things the Run-Crank-Stop switch does (since putting it to Crank disables ignition and/or fuel introduction?). But that's just from my reading of the manual, maybe I'm wrong! in contrast, the start goes as expected (including the NTS check) as long as continuous ignition is on in some way (generally Auto) 2. The Glass version of the plane flies on the GPS just fine in NAV mode, without using GPSS Roll Steering. This one I assume is expected behavior... However the Roll Steering button still exists on the panel. 3. The Glass version can track the G500 Vertical Speed bug in VS mode whereas the other models do not have this function and only hold the VS you have at time of engagement. This also may be expected? I'm not complaining, despite being fine with control-wheel steering options in most planes in this one it seems awfully janky, almost like the AP isn't quite trimmed out despite it being trimmed when I hand control over to it (this could be realistic, I'm not sure), so I am happy to have a proper VS mode where I can dial it in. 4. The toe brakes feel like they take half a second or more to apply even with the brake rate thing in the settings set to 0.01. I have hardware toe brakes and I'm used to getting basically a one-to-one mapping of brake force to pedal position. In the MU-2, even if I slam them to full, I don't get any indication they're applied at all for a short period of time (at which point they lock up as expected). Maybe this is normal. 5. Static elements (chocks, pitot covers, yoke lock) don't appear to persist after quitting the sim. Maybe intended, but seems a bit odd if so - what's the point of simulating them if I have to put them on before I take them off on my walkaround? Things that are probably bugs: 1. There is no clickspot/manipulator for the command rsg/g500/cmd/mfd/knob_push for the Glass version. I can get around this by mapping a key in the interim. 2. I cannot monitor NAV idents. Clicking the buttons on the audio panel does nothing. (I wanted to do this as I noticed some interesting behavior on the needles at extreme distance from a VOR, and was curious if you had implemented libradio into the plane; I'm guessing not since the DME doesn't seem fuzzy at all, but noticed this bug while I was at it) 2a. (There might be other issues there, but the NAV idents are the only one I've confirmed) 3. The audio panel does not light up except for the marker sensitivity lamps. I have seen this one was reported and confirmed already, but just for posterity... This is the case in both the GNS and Glass variants. 4. The flight timer on the transponder unit displays 60 in the seconds field for a half second or so after 59, before switching to 00 as it should. For example, the time going from 00:39:59 to 00:40:60 before switching to 00:40:00. 5. in the GNS version, the yoke shaker animation plays every few seconds with battery power on. I did not notice it happening once the engines were on or generators were on the bus, but I did not test properly so I don't have details for you. Update: saw it happening during taxi. So generators were definitely on bus. No sound, just the animation. This does not happen in the Glass version Yes it does. 6. You already know about the slow reverse application, especially noticeable while adding reverse after touchdown. But I've seen it as well! 7. The yoke lock prevents you from showing/hiding the yoke with the clickspot. I neglected to test the keybind. It doesn't matter what state it was in when you put the lock on (showing or hidden), but you can't change it at that point until you remove the lock. 8. In the GNS version at least (neglected to test in the Glass version), after using GPSS roll steering in a flight and then disconnecting the AP without switching back to regular heading mode, the GPSS roll steering lamp stays lit even after the battery is turned off. 9. I noticed that the two custom commands for "add_left/right_roll_trim" don't appear to work. Instead I just mapped the default roll trim commands and they worked as expected. Finally, not bugs at all, but just questions. Are there datarefs/commands for the pitch wheel and roll knob on the autopilot? I wouldn't mind lacking a controllable VS mode if I could just leave it in Pitch mode and control it manually with external hardware (the virtual wheel is just a bit of a pain, my own issue, I know). I see a pitch wheel command in the documentation but it doesn't appear to work, and I don't see anything for roll. Thanks Tom! No hurry of course, I think I'd prefer having the old 737 back in my sim versus these little issues I can work around here!

What jsnapp said, but in more detail: it's not mentioned in this thread as far as I'm aware. I don't know enough under the hood to know if it's a command or a dataref since I'm barely a scripter, let alone a developer, but I know you can trigger it by writing 1 to it (it will reset to zero next frame). I've done it in DRE, and with my FWL script (required some finagling, as in I had to use jjjLib1.setDataRef_f(tickle_cubemaps, 1.0) to actually trigger it vs. using the built in FWL dataref manipulation, so maybe that's what you're having an issue with). In normal simming, when you make a lighting change, X-Plane doesn't update the reflections for a couple of minutes, or when you force a change to the time-of-day. As such, your ambient lighting environment is actually incorrect, until that couple of minutes passes and the sim updates it, and suddenly your flight deck gets brighter/darker accordingly. It also affects screen/light source reflections on windows. As an example, take the CL650 before Toto implemented automatic triggering of this dataref whenever you change a brightness knob: you'd load in, turn on the plane, have really bright screens because the last flight was in the daytime and XP12 requires you to actually change brightness settings. Then you'd turn the knobs down, the screens would dim, but the windscreen would still show an ugly blue reflection from the PFD until the sim decided to update the reflections (usually a couple of minutes, as I said). "Tickling the cubemaps" forces a refresh on demand. I wasn't aware Supnik said this was an alright idea since I'm not in the dev circles (except the HotStart discord which is full of really smart people), but there you go, take it from the man himself.

Speaking of night lighting, has any consideration been given to triggering "sim/private/controls/render/tickle_cubemaps" when a lighting setting is changed (such as the bright/dim switches, or brightness knobs)? I have a Lua script that lets me trigger it manually with a keybind, but it's super nice having the lighting update happen instantly when you twist a rheostat or flip a switch in the Challenger vs. having to press a button (or worse, wait 2+ minutes for the sim to do it automatically - Laminar PLEASE make this happen more often...).

View File FAA Flight Check N89 Livery for N89 (very similar to N88, N90, etc), flown by the FAA on Flight Check missions to ensure procedures, airways, and more can be flown and relied on safely. Many thanks to a real Flight Check captain for providing direct color references. To my eye the registration looks best in Arial Bold. For copyright reasons, this font file is not included in the download - if you're running Windows, you should be able to grab it out of your C:\Windows\Fonts folder and copy it in to the livery folder. If not, there are several open alternatives to Arial that will probably look fine. Submitter rosseloh Submitted 01/29/2022 Category Hot Start Challenger 650 Livery For https://www.x-aviation.com/catalog/product_info.php/take-command-hot-start-challenger-650-p-212  

Toto showed this off in a few of his development streams. It is very likely that it was due to the wind gusts. In reality, the solution to this is "tow the airplane somewhere where it's not getting buffeted by the wind (like behind a building or fence), or at least point it into the wind so it's not yawing".

For the time being, check your X-Plane UI scaling setting. I learned that at 150% the tooltips do not show, but if you set it to 100% they'll come up fine.

I had some nearly full tanks and was starting the takeoff roll; once I had hit a point where (I think, I didn't have the time to check the study panels) the fuel sloshed around due to Gs, I got an AUX TANK HEAVY caution that lasted until I lifted off or thereabouts and then went away. This in itself makes perfect sense to me, but the bit that I don't think is right comes from the 605 FCOM I've been reading through. In volume 2, page 03-10-26, it shows the list of allowed cautions when on the takeoff roll. AUX TANK HEAVY is not one of them. But, I've been wrong before!

When the fueler asks how much you want in your tanks, if you accidentally/purposely click "Give me this many gallons/liters" without moving the slider (that is, the number set is still zero), he will go out and pump until the valves close, as if you had told him to fill the tanks. I tested until the mains and aux tanks were full, and stopped him when I was down to just the tail tank so as not to spend 15 more minutes waiting. Granted, this is better than a divide-by-zero crash, for sure - but I'd prefer if he asked me if I was sure I wanted zero gallons!

With the scaling set to 150%, the tooltips didn't work. After switching to 100% and not reloading the plane, the tooltips worked but overflowed their backgrounds. On switching back to 150% this evening (meaning in the freshly-loaded sim rather than last night's session), the tooltips stop working again. And then switching back to 100% yet again, they appear to fit their boxes as expected.

Update - the text is fitting in the boxes tonight, after a fresh reload of the sim. There have been no changes since last night apart from it being a fresh load.

While running in 4K, in the Study popups, the tooltips don't work if the simulator UI is set to anything above 100% scaling. And, if you set the scaling to 100%, while they will appear, on my system the text runs past the edge of the background shading. This is on Windows with an Nvidia GPU and Intel CPU, if necessary.