[Flightgear-devel] nasal airportinfo()
Hi, when playing around with airportinfo() (actually the nice gstunnel script) I noticed it would throw a naRuntimeError() and thus not return nil as it claims to do when called with e. g. some bogus string like airportinfo(FOOBAR). Imho it would make sense to follow the documented behaviour in that not being an error, but the equivalent of not found. Deleting l. 535 in NasalSys.cxx should do the trick (and hopefully not break anything else *g*) regards K. Hoercher - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal airportinfo()
* K. Hoercher -- Thursday 18 October 2007: it would throw a naRuntimeError() and thus not return nil as it claims to do when called with e. g. some bogus string like airportinfo(FOOBAR). Yes, that's a bug. Fixed, thanks. :-) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal airportinfo()
* K. Hoercher -- Thursday 18 October 2007: airportinfo(FOOBAR). BTW: it's only documented in the source code for now, but in case you missed it: the syntax has slightly changed a few days ago: (a) airportinfo(id);... e.g. KSFO (b) airportinfo(type); ... type := (airport|seaport|heliport) (c) airportinfo() ... same as airportinfo(airport) (d) airportinfo(lat, lon [, type]); That is, an airportinfo() without argument returns the next regular (land-)airport, but one can ask for the next seaport or heliport, too: airportinfo(seaport); It's a bit ugly that the syntax is the same for (a) and (b), but I wanted to avoid yet another argument, and the three airport types can't be misinterpreted as airport ids thanks to case and length. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Secondly, there are a selected number of processes that take disproportionally long to execute. The most significant one I found sofar is a call in src/Input/input.cxx (around line 911). I have surrounded this statement by debug timestamp information: stamp(update_joystick_fire_prep ); a.bindings[modifiers][k]-fire(axis_values[j]); stamp(update_joystick_fire_end); Although the Nasal code in bindings is mostly simple and rather quick to parse, it should be noted that this is done again for every single fire() call. And in some joystick drivers there's some more sophisticated code, which could explain your results. If you look around with a digital hat and operate the throttle, there are oodles of Nasal recipes read in, parsed, and executed. The good news: I have a Nasal binding/script cache almost finished. I don't know yet if it makes a huge difference, but I guess it's desirable in any case. After all, there's a tendency to use more Nasal everywhere (which is a good thing!), and it's asked too much of users to know where Nasal code is cheap and where not. The Nasal cache re-parses the script when it was changed in the property tree, so we don't lose any flexibility. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programmatically Gathering Incoming Multiplayer Data to FlightGear
Frank, Information on nearby multiplayer entities is provided in the property tree so you can access this information at least within flightgear. You could query this data via the property interface, or build some sort of nasal script. You would need to add an extra telnet/property interface to your external code to query this data, but it should be pretty doable. Curt. On 10/18/07, frank hadder wrote: I'm working on a UAV simulator using FlightGear. The goal is to make an autonomous UAV. We have written code that receives FDM input and sends the flight controls back to the FlightGear simulator ie. we have written a program to fly the plane. Now we want to add the data from the Multiplayer server to help make flight decisions (such as if we wanted an autonomous UAV to follow another plane). To do this, we need to have access to the data being sent from the multiplayer server to our local instance of FlightGear. The problem, at least as I see it, is that we cannot bind a socket to the port being used to send this information to our local FlightGear because it is already in use (by FlightGear). I'm searching for a solution to this problem. Listed below are possible ideas in order of preference: 1. Set some command line option in FlightGear to enable our program to have access to the FlightGear multiplayer information (namely the position of other aircraft). If there is such an option, I'm not aware of it. 2. Enable some kind of port forwarding. If there is a way to do it, we could, at the OS level (linux), forward information coming in on a certain port to both the original port and a second port that my program can bind to. I'm not sure if this is possible. I know you can forward packets coming in on one port to another port but I assume the original port never receives the packet. I would need a kind of copy to be placed for access on a second port. 3. Change the FlightGear code to not only listen to the multiplayer port but to also forward those packets onto another port. This is perhaps the most straightforward option but I hesitate to introduce new code into as complex of a system as FlightGear. So, I ask the community, which of these options (or none of the above) seems like the easiest/possible solution? Thoughts? Are there any details I forgot to provide that you would need to know? Thanks, frank - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Programmatically Gathering Incoming Multiplayer Data to FlightGear
I'm working on a UAV simulator using FlightGear. The goal is to make an autonomous UAV. We have written code that receives FDM input and sends the flight controls back to the FlightGear simulator ie. we have written a program to fly the plane. Now we want to add the data from the Multiplayer server to help make flight decisions (such as if we wanted an autonomous UAV to follow another plane). To do this, we need to have access to the data being sent from the multiplayer server to our local instance of FlightGear. The problem, at least as I see it, is that we cannot bind a socket to the port being used to send this information to our local FlightGear because it is already in use (by FlightGear). I'm searching for a solution to this problem. Listed below are possible ideas in order of preference: 1. Set some command line option in FlightGear to enable our program to have access to the FlightGear multiplayer information (namely the position of other aircraft). If there is such an option, I'm not aware of it. 2. Enable some kind of port forwarding. If there is a way to do it, we could, at the OS level (linux), forward information coming in on a certain port to both the original port and a second port that my program can bind to. I'm not sure if this is possible. I know you can forward packets coming in on one port to another port but I assume the original port never receives the packet. I would need a kind of copy to be placed for access on a second port. 3. Change the FlightGear code to not only listen to the multiplayer port but to also forward those packets onto another port. This is perhaps the most straightforward option but I hesitate to introduce new code into as complex of a system as FlightGear. So, I ask the community, which of these options (or none of the above) seems like the easiest/possible solution? Thoughts? Are there any details I forgot to provide that you would need to know? Thanks, frank - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bad high altitude engine behavior ?
I have a bug report I've been looking at for JSBSim that was filed by a user here. http://sourceforge.net/tracker/index.php?func=detailaid=1739190group_id=19 399atid=119399 I'm wondering if this behavior can be duplicated by anyone else with the current revision of FlightGear with the latest JSBSim code that is in FlightGear cvs. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
