Board index FlightGear Development Aircraft

FMC

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

Re: FMC

Postby Hooray » Fri Feb 26, 2016 1:02 pm

Sorry, you misunderstood, there's no contradiction here at all - you were the one to emphasize that a corresponding MFD framework using airliner-based abstractions/building blocks would not have helped you much with the creation of the shuttle avionics:

Thorsten wrote:The thing with the Shuttle is that you can't really factorize in terms of 'pages' for instance, because from the point of view of the edgekey navigation system that's shared with the F-15, all the 21 DPS pages are just one single page - the DPS submenu. Whereas the whole DPS selection logic is its own beast, grafted onto the edgekey structure.


Anyway,, if all you are concerned about is the fact that there are CRTs/LCDs used to show a bunch of pixels, you don't understand what a MFD framework is all about, or you simply have different priorities - either way, there's no contradiction here at all; admittedly that might be more obvious to you under different circumstances, i.e. different interests/priorities and experience.

None of this is intended to be "unproductive" - but the kind of programming you are currently doing on the shuttle does not lend itself to refactoring and unification of common building blocks, because there's no encapsulation of concepts at all, it's a fairly rigid coding style - that almost looks like copy & paste, without any refactoring of common functionality whatsoever.

It works obviously extremely well for you, because you can focus on other, more interesting, aspects of the work - but it's definitely not in line with your previous comments on being interested in seeing "the benefit of factorizable code".


I think you can really only appreciate such subtleties once you are sufficiently familiar with systems level design, i.e. beyond procedural programming, see Richard's comments.

(no offense intended or taken - I think the shuttle code /could/ be useful, but only if it is reviewed to extract common building blocks and move them to other layers, such as animation handling - which does not have to do much with airliner specific features like MFD "pages").
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby Thorsten » Fri Feb 26, 2016 3:24 pm

but it's definitely not in line with your previous comments on being interested in seeing "the benefit of factorizable code".


My actual comment was:

It's not that we wouldn't see the benefit of factorizable code (at least I do), but it's often that the cost-benefit analysis doesn't go through.

None of this is intended to be "unproductive" - but the kind of programming you are currently doing on the shuttle does not lend itself to refactoring and unification of common building blocks, because there's no encapsulation of concepts at all


I'm not sure you understand how it supposed to work... mostly the task is 'read property, convert to imperial units/a string, display'. It's a menial task mostly, but it's so straightforward that it's not clear how it'd benefit from encapsulation.

Anyway - I think you're after the wrong audience. Somehow you expect all the people who pioneer features and trail-blaze to do this knowing in advance what concepts others are going to find useful (which is impossible) and try to convince them to deliver in broadly usable form (which is unreasonable since these people have dumped a lot of time into this already and aren't likely to spend more time without seeing any benefits).

It's also much easier to talk in broad terms about what would be useful than to make it work for an actual use case - I'm assuming you think of the canvas map layer as elegantly re-factored - but who actually uses it? After 5 minutes, it was clear it wouldn't deliver for the Shuttle trajectory display for instance.

What would make sense is to assist the people who come second or third and want to re-use an existing framework where possible in implementing and re-factoring. Or people who just want to work on the framework and don't have a particular use case in mind. Because then you can make it work with a well-defined set of requirements in mind, rather than trying to guess what the requirements are ahead of time.

You can consistently see that I spit out effects for rendering with the intention of making them broadly useful because by and large I'm not interested in particular applications (with few exceptions). You can also consistently see that I write special-purpose code when I see no broader application.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Hooray » Fri Feb 26, 2016 4:08 pm

I'm assuming you think of the canvas map layer as elegantly re-factored - but who actually uses it? After 5 minutes, it was clear it wouldn't deliver for the Shuttle trajectory display for instance.


Look, you are missing the whole point of this - this is not about "elegant design" at all - it's about reusable components and modules that can be parameterized and customized for different needs, by different people, with different backgrounds and very different requirements in mind.

I completely realize that this is a pain/gain issue - in fact, I have done exactly what I suggested to do (so I know more about the pain than I care to admit), e.g. you mentioned the mapping framework. The point of it is not that it is elegant, but that it localizes functionality in a generic fashion.

