Board index FlightGear Development Aircraft Cockpit development

A330-200 with Canvas and other features

Discussion about creating 2d and 3d cockpits.

Re: A330-200 with Canvas and other features

Postby Hooray » Fri Aug 08, 2014 9:27 am

have to agree with artix here: given the current structure of the code, adopting it elsewhere right now (other aircraft) would inevitably mean more work in the time to come - it makes a lot of sense to refactor things now and generalize things sufficiently so that there's no copy&paste involved when adopting/integrating the instrument. I think the whole ND implementation method used by Gijs' code can, and should, serve as an example - even though even that can be further simplified - but overall, it's simple enough probably.
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

Re: A330-200 with Canvas and other features

Postby omega95 » Fri Aug 08, 2014 4:33 pm

Alright, I suppose you could push it to a separate branch there - but it'd be better if the users got a sneak peak at it.

Also for the A380, I'm a little busy now so it's alright if it's going to be a while till it's ready.

Cheers.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: A330-200 with Canvas and other features

Postby Hooray » Fri Aug 08, 2014 4:53 pm

the main thing I'd like to ensure is to sufficiently generalize things and move them out of aircraft-specific code into "global" aircraft-agnostic modules (like MapStructure layers, or at least ND styles), otherwise, the chances of seeing merge conflicts, and even diverging branches, might be too much of a hassle my opinion - I once the whole livery analogy: it doesn't make much sense to have people adopt, create and use liveries until the underlying 3D model is sufficiently complete - otherwise, there'll be a lot of frustration sooner or later, because people will adopt the current system in a lot of places, even though its structure is still likely to evolve significantly - so that this would mean a lot of extra work.
I do like the idea of pushing this to the A330 branch, but like I said, I'd then suggest to proceed by generalizing things more and moving them out of aircraft specific modules into generic modules, ideally at the ND or MapStructure level. Regarding the latter, it makes sense to consider if it's likely that a certain layer/feature could be useful outside the ND use-case, i.e. as part of some kind of standalone dialog - if that's the case, I'd turn it into a MapStructure layer. Likewise, aircraft-specific code/features that could be useful for other aircraft, should also be moved to some kind of "ND style", so that others can adopt and reuse your work easily, without involving any copy/paste.
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

Re: A330-200 with Canvas and other features

Postby Wombat » Fri Aug 08, 2014 6:00 pm

Hey guys!

Your Improvemt Looks amazing!! Is it still inside the git?? :)
Operations Director of MerlionBlue/Europe - Merlion Hub Manager for EGKK - Controller for LOWI (NIATCA-project) - Fan of Lufthansa - ATC services at European Airports
Wombat
 
Posts: 36
Joined: Mon Jan 27, 2014 5:15 pm
Location: EDDF
Callsign: MIA1481/DLH159
Version: FG 3.0
OS: Windows 7

Re: A330-200 with Canvas and other features

Postby artix » Fri Aug 08, 2014 8:01 pm

For what concerns the generalization of the code, i still can't figure out what's the best way to achieve it. An example: many MapStructure layers i created for the Airbus ND differs from the ones used by the Boeing ND, and it's not just a matter of graphics, but sometimes they also have different logics, so different code for Symbols and maybe for Layer Controllers too.
So, for example, the RTE layer in the airbus can use dashed or solid lines, or different colors depending on the fact that the flight plan is active or that horizontal mode is "managed" (Boeing LNAV).
The VOR Symbol has different graphics from the Boeing one, and changes color depending on the fact that it's tuned or not.

So, if we want to move all this stuff outside the aircraft (into the FGData canvas/map directory), what's the best way the create aircraft-agnostic code at this point?

- Using different names for layer, ie. Airbus-VOR.symbol, Airbus-RTE and so on, so that specific Airbus Style Hash can use these layers instead of the base (Boeing) ones?
- Creating subdirectories inside the canvas/map directory, so we could have canvas/map/Boeing, canvas/map/Airbus and so on?

On the other hand i'm sure that there also are various layers that don't need to be specific, ie. some symbols could only differ for the graphics, and then maybe we could use the df_style that could be configured inside the main ND style hash.

Do you have some suggestion?
artix
 
Posts: 93
Joined: Wed Jun 25, 2014 9:42 pm
OS: Mac OS X

Re: A330-200 with Canvas and other features

Postby Hooray » Fri Aug 08, 2014 8:12 pm

i still can't figure out what's the best way to achieve it. An example: many MapStructure layers i created for the Airbus ND differs from the ones used by the Boeing ND, and it's not just a matter of graphics, but sometimes they also have different logics, so different code for Symbols and maybe for Layer Controllers too.


In such cases, it makes sense to use "styling" support for colors, fonts, symbols etc - and if something contains custom logic, just allow the corresponding logic to be overridden by using an optional callback that defaults to nil and which is only used if typeof(callback)=='func'. However, in general, it does make sense to use separate controllers for now - Philosopher once mentioned that he was contemplating to generalize the frameworks so that we could reuse draw/symbol routines with different controllers and vice versa - but maybe we shouldn't skip too many iterations currently, and just let things evolve naturally, i.e. step-by-step.
For that, I'd suggest to use 1) separate controllers, 2) styling hashes (df_style), 3) customizable logic via optional callbacks

Likewise, there are some other things that should ideally be configurable, such as hard-coded properties like nav[x] - those could/should use the same method for making properties OPTIONALLY configurable.

So, for example, the RTE layer in the airbus can use dashed or solid lines, or different colors depending on the fact that the flight plan is active or that horizontal mode is "managed" (Boeing LNAV).
The VOR Symbol has different graphics from the Boeing one, and changes color depending on the fact that it's tuned or not.


that's the kind of stuff that should be addressed via styling, grep for "df_style" to learn how it's done currently, I think the VOR/DME files contain a few examples.
In general, we're hoping to move styling out of the lcontroller files into the symbol files using the style, though.
aircraft-specific "behavior" would best be implemented as is, but customizable via callbacks.

So, if we want to move all this stuff outside the aircraft (into the FGData canvas/map directory), what's the best way the create aircraft-agnostic code at this point?


Anything that is aircraft specific should be passed to the controller, i.e. at initialization/ctor time via the new() flag - alternatively, use a separate .setBehavior() method that accepts a hash with callbacks supported by your lcontroller/symbol files. You can look at how styling is implemented, it basically works at layer creation time (see api.nas and .addLayer() there) - from then on, it's passed down to the corresponding ctor.

The whole idea is to introduce/support a custom hash and support optional fields in there, that may contain callbacks for keeping "delegates" that can be provided by some external front-end, such as for example your aircraft. I think you only need to look at how styling support is implemented, to see that you can use the same method for also passing callbacks around to move aircraft-specific logic out of the MapStructure layers.
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

Re: A330-200 with Canvas and other features

Postby Philosopher » Fri Aug 08, 2014 8:58 pm

Sorry, I'm not keeping up with everything, but for callbacks/etc. there's a "options" argument which can handle that (it's essentially the same as style, just a slightly different use case – all the other parameters). It's like a userdata struct ;)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: A330-200 with Canvas and other features

Postby Hooray » Fri Aug 08, 2014 9:05 pm

right, thanks for reminding me - I completely forgot about that, even though I think I was the one to add this when Soitanen asked about having more than 2 navcom instances per aircraft: https://gitorious.org/fg/fgdata/source/ ... i.nas#L463

As you can see, options defaults to nil but will be passed to the constructor, so if it contains any custom callbacks, those can be easily used to customize things.
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

Re: A330-200 with Canvas and other features

Postby Philosopher » Fri Aug 08, 2014 9:07 pm

and it is also made to inherit from df_options so those values are always available ;)

n.b. due to the use of parents to inherit, made sure all access is of the form: me.options.name_of_option, otherwise (e.g. me.option["name-of-option"]), the default won't be seen.
Last edited by Philosopher on Fri Aug 08, 2014 9:13 pm, edited 1 time in total.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: A330-200 with Canvas and other features

Postby Hooray » Fri Aug 08, 2014 9:09 pm

right, good thinking - BTW: a working use-case can be found in the map-canvas.xml dialog: https://gitorious.org/fg/fgdata/source/ ... s.xml#L360

(The main thing here is the Options hash, which is passed to the constructor via the addLayer call)

Another example can probably be found in navdisplay.mfd
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

Re: A330-200 with Canvas and other features

Postby omega95 » Sun Aug 10, 2014 12:12 am

I'm also working on a new more realistic WXR for the ND (currently testing on my A380 project). I've added you as a developer for the A330-200s project - so go ahead and create a new branch for your work. :)

Image

It would be awesome to merge all of these changes. :D
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: A330-200 with Canvas and other features

Postby Hooray » Sun Aug 10, 2014 12:28 am

right, but the chances of merging them "properly" are much better once things are sufficiently generic, i.e. once features are added as dedicated ND features/styles or MapStructure layers, otherwise maintenance is likely to become quite a challenge over time. Likewise, even the VSD should really become a "vertical" MapStructure layer at some point hopefully.
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

Re: A330-200 with Canvas and other features

Postby Hooray » Sun Aug 10, 2014 8:30 am

both of you (omega95 & artix) now have commit access to the "canvas-hackers" team clone - the main idea here being to refactor the code such that aircraft-agnostic code is moved out of the aircraft folder - for testing purposes, I'd suggest to create a branch where your work can be merged, your aircraft repo should become more lightweight that way - to test your changes, just check out the corresponding fgdata branch and then use the --fg-aircraft= option to point fgfs to your aircraft directory.
Over time, this should help you come up with generic modules that you can also easily reuse on other aircraft (e.g. the A380 or other/similar aircraft).

From my side, it may still take me a few weeks to really go through your changes - and as far as I understand, Philosopher may also take a while to be "back".
But it is my impression that omega95 has been making lots of progress with Canvas prototyping, while artix seems to have mastered MapStructure basics pretty quickly.
In other words, if the two of you could team up and actually "peer-review" you code mutually, you should be unstoppable :D
You'll mainly want to think in terms of building blocks that work at the ND/MapStructure level, and not have too much aircraft-specific code in the actual aircraft directory/repo.
I'll obviously help with advice, code snippets etc - but once that is the case, it will be much easier for us to review the whole thing - and Gijs or Hyde can then take it and commit to fgdata, and even adopt it on their own aircraft.
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

Re: A330-200 with Canvas and other features

Postby omega95 » Sun Aug 10, 2014 10:04 pm

Artix, I just took a look at your ND code and I saw that there were a lot of AP based hard coded properties in there. That would probably not be a good idea for a generic instrument. As you probably already know, most aircraft in FG use the default autopilot properties, most of my aircraft use different properties. So, maybe add a new hash like the cockpit switches with autopilot properties (including active, current wpt etc. or any connection to /flight-management and /autopilot) That way, we can define custom properties. :)

Btw, I'm also giving you access to the A380 development repo so you can push your changes. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: A330-200 with Canvas and other features

Postby Hooray » Mon Aug 11, 2014 6:30 am

yeah, it makes sense to encapsulate such things using a hash with keys that uses sane default values (i.e. for the standard AP system) - likewise, nav/com properties should be configurable that way, too. You could in fact even support a custom route-manager this way. Encapsulation is the main thing here.

EDIT: Thinking about it, I would prefer this to be part of the existing aircraft controller (see aircraftpos.controller) - we could easily encapsulate AP/RM and NAV/COM stuff there and support differing implementations at the MapStructure level - we're already duplicating this functionality in several places, including the whole "NDSourceDriver" mess that should normally also be a part of this module.
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

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 0 guests