From: Paul S. <su...@te...> - 2005-12-30 19:36:09
|
Would anyone object if I tied nasal code specific to scenarios into FG aircraft? Currently there isn't a way to load nasal code when a scenario is loaded and the only feasible way seems to be to add a check in the aircraft config files and then load a specific nasal script if a scenario is running. In my opinion it's an architectural no-no but at the moment it's the path of least resistance. Reason : I was considering adding training scenarios to FG similar to what can be found in MSFS2004. I either need to lock the scenarios to a specific aircraft like the 172 and dissallow the user from selecting other suitable aircraft like the J3Cub, 182, Cirrus SR20, etc. or I need to modify a whole stack of aircraft and give the user to option of learning in their favourite aircraft. Yay or nay? Paul |
From: Curtis L. O. <cur...@fl...> - 2005-12-30 20:45:48
|
Paul Surgeon wrote: >Would anyone object if I tied nasal code specific to scenarios into FG >aircraft? > >Currently there isn't a way to load nasal code when a scenario is loaded and >the only feasible way seems to be to add a check in the aircraft config files >and then load a specific nasal script if a scenario is running. >In my opinion it's an architectural no-no but at the moment it's the path of >least resistance. > >Reason : I was considering adding training scenarios to FG similar to what can >be found in MSFS2004. > >I either need to lock the scenarios to a specific aircraft like the 172 and >dissallow the user from selecting other suitable aircraft like the J3Cub, >182, Cirrus SR20, etc. or I need to modify a whole stack of aircraft and give >the user to option of learning in their favourite aircraft. > > I'm pretty sure that any scripts you drop into the $FG_ROOT/data/Nasal/ directory will be automatically loaded. You can use a timer hack to have the script run every iteration. You could probably check the status of a property you create to run the script or just skip the whole thing ... if ( getprop("/sim/paul-surgeon/training/scripts-enabled") ) { train(); } else { # do nothing } That means the code would be loaded and occupy space no matter what, but it would only get executed if the enable flag was set to true. Perhaps there is a better way to conditionally load nasal code (but not on a per-aircraft basis?) For what it's worth, I think a set of training scripts (with some corresponding documentation) would be a great addition to FlightGear. You might consider setting up some basic user setable parameters so the scripts could easily be adapted to a variety of aircraft ... things like basic target speeds for the manuevers, number of engines, perhaps flags to specify what equipment is available ... then the scripts could intelligently fail things at inopportune times. If you have any questions about setting up weather parameters or setting an initial aircraft location, heading, altitude, speed, just holler ... that stuff should all be 'easily' doable from scripts. Note also that you could do much, if not all of this from an external perl/python script as well and interface to FG through the network interface. 101 ways to skin a cat ... Regards, Curt. -- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Roy V. O. <roy...@bl...> - 2005-12-30 21:08:01
|
On Friday 30 December 2005 21:45, Curtis L. Olson wrote: > Note also that you could do much, if not all of this from an external > perl/python script as well and interface to FG through the network > interface. With perl/python you can do alot more that you can do with nasal. Play mp3, vorbis or even speex encoded sounds. FileIO, for example for evaluation reports. > 101 ways to skin a cat ... Indeed! -- Roy Vegard Ovesen |
From: Roy V. O. <roy...@bl...> - 2005-12-30 21:21:30
|
On Friday 30 December 2005 22:07, Roy Vegard Ovesen wrote: > On Friday 30 December 2005 21:45, Curtis L. Olson wrote: > > Note also that you could do much, if not all of this from an external > > perl/python script as well and interface to FG through the network > > interface. > > With perl/python you can do alot more that you can do with nasal. Play mp3, ^^^^ than -- Roy Vegard Ovesen |
From: Paul S. <su...@te...> - 2005-12-30 21:25:17
|
On Friday 30 December 2005 23:07, Roy Vegard Ovesen wrote: > On Friday 30 December 2005 21:45, Curtis L. Olson wrote: > > Note also that you could do much, if not all of this from an external > > perl/python script as well and interface to FG through the network > > interface. > > With perl/python you can do alot more that you can do with nasal. Play mp3, > vorbis or even speex encoded sounds. FileIO, for example for evaluation > reports. > > > 101 ways to skin a cat ... > > Indeed! Hmmm ... I didn't know that the network interface was that flexible. So I can read and write any properties in the property tree from an external app? Playing sounds from an external app (which is an absolutely neccessary for what I want to do) would be a problem for some people who's sound cards don't do hardware mixing. I assume playing sounds from nasal would get mixed inside FG's openal setup? Paul |
From: Curtis L. O. <cur...@fl...> - 2005-12-30 21:42:09
|
Paul Surgeon wrote: >Hmmm ... I didn't know that the network interface was that flexible. >So I can read and write any properties in the property tree from an external >app? > >Playing sounds from an external app (which is an absolutely neccessary for >what I want to do) would be a problem for some people who's sound cards don't >do hardware mixing. I assume playing sounds from nasal would get mixed inside >FG's openal setup? > > I keep thinking that someday I should pen a book ... 101 tricky things you can do with flightgear. For instance, start FlightGear with the following option: --httpd=5400 You can pick any port number, but 5400 will probably work just fine. Now on the same machine, fire up a web browser and open up the following url: http://localhost:5400/ Now you can browse the entire FG property tree "live" and even change values if you like. You can configure autopilot modes and even set control inputs so you can literally fly the airplane from your web browser, although it's not the most convenient interface for doing that. ;-) There is a similar interface minus the html wrappings that you can enable with the following option: --props=5401 Note that you can setup as many of these as you want ... for instance, just to be obscene you could do: --httpd=5400 --httpd=5401 --httpd=5402 --props=5403 --props=5404 --props=5405 Now you have 6 different network interfaces running that you can access from anywhere. [Note: security issues if not used wisely.] If you have a 'props' inteface configured you can now "telnet localhost 5401" and interact with the property system (again live) and set and examine values using a 'command line' style interface. The cool thing is that you can easily write scripts to access this --props=<port#> interface. Take a look at: FlightGear/source/scripts/perl/examples/ Note that there is no requirement that you do this with perl. You could just as easily interact with FlightGear this way using perl, C, C++, java, probably even <ack> visual basic or anything else that can do tcpip network communication ... matlab? netcat? Also note that the downside to this interface is that you can't blast a lot of data across it. It's fine if you want to monitor location and speed every second or 1/4 second and occasionally set some values (such as dump in a new weather configuration, reset the aircraft location, or read a set of values, etc.) But if you need to track 100 different variables at 60hz, this isn't the interface for you. Best regards, Curt. -- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Paul S. <su...@te...> - 2005-12-30 21:56:15
|
On Friday 30 December 2005 23:41, Curtis L. Olson wrote: > For instance, start FlightGear with the following option: > > --httpd=5400 Yeah, I knew about that one although last time I tried a lot of the properties seemed to be read only. > There is a similar interface minus the html wrappings that you can > enable with the following option: > > --props=5401 Now this one is real handy one I didn't know about it. > Also note that the downside to this interface is that you can't blast a > lot of data across it. It's fine if you want to monitor location and > speed every second or 1/4 second and occasionally set some values (such > as dump in a new weather configuration, reset the aircraft location, or > read a set of values, etc.) That's more or less what I want to do. Just a few variables every second or so to see if the trainee is obeying instructions. :) > But if you need to track 100 different variables at 60hz, this isn't the > interface for you. Yeah but I'm not sure nasal would be the solution at that sort of speed either. My biggest concerns are : 1. Sound mixing from two separate apps (not a real problem in Windows since it does software mixing by default but more of a problem for the *nix guys) 2. The user having to download and install the Python or Perl libraries separately. Maybe a separate C++ app would be a better idea. 3. Modifying fgrun to make things launch together. Paul |
From: Georg V. <hel...@ar...> - 2005-12-30 22:56:08
|
Hi Paul, your idea is really great! :-) But as you seem to recognize yourself, every separate application has to be very simple to use and *install* as the group of people you are aiming to probably will also be a group of people not very professional with their O/S. *nix people will always think of only Windows user to have problems with such stuff, but as Linux has changed and migrated to a GUI system with Gnome and KDE (which got me to now setting up a 100 GB Open Suse 10.0 Linux system :-) ) I found that there are a lot of Linux users nowadays who do have only minor knowledge (when looking into German Linux forums). I personally like Python as it was "Nasal for FLY! II" and it is very easy to install and run on Win systems, but you have to install the whole stuff - a real "problem" for some FLY!ers :-/. So a *.exe would be the most comfortable and clean solution after my opinion, looking at it from the "newbe" user side. Anyway, a big step forward for FlightGear! Regards Georg EDDW Paul Surgeon schrieb: >... > > >My biggest concerns are : >1. Sound mixing from two separate apps (not a real problem in Windows since it >does software mixing by default but more of a problem for the *nix guys) >2. The user having to download and install the Python or Perl libraries >separately. Maybe a separate C++ app would be a better idea. >3. Modifying fgrun to make things launch together. > >Paul > > |
From: Ampere K. H. <amp...@sy...> - 2005-12-31 03:58:38
|
On December 30, 2005 04:57 pm, Paul Surgeon wrote: > 2. The user having to download and install the Python or Perl libraries > separately. Maybe a separate C++ app would be a better idea. Bad idea, unless you like doing more work! Remember, FlightGear can be run on different platforms. Your C++ application would need to be just as flexible. Ampere |
From: Isao Y. <iss...@ya...> - 2005-12-31 03:26:28
|
Wow... That's really neat, and that's what I have been trying to figure out for a long time ! FG's manuals are spread to many places on the net, and there's only one or two pages on the subject, so I just got tired of digging this kind of info out. BTW, so how should I go about when I need to track 100 different variables at 60hz ? Isao "Curtis L. Olson" <cur...@fl...> wrote: Paul Surgeon wrote: >Hmmm ... I didn't know that the network interface was that flexible. >So I can read and write any properties in the property tree from an external >app? > >Playing sounds from an external app (which is an absolutely neccessary for >what I want to do) would be a problem for some people who's sound cards don't >do hardware mixing. I assume playing sounds from nasal would get mixed inside >FG's openal setup? > > I keep thinking that someday I should pen a book ... 101 tricky things you can do with flightgear. For instance, start FlightGear with the following option: --httpd=5400 You can pick any port number, but 5400 will probably work just fine. Now on the same machine, fire up a web browser and open up the following url: http://localhost:5400/ Now you can browse the entire FG property tree "live" and even change values if you like. You can configure autopilot modes and even set control inputs so you can literally fly the airplane from your web browser, although it's not the most convenient interface for doing that. ;-) There is a similar interface minus the html wrappings that you can enable with the following option: --props=5401 Note that you can setup as many of these as you want ... for instance, just to be obscene you could do: --httpd=5400 --httpd=5401 --httpd=5402 --props=5403 --props=5404 --props=5405 Now you have 6 different network interfaces running that you can access from anywhere. [Note: security issues if not used wisely.] If you have a 'props' inteface configured you can now "telnet localhost 5401" and interact with the property system (again live) and set and examine values using a 'command line' style interface. The cool thing is that you can easily write scripts to access this --props= interface. Take a look at: FlightGear/source/scripts/perl/examples/ Note that there is no requirement that you do this with perl. You could just as easily interact with FlightGear this way using perl, C, C++, java, probably even visual basic or anything else that can do tcpip network communication ... matlab? netcat? Also note that the downside to this interface is that you can't blast a lot of data across it. It's fine if you want to monitor location and speed every second or 1/4 second and occasionally set some values (such as dump in a new weather configuration, reset the aircraft location, or read a set of values, etc.) But if you need to track 100 different variables at 60hz, this isn't the interface for you. Best regards, Curt. |
From: Roy V. O. <roy...@bl...> - 2005-12-30 21:52:53
|
On Friday 30 December 2005 22:25, Paul Surgeon wrote: > Hmmm ... I didn't know that the network interface was that flexible. > So I can read and write any properties in the property tree from an > external app? Yes, with the telnet interface you can. There are examples in source/scripts. > Playing sounds from an external app (which is an absolutely neccessary for > what I want to do) would be a problem for some people who's sound cards > don't do hardware mixing. I assume playing sounds from nasal would get > mixed inside FG's openal setup? Yes, but AFAIK you would have to define the sounds as sound effects that react to certain properties, in an xml file, just like c172-sound.xml. And that could become ugly very fast. :-( I also think that they have to be wav files and that could become very large very fast. -- Roy Vegard Ovesen |
From: Paul S. <su...@te...> - 2005-12-30 20:54:05
|
On Friday 30 December 2005 21:37, Paul Surgeon wrote: > Would anyone object if I tied nasal code specific to scenarios into FG > aircraft? Please ignore that question. Roy Vegard pointed out that I can load nasal scripts with --prop instead which is a much cleaner way of doing it. Paul |
From: Melchior F. <mf...@ao...> - 2006-01-01 08:44:49
|
On Fri, Dec 30, 2005 at 03:41:21PM -0600, Curtis L. Olson wrote: > --props=5401 In real life it's called --telnet IIRC. :-) m. |
From: Arnt K. <ar...@c2...> - 2006-01-01 17:59:47
|
On Sun, 1 Jan 2006 09:44:27 +0100, Melchior wrote in message <200...@lo...>: > On Fri, Dec 30, 2005 at 03:41:21PM -0600, Curtis L. Olson wrote: > > --props=5401 > > In real life it's called --telnet IIRC. :-) ..sounds like a way to crew aircraft like the B52, B 29 etc. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. |