Using Aircraft Characteristics in Simbrief an Alternative to Custom Airframes

[lesmar54]

Is your feature request related to a problem? Please describe. If you want to add more realism to PHPVMS then of course you can set up a subfleet record for a single class A320 and a multi class version. Albeit you would need to create an Airframe Record on Simbrief for this purpose for every variant from the base A320 you choose and then set up all the data in Simbrief and copy the simbrief internal ID into your subfleet record. The problem with this is that if you share these Airframes or use an existing code then the data could change without you knowing and your subfleet information you once had is incorrect i.e. if somebody decided that a multi-class A320 had a maximum seat capacity of 140 economy and 20 business and then somebody else using that record changed the maximum capacity to 135 because they wanted 5 more business seats then the ofp would change.

Describe the solution you'd like Depending on having as much data about a subfleet type and extending the data to be more inclusive of additional aircraft specifications at present MTOW and ZFW are there but not used , so we can use these types of figure in a special parameter in the SimBrief API call. I have copied the notes below as follows -: Note regarding Aircraft Data

Specific airframe data, such as aircraft weight limits and onboard equipment, can now be specified using the “acdata” parameter. This data must be passed as a JSON object, for example:

{"cat":"M","equip":"SDE3FGHIRWY","transponder":"S","pbn":"PBN/A1B1C1D1", "extrarmk":"DAT/V RVR/250 RMK/EXAMPLE","maxpax":"146","oew":96.5,"mzfw":134.5, "mtow":169.8,"mlw":142.2,"maxfuel":42.6,"hexcode":"123ABC","per":"D","paxwgt":230} The following parameters can be specified: “cat” (aircraft weight category, i.e. L, M, H, or J), “equip” (the aircraft’s onboard equipment string), “transponder” (the transponder type), “pbn” (performance based navigation string, must start with “PBN/…”), “extrarmk” (additional info to be included in Section 18 of the ICAO FPL string), “maxpax” (the maximum passenger count), “oew” (the operating empty weight), “mzfw” (the max zero fuel weight), “mtow” (the max takeoff weight), “mlw” (the max landing weight), “maxfuel” (the max fuel capacity), “hexcode” (the ICAO Mode-S Code), “per” (the ICAO performance category), and “paxwgt” (the average passenger weight to use, in pounds). All weights except the paxwgt value must be in thousands of pounds, but can be specified with up to 3 decimal places (in order to set precise values). Also note that for the “cat”, “equip”, and “transponder” options to work, all 3 must be specified. If one of the 3 parameters is missing, all 3 will be ignored.

Please ensure that your JSON string is properly encoded to be passed in a URL, otherwise it may not work correctly. '' Now that would return full control to the Virtual Airline to control subfleet characteristics and also this data could be used for better OFP planning for the pilots rather than just use the A321 standard in Simbrief

Describe alternatives you've considered Yes you can use the standard Simbrief OFP aircraft profiles and create your own and use the Internal Id. However I am sure somewhere this data can be used in tours and charters to price fares as you could set hire cost of the aircraft for a charter flight and then after costs etc you divide the total cost of the charter by the number of passengers for the subfleet and then you get a nice fare price.

Additional context Add any other context or screenshots about the feature request here.

[FatihKoz]

You can "copy" the airframes somebody shared and/or create your own simbrief airframes ... So nobody else can edit or change them, using somebody else's airframe id is not a solution, never been. They are shared for you to copy/duplicate.

Anyway, what is the solution you offer here ? I really do not understand how to utilize the MTOW and MZFW fields for "detailed" simbrief api calls ?

Do you want to put json strings there by allowing more chars for those fields ?

If this is the case, what will happen if someone uses those fields for MTOW, as their intended purpose ?

[lesmar54]

If we had all the aircraft characteristics even by PAYWARE /FREEWARE that could be input then if you are using FSLABS A320 the MTOW etc would be different from AEROSOFT and all the others. So you could have in the SUBFLEET a flight simulator reference for add-on or code the subfleet name to give an indication of the add-on. A better alternative is a sub-file of the subfleet where you can define the variants as many as you want

[FatihKoz]

MTOW will probably be same between addons (unless they model a special sub-variant of that base model). What will be different is;

1. Engine type
2. Fuel Factor (Performance Factor)
3. Fuel Capacity
4. Dry Operating Weight
5. Zero Fuel Weight
6. Equipment

If you want to have a detailed flight plan, matching perfectly with the addon you use then you need to have all required info. Otherwise there will be differences in weights and fuel figures.

For example, current Aerosoft Airbus A330 Professional (P3D v4.5) burns around 300 kgs MORE fuel per hour compared to a flight plan generated with SimBrief default values at Maximum Take Off Weight. For a 10 hour flight this means that you will burn 3 tonnes more ! This, if you fly by the book, will FORCE you to divert before reaching your destination due to fuel.

[lesmar54]

Exactly a good point and then you have all the admins for the same aircraft and even with one aircraft add-on package you get variants in that like a twin otter with floats , skis and wheels. It is a bit of a nightmare I agree

So it there was a capability to have a VARIANT file where you can identify the 1 to 6 below per aircraft and even by software provider you could have the ability to have 10 variants or more for the same aircraft which would indeed help perhaps.

On 8 Sep 2021, at 15:19, B.Fatih KOZ @.***> wrote:

MTOW will probably be same between addons (unless they model a special sub-variant of that base model). What will be different is;

Engine type Fuel Factor (Performance Factor) Fuel Capacity Dry Operating Weight Zero Fuel Weight Equipment If you want to have a detailed flight plan, matching perfectly with the addon you use then you need to have all required info. Otherwise there will be differences in weights and fuel figures.

For example, current Aerosoft Airbus A330 Professional (P3D v4.5) burns around 300 kgs MORE fuel per hour compared to a flight plan generated with SimBrief default values at Maximum Take Off Weight. For a 10 hour flight this means that you will burn 3 tonnes more ! This, if you fly by the book, will FORCE you to divert before reaching your destination due to fuel.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nabeelio/phpvms/issues/1304#issuecomment-915148139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ7CEFUKAX3LI3JKSB4YU3UA5BE7ANCNFSM5DUKIM2Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[FatihKoz]

Defining "variants" based on addons at subfleet level and adding aircraft under those variants is not logical at all.

Imagine you have 10 aircraft defined for PMDG variant , will you add 10 more B738's for Zibo variant ?

Or worse, imagine having 10 aircraft assigned to Flight Factor A320 variant (X-Plane), then adding 10 more to Aerosoft and 10 for FsLabs (both Prepar3D) , then 10 more for Asobo (MsFs2020) ! You will need 40 A320's in your fleet to cover all addons.

And what happens if you are "simulating" a real world airline with just 5 A320's in their fleet ?

Supporting various addons and simulators should be outside the scope of sub fleet definitions of phpvms v7. And doing this for just simbrief integration, no it will not help.

[lesmar54]

Yes that is a valid point so we just stick for now with what we have and if there are short-comings with flights running out of fuel because the Simbrief OFP gave the wrong information then it has to be the case. I agree that the best we can do is keep things simple for now and get them working properly first and this idea might be looked at in the future should the need arise

I will not send any more ideas on this subject

On 8 Sep 2021, at 15:37, B.Fatih KOZ @.***> wrote:

Defining "variants" based on addons at subfleet level and adding aircraft under those variants is not logical at all.

Imagine you have 10 aircraft defined for PMDG variant , will you add 10 more B738's for Zibo variant ?

Or worse, imagine having 10 aircraft assigned to Flight Factor A320 variant (X-Plane), then adding 10 more to Aerosoft and 10 for FsLabs (both Prepar3D) , then 10 more for Asobo (MsFs2020) ! You will need 40 A320's in your fleet to cover all addons.

And what happens if you are "simulating" a real world airline with just 5 A320's in their fleet ?

Supporting various addons and simulators should be outside the scope of sub fleet definitions of phpvms v7. And doing this for just simbrief integration, no it will not help.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nabeelio/phpvms/issues/1304#issuecomment-915159042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ7CEF2OOCXFVDLGIE2RPDUA5DJNANCNFSM5DUKIM2Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[lesmar54]

Can we please close and delete this suggestion , although it had some good merits after discussion it may be too much to set up for little gain or reward. I thank those who have contributed to this idea from perhaps a different angle and thus we need to put this idea to one side for now

[nabeelio]

I'll keep this open and put it in a "parking lot" so we don't lose track of it.