I would say it is far from elegant actually - but it hides implementation details and is highly reusable. You ask how many people are using it ? More than you may think, because everybody who's using a ND (or the canvas-map dialog) will instantiate a generic layered map, and I am referring to aircraft developers here - last I checked, there were roughly 10-15 aircraft using the ND framework, which internally uses the MapStructure framework.

Not a single person needs to know how the MapStructure framework works to use it, only to extend/develop and maintain it.

Was it usable for your needs, no - definitely not. I never said it would ...

It was designed by having one concrete use-case in mind: aircraft-centered mapping, not orbital maps.

Would it possible to also support your use-case ? Sure, which is why I shared certain code snippets with you, and which is why I provided basically every building block/code snippet that you asked for, so that you can come up with an orbital map - without using the MapStructure framework.

Ultimately, I didn't pursue this because I looked at your commits and the code you came up with, realizing that it would be tons of work to refactor that code to become sufficiently generic in nature - i.e. to support independent instances, to be more efficient and to support other aircraft/spacecraft.

But that's really not the point - the "elegance" of the underlying code should not matter at all - in fact, I would hope that the ND stuff gets rewritten one day - however, we keep seeing it widely used (~15 aircraft certainly), because it's good at two things: de-skilling and enabling people to collaborate despite them working on hugely different aircraft/instruments.

From a programming/software engineering standpoint it's pretty ugly actually, i.e. not using any design patterns, no fancy OOP design - it's basically an ugly superclass that has tons of responsibilities - but for some reason, aircraft developers without a coding background find it much better accessible than much better code that can be found elsewhere (think the Avidyne Entegra R9 codebase).

Thorsten wrote:It's a menial task mostly, but it's so straightforward that it's not clear how it'd benefit from encapsulation.

look, why would I not understand what the Canvas/Nasal snippets are doing, i.e. the very code for which I wrote the tutorials on the wiki ??

you only need to look at the repititve nature of your own code to realize what the problem is; besides what may seem straightforward to you (now), may not be straightforward for others.

In fact, let's face it - you, too, faced quite a steep learning curve when you first tinkered with Canvas despite having an unprecedented track record of working with rendering/graphics code, and all the solid math expertise to understand what a translation is, what a transformation is and what they have in common - and still, we exchanged a bunch of messages to get you going - you stated a few times that the documentation/examples and snippets were lacking, and that you needed to know how to do certain things - and even in this very thread, we're still posting snippets that you are incorporating directly in your code, as we can see in your commits.

And even despite your massive Nasal experience, you had problems looking at api.nas to see what you could do with certain objects - so what may seem "menial" and "straightforward" to someone with your background in maths, physics, Nasal coding - may certainly not be all that easy for others.

In fact, didn't you just suggest, that I don't understand what your 5 lines of repeated Nasal blocks are doing ?

Which is to say, what seems "straightforward" to you now, clearly wasn't straightforward 6+ months ago, when we still exchanged a bunch of PMs and you basically complained that the degree of Canvas documentation we have is insufficient and simply not useful usually.

Equally, this is not just about things being straightforward, but also about computers being better at things like repition than humans are (please let's not discuss loop unrolling techniques, GLSL "singularities" or other low-level optimizations/techniques that are not overly relevant in such high level Canvas code).


Thorsten wrote:What would make sense is to assist the people who come second or third and want to re-use an existing framework where possible in implementing and re-factoring. Or people who just want to work on the framework and don't have a particular use case in mind. Because then you can make it work with a well-defined set of requirements in mind, rather than trying to guess what the requirements are ahead of time.


I agree with that wholeheartedly - and I think we're not really disagreeing on the key message here, but we tend to disagree on subtleties - Richard's MFD code is sufficiently decoupled to be useful elsewhere, and if you were to review your own additions/use of it, you would also identify building blocks that would be useful for people wanting to create MFDs for airliners.

In fact, this is where our whole notion of a "MFD framework" may fails us by being very different: you highlight that "pages, modes and page elements" may not have worked too well for the spacecraft/shuttle use-cases, whereas I find the CRT/LCD-level far too low-level to be a common foundation - simply because at that point, Canvas itself is already a fairly popular abstraction and does not need much more (it seems).

Thus, what might be more useful would be to review use of Canvas/Nasal for creating MFDs and identify, extract and generalize building blocks regardless of the MFD use case/focus, i.e. for things such as animation handling. Which, coincidentally, may seem "menial" and "straightforward" to you, but clearly isn't - and which is one of the main things that would benefit from C++ level additions to the Canvas code, so that it does make sense to provide generic building blocks for a "Canvas Animation" by hiding the use of timers/listeners, so that code using such an abstraction can be migrated to use native code once those building blocks become available.

I don't think we fundamentally disagree on this - it just seems that we have a tendency to get wound up in fairly irrelevant implementation details - I do agree that the ND/mapping framework would not be very useful for the orbital use you have in mind - but I do think that your own orbital mapping code could be of interest to others interested in spacecraft - so that it would at least make sense to come up with an orbital map dialog for the menubar, so that it can be used to show other spacecraft (think satellites).

Equally, it would be possible to also refactor the MapStructure framework accordingly, but the pain/gain ratio would not be too good... :D
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby Thorsten » Fri Feb 26, 2016 7:41 pm

In fact, didn't you just suggest, that I don't understand what your 5 lines of repeated Nasal blocks are doing ?


No, I did not - I suggested that maybe you don't understand what the Shuttle avionics is supposed to do.

I'm also not sure what five lines of repeated code blocks you refer to. I'm sure it's more elegant to replace a direct property getter/displayer by an abstracted property getter.displayer of the same length, but admittedly I fail to see the point here :-) As I said, it's rapidly becoming unproductive.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Hooray » Fri Feb 26, 2016 7:53 pm

Thank you for keeping this short (productive).

I have not actually run any of the shuttle code, it would not work on the netbook I am currently using - which is why I only reviewed some of the commits you made, specifically in response to questions you raised in the shuttle thread.

I was referring to code where you were clamping a value and using that in a translation call for a handful of meds symbols (IIRC) with different offsets/restrictions.

However, you keep using the term "elegant" - whereas my only suggestion was to hide such functionality in a helper function/class so that you don't need to copy/paste the same code over and over again, but also so that you can more easily update things in the future.

Apart from that, I do get your point that it makes sense to focus on something with a concrete use-case. So assuming that our MFD related ideas seem to diverge too significantly for the time being, it may make more sense to come up with a helper module for handling Canvas animations using timers and listeners.

So, anybody interested in SVG-based Canvas MFDs, may want to read up on some of the original discussions we've had: Canvas animations

And to put things into perspective (i.e. the whole pain/gain thing), I suggest to refer to this statement (which coincidentally came from a core developer):
SVG editing skills needed
zakalawe wrote:Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself :D


And that sums up the whole reason for why the extra500 avionics are not reusable elsewhere, despite being the most sophisticated avionics we have today in FG (admittedly, the shuttle is catching up quickly, but its avionics are obviously not as modern in comparison to modern MFDs).

Which gets us back to the original point of encouraging a framework-centric development model, where people don't just add functionality to "their" instrument, but possibly to a lower level component/set of modules that can be reused by others.
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby Thorsten » Sat Feb 27, 2016 6:15 am

I was referring to code where you were clamping a value and using that in a translation call for a handful of meds symbols (IIRC) with different offsets/restrictions.


Then if you're monitoring commits I fail to see your point because for those I actually have introduced helper functions.

However, you keep using the term "elegant" - whereas my only suggestion was to hide such functionality in a helper function/class so that you don't need to copy/paste the same code over and over again, but also so that you can more easily update things in the future.


If I make a helper function for the one liner property getter/converter/displayers I have, then I end up copy-pasting helper functions instead of straight one liners.

And if I ever have to update things, I have to run search/replace on the helper function call rather than the one liners everywhere.

Admittedly I fail to see how this saves me anything, that's why I ain't doing it.

And that sums up the whole reason for why the extra500 avionics are not reusable elsewhere, despite being the most sophisticated avionics we have today in FG (admittedly, the shuttle is catching up quickly, but its avionics are obviously not as modern in comparison to modern MFDs).


I think the GNC and systems management tasks and requirements of the Shuttle are quite a bit more complex than of a GA aircraft, and they have been that even in 1981. So while the presentation layer might seem aged, the avionics underneath is a different story. You will find that the vast majority of the Shuttle avionics outside Nasal - what you see there is merely the very high-level management and display routines.

But as I said - I'm getting the impression you don't really understand what the Shuttle avionics does.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Hooray » Sat Feb 27, 2016 12:54 pm

I agree absolutely, I was definitely referring to the front-end ("presentation layer") - simply because this is the thread where people want to have a common CDU framework (without them even realizing it, i.e. as can be seen by their use of the term FMC).

I definitely wasn't referring to the underlying degree of systems modeling - but just the Nasal/Canvas specific layer on top of that.

I don't disagree at all with your notion that the avionics on the real shuttle a much more sophisticated than avionics commonly found on an airliner - but that was never the point, i.e. you have a tendency to put words into people's mouth so that you end up being right 100% - if had looked more carefully, you would have noticed that we were talking about the UI-level presentation.

I think I am the only one to bring up the FDM/FMS-level restrictions (think VNAV) a few days ago.

I would not know how much "code reuse" or modularization is possible there, especially looking at the degree of FDM-level systems modeling you are currently using, which also is very novel in comparison to the usual Nasal space workarounds we are seeing for those purposes.

Again, to be 100% clear about it: I don't understand what the shuttle avionics is doing under the hood, I really only ever looked at the presentation layer, and that is the only thing that I was commenting on, and that I feel qualified to comment on. I have no interest in the back-end of the Canvas stuff you are working on, I only commented on the need for having a MFD framework and one that supports animations in a use-case agnostic way.
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby Thorsten » Sat Feb 27, 2016 1:09 pm

if had looked more carefully, you would have noticed that we were talking about the UI-level presentation.


As you point out yourself

Like I said, people should be really prepared to differentiate between the FMS (flight management computer), and the FMS (flight management system) and the CDU/MCDU (control display unit).

words actually have a definite meaning, and the meaning of

despite being the most sophisticated avionics we have today in FG

is not the same as 'the most sophisticated presentation layer'.

Since you took the opportunity to be careful in defining terms early in this thread, I was assuming you'd actually be careful in using them as well - apparently that is not the case, my mistake.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Octal450 » Sat Feb 27, 2016 6:33 pm

Thorsten wrote in Fri Feb 26, 2016 6:12 am:
Well, the only good FMC in FlightGear is the one in artix's A330.


I do beg to differ.


I was talking about FMC in commercial aviation.
Waste of time. Goodbye forever.
Octal450
 
Posts: 4398
Joined: Tue Oct 06, 2015 12:51 pm

Re: FMC

Postby Thorsten » Sat Feb 27, 2016 6:39 pm

I was talking about FMC in commercial aviation.


No, sorry - you where not:

Well, the only good FMC in FlightGear is the one in artix's A330. The rest are very simple, and have no functional point yet.

Doesn't say commercial aviation in here. You probably mean you where thinking about commercial aviation, but you didn't put it into words.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Hooray » Sat Feb 27, 2016 11:35 pm

Thorsten wrote in Sat Feb 27, 2016 1:09 pm:Since you took the opportunity to be careful in defining terms early in this thread, I was assuming you'd actually be careful in using them as well - apparently that is not the case, my mistake.


wow, you are in quite a mood lately, I hope it's just about interactions with me and isn't affecting any other parts of your FG involvement :D

I am still convinced that this is what the thread is about, not because you are wrong, but because most people don't even know that a CDU is very different from the underlying FMS/FMC.
So to be very clear about it, the degree of systems modeling you have done on the spaceshuttle is unprecedented in FlightGear, but also unlikely to translate to the kind of avionics that the the OP is interested in - unless of course we're specifically talking about the presentation layer (the CRT stuff you were referring to), at which point your semantics are plain pointless and not the slightest bit helpful to further the case we've been discussing in this thread, except for the MFD part obviously.

I am not sure why you are being so controversial currently - but if it's about me, feel free to shoot me a PM - I haven't responded to your other PM, because I didn't consider it constructive, but if there's something you'd like to discuss, feel free to get in touch.

Regarding the thread in the Canvas forum, and your recent posting there, I am hoping to get back to it this weekend - but I would also hope that we try to find some common grounds, because like you said, we're (again) about to get lost in all kinds of irrelevant semantics that are no longer about the topic of the original discussion - and even if you are only remotely annoyed by my response as I am by your's, we should either discuss that in private or better stop this altogether - the last couple of days were not productive at all, and I cannot help but noticing the confrontational nature of your responses - unfortunately, I am inclined to respond similarly, which isn't likely to help any of us (I mean, we've been there before, so this wouldn't be a first ...)
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby Thorsten » Sun Feb 28, 2016 6:24 am

I am not sure why you are being so controversial currently


I don't think it's controversial to insist that words have a meaning and that we should strive to be clear about what we mean. After specifically discussing the different layers of an avionics setup, I think it makes sense to use the definitions.

As for the question discussed, I think it's primarily helpful to see a problem worked out if you have the same problem. It's even better to see it worked out in multiple different ways, so that you can decide which one works best for your needs.

From the point of software evolution, it's much better to have 3-4 independently developed frameworks from which strength and weaknesses can be judged in comparison than one standardized and pre-conceived solution which we can't compare to anything.

I personally think that it pays off to structure things along the seams they have in reality - it will make it easy to achieve a realistic result that way. For starters, you will get a natural failure modeling.

Case in point - the Shuttle displays are not homogeneous blocks but their DPS structure is rendered right into the MEDS structure. So creating a failure mode in which the DPS pages cannot be provided but the MEDS menu structure still works because the IDP remains functional is trivial to implement - it would be very difficult if we had not chosen to use the real structure.

So to the degree that different instruments/presentations are different in reality, it makes sense to me to do them as custom jobs.

As such, the question is about low level tasks - animate a set of gauges or indicators. Display numbers. This can be achieved in different ways, how to do it efficiently depends on where the data resides in the first place (Richard has for instance a HUD data provider to interface between property tree and HUD, systems may be modeled in Nasal in the first place,...) and it depends on design needs/wants (I like the idea of creating an SVN text mask of displays rather than using canvas to place text,...)

If you think people can't learn lessons from the Shuttle avionics or the Extra and because you feel they should have been structured in a generic way, that's your cup of tea, not mine. There's more than one way to skin a cat and different people have different needs - a standardized system is unlikely to satisfy them.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Thorsten » Sun Feb 28, 2016 1:05 pm

wow, you are in quite a mood lately,


It might have to do with having to read a constant stream of negativity.

Let me quote from the Wiki (which in my view is for documentation, not politics):

The purpose of this article is not to document the actual instrument, but to streamline future development in order to avoid wasted/redundant efforts due to lack of coordination among Nasal/Canvas developers working on conceptually similar/identical MFD instruments/displays.
(...)
Unlike the majority of other Canvas-based instruments like the PFD/ND and EFB code, it was also properly designed to support multiple instances per aircraft right from the beginning, and encapsulates the concept of MFD pages and different page elements.
(...)
All this is further complicated by the fact that some people write exceptionally good code that is never generalized and committed, while others write pretty poor code, that is directly committed to fgdata.


I could go on like this and add more quotes.

I can only shake my head that this kind of highly opinionated texts ends up on a wiki page.

It seems obvious that you believe that FG would be in a better shape if a few things were different. If people would start to code in the style you prefer. If core developers would commit osgEarth support. If a few people you think fit would get commit rights.

What is so difficult about respecting that others can have different opinions on these matters? What's the problem with asking people once to consider structuring their framework as you prefer, and if they say 'no thanks' letting them be - rather than filling the wiki with descriptions of other's flaws?

The extra500 folks have done an outstanding job - and get to read all the time what they should have done instead. We're working hard to make the Shuttle avionics as realistic as possible - to read at every corner how you think it should be done differently.

By your own admission, you don't actually understand what the real thing does. Could you perhaps entertain the notion that coding close to the real thing is part of design considerations? That getting workable states is vastly more important than getting it elegant? That there are design priorities different from yours? And that we got what you think the first time, so the constant repetition of the same argument doesn't accomplish anything?

Would it be possible to respect aircraft developers to the point that their efforts don't get called 'wasted' in a multitude of places if their design philosophy is different from yours? I'd much appreciate that.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: FMC

Postby Hooray » Sun Feb 28, 2016 3:31 pm

You are quoting out of context, and you are mixing up examples/references I made - e.g. I was actually referring to the extra500/Avidyne Entegra R9 code as excellent code, that just isn't available to other fgdata developers (like you...) - so it is obvious that you are misrepresenting things enormously - if everything you said above were true, I would wholeheartedly agree with you, on all counts - but as things are standing now, you are either doing this deliberately or just missing the point completely - either way, it would take up tons of our time to respond to this quote by quote (which I actually started doing, but then stopped realizing that this is just another pointless debate with you).

Again, I agree with your findings and conclusions on pretty much everything you said above, including the quality of Canvas docs, and your coding approach - it's just your early logic where we differ, otherwise I would be willing to sign your whole posting. But I just don't have the time to put all this apart word for word just to make the case I have been making.

From where I am standing, this is not about me at all - in fact, I don't commit stuff to fgdata, and I don't usually review things at all - unless I am specifically asked to do so (well, you can find a number of threads where people specifically asked me to help review their Nasal/Canvas additions).

But again, this does not have to do anything with my own involvement or its nature, that you may disagree with - but you only need to look at the devel list and Nasal/Canvas related debates there to realize that it makes sense to make people aware of certain issues. And as you may remember, I am not opposed to Nasal at all, but I believe the most disrespectful thing we can do as a community is to encourage people to work on something only to see it getting ripped apart on the devel list due to the approach/implementation taken and some non-obvious deficiencies.

The key people involved in the project who are currently reviewing merge requests in this areas are TorstenD, Stuart and James - and they have explicitly stated their goals - and Torsten (and before him, ThorstenB) in particular are overzealous in pointing out that they don't want to see certain Nasal based additions, the most recent example being the "wingflex" contribution, i.e. which got re-implemented outside Nasal.

It is only fair to point out such issues to people who are not aware of them - all this may seem irrelevant to you as long as you are only interested in developing code for your own aircraft, but once that is no longer the case, you should take a look at what else is going on, and what kind of attitude is communicated by those doing such reviews - and what requirements are stated when it comes to HLA, multi-instance setups (FSWeekend/LinuxTag), multiplayer and design issues resulting from current coding practice.

I could go and on commenting on each of your points, but like I said, I don't disagree with your conclusion/opinions at all, and we would be in a better shape if things were the way you described them - but in reality, things are very different, so that you are arriving at your conclusions due to the wrong assumptions.

Again, this is not about my "opinion" (despite the quotes you posted above) - the extra500 code contains awesome functionality and great code, but even its own developers stated specifically that the code does not satisfy the requirements for code reuse:

extra500 - Avidyne Entegra 9 IFD - approach
D-Leon wrote:NOTE: This sounds like a reusable framework but the encapsulation isn't as far and its optimised for the internal need.
There are some calls going over parents where no interface is "rechable" or defined.


Equally, I can back up pretty much everything else you find summarized in my postings - if it seems opinionated and like "my" standpoint, it is because it is lacking the one thing that you disagree with so strongly, i.e. quotes and links back to discussions where other experienced contributors agree that certain features would ideally be supported.

Either way, this is not about my opinion at all - the challenges remain, even if I were to decide to move on and ignore the FlightGear forum.
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: FMC

Postby MIG29pilot » Sun Feb 28, 2016 3:42 pm

Forgive my ignorance but what is an FMC?
User avatar
MIG29pilot
 
Posts: 1454
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: Google [Bot] and 1 guest