Conditions in the format field

[jimdabim]

Hello, first of all I want to thank you for provifing this plugin. It is amazing!

I would like to use a condition based formatting on the mach / ias value of the pmdg boeing 737. The adress is use is "L:ngx_SPDwindow".

When it is in mach mode, it gives me number like 0.7853687. It is ease to limit the decimal digits to 2 by using 2:%s

However I only want that behavior when the value is below 1 as I do not want to have 2 decimal digits on the IAS value. I tried <1 2:%s in the format field but this does not work.

Can you please provide a hint how I get this to work?

Many thanks in advance, Sebastian

[Fragtality]

Hello, thanks for the kind Words! (I hope it will be even more amazing soon) 😃

Conditions are not supported on the Format Field - it is only static Modifier on the Value. Unfortunately there are also no Plans that this will change: for one there are some Limits to what I can/want to do via the Property Inspector because the Plugin slowly outgrows its Foundation in Terms of the Setting Model.

And also: for something like that, especially AP Panel Use-Cases, there has always been the Way/Workaround via Lua Scripts. My Profiles for the FBW A320, Inibuilds A300 and Toliss A321 all use Lua to generate such "Display Data" - where the only Limit is what the Aircraft provides to model the accurate State. I understand that managing a Lua Script in an external Addon is cumbersome - especially in MSFS since you need to pay for FSUIPC (for Lua Scripts) and for that even get a more complex Way to exchange Data/Commands than a Freeware (FlyWithLua).

For this Reason the new Plugin Version will have its very own Lua-Engine! You can look in Issues #62 and especially #63 where I also talked about this new Feature and gave some Examples.

[jimdabim]

Thanks for your quick response. That sounds amazing!

Any ETA :-)

greetings Seastian

[Fragtality]

ETA: Depends - either "now" or "a while".

The Lua Engine is already pushed to the Dev/Latest-Build, so it is already useable/testable! (As useable as it can be for others without Documentation 😅 )

An official Release with all Bells and Whistles still takes a While. I'm in the middle of Development, still need to write/update the Documentation and have to update at least some/all of my Profiles to be released with the new Version (e.g. migrating their Lua-Scripts and Package them for the new Profile Installation Feature 👀 )

[jimdabim]

Ok, so I will try my best in being patient ;-)

Sebastian

[Fragtality]

Sure, that is up to you! :)

But you're aware that said latest Build is always openly available here? The linked Issues earlier also contain some "documentary" Information already 😅

[jimdabim]

Ok, you got me testing it and it seems that it works after playing around for 10 minutes :-)

That's my script:

function MCP_SPEED() local SPDwindow = SimRead("L:ngx_SPDwindow") local mcpspeed = "" if SPDwindow < 1 then mcpspeed = string.sub(SPDwindow,1,4) elseif SPDwindow >= 1 then mcpspeed = string.sub(SPDwindow,1,3) elseif SPDwindow == -1 then mcpspeed = "" end return mcpspeed end

All the states are now coverd. IAS / MACH / BLANK in VNAV. I need to test during the flights if cutting the string or rounding is the correct solution.

Two questions:

1. When do I need to use the Simvar assignment like "SimVar("L:Some_Landing_Light_1")"? In my case, it works without that.
2. What is the best practice for the future? Moving everything to lua and only calling the lua functions in Pilot's Deck or using lua only for complex cases like my example here?

Many thanks for all the effort you put into this project!

Cheers, Sebastian

[Fragtality]

👍

1. "For all time. Always." Everything in PilotsDeck has to register it's Variables used in a central Spot (that is normally done for you in the Background), so Scripts have to do the same. The Reason it worked for you is that you were Lucky that something else (currently active!) used that Variable apparently. That Pattern might be unknown to FSUIPC Users, but for FlyWithLua Users it is very familiar.

2. Well, I'm still learning the Limits and Options it offers myself still 😅 The Main Goal was/is to replace the "external" Lua Scripts of my Profiles with "internal" ones, so that everything is contained in the Profile (-Package 👀 ) and there is no Step to setup these Scripts. Normally these Scripts covered Things that where either to complicated or not possible to configure directly. Things like combining/transforming/formatting different Values into one, a more complex Format on one Value, triggering Commands in a special Way not possible via the available Command Options (like Reset, Toggle or Hold). But that isn't a Guideline - for the Moment I'd say it is open to everyone's own Preferences on which Route to take if it possible in both Ways. For Example: mapping numeric Values to a Text ("Text-Mapping"). That was already possible to configure via the PI/GUI, but Lua could also be used for that. I think I will use both Options for these Use-Cases - mapping for 2-4 Values goes quick, but for more States (e.g. an ND-Range-Knob) it might be more comfortable to use Lua as Syntax than my own 🤣

[jimdabim]

Ok. We will see what the future brings :-)

I think that I have found a bug. I am using the SD plus and I use the lcd to show pictures of course. As "Default Image" I show the picture in the "Off" state and I use the "Special State" option e.g. ">0" to show them as "on". That worked fine so far.

Now with the current test build, It zoomes the "special state" picture.

Even when I configure the exact same picture as "Default Image" and "Special State Background" the same happens.

This worked fine in the last stable version.

It seems that only the lcd is affected. The buttons seem to work as expected.

Sebastian

[jimdabim]

Solved the issue with the images by resizing them to 200x100 pixels.

Cheers, Sebastian

[Fragtality]

It was never "Best Practice" to use incorrect Image Sizes, but you are right: it is something the Plugin has done for ease of use.

Please try the latest Build with the non-resized Images again, it should behave as known again I hope!

[jimdabim]

I fully agree. I converted now all images to the correct size. However, I restored two of the original images and tested with the latest build. It works as before!

Two more questions:

1. Is there a way to donate a beer or coffee for your amazing work via PayPal?
2. Is here on github a way to directly send you a message? I have one and I don't want to open an issue all the time :-)

Greetings. Sebastian

[Fragtality]

1. No, I have a strict No-Donation-Policy. If you want to give something back: spread the Word and/or share Profiles. People should just know that there is an Alternative. Maybe they like AAO, Spad.next et. al. still more. Maybe they still prefer to buy from FlightPanels because they'd rather invest Time than Money. That is all fine, if they had at least all the Information before making that Decision. Just these Days there was "big Coverage" again on FlightPanels releasing an A300 Profile - nobody mentioned that it is my free Plugin making that possible. FlightPanels is pushed all over the Place on fs.to, only accidentally you find my Plugin & Profiles (so maybe donate a Rating ;) ) The Thing is just: Money doesn't give me my Time back and doesn't in any way improve the Plugin-Development. It would be just nice, if all the extra Work for publishing it / doing it in a Way others can use it better would be more worthwile (in Terms of Size of Audience).
2. Not that I'm aware of, I myself didn't found anything in that Direction when I wanted to send a DM/PM. But I have Threads about PilotsDeck on the "well known" Forums (with PM Functionality) like avsim.com or x-plane.org. And I have dedicated Channels in the GSX Community and V1 Community Discord. And yeah, of course PMs on fs.to.