hammertime

It's not obviously clear from the SDK what the new (2024-native) livery structure should look like... But essentially liveries are now a child of the parent aircraft in 2024 VFS Child liveries don't have their own aircraft.cfg (and therefore no TITLE= line). Instead, they now have a livery.cfg that defines the parent aircraft (and engine-type relationship), with a [General] section where you can give a livery a name [Version] major = 1 minor = 0 [General] name="<Livery Name here>" So in 2024 native aircraft/liveries, TITLE returns the name of the parent aircraft only, and the new LIVERY NAME simvar exposes the name in [General] from the livery.cfg FS2020 aircraft and liveries that are "compatible" with 2024 (but are literal copy/pastes into the MS2024 community folder), still exhibit 2020 behaviour when it comes to TITLE, so aren't "problematic". But as developers slowly adopt the new 2024 livery packaging format, this will become more and more problematic to those of us who need livery info exposed. Thanks for the clarification around which SDK you're compiling against, and appreciate that FSUIPC serves both sims simultaneously at present. I'd have thought though, that any application that has historically relied upon livery detection would be interested in this feature potentially. As a VA we certainly have a requirement from an ACARS perspective, but appreciate this is probably the first your hearing of it. If this thread starts the ball rolling for others to chip in, awesome. If not, we'll have to potentially consider an in-house solution as you previously advised. TITLE has been around for donkey's years, has always served its purpose, and its frustrating that Asobo have decided to suddenly change this in 2024. Going forward, I for one certainly consider the new simvar as "core" as TITLE has always been. Thank you for engaging with this thread, and I'd ask (if possible) to keep this in the back of your minds when it comes to your wider development roadmap.

Hi John, Thanks for the reply. The reason why Livery Name got added to the MSFS 2024 SDK was because Asobo changed the way that native liveries are packaged. The "title" simvar now only returns the name of the "parent" aircraft type irrespective of livery, with no insight into the specific livery being used. I'll surely check out the advanced user guide in terms of adding custom offsets, however I raised it here as I believe the addition of a new offset native to FSUIPC will be of interest to other users/developers that need this info out of the sim

With the addition of LIVERY NAME / LIVERY FOLDER in SDK 1.1.1, do we need to request a dedicated FSUIPC offset from yourselves to get this info via FSUIPC as an alternative to interfacing with SimConnect? Had a quick read of the Offsets PDF from 7.5.1 and didn't see anything of relevance on the topic Thanks in advance

That's an issue across all products that use PBR in v4... Apparently LM have fixed it in v5

I'll try another uninstall and reinstall. I appreciate someone else taking a look, thanks Jim.

Correct. As described in the original post, I can sometimes get spoilers to deploy once (With spoilers showing extended on the external model, and EICAS, and speed slowing), but once retracted, will not come out again. No external extension, no EICAS message, no reduction in speed. I am defo on SP1 because the reported interior that was too dark with door L1 open, is now fixed... I also uninstalled the pre-SP1 version, deleted any leftover files before installing SP1 as admin. Running Win 10 with latest version of P3Dv4.5 HF2

No, I don't think there is any spoiler function and it's just the case they aren't displaying visually. Certainly Pre SP1 in a VNAV descent it certainly didn't feel that the spoilers were working. Speed kept on increasing. Time to run this past the developer I feel

Hopefully it's one of the things that can be tested by the developer

Tested without hardware TQ. Still the same

I get what you're angling at. It could be noisy pots or something like that, or a deadzone tweak required. I will, simply for "science", but to note, given that the fact that the throttles don't move any further backwards at all when pressing F1 either, seems to highlight that it's not a hardware issue or deadzone. Also the very fact that the spoilers successfully deploy once with my hardware TQ, seems to rule this out.

I click on the AT disconnect on the TQ levers, and bring them back to idle using my Logitech TQ... Thats enough to get them deployed once... Retract spoilers, re-engage AT to go back into managed speed descent again, (when speed and descent is controlled). FADEC takes control of the throttles again... All good... If the descent runs away from itself again, I repeat the process, spoilers dont redeploy. Also tried pressing "F1" to force throttles to idle... still no re-deploy.

Had this behaviour with the 195 pre-SP1, and was hoping that it might have been resolved in the SP, however... I realise that throttles need to be idle for spoiler use (no flaps are out). Pre-SP1, spoilers were v much needed to try and control the slightly wonky VNAV 3 degree un-achievable descent path pre SP1. It seems that I can extend the spoilers (using either the VC handle, or the default / key), and retract them again... But seem to be unable to extend the spoilers again (if needed), via any method even in SP1. Can anyone reproduce? No particular payload or weather configuration required. Is is there any work planned to improve on the engine spinner textures when engines are running? The rest of the external model is gorgeous, but this is definitely one area that I feel is personally lacking. Thanks for a great product however.

If you downloaded the product recently, you're probably as you to date as possible. In terms of your other question, FeelThere have released a great YouTube playlist on the E-Jet which taught me all I needed to know You will need to consult the Vspeed tables from the manual for any given weight and OAT, but you shouldn't need anything else