Board index FlightGear Development

Changes to GPS creating problems.

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Changes to GPS creating problems.

Postby omega95 » Sun May 26, 2013 2:09 pm

I would also like to know what changes have been made to the GPS. I can't run any GPS functions using nasal anymore.

The below code returns an error that result-count is nil.

Code: Select all
var gps = "/instrumentation/gps/";
var query_types = ["vor", "ndb", "fix"];

var gpsSearch = func(query) {
   
   var results = [];
   
   foreach(var type; query_types) {

      setprop(gps~"scratch/query", query);
      setprop(gps~"scratch/type", type);
      setprop(gps~"command", "search");
      
      var num = getprop(gps~"scratch/result-count");
      
      for(var n=0; n<num; n+=1) {
      
         var result = {
         
            ident: getprop(gps~"scratch/ident"),
            name: getprop(gps~"scratch/name"),
            brg: int(getprop(gps~"scratch/true-bearing-deg")),
            dist: int(getprop(gps~"scratch/distance-nm")),
            lat: getprop(gps~"scratch/latitude-deg"),
            lon: getprop(gps~"scratch/longitude-deg"),
            type: type
         
         };

         if (result.dist != nil) {
            if (result.dist > 0) {
               append(results, result);
            }
         }
         
         setprop(gps~"command", "next");
      
      }
      
   }
   
   return results;

};


Also, setting "/instrumentation/gps/command" to search doesn't seem to work anymore. :cry:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changes to GPS creating problems.

Postby omega95 » Mon May 27, 2013 2:47 am

I see you have introduced 'positioned' to run GPS functions instead of using 'instrumentation/gps/command'. This is a HUGE problem for me because there are multiple instances in my aircraft where I use 'instrumentation/gps/command' and I frankly don't have enough time to change all of them or change them again when you do something like that.

First of all, what's the point in taking out the 'instrumentation/gps/command' system of searching? Unless there's a major advantage, would you be able to revert or atleast make a system where this is still possible but using 'instrumentation/gps/command' redirects to positioned?

I would rather stay with an older version of FlightGear and be able to use my aircraft instead of get the latest version and not be able to. :evil:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changes to GPS creating problems.

Postby dbelcham » Mon May 27, 2013 2:59 am

Funny. I noticed this behaviour last night too. Had just started to track it down tonight when I saw this.
dbelcham
 
Posts: 58
Joined: Thu Jun 07, 2012 3:55 pm

Re: Changes to GPS creating problems.

Postby Hooray » Mon May 27, 2013 4:59 am

You should really be using the issue tracker to report this issue - it sounds like a regression that may affect a bunch of aircraft, so better report it early so that it can be verified and addressed prior to the upcoming release.
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: Changes to GPS creating problems.

Postby omega95 » Mon May 27, 2013 5:39 am

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

Re: Changes to GPS creating problems.

Postby Hooray » Wed May 29, 2013 6:30 am

Subject: Changes to GPS creating problems.
http://code.google.com/p/flightgear-bug ... il?id=1128

zakalawe wrote:
omega95 wrote:I see you have introduced 'positioned' to run GPS functions instead of using 'instrumentation/gps/command'. This is a HUGE problem for me because there are multiple instances in my aircraft where I use 'instrumentation/gps/command' and I frankly don't have enough time to change all of them or change them again when you do something like that.
I realised that it's not just 1 of my aircraft but 5 different series!
In this case, the scale of updating required is much larger than I anticipated, hence me restoring the old API while I decide a way to move forwards.



omega95, I think, in order to work around the issue and update all of your aircraft at once, you only need to provide a single Nasal wrapper that implements the old behavior /command behavior by using the NasalPositioned APIs (which really are the better method).

To do that, you only need to register a listener and parse the old commands there, and then call the corresponding NasalPositioned APIs - that's the most flexible and portable way, while also providing backwards compatibility, i.e. for FG versions <= 2.11

You can then share the file with all your aircraft, and only need to run io.load_nasal() if getprop("/sim/version") is greater than 2.10 - which could also be done automatically as part of a script in $FG_ROOT/Nasal.

That way, you should not need to modify any of the code - only add a portability wrapper, which is exactly the approach taken by ThorstenR's local weather system - to ensure that it works for most FG versions, despite FG APIs and features never being stable - we could show a warning message saying "this api will soon be phased out, go to http://wiki.flightgear.org/gps to learn how to port your aircraft"

Note that I have not at all looked at the C++ code changes in question, which is why I suggest to get in touch with Zakalawe, so that he can review my suggestion, and suggest refinements.

Again, I don't think that you should have to modify all your aircraft - and I also don't think that the old code needs to be added again, we really only need a Nasal-space portability wrapper that retains the old functionality, which could simply be dropped into $FG_ROOT/Nasal for a certain "grace period"
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: Changes to GPS creating problems.

Postby omega95 » Wed May 29, 2013 1:16 pm

That's exactly what I've asked zakalawe to do - add a nasal wrapper that simulates the behavior of the gps command but actually runs positioned. But there's a lot more functionality like runways navigational frequencies et. that it needs to generate too because a lot of information from the scratch is used.

There are 2 problems I see right now-
1. Zakalawe reverted to the old code in http://gitorious.org/fg/flightgear/commit/def81b4de5f87c28b5afd92264e40e66e4fd93e3 but that didn't fix the problem. There're also users who said that they had this issue with FG2.10 so it's a lot bigger than just that.
2. For some reason, I can't set command to 'search' - that's the problem. If I could do that, I would make a test wrapper to simulate the old code behavior but it simply doesn't let me set that property with setprop('/instrumentation/gps/command','search'); Any idea why this issue occurs?

Honestly, I like the positioned API better than getting data from the property tree - it's a lot easier to have a nasal function to get data like that, but if it causes a lot of problems, wouldn't it be easier to either leave it at the old code or make a "wrapper" so the old code works too?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changes to GPS creating problems.

Postby omega95 » Wed May 29, 2013 1:31 pm

Actually, the reversion to the old code seems to have fixed some of the issues I had. I'm able to search for waypoints now and add them to the flightplan - now I'm trying to replicate the error dbelcham is getting.

Hmm, I think there's something with the distance-nm when reverted to the old code. The ATR72's rte function uses distance!=nil and distance>0 to check if that waypoint really exists but the distance doesn't seem to be a realistic value. And that messes up with other distances.

Image

^ I was able to plan a perfectly normal route for a 180 nm trip but it gives me the initial distance over 5000 nm and the others 0. :|

I also think it's not behaving completely like it did before, when you search, it actually searches for a fix of that name, vor of that name and ndb of that name, and uses only the correct distance based on the distance!=nil and distance>0. Any idea why that occurs?

Also, do you have a wiki page of a manual on the positioned API? I couldn't find anything in the Nasal folder so I assume it's done in C++.

Also, why can't I use 'any' as a query type in either the command search method or the positioned API? It is listed as an option in the GPS dialog. :|
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changes to GPS creating problems.

Postby Hooray » Wed May 29, 2013 2:16 pm

Honestly, I like the positioned API better than getting data from the property tree - it's a lot easier to have a nasal function to get data like that, but if it causes a lot of problems, wouldn't it be easier to either leave it at the old code or make a "wrapper" so the old code works too?


I believe a Nasal-space wrapper is the right approach, but obviously Zakalawe is more familiar with the code and the changes that were introduced - but in general, it should be fairly straightforward to provide a separate Nasal module that provides the old functionality while using the new APIs, and from an engineering point of view, it would also be the right thing, rather than phasing out APIs completely, which is also why Thorsten's LW system uses such a portability wrapper, to ensure that things work despite APIs changing, but also for older FG versions, but that requires conscious design.

also, do you have a wiki page of a manual on the positioned API? I couldn't find anything in the Nasal folder so I assume it's done in C++.

It's all done in C++, and will be using the cppbind framework: http://wiki.flightgear.org/List_of_Nasa ... ct_Queries
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: Changes to GPS creating problems.

Postby zakalawe » Thu May 30, 2013 7:23 am

The problem with writing a Nasal wrapper is the scratch API and Nasal positioned APIs handle state in different ways, so that wrapper layer would have to encapsulate some state itself, and that could get interesting to make reliable. I'm definitely not saying it's impossible, but since this is an interim solution anyway, I felt the lowest-risk, lowest-effort solution was to add the existing C++ code which (ignoring the issues mentioned) is obviously backwards compatible.

Also, there are couple of properties still used in the 'new' C++ API, which overlap. So there would be some fiddly logic to handle that, or it would be cleaner to completely remove the command system from the GPS, use some other system (fg-commands, but the problem is they are awkward to target to a specific instrument, normally they're global), and have all the command/scratch emulation happen in a Nasal layer.

(Which is likely the approach I will follow if no-one beats me to it)

omega95, in terms of the bugs you're mentioning with search on 'any', and distances, I'm finding it a bit hard to isolate each issue. If you could follow up in the bug tracker, ideally will a separate comment for each one (I don't think it's worth making completely separate issues), I will get those fixed. It would also be interesting to know which ones occur in 2.10.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Changes to GPS creating problems.

Postby Hooray » Thu May 30, 2013 10:36 am

Okay, thanks for clarifying that.

it would be cleaner to completely remove the command system from the GPS, use some other system (fg-commands, but the problem is they are awkward to target to a specific instrument, normally they're global), and have all the command/scratch emulation happen in a Nasal layer.


that sounds like an excellent idea - in fact, Philosopher started documenting the new addcommand()/removecommand() APIs that you added a while ago.

So this would be another great opportunity to move some C++ code into "user space" (aka the base package), given that it's not exactly performance-critical stuff, and that it would definitely be useful to allow end users to extend the system and help maintain it. With these changes it should actually be possible to come up with fgcommands that are instance-specific, i.e. for addressing a single instrument. But it would probably make sense to introduce some notation/convention for such fgcommands, i.e. something like an object.method syntax that can be easily processed by Nasal to address a single instrument in the tree
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: Changes to GPS creating problems.

Postby omega95 » Thu May 30, 2013 1:25 pm

For the ATR72, dbelcham and I wrote a few nasal functions that use the 'positioned' API to get some data and other functions to add on what else the GPS used and return the results, and after some work, I managed to remove any interactions with the old GPS code and it works. (except it messed up for some reason while flying a STAR - don't get any errors, so I'm a little confused with this)

Now, I have 3 other aircraft series which I care about atm where I have to do the same but unfortunately, the folder structures and organization for those aircraft are pretty bad compared to that of the ATR72 - hopefully, I'll find all of them.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changes to GPS creating problems.

Postby Hooray » Thu May 30, 2013 1:31 pm

omega95, in general it would make sense for such code to be shared through a single module, so that ALL your aircraft can benefit from your changes - without needing to be manually adjusted each.
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: Changes to GPS creating problems.

Postby omega95 » Thu May 30, 2013 1:57 pm

Hooray wrote in Thu May 30, 2013 1:31 pm:omega95, in general it would make sense for such code to be shared through a single module, so that ALL your aircraft can benefit from your changes - without needing to be manually adjusted each.


Well, I didn't write a wrapper for the GPS command but rather changed all the places where it was used. It would still be MUCH easier to write a wrapper but for some reason, I can't set the command to a value.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04


Return to Development

Who is online

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