Board index FlightGear Development Aircraft

Aircraft Property Standardization

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Aircraft Property Standardization

Postby jer029 » Wed Jul 25, 2018 2:57 am

I've seen this topic discussed in various threads across various forums here. Perhaps I'm missing something, as I'm fairly new to FlightGear development (only developing an ACARS program for my VA right now). While I've managed to cobble together a workable ACARS program for FlightGear simmers, the process becomes more difficult by the lack of standardization of properties (names and location) across the various aircraft models available. Both the JSBSim and the YAsim FDM's offer different property layouts - and this varies even within the individual FDM depending on the aircraft model.

This makes finding the desired property for each FDM, and even a particular aircraft, a virtual treasure hunt with no gaurantees that the property being searched for even exists. It would truly make it easier for additional development of FlightGear addons if increased efforts toward standardiaztion were taken.

I applaud the efforts and talents of those who have contributed so much, now let's work toward coordinating these efforts a bit more perhaps?

My case in point dealt with finding MTOW and Payload configurations between the to FDM's and individual aircraft within them. Of course, it's possible I'm just missing something, but then again - I'm just getting my feet wet with FlightGear simulation, so I apologize if I spoke out of turn.

John
jer029
 
Posts: 2
Joined: Wed Jul 25, 2018 2:03 am

Re: Aircraft Property Standardization

Postby Thorsten » Wed Jul 25, 2018 6:39 am

This makes finding the desired property for each FDM, and even a particular aircraft, a virtual treasure hunt with no gaurantees that the property being searched for even exists. It would truly make it easier for additional development of FlightGear addons if increased efforts toward standardiaztion were taken.


Not doable.

ACARS seems to be screaming 'emesary' (which is a message-transmission protocol that's been added to FG by Richard). Otherwise, if you produce an interesting addition, define the properties you need, document the whole thing - the maintainers who want it can then alias properties to make use of your addon.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Aircraft Property Standardization

Postby tdammers » Wed Jul 25, 2018 9:14 am

Indeed, not going to happen.

The problem is essentially one of a Tragedy of the Commons. While the community gain of having standardized properties would be huge, there is no immediate payoff for an individual aircraft developer to do it, and changing your code to accommodate the standard properties after the fact comes at a considerable cost. In fact, even using standard property layouts for new development carries a cost, because now instead of just creating properties as you see fit, you have to look up what you're supposed to use, and verify that your setup meets the standard, for every property you create.

And the gain will only be useful if all, or most, aircraft out there get updated to the new standard - if only a small subset matches it, then it's still useless, because anything that depends on it will break most of the time.

And there's another problem, namely, who is going to manage the standardization effort? How are you planning to get people to agree on a standard? This isn't going to be easy, remember that for most people here, their work is a work of love, they have strong feelings about it, and they are not looking for others to tell them how to do it. So whatever standard you may propose, someone's feelings will get hurt, someone will have to say goodbye to something they value, and heated discussions with an uncertain but probably unproductive outcome will ensue.

If you want some sort of standard, then it will have to evolve, so the question is, how do you make that happen. It's a fine balance, really; one between getting people on board, and making those on board productive towards to goal. Let me explain with a simpler example.

Let's say you want to add a property that holds the ICAO code for each aircraft model, and transmit that over multiplayer. That would be a super useful feature, because it means that all sorts of other tooling (like OpenRadar) could trivially display correct codes, MP games could load reasonable placeholders for missing MP models, etc. So how do you make this happen? You can't post a message saying "from now on, all aircraft must set the `/sim/type-code` property to the ICAO type code or else", because you don't have any authority to enforce this. You have to give aircraft developers a reason to add that property, and you have to give tool developers a reason to look at it. Without aircraft supporting this property, no tool will look at it; but with nothing consuming it, no aircraft will expose it. Vicious circle. So in order to break that circle, you need to be in a position to start making that change on both ends, enough to gain some social traction. You could, for example, add it to the half dozen aircraft you maintain, and convince the developers of the online maps and / or fgtracker to look at the property if it is present, falling back to the old behavior if it's not. The fallback is important, because without it, existing functionality will break, and that will hurt the tool's popularity, so that's a no-go. But if you do this right, and the change proves to actually be useful, then more and more aircraft developers will add the property, and more and more tooling will start using it. Most likely, you'll never get 100%, but it's possible that at some point in the future, all the "serious" tools and aircraft do, and the property becomes a de facto standard. Then, and only then, does it make sense to seek community consensus about formalizing the standard and making it "mandatory". But that takes months, if not years.
tdammers
 
Posts: 391
Joined: Wed Dec 13, 2017 11:35 am
Callsign: NL256
IRC name: nl256

Re: Aircraft Property Standardization

Postby Hooray » Sat Sep 15, 2018 5:26 pm

you could introduce your own table of required "acars" properties, and then allow aircraft developers to simply alias their own properties to propagate the corresponding state.
Basically, this is how the flight recorder subsystem works, too. (that's basically a system that implements black-box functionality, including instant replay)

The back-end could then indeed be Emesary (see the wiki)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Aircraft

Who is online

Users browsing this forum: wlbragg and 16 guests