Board index FlightGear Development Nasal

Spoken GCA

Nasal is the scripting language of FlightGear.

Re: Spoken GCA

Postby rleibner » Wed Nov 01, 2017 8:42 pm

OK, thanks. I thought it was an index as documented in the wiki page.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Wed Nov 01, 2017 9:28 pm

yeah, but you missed the fact that you are linking to the getprop() API, whereas I was using the getNode() API from the props.nas module: http://wiki.flightgear.org/Nasal_librar ... Node.28.29
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Thu Nov 02, 2017 7:49 pm

I just uploaded the latest modifications.
Now the first entry on the UI dialog ("Callsign") accepts any available AI/MP callsign. And its tooltip shows the list of the flying ones.
I hope that allows me to sit comfortably in the apt Tower and watch the arrival of an AI aircraft on the radar screen.

Note that for now, that entry do not accepts .../position node paths. (If you think it's worth it, I can work on it later.)

On the other hand, I would like to stamp some texts on the screen (eg icao & rwy, callsign currently served, etc.).
Thus, the question:
May I add a text object to the PAR graph layer? Or must I work on an additional layer on which I'll add labels?
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Thu Nov 02, 2017 8:38 pm

Obviously, you can do whatever you want - my personal preference/suggestion would be adding a separate Canvas group and use that to act as the equivalent of a "layer" - so that you can add text info there - that would have the added advantage that you can invoke the .hide() and .show() methods on the whole group to hide/show the whole "layer" - for example, you could add a checkbox that toggles the information layer on/off.

But actually it really doesn't matter at all - I just think that it makes it easier to organize/structure the code over time, and treat features separately.
In the case of the NavDisplay/MapStructure framework, each navaid feature layer is represented by a separate Canvas group added to the same top-level Canvas map.
That is one of the reasons why I previously suggested to also refactor your current PAR graph classes into separate helper classes - i.e. for drawing two different graphs, possibly inhering from a common "graph2D" baseclass - the point being that it would be much easier to add changes to the baseclass that all child classes would benefit from.

Equally, it would be easier to reuse your code elsewhere - for example, Stuart is currently working on G1000-style MapStructure layers - and he is also considering to a add a VSD layer for plotting the terrain - which is overlapping with work you have done already.

Thus, my suggestion would be to refactor the PAR screen class two draw two separate graphs, while both would be implemented as child-classes inheriting from a common parent class that provides common functionality (e.g. x/y axes, labels, tic marks and stuff like that).

But like I said originally - it is obviously entirely up to you what to work on and when to do something. I only made that suggestion because I realized that some of your work was indeed overlapping with Stuart's work. You can see some of his recent work when navigating to the EQUIPMENT menu, to open the map-canvas dialog - if some of your recent work would be refactored to become more generic, this would mean that we could also render vertical profile views in the same dialog - e.g. for evaluting a approach, or for visualizing terminal procedures.

Anyway, please don't spend any significant amount of time working on anything related to this without first coordinating related efforts with Stuart - what I think is irrelevant, Stuart may have completely different plans after all:

http://wiki.flightgear.org/FG1000
Image
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Thu Nov 02, 2017 9:26 pm

I appraise and have total confidence in your opinions and suggestions. Experience shows me that they are usually right.
If I have not followed some of your proposals, it has been because of not knowing how to implement them.
You have already realized that working with canvas is not the field where I feel most comfortable.
That is why I would welcome the intervention of a co-author who took those tasks into his hands. Can you propose a canvas specialist to offer him the participation in the project? Maybe yourself?
I would continue working on the improvement of the heuristics, etc.
As I said before, now I'm focused on getting to track the trajectory of an AI aircraft on the radar screen.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Thu Nov 02, 2017 11:00 pm

I see, but as you may have noticed, it is currently taking me up to two weeks to get back to questions you raise here - and I typically get to start up fgfs only once a month. So I am not in a good position to get involved beyond what I am currently doing, i.e. posting pointers, code snippets or self-contained modules doing something. I don't think there is much needed to implement at this point - and that also applies to the improvements I mentioned, it's not that these are literally required anyway. Thus, my suggestion would be to make sure that this whole journey remains fun to stay motivated - with these things it is hard to tell when/if someone shows up to get involved, sometimes this takes so long that the original author is not even around/involved anymore - which is why documenting things (readme files, wiki etc) is a good thing.
As a matter of fact, I think Alant was the one to originally inspire development of this - and I am sure that he'll agree that you have already exceeded all expectations at this point anyway.

Other than that, if I should find a little more time, the one thing I would be most interested in developing/implementing myself is a simple tanker.nas based AI module to start arbitrary AI aircraft that respond to the GCA instructions to actually land at an airport - because that's something that I'd consider the groundwork for scripted AI traffic beyond just the tanker.nas use-case, i.e. generic AI aircraft that respond to a subset of well-formed ATC instructions - with the added advantage that this would even work for the multiplayer use-case.

Apart from that, I don't see any immediate need to really change things - such an AI module is a long-standing idea, and it would be self-contained, too - i.e. have nothing to do with Canvas coding, but it would be an awesome way to populate airports with traffic that behaves in a sane way: http://wiki.flightgear.org/Scripted_AI_Objects
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby Alant » Fri Nov 03, 2017 12:04 am

Hooray wrote in Thu Nov 02, 2017 11:00 pm:As a matter of fact, I think Alant was the one to originally inspire development of this - and I am sure that he'll agree that you have already exceeded all expectations at this point anyway.



Correct. I am amazed by this work.

Your Canvas Gui work is interesting to me as I am trying to implement a Canvas Gui for one of my aircraft systems, and your work is filling some of the holes. Thanks.

It is a bit of a side show for me as well - my main interest is developing the aircraft systems and in this case the Canvas Gui seems the best way forward. My code will be much less object orientated than yours, as I find OO code very difficult to follow.

Alan
Alant
 
Posts: 940
Joined: Wed Jun 23, 2010 5:58 am
Location: Portugal
Callsign: Tarnish99
Version: from Git
OS: Windows 10

Re: Spoken GCA

Postby Hooray » Sat Nov 04, 2017 1:12 am

Regarding the Canvas UI stuff, it's actually just the underlying Nasal/Canvas bindings that are object-oriented, the code I added is pretty procedural - I think there is only a single helper class to serve as the "container" for all UI state - other than that, it's really entirely based on the Canvas Snippets article, i.e. relevant snippets that seemed useful that I put together

Regarding the other OO code, Thorsten is actually circumventing some of the OO layers - mainly for performance reasons. In other words, many things would even work using the conventional getprop()/setprop() APIs used in a procedural fashion - however, be advised that there is a breakeven point where the OO stuff pays off rather quickly - obviously that depends highly on the complexity of the code/features you are developing - but the kind of design I suggested for the PAR screen simply makes sense if people want to be able to reuse rleibner's groundwork without having to use 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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Wed Nov 15, 2017 7:50 pm

Hi,
I've been working on the PAR class, and have uploaded it.
Now the PAR screen can be opened by other scripts (other than SpokenCGA). Some examples are shown at the wiki page.
(May be a good idea to include that on the main menu / equipment ?).
And talking about the wiki, I'm considering to create a new PAR page there. Now it has sense, and I can focus the SpokenCGA page on the GCA itself.

EDITED:
Alant wrote in Fri Nov 03, 2017 12:04 am: My code will be much less object orientated than yours, as I find OO code very difficult to follow.

Alant, as you know I'm not an expert on OOP, but feel free to ask me for help if you need it.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Wed Nov 15, 2017 9:05 pm

Just briefly, from a MapStructure/Canvas standpoint, what would be most useful is establishing some kind of separation for the various components of the PAR screen - for example, by splitting the two graphs into separate diagrams, i.e. coming up with helper classes for 2D plotting using X/Y axes and a set of points to be plotted. At that point, the PAR screen components could be more easily reused elsewhere - such as in Stuart's ongoing FG1000 effort (for which he also needs a way to draw vertical diagrams, called VSDs => Vertical Situation Displays).

Speaking in general, it would be a good thing to aim for to support independent instances of the GCA module, because that would also come in very handy when working out a GCA module to instantiate/control AI objects without requiring manual intervention (= scripted pilots & scripted controllers)
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Thu Nov 16, 2017 3:06 pm

Hooray wrote in Wed Nov 15, 2017 9:05 pm:... establishing some kind of separation for the various components of the PAR screen - for example, by splitting the two graphs into separate diagrams, i.e. coming up with helper classes for 2D plotting using X/Y axes and a set of points to be plotted.

Let me see if I understood. Do you mean to work on different layers for XY and XZ graphs and provide helpers into the class, per example:
Code: Select all
var drawLine = func(layer,from,to) { # from and to as [x,y] vectors ...
var drawVSD = func(layer, geo1, geo2, resolution, orig) {  # resolution as <pixels/sample>, orig as [x,y] vector
 ....
Is that your idea?

Hooray wrote in Wed Nov 15, 2017 9:05 pm:Speaking in general, it would be a good thing to aim for to support independent instances of the GCA module, because that would also come in very handy when working out a GCA module to instantiate/control AI objects without requiring manual intervention (= scripted pilots & scripted controllers)
I love the idea of taking control of the arriving AI objects (freeing them from their pre-assigned route) and guide them according to the GCA instructions.
Is that possible? What would it take?
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Thu Nov 16, 2017 8:45 pm

Yeah, it is absolutely possible to create a scripted "pilot" module that controls AI objects.
That is basically how the whole Bombable addon works under the hood (all implemented in Nasal space).
However, that's a fairly complex/sophisticated piece of code - much more straightforward is tanker.nas in $FG_ROOT/Nasal
Another thing to look at is the fox2.nas which implements a simple scripted AI missile - from a FlightGear standpoint it really doesn't matter what kind of 3D model is loaded/updated.

For example, you could load a handful of different 3D models and control them from scripting space (the use-case you mentioned would also be possible to support at some point):

Image


Here a few more pointers to get you started:

http://wiki.flightgear.org/Scripted_AI_ ... ementation
http://sourceforge.net/p/flightgear/fgd ... tanker.nas


The most recent work relating to this is ThomasS ground-services project, which is focused on controllind ground traffic: http://wiki.flightgear.org/Ground_Services

Image

PS: Regarding the other question, yes - the point would be to identify "building blocks" (think modules) that can be become truly reusable, i.ee. components of the PAR screen: 2D graphs, with each graph having 2 axes and labels, as well as a set of points. That way, your code could be reused for other purposes (e.g. rendering a vertical situation display on an airliner) - this would require separating/isolating functionality to remove GCA/PAR-specific functionality and move that to a separate helper class - because a VSD would not need a PAR-specific screen:

Image



Basically, the first step would be splitting the PAR class module into separate classes/files to isolate useful functionality that could be reused elsewhere, without being specific to the PAR/ATC or GCA use-case, and then take it from there. For instance, you would start by adding a Plot2D class that has two axes, with each axis having an associated label and the whole Plot2D class taking a vector of data points.

That kind of design would make it possible to easily reuse your code elsewhere without people having to use the PAR/GCA code.
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Thu Nov 16, 2017 9:37 pm

Hooray wrote in Thu Nov 16, 2017 8:45 pm:Yeah, it is absolutely possible to create a scripted "pilot" module that controls AI objects.
Wow ! At some point I will try that.

Hooray wrote in Thu Nov 16, 2017 8:45 pm:Basically, the first step would be splitting the PAR class module into separate classes/files ... For instance, you would start by adding a Plot2D class that has two axes, with each axis having an associated label and the whole Plot2D class taking a vector of data points.
So, the Plot2D class would return a layer (neither a window nor a canvas nor a root group). Then PAR class would create the window/canvas/root and instance a Plot2D.new() for his XY area and another for the XZ one.

Will try that.
Thanks.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Spoken GCA

Postby Hooray » Thu Nov 16, 2017 10:07 pm

yeah, pretty much like that - to come up with an even more generic design, you'd merely need to look at your current code and identify those areas that contain use-case specific assumptions/defaults - i.e. stuff that, if sufficiently generalized, could be reused elsewhere - without being specific to the GCA/PAR use-case. That would also mean that you'd want to support a number of independent instances of the plot2D class - as well as being able to set the dimensions/labels/scale of the axes per diagram.

For example, imagine the Canvas system had a dedicated "graph plotting" API - and ask yourself: what would it look like from your perspective (ideally).

Like you said, it would not create its own canvas, but merely render into a canvas element/group that must be specified by the caller - analogous to the existing APIs.
That way, other projects/efforts and aircraft developers could reuse your 2D plotting framework to implement a VSD:

http://wiki.flightgear.org/Howto:Implem ... y_in_Nasal
Image

For some inspiration, you could also refer to the FGPlot module: http://wiki.flightgear.org/FGPlot
Image
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: 11605
Joined: Tue Mar 25, 2008 8:40 am

Re: Spoken GCA

Postby rleibner » Fri Nov 17, 2017 5:16 pm

I'm trying a new plot2D class :
Code: Select all
var plot2D = {
new: func() {
 var m = {parents:[canvas.Window, canvas.PropertyElement, plot2D ] };
 m.x0 = 0;
 m.y0 = 0;
 
 m.create = func(root,size) {
  m.size = size;
  root.createChild("group");
  };
 
 m.setOrigin = func(x0, y0) {
  m.x0 = x0;
  m.y0 = y0;
  };
 
 m.plotGrid = func(dx=50, dy=80) {
  var grid = m.createChild("path", "grid").setColor(0.25,0.25,0.25);
  for(var x=m.x0; x<m.size.width; x+=dx){
    grid.moveTo(x, m.y0).lineTo(x,m.size.height-2);
    }
  for(var y=m.y0; y>0; y-=dy){
    grid.moveTo(2, y).lineTo(m.size.width-2,y);
    }
  };
return m;
Then, from my par_class I call:
Code: Select all
 ...
 me.graph = plot2D.new();
 me.graph.create(m.root,m.size);
 ...
 me.grid = me.graph.plotGrid(dx:me.hzGrid*me.XYscale, dy:me.vtGrid*me.Zscale);
At that point, I get the error msg "Nasal runtime error: No such member: createChild"
Obviously it's about the heritage stuff.
Which parents should I declare to inherit their methods?

P.S.: I did not found anywhere the FGplot script. I think that I would learn a lot from it.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

PreviousNext

Return to Nasal

Who is online

Users browsing this forum: No registered users and 1 guest