Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 09:05, Chris Metzler wrote: Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), There is no electrical output to power the nav radio. Apply this patch to fix it: Index: c310-electrical.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c310/c310-electrical.xml,v retrieving revision 1.8 diff -p -u -r1.8 c310-electrical.xml --- c310-electrical.xml 22 Apr 2004 14:54:34 - 1.8 +++ c310-electrical.xml 12 Dec 2004 10:53:03 - @@ -144,6 +144,11 @@ prop/systems/electrical/outputs/gps/prop /output + output +nameNav Radio Power/name +prop/systems/electrical/outputs/nav/prop + /output + !-- connect in power sources -- connector @@ -317,4 +322,12 @@ /switch /connector + connector +inputBus Bar/input +outputNav Radio Power/output +switch + prop/controls/circuit-breakers/nav/prop +/switch + /connector + /PropertyList What puzzles me is that there was never a navcom output in the c310 electrical config, so how did it work before?? the pa28-161, I tried the pa28-161 and it seemed to work fine. and the beech99. The same problem as for the c310. The same patch can be applied to the beech99-electrical.xml file. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, turn, airspeed, ai) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
On Sun, 12 Dec 2004 04:33:04 +0100, Arnt wrote in message [EMAIL PROTECTED]: On Thu, 09 Dec 2004 10:14:11 -0600, Curtis wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: You can definitely do that. Just list the 0.9.7 tree first in your --fg-scenery path, i.e.: --fg-scenery=/stage/fgfs04/curt/Scenery-0.9.7;/stage/fgfs04/curt/Sc en ery-0.9.5 ..semicolon is the path separator? These are absolute paths, or relative to $FG-ROOT??? You may see odd cracks at the borders between 0.9.7 and 0.9.5 scenery but I suspect they would be fairly minor. ..naaah, just a coupla big drinks. Unless you goofed or changed the scenery path syntax recently, I tried various variants of this: fgfs --geometry=1280x1024--fov=75--httpd= --telnet=23 \ --start-date-lat=2004:12:11:12:00:00--airport=ENZV --runway=36 \ --fg-scenery=:/mnt/hdc5/FlightGearScenery/pub/fgfs/Scenery-0.9.5 \ --prop:draw-fps=1 ..no scenery at ENZV, KOSH or KSFO, and I do have the whole 0.9.5 planet. Nor could I get the fps from the command line, I had to use the menus in either the gui or the web server. Flying over the drink get's me 4 to 5 fps, over the Bay area Terraserver scenery, I see 1 fps, and that's flyable, even from the web server in the default C172. ;-) ..except for the $FG-ROOT dependant variety; duh! -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 12:22, Roy Vegard Ovesen wrote: On Sunday 12 December 2004 09:05, Chris Metzler wrote: Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), There is no electrical output to power the nav radio. Apply this patch to fix it: Index: c310-electrical.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c310/c310-electrical.xml,v retrieving revision 1.8 diff -p -u -r1.8 c310-electrical.xml --- c310-electrical.xml 22 Apr 2004 14:54:34 - 1.8 +++ c310-electrical.xml 12 Dec 2004 10:53:03 - @@ -144,6 +144,11 @@ prop/systems/electrical/outputs/gps/prop /output + output +nameNav Radio Power/name +prop/systems/electrical/outputs/nav/prop + /output + !-- connect in power sources -- connector @@ -317,4 +322,12 @@ /switch /connector + connector +inputBus Bar/input +outputNav Radio Power/output +switch + prop/controls/circuit-breakers/nav/prop +/switch + /connector + /PropertyList What puzzles me is that there was never a navcom output in the c310 electrical config, so how did it work before?? the pa28-161, I tried the pa28-161 and it seemed to work fine. and the beech99. The same problem as for the c310. The same patch can be applied to the beech99-electrical.xml file. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, turn, airspeed, ai) Someone might want to commit these patches to CVS. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] World scenery rebuild
On Sat, 04 Dec 2004 19:17:30 -0600, Curtis wrote in message [EMAIL PROTECTED]: You can track and download the latest world scenery rebuild graphically here: http://www.flightgear.org/Downloads/scenery-0.9.7.html ..I know green boxes are built and red not, but I also see orange boxes in the map, what are these orange boxes for? 0.9.5-ok-as-is-4-0.9.7, or rebuilt 0.9.7 or cvs??? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
On Sunday 12 December 2004 04:33, Arnt Karlsen wrote: ..naaah, just a coupla big drinks. Unless you goofed or changed the scenery path syntax recently, I tried various variants of this: fgfs --geometry=1280x1024--fov=75--httpd= --telnet=23 \ --start-date-lat=2004:12:11:12:00:00--airport=ENZV --runway=36 \ --fg-scenery=:/mnt/hdc5/FlightGearScenery/pub/fgfs/Scenery-0.9.5 \ --prop:draw-fps=1 ..no scenery at ENZV, KOSH or KSFO, and I do have the whole 0.9.5 planet. Nor could I get the fps from the command line, I had to use the menus in either the gui or the web server. The draw-fps property is supposed to be located in /sim/hud/, so your command line should read: --prop:/sim/hud/draw-fps=1 -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: NAV radios still borked on three a/c
* Roy Vegard Ovesen -- Sunday 12 December 2004 12:44: Someone might want to commit these patches to CVS. ... and add some that make DME work again, which does not work at least in the 737 and the c310. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sun, 12 Dec 2004 12:22:35 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: On Sunday 12 December 2004 09:05, Chris Metzler wrote: the pa28-161, I tried the pa28-161 and it seemed to work fine. Really? I just checked it again, and both NAV1 and NAV2 are dead for me. I'm running CVS, current as of last night. and the beech99. [ snip ] Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. Hmmm... I just tried it, and all gauges seemed to work fine (alt, vs, turn, airspeed, ai) The gauge that was messed up for me in particular was the artificial horizon; it was starting out tumbled, and wasn't resetting after a few seconds. But I just tried it again, and it came up OK. So I dunno. Thanks. -c P.S. The patch for C310/beech99 worked just fine. -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpXbiY0qxkOY.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NAV radios still borked on three a/c
On Sunday 12 December 2004 14:02, Melchior FRANZ wrote: Thanks! We do not forget over those minor complaints how valuable and well done your instrument reorganization is! :-) Such words warm my heart, and give me inspiration, thanks! I welcome every minor and major complaint. They help us improve FlightGear. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NAV radios still borked on three a/c
On Sunday 12 December 2004 13:32, Chris Metzler wrote: I tried the pa28-161 and it seemed to work fine. Really? I just checked it again, and both NAV1 and NAV2 are dead for me. I'm running CVS, current as of last night. First thing to note is that both gauges of the pa28-161 are connected to the same nav radio. So they will always display the same values. And since they are 3d models, you can't click them with the mouse to change the OBS. You have to use the Radio settings dialog from the Equipment menu. Try to browse the property tree to /instrumentation/nav/radials. If the values here seem correct then at least the module (the c++ code) is working and is serviceable. If not then either the serviceable property is not set or the navradio does not get power. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] World scenery rebuild
Arnt Karlsen wrote: ..I know green boxes are built and red not, but I also see orange boxes in the map, what are these orange boxes for? 0.9.5-ok-as-is-4-0.9.7, or rebuilt 0.9.7 or cvs??? Right now just assume a box means the area is built. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
On Sun, 12 Dec 2004 13:16:45 +0100, Roy wrote in message [EMAIL PROTECTED]: On Sunday 12 December 2004 04:33, Arnt Karlsen wrote: ..naaah, just a coupla big drinks. Unless you goofed or changed the scenery path syntax recently, I tried various variants of this: fgfs --geometry=1280x1024--fov=75--httpd= --telnet=23 \ --start-date-lat=2004:12:11:12:00:00--airport=ENZV --runway=36 \ --fg-scenery=:/mnt/hdc5/FlightGearScenery/pub/fgfs/Scenery-0.9.5 \ --prop:draw-fps=1 ..no scenery at ENZV, KOSH or KSFO, and I do have the whole 0.9.5 planet. Nor could I get the fps from the command line, I had to use the menus in either the gui or the web server. The draw-fps property is supposed to be located in /sim/hud/, so your command line should read: --prop:/sim/hud/draw-fps=1 ..thanks, and I see a symlink should fix my big drink sceneries. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] basic.dat : Airport database update
Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. I'd prefer to keep the contents of $fg_root/data read only, or at least not have the app modify anything in there. I think this should be handled some other external way. How would his field be updated for the average user? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On 12/12/04 at 6:00 PM Paul Surgeon wrote: On Sunday, 12 December 2004 17:32, Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul Please disregard - Melchior pointed out quite correctly that user data should not be stored in CVS files. Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: basic.dat : Airport database update
* David Luff -- Sunday 12 December 2004 18:14: Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. Rough estimation: $ time find $FG_ROOT/WorldScenery /dev/null real5m2.778s user0m1.184s sys 0m4.976s $ time find $FG_ROOT/Scenery /dev/null real0m0.187s user0m0.002s sys 0m0.005s m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 19:14, David Luff wrote: Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Actually I would provide the unavailable airports but if the user selects one that is not installed inform them of the issue as well as tell them which scenery file to download in order to get the airport. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. I would make it a manual process to start with and store the data between sessions. The user can click on a button to rebuild the list if they add scenery. This can all be done from inside the airport dialog which means that there is zero performance penalty until someone tries to use the feature. However I will investigate the performance impact of an auto update based on file timestamps and if it's feasible for 12GB of data suggest it. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. That would be nice although we don't store that info yet. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] User home
On Sunday, 12 December 2004 19:29, Paul Surgeon wrote: What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. After chatting with Melchior a bit : Can I add a FG-HOME environment variable in case HOME does not exist? The order of preference will be : 1. FG_HOME 2. HOME 3. ./ For *nix options 1,2,3 will work For Windoze options 1,3 will work Option 2 does not work for Windoze unless using Cygwin. (according to fg_init.cxx) Option 2 will work on Winbloze. I was looking at .fgfsrc.hostname Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
An alternative solution would be to run terrasync in the background. Ampere On December 12, 2004 12:14 pm, David Luff wrote: Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] User home
On 12/12/04 at 7:52 PM Paul Surgeon wrote: On Sunday, 12 December 2004 19:29, Paul Surgeon wrote: What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. I personally think that if you can get fgfs to save and restore settings set through the menu system in a cross-platform way that that would be bl*%dy excellent, and extremely useful. It is, after all, normal behaviour for the vast majority of programs. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 20:23, Ampere K. Hardraade wrote: An alternative solution would be to run terrasync in the background. Ampere Terrsync works great for people with dialup connections who pay by the minute ... :-\ I have to connect at off peak times to get cheaper rates and 64K ISDN is not fast enough when flying at 400kts. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear mailing list gone?
I can't find the SimGear maling list details on SimGear.org or FlightGear.org but they used to be there. I can only find SimGear-CVSLogs. What happened and where can I ask SimGear related questions? Was the list taken down? Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Was : SimGear mailing list gone
On Sunday, 12 December 2004 22:22, Paul Surgeon wrote: I can't find the SimGear maling list details on SimGear.org or FlightGear.org but they used to be there. I can only find SimGear-CVSLogs. What happened and where can I ask SimGear related questions? Was the list taken down? Thanks Paul Seems like I was wrong (for the nth time today). What I wanted to ask was : Can I add mkdir and rmdir functionality to SGPath? I can't think of a more logical location where all the path handling is done and it does fall under the misc catagory in my opinion. Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] User home
Paul Surgeon wrote: What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. After chatting with Melchior a bit : Can I add a FG-HOME environment variable in case HOME does not exist? The order of preference will be : 1. FG_HOME 2. HOME 3. ./ Paul, We already have FG_ROOT which I think is essentially what you intend for FG_HOME Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: User home
* Curtis L. Olson -- Sunday 12 December 2004 22:08: We already have FG_ROOT which I think is essentially what you intend for FG_HOME No. Paul wants to store user specific information. Users cannot write to FG_ROOT. It's not owned by the fgfs user and may not even be mounted RW. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Sun, 12 Dec 2004 10:36:19 +1100, Nick Coleman [EMAIL PROTECTED] wrote: I must have missed it, sorry about that. Oh yeah, 2 months ago was exam time, I stopped reading the list for a few weeks. No harm done. We're all unhappy, of course, but it's hard for non-Americans like me to complain too much -- the U.S. is removing information about our countries that our own governments never made freely available in the first place. The FAA database is still available for the U.S., but other governments (like mine) do not make their aero data available freely at all, and we've been lucky that the U.S. has made data for Canada, Europe, Asia, etc. available. It's so bad that the Garmin 296 GPS (which displays terrain and manmade obstructions) does not even display towers in Canada, because the Canadian government wanted royalties for every Garmin unit sold (!!!). The real solution to this problem is to come up with a worldwide, peer-reviewed open-source aero database, for use both by the simulation community and by the aviation community. That's an enormous undertaking, of course. Originally, the excuse for pulling DAFIF was the Australian government's attempt to sue Jeppesen for royalties on Australian aero data, or something similar. Now, the reason is simply national security. I wonder if the Australian thing died out, or if it was just easier to use the security boilerplate than to get into the complex legal details. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: User home
Melchior FRANZ wrote: * Curtis L. Olson -- Sunday 12 December 2004 22:08: We already have FG_ROOT which I think is essentially what you intend for FG_HOME No. Paul wants to store user specific information. Users cannot write to FG_ROOT. It's not owned by the fgfs user and may not even be mounted RW. IMO this should be discussed very carefully before proceeding. What data do we want to write out? What section of the code will do the writing. I'm not opposed to using a ~/.fgfs/ directory. Perhaps we should have a ~/.fgfs/settings.xml file instead of a ~/.fgfsrc, if we wanted to make this writable, then perhaps the first time FG is run, it would create this directory and copy in a default template file. We would also want to have a restore defaults option available. But to really do this, we would probably want a more consistent/coherent way to set options within FG ... perhaps we could start to move some fgrun functionality (the part the sets various options inside FG.) We should probably look at sorting/grouping the options a bit more and pehaps explaining them a bit more. This would be a very large gui task ... but certainly would be nice to have. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] User home
On Sunday 12 December 2004 18:29, Paul Surgeon wrote: What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. I would prefer a folder called ~/.flightgear instead of ~/.fgfs. This is an usability issue because a folder that is called ~./fgfs is in my opinion too meaningless for the ordinary user. When we call it ~/.flightgear everyone will know what it is all about. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Sun, 12 Dec 2004 16:34:19 -0500 David Megginson [EMAIL PROTECTED] wrote: Originally, the excuse for pulling DAFIF was the Australian government's attempt to sue Jeppesen for royalties on Australian aero data, or something similar. Now, the reason is simply national security. I wonder if the Australian thing died out, or if it was just easier to use the security boilerplate than to get into the complex legal details. I'd bet the latter -- I suspect the national security-ish lines in the FR entry are in there only because every decision the Federal government makes anymore gets some kind of national security justification. What I didn't see was some kind of notification about an official comment period. Normally, when a policy change takes place, the first announcement in the FR mentions a period during which comments can be made. I didn't see that in there. This is significant in that comments made in response to policy changes like this actually do matter. I had breakfast yesterday with two senior executives in the Federal bureaucracy (both GS 15 or higher) who were very emphatic that commenting during the comments period is worthwhile: in subsequently making their decision official or in changing it to something else, the agency in question *must* substantively address the comments received. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpnsNQmBlsEr.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Curtis Olson wrote: Let us know what you come up with on the broadcast stuff. Regards, Curt. Okay, here's the answer... In plib line #80 if (host[0] == '' strcmp(host, broadcast) == 0) sin_addr = INADDR_BROADCAST; expects the string argument as noted above. There does not appear to be any option to set the address expicitly, as in 192.168.2.255, which results in an error and program termination. SimGear expects the string argument to be broadcast and passes that on to plib. If you try to set the string in the command option; e.g. native-fdm=socket,32,broadcast,6000,udp then FG/SimGear complains and exits. So the fix can be in either place, change SimGear to pass the string as required or change plib to if ( strcmp(host, broadcast) ==0) you make the call Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Sun, 12 Dec 2004 19:03:58 -0500, Chris wrote in message [EMAIL PROTECTED]: What I didn't see was some kind of notification about an official comment period. Normally, when a policy change takes place, the first announcement in the FR mentions a period during which comments can be made. I didn't see that in there. This is significant in that comments made in response to policy changes like this actually do matter. I had breakfast yesterday with two senior executives in the Federal bureaucracy (both GS 15 or higher) who were very emphatic that commenting during the comments period is worthwhile: in subsequently making their decision official or in changing it to something else, the agency in question *must* substantively address the comments received. ..one way is point .gov and .com people to if someone flies into an Aussiestani or Canuckistani tower, is it jihad, and who get's sued? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NAV radios still borked on three a/c
Hi. From the CVS logs, it looks like a whole lot of radios/instrumentation changes went through last week to finish the transition (and thus fix the NAV radio problems). I just went through and manually checked all the a/c which have relevant gauges, and found that the c172 and 737 and so on all work; but three planes still have broken NAV radios: the c310 (and its children), the pa28-161, and the beech99. Lots of things don't work about the latter, including various gauges, so the problem may be something other than this transition. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpo7UAUWciGe.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
Arnt Karlsen wrote: On Thu, 09 Dec 2004 10:14:11 -0600, Curtis wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: You can definitely do that. Just list the 0.9.7 tree first in your --fg-scenery path, i.e.: --fg-scenery=/stage/fgfs04/curt/Scenery-0.9.7;/stage/fgfs04/curt/Scen ery-0.9.5 ..semicolon is the path separator? These are absolute paths, or relative to $FG-ROOT??? You can assume everything that starts with a slash (or backslash on Windows) to be an absolute path - not just in FlightGear. The semicolon is the commonly used path separator on Unix, analogous to the colon on Windows, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 17:32, Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul Please disregard - Melchior pointed out quite correctly that user data should not be stored in CVS files. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] User home
What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. After chatting with Melchior a bit : Can I add a FG-HOME environment variable in case HOME does not exist? The order of preference will be : 1. FG_HOME 2. HOME 3. ./ For *nix options 1,2,3 will work For Windoze options 1,3 will work Option 2 does not work for Windoze unless using Cygwin. (according to fg_init.cxx) Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Was : SimGear mailing list gone
Paul Surgeon wrote: On Sunday, 12 December 2004 22:22, Paul Surgeon wrote: I can't find the SimGear maling list details on SimGear.org or FlightGear.org but they used to be there. I can only find SimGear-CVSLogs. What happened and where can I ask SimGear related questions? Was the list taken down? Thanks Paul Seems like I was wrong (for the nth time today). What I wanted to ask was : Can I add mkdir and rmdir functionality to SGPath? I can't think of a more logical location where all the path handling is done and it does fall under the misc catagory in my opinion. You might want to check first if plib has this functionality already, or putting it in plib's file/directory handling library might be more appropriate. The purpose of SGPath is to be a platform independent path name abstraction. If we create a mkdir function, I think it should probably go somewhere else. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
