Board index FlightGear Development New features

Ground services !

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: Ground services !

Postby Hooray » Thu Aug 31, 2017 4:59 pm

for starters, you could simply copy it, or just extend it - it would be easy enough to restore the original dialog later on.

Your ground service code needs to provide a function that returns a vector with positions (lat/lon) - ideally in the form of geo.Coord instances.
Once you have that API, it is literally a piece of cake to make the MapStructure framework render all sorts of stuff.

There is a simple example that renders tutorial targets (i.e. waypoints) using fairly simple code: http://wiki.flightgear.org/Canvas_MapSt ... _Layer_TUT
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: Ground services !

Postby Hooray » Sat Sep 02, 2017 4:05 pm

I forgot to mention: There's a distinction in MapStructure between rendering static (=stationary/non-moving) objects and objects that move (="traffic") - for reference, it would make most sense to look at the implementation of the TRAFFIC (=TFC) layer, and its searchCmd() which is populating a vector with geo.Coord objects to be rendered.

You can find it somewhere in $FG_ROOT/Nasal/canvas/map/TFC.lcontroller (IIRC)

EDTT: https://sourceforge.net/p/flightgear/fg ... controller

On the other hand, it may make more sense (for starters) to look at the WXR (=weather) layer, because it's dealing with the same problem, without adding any complexities that are inherent to dealing with AI/MP nodes: https://sourceforge.net/p/flightgear/fg ... controller

HTH
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: Ground services !

Postby ThomasS » Tue Sep 05, 2017 9:02 am

Well, both TFC and WXR appear to be suitable templates. And indeed I succeeded in duplicating/modifying TFC for displaying ground vehicles (which as a side effect the standard TFC might also do).

But the map is not updated. Its only drawn once. I expected the mapstructure engine to call the "searchCmd" repeatedly, but its only called once. Maybe there is something wrong with the way I register my lcontroller file:

Code: Select all
var name = 'GROUNDSERVICES-vehicle';
var parents = [SymbolLayer.Controller];
var __self__ = caller(0)[0];
SymbolLayer.Controller.add(name, __self__);
SymbolLayer.add(name, {
   parents: [MultiSymbolLayer],
   type: name, # Symbol type
   df_controller: __self__, # controller to use by default -- this one
});


The original TFC layer IS updated, but my copy isn't. There seems to be some magic inside MapStructure.nas which decides when to update. But I have no clue what it is. Maybe a missing "visible" node somewhere. :?:

And reusing WXR I run into annoying

Code: Select all
Nasal runtime error: Fatal error in Nasal call: Can not convert to 'Positioned': not a derived hash
flightgear/src/Scripting/NasalSys.cxx:1147:  at /Applications/FlightGear-2016.4.3.app/Contents/Resources/data/Nasal/geo.nas, line 382


errors. Apparently due to a wrong result of SearchCmd. But it is a list of Coord. Seems I solved this by adding the line

Code: Select all
layer.searcher._equals = func(l,r) l.equals(r);


which got lost. And still I only have a vague idea about whats happening here. :(

And one more success message: The RTE layer appears to be a good sample for displaying the groundnet.
ThomasS
 
Posts: 59
Joined: Sun Sep 11, 2016 1:21 pm
Location: West of EDDK
Version: 2018.2.1
OS: Linux,MacOS,Windows

Re: Ground services !

Postby Hooray » Tue Sep 05, 2017 4:44 pm

Thanks for the update.

Regarding the missing update, there is a dedicated "position source" to configure your driver, it also contains a hard-coded list of layers to be updated "quickly": https://sourceforge.net/p/flightgear/fg ... controller

see the names of TFC and FLT for instance.

This is intended to contain all aircraft specific stuff - this encapsulation makes it possible to easily use your work using different "source objects" - e.g. displaying AI traffic (or groundservices!) from the perspective of another AI vehicle/aircraft

The _equals_ stuff is better explained here: http://wiki.flightgear.org/Canvas_MapStructure

PS: Maybe you could add your experiments to the git repo or share them here ? Ideally in a self-contained fashion, e.g. a dialog file that already contains a test-func with the data you have ? That way, I can more easily reproduce the errors you are seeing. Ideally, you would separate the back-end from the front-end, e.g. only provide a custom vector with your data and hook that up to the drawing routines (searchCmd).
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: Ground services !

Postby Hooray » Thu Nov 30, 2017 8:05 pm

Regarding your latest wiki edits:


http://wiki.flightgear.org/Ground_Servi ... f_0.3.0.29
Image

Assuming that this is using the MapStructure framework, may I suggest to consider creating a merge request to see your changes merged upstream ?
Also, the MapStructure framework is designed so that the viewpoint/perspective can be switched by using alternative "position sources" (drivers) - i.e. to see the perspective of an arbitary AI entity.


The point being that it would be much easier for other people to reuse your work once it's committed to fgdata - for instance, a few folks seem to be working on a moving-map GPS for cars:

Subject: What/Where did you drive today?
MMW wrote:Real world vehicles will be added once someone has made a simple GPS model with map like this (so that I can attach to every vehicle :) )
Image


PS: But for starters, I would suggest to use a darker background color on the dialog, so that the yellow lines can actually be seen ;-)
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: Ground services !

Postby ThomasS » Fri Dec 01, 2017 5:53 am

Indeed the MapStructure framework is used. I created two layers, one for displaying the groundnet.xml information and one for displaying ground vehicle positions. But I'm afraid these are too specifically coupled to the purpose of ground services. At least currently. It might be possible to extract the layer for vehicles and make it a generic layer for displaying the position of any AI vehicle/ship/aircraft. I'll keep this in mind.

About the background: Agreed. It should be slightly darker.
ThomasS
 
Posts: 59
Joined: Sun Sep 11, 2016 1:21 pm
Location: West of EDDK
Version: 2018.2.1
OS: Linux,MacOS,Windows

Re: Ground services !

Postby Hooray » Sat Dec 02, 2017 10:31 am

Yeah, I agree. My suggestion would be two treat those two layers an independent features - i.e. regardless of the Ground Services addon, it would be a good idea to add a dedicated "ground-network" layer to the MapStructure system. That way, the same layer could also be added to map-canvas.xml, which could be a huge asset for people developing AI related features. At the same time, that would mean that your work/addon would have less code to deal with, and more of its functionality would be part of fgdata.

Likewise, the changes you have done at the MapStructure/Phi level could be unified, e.g. by introducing a dedicated "flag" (aka property) to "mark" certain AI nodes as "ground traffic" - that way, Phi/MapStructure could easily pick up such nodes automatically, without requiring any patching instructions.

By the way, we also once tinkered with creating "editable" MapStructure layers, i.e. to dynamically add layer elements in an interactive fashion - e.g. by responding to mouse clicks (drag & drop etc). That might be more relevant to your concrete "Ground Services" use-case, right ?

Originally, the idea was to allow fictional navaids (VOR, NDB, LOC/ILS) to be placed on a map via drag & drop, that would then drive the back-end layers.
Technically, that's not very difficult to do actually thanks to the decoupled/modular nature of the MapStructure framework.

Basically, certain MapStructure layers could implement an "EditableLayer" interface (class) by providing their own methods to add/remove/update and customize a certain element (think symbol).

What I came up with a few years ago was a way to add symbols to the map, that would "de-project" their position from screen coordinates to lat/lon tuples, with support for responding to canvas events (mouse clicks) as well as custom tooltips.

That would be roughly 40-50 lines of Nasal code added to MapStructure.nas, so relatively simple - and if that's something that you would find useful, I am sure that we could resurrect the idea and team up to come up with such a feature for your "Ground Services" addon ?

Basically, this would make it possible to come up with an interactive editor for creating/updating ground service networks, possibly including pre-routing support.
At the same time, such an editable layer could be reused by people working on the tutorial/mission addons to easily create "missions" in a visual fashion where gound vehicles could follow certain pre-defined tracks, which could also be the foundation for the kind of "mission editor" that some folks have been working towards - so this kind of work could be highly relevant for folks interested in these aspects of the simulation.

If in doubt, you may want to get in touch with Marius_A.

PS: I think you can do an equality check using the edges of the net/line segment ? Referring to: https://github.com/thomass171/GroundSer ... roller#L22
Also, regarding the FLT/RTE handling, I never really liked that - and my suggestion would be to patch MapStructure.nas (aircraftpos.controller) to use a vector of layers there, and provide register/unregister functions for adding layers dynamically.
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: Ground services !

Postby ThomasS » Sat Dec 02, 2017 3:17 pm

Again you are full of new ideas and visions :D and I'm afraid I don't really get all of it. What I extracted as possible next steps is:

    A register/unregister function in MapStructure.nas for adding additional layer would be great. This made it easy for addons to add layers. Having said that, this is the opposite of making layer generic.

    Making my groundnet layer generic and available for other modules will introduce the overhead of reading/parsing groundnet.xml. Not nice. I consider this a workaround for now until the groundnet will be available otherwise (preferably in the property tree).

    The most promising step seems to make the AI layer a generic layer. A layer that shows the position of all AI aircraft/ships/vehicle. I for myself see a use case for using it in the ModelCockpitView addon. And for such a layer mouse click features appear very useful. Clicking an icon and either show additional information or trigger some action.

    A major pending challenge is unifying/integrating my ground services addon with existing features (core AITraffic, Jetways, ramp agent a.s.o.). A ground service vehicle eg. doesn't know when an AI aircraft arrives or departs. And it doesn't know the model and so it doesn't know the door position for approaching a catering vehicle.

Unfortunately I'm not yet sure how to proceed now.
ThomasS
 
Posts: 59
Joined: Sun Sep 11, 2016 1:21 pm
Location: West of EDDK
Version: 2018.2.1
OS: Linux,MacOS,Windows

Re: Ground services !

Postby Hooray » Sat Dec 02, 2017 3:41 pm

Sorry, if I was overwhelming you. That was not my intention.
It's not so much ideas or "vision" as such, but rather seeing overlapping developments going on, i.e. stuff that people are currently working on that could be useful from the ground services adddon perspective, but also looking at your own development and realizing that this could be useful for stuff that other folks are working on.

Turning your MapStructure related changes into dedicated "layers" is just one part of that, because that would mean that these layers could be more easily reused without people having to have your grasp of Nasal knowledge ;-)

  • the registerLayer()/unregisterLayer() API was just an idea to expose a vector (or even just a hash) of layers that are to be updated "quickly" (=regularly), regardless of other update semantics.
  • Regarding the groundnet parsing overhead - I do not think that this will show up at all, because these layers are only instantiated when actually used - so that instruments/dialogs not using your layer will not even do any parsing. Apart from that, if this is pure parsing and building a Nasal-space data structure only, you can use thread.newthread(callback) to run an arbitrary Nasal callback in a background thread, as long as it is not using any of the FlightGear specific extension functions (namely fgcommands, the property tree and any of the Canvas APIs).
  • Like you say, exposing the groundnet at the property tree level would also be possible - and even that could be accomplished using a Nasal space workaround (until the C++ folks have come up with a patch to do just that) - imagine having a down-stripped version of your current code that will do the parsing/processing in a background thread, build the data structure and the populate the property tree afterwards - that could be a standalone component, one that could be replaced if/when the corresponding task is moved to C++ code.
  • A generic AI layer would definitely seem possible, but we have already seen all sorts of different "filtering" requirements, including people wanting to implement radar/radio propagation semantics to exclude certain traffic that would be hidden behind a mountain range etc.
  • Like you say, the generic AI layer could be generalized a little more and could also have optional support for becoming an "UI" layer with support for interactive functionality (as in Nasal/Canvas tooltips, or context menus for selected nodes on the map)

Regarding the major change you have in mind, my suggestion would be to proceed according to your own goals and priorities - I mean, like I just mentioned on the wiki, you have already made enormous progress with your latest code, and it is much cleaner and much better organized than pretty much everything I have seen in that department over the course of the last couple of years -I mean, it even has built-in unit tests apparently ...

Then again, my recommendation would be to get in touch with the devel list, it is foreseeable that your addon should be added to FGAddon sooner or later (assuming it is GPL?) - thus, it would make sense to get it committed there, which also means that its development will be more prominent, and more people will be tracking its development and actually help with testing, and possibly feature requests/patches.

Besides, it is worth noting that there are quie a few related features, you mentioned already the "jetways" functionality.
I would suggest to look up the recent discussions related to that - and get it touch with the developer/s who came up with that code (I believe it was primarily skyop, not sure though): https://sourceforge.net/p/flightgear/ma ... /34725917/

I do think that the most recent consensus on the devel list was to keep this stuff in Nasal space, but extend the underlying C++ code in the AI system to better support these use-cases.

I think that it was James who mentioned that he'd be willing to "mentor" people to do just that, referring to:

https://sourceforge.net/p/flightgear/ma ... /35491165/
James Turner wrote:There’s zero need for anything to hit the disk in this process, or duplicate any XML files - but it needs some C++ coding, it can’t be done entirely from Nasal.

So, we need a volunteer to port the jetways logic to some C++ to create the instances (the per-jetway logic can stay in Nasal as needed). I’m happy to coach / assist.


Thus, my take on the matter is that it would make sense to reach out to the people involved in the original Nasal code, because that is what your code is using, too. And then see if they're still around or not, and work out a way to come up with the requirements for the corresponding C++ changes to support these kinds of use-cases better.

As a matter of fact, Durk himself mentioned on various ocassions that he'd be supportive of generalizing the original AI code accordingly, so that some of its hard-coded and built-in assumptions could be better customized or disabled completely (referring for instance to the Bombable/dog-fighting use-case):

viewtopic.php?p=134970&#p134970
Durk wrote:Note that I won't oppose other ideas, and if you have nasal code that would require certain components of the AI system to be shutdown, or need specific hooks to interface certain C++ components with nasal bindings, than I would certainly be willing to support that.


Speaking in general, I am however not sure if Durk is currently around or actively involved at the code level. Thus, my recommendation would be to look up James' comments involving the jetways/AI discussion, because he's been around for a number of years now, and he's basically the most likely person to help with reviewing/integrating such changes, because he belongs to the camp of the few people not just wanting to see less Nasal code running in the main loop, but also offering to actually do the corresponding C++ work to provide alternatives that are accessible to Nasal coders.

Other than that, my suggestion would be to keep on working with such a clean structure, and maybe even introduce a dedicated folder for code/modules that may sooner or later become a part of $FG_ROOT/Nasal.

From a functionality standpoint, I can however foresee that it would be great if you could get in touch with the OSM2City folks, because that's the primary other ground-traffic application in FlightGear that already provides the equivalent of a "groundnet", and that's the kind of feature that could help make your work really popular among folks, so that C++ level additions will sooner or later be really required.

The other power-feature being integration with the so called "Traffic Shader" that Thorsten, i4dnf and others worked out a while ago (also apparently using OSM2city data these days).

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

Re: Ground services !

Postby vezza » Sat Apr 07, 2018 6:43 am

ThomasS thanks for you effort... I am not a serious coder, just trying to understand how things works in order to be of any help in the future... I am surely missing something, anyway... Is there a reason why you are using a new folder for the groundservices models (Models/GroundServices)? Is it just to experiment or it will be a new shared model folder in the fgdata tree? I'am asking that because, if I will be able, I would like to add some Ground Service vehicle's to the fgdata tree but I saw that at the momente they are located in Models/Airport/Pushback or Models/Airport/Services or Models/Airport/Vehicle...
vezza
 
Posts: 16
Joined: Sat Dec 15, 2012 11:02 pm

Re: Ground services !

Postby ThomasS » Wed Apr 11, 2018 4:33 am

What I did was just creating a collection of vehicles possibly suitable for ground services from various locations in the FlightGear universe (see file CREDITS in the addon). I just put these into a dedicated folder inside the addon and did some slight modifications to the models like adjusting the z-axis rotation point and removing unneeded parts which is useful for the special purpose of ground service. I'm aware its no good idea to copy model files instead of keeping these in a central place. But I'm afraid even FGdata is no such central place. Maybe the scenery model database is such a place.

And there might be additional useful modifications to the models in the future like light cones, spinning wheels and moving luggage. If you are interested and familiar with modeling you might modify the catering vehicle model to make its box liftable by splitting the object into several objects that can be animated..
ThomasS
 
Posts: 59
Joined: Sun Sep 11, 2016 1:21 pm
Location: West of EDDK
Version: 2018.2.1
OS: Linux,MacOS,Windows

Re: Ground services !

Postby wkitty42 » Wed Apr 11, 2018 3:00 pm

ThomasS wrote in Wed Apr 11, 2018 4:33 am:I'm aware its no good idea to copy model files instead of keeping these in a central place. But I'm afraid even FGdata is no such central place.

models are distributed via TerraSync these days...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4286
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 3 guests