hello world,i've made this perl script plandevol to easyly find a route between to points in the flightgear world. the goal was to make a very light single-file script to make flightplan. off course, the route created *is not real*, it's only a mean to know how to reach a point with flightgear. it's used by command-line in a terminal, all options are explained in the help (recheable by typing ./plandevol -h).about some facilities?- compatible with all actual versions of nav.dat files (thanks mfranz to report this bug quite a month ago)- data files (nav.dat, fix.dat, ...)can be gziped or not- SID/STAR procedures included (if asked and avalaible), thanks for the xpgoodway team to let use their sid.dat and star.dat files released on the xpgoodway.com site (downloads->navigation files)- print some interesting COM info for departure and arrival airports- if nav.dat version > 6.00, the script take care about the range of navaids- it's possible to save the flight plan in files: csv for printing plots, or list of waypoints usable by fgfs with the --flight-plan=file option. soon in xml format for using with a nasal script (module not yet released, because not fonctionnal).the script doesn't care about fuel consumption, or ete/eta. another script (ballade) is useful to know the available airports in a given range around the place you start your next launch of fgfs, and give infos about SID/STAR procedure, distance, direction and elevation. it could be used with plandevol (automatically proposed if the script is present). type ./ballade -h for help about all the options.sure , you need perl installed and you need to change config parameters inside the script (path to files, marked by $EXAMPLEFILE, in # CONFIGURATION section, at the head of the script). the scripts have been tested only under linux.obviously, these two scripts are only in french right now... (something like 20Kb of comments need some time to be translated by a bad-english speaker like me ;)) you'll be informed when the english versions will be releasedanyway, maybe they could be useful for someone else than me ;)bye

> http://seb.marque.free.fr/fichiers/scripts/perl/plandevolHi, this is pretty neat!You may want to consider making it available under the GPL (add a corresponding header to the script) so that it can be officially included in the $FG_SRC /contrib or /scripts directory.So that it might eventually serve as inspiration,i.e. to implement similar functionality in FlightGear directly, using the integrated scripting language Nasal.

hello,>You may want to consider making it available under the GPL>(add a corresponding header to the script) yes, in my mind for sure this script is under GPL. but my mind is not a legal affair... I'll add the GPL header in the following next minutes>so that it can be officially included in the $FG_SRC /contrib or >/scripts directory.I would be very proud of it ;), I'm taking some of my time right now to translate comments, so non-french speakers could understand the code, and so modify it in an easier way, and I explain too how the route plan is written in memory so it can be used by other "modules" easily.>So that it might eventually serve as inspiration,i.e. to>implement similar functionality in FlightGear directly, using>the integrated scripting language Nasal.yes, i'm equally trying to translate from perl to nasal this script, actually i'm reading the nasal page, and i am finishing another nasal script (named plandevol.nas) used for reading xml flightplans created by the perl script.I've got some other projects (in perl cause I really like it):- a script to create some problems to aircraft using telnet, so properties could be changed from an "instructor" to a "student", as weather conditions, losing fuel, bad information given by instrument, battery or magnetos or alternator failure, etc.- a script to create from an other flight sim AI flights (if they are under GPL off course), and random traffic.- a script for changing smoothly the weather conditions, using metar informations (using gradients) or created weather scenarios- make the electrical system on the C172 more complex (using nas script and xml) the beginnig of the project is here in frenchall of them would take some time, but you'll be informed as soon as they are usable (or before if you are interested ;)).

While adding a GPL header and some English comments would certainly help, I am not sure how many regular FlightGear developers actually check back with forums such as these, so you might want to simply send your script to the developer's mailing list or maybe even directly to one of the developers with CVS access, to ensure that the team is made aware of your contribution.Also, you could probably avoid most of the customization requirements ($NAVFILE,FIXFILE,APTFILE etc.) by simply using $FG_ROOT as reference, regardless of whether it is actually defined or not, it should be much easier to simply have the script use $FG_ROOT as basis?If it isn't set properly, there could still be the option to pass the correct path manually (as is done via fgfs --fg-root=/xxx/xxx/xx).

> yes, i'm equally trying to translate from perl to nasal this script, Actually, I don't think this should be too hard: while Perl is definitely very powerful and useful, it is hardly necessary to use it in order to implement a relatively simple idea because FlightGear's integrated scripting language should be perfectly sufficient. In addition, having the script written in Perl adds a non-trivial dependency for many non-*nix users, most of whom are not even familiar or comfortable with a console environment.Apart from that, most of the difficult and complex stuff (i.e. parsing) is already done in FlightGear anyway.Likewise, the corresponding databases are also kept in memory all the time currently, so you can access them at runtime whenever you want (no need to have a separate process parse and browse the same dataset that is likely to be already loaded in RAM).Also, having this functionality directly available in FlightGear would definitely be useful and many users would probably find it much easier to actually use your script this way. And then there would also be the possibility to provide a XML-GUI dialog for the script to make usage easier. Basically, making it a native part of FlightGear would also ensure that it will be maintained in the future and would also make much of your current glue code unnecessary.I think, pretty much everything you would need is already in place in FlightGear, most of which is also accessible via Nasal. While there are however currently no Nasal wrappers for the nav/apt/awy/fix databases, these would be pretty trivial to add (and probably also pretty useful in the long run for other purposes!).I am not sure if you are proficient in C/C++ (STL) and familiar with the FG code base, but basically it would boil down to checking out $FG_SRC/Navaids, where you can find the C++ code that is currently used to make the databases available within FlightGear. Most entries that are of interest for your purposes are stored in FGNavRecord instances, see $FG_SRC/Navaids/navrecord.hxx for details (members & methods). Basically, there are various different lists maintained (in a vector/map) that contain entries of type FGNavRecord*. So, you end up with one list for airports, runways, navaids, fixes etc.At runtime, these databases are available to arbitrary functions/methods by using the "globals" pointer (check $FG_SRC/Main/globals.[c/h]xx): most of the relevant methods return a FGNavList* (see $FG_SRC/Navaids/navlist.[c/h]xx). So, of the top of my head, you could obtain a handle to the data by doing something like:FGNavList* apt = globals->get_airports(); FGNavList* rwy = globals->get_runways(); FGNavList* nav = globals->get_navlist(); FGNavList* dme = globals->get_dmelist(); So, working with the corresponding data would come down to:- iterating through the corresponding list- taking each individual FGNavRecord entry- and dealing with its member values (ID,name,freq,position etc. as defined in $FG_SRC/Navaids/navrecord.hxx)If you aren't quite sure how to go about this, you can find plenty of examples by simply grep'ing through $FG_SRC for "globals->get_airports()", "globals->get_runways" etc. respectively (usually, whenever such calls are made, you can expect related code to be close).For example, in order to look up all navaids that have "SFO" as identifier and "115.8" as frequency, you would want to iterate through all navaids in the navlist and search each individual FGNavRecord using the get_ident() or get_freq() (FGNavRecord) methods respectively-so that you can compare the current entry against your query.The next step would probably be to add corresponding functions to the Nasal interpreter itself, so that you can actually deal with the corresponding databases from a Nasal script.Adding new Nasal functions to the interpreter is basically also pretty straight forward, you will probably want to check out some of the simpler Nasal functions defined in $FG_SRC/Scripting/NasalSys.[c/h]xx. Basically, you could simply copy/paste an existing function such as f_rand(...) and rename it to "f_test(...), afterwards you merely have to add the function to the static funcs struct (together with a nasal name), so that the interpreter knows about it. (Recently, there was also a discussion on FlightGear-Devel about this: http://sourceforge.net/mailarchive/forum.p...2&forum_id=1919 )This would probably also be useful because some of the maths functions you are using in your perl scripts, are simply not yet available in Nasal, so you could simply wrap the ANSI C functions as a Nasal function and insert them into the "math" module ("namespace" that is, see $SG_SRC/nasal/mathlib.c)Of course, there would be the possibility to simply do all calculations in C/C++ and use Nasal merely to trigger the extension functions, however while this would add some marginal performance gain, I don't think these calculations are too much to handle for a script (also, we are not talking of something that needs to be called many times per second or even per frame).

> actually i'm reading the http://plausible.org/nasal/ nasal pageConcerning Nasal coding itself, apart from that webpage, there is currently not really that much documentation available. Also, the Nasal webpage isn't that current either, there are quite a lot of recent Nasal additions that are still undocumented, likewise the majority of FlightGear-specific extension functions that are only available in FlightGear's Nasal interpreter are practically undocumented.So, currently the most reliable sources for Nasal information would definitely be:a) the FlightGear source tree ($FG_SRC/Nasal) for Nasal extension functions:( the FlightGear base package ($FG_ROOT/Nasal) for code examples and c) the devel mailing listIf you search the mailing list, you can actually find quite a lot of helpful Nasal related discussions that somehow never made it into the base package documentation. Nevertheless, with your Perl background you should find it pretty easy to get started in Nasal.Another thing to watch out for, is NOT to use the standalone Nasal interpreter available at plausible.org too excessively, while it was initially a pretty handy tool (especially for those people who prefer to code (and test their code) without having to run/restart FlightGear permanently), it hasn't been updated for quite a while now. And thus, it simply doesn't reflect the status of the FlightGear-Nasal interpreter anymore properly, some might even say it would encourage "bad Nasal programming" because it doesn't support certain features (such as named function arguments) that have been available in FlightGear's Nasal interpreter long enough to be meanwhile considered "standard" (eventually, it might be a good idea to simply provide a standalone Nasal interpreter that's directly based on the Nasal interpreter in SimGear, maybe even with its own property tree?).

hi hfitz,such a response ;) and you answered me before i ask the questions, thank you very much!as i re-discorered coding pleasure with the perl examples from FG_SRC something like 6 months ago, i was like a child discovering a new wonderful world. and this week-end i've looked inside the code, and... whaou! definitely an other wonderful world with very nice function names as FindClosest, get_airports, and so on!As I was used to "code" in Borland C/C++ ten years ago, i'm understanding quite everything the code is telling to me. great fun for next monthes!thanks again!

You mentioned a couple of other things in your postings that are currently not directly possible in Nasal, and which would thus require some additional minor extension functions: File I/O is one of the areas that are currently not supported by Nasal itself.The workaround for the Nasal interpreter integrated in FlightGear, is to use FlightGear's integrated fgcommand interface to deal with XML files (check $FG_ROOT/Nasal for examples).While this is powerful enough to deal with most FlightGear specific XML files (PropertyLists), it is however not particularly flexible and imposes various restrictions on the way you can read/write data (basically, everything you write or read needs to pass through the property tree, thus you are also restricted to the (pretty verbose) PropertyList format that supports the use of XML attributes only for internal purposes, so any relevant tag attributes need to be implemented as child tags (sub tags)).Depending on whether you intend to deal with plain text files or really parse XML files in Nasal, you may want to wrap fopen(),fwrite() etc. or SimGear's XML routines that you find under $SG_SRC/xml/easyxml.[c/hxx].On the other hand, I think various developers have also indicated a strong interest in providing the Nasal interpreter with file I/O cababilities in the long run, so maybe this limitation will vanish rather soon without you having to implement this yourself.However, as long as you don't need to do anything fancy, FlightGear's integrated XML support should be sufficient most of the time.