Re: [Flightgear-devel] When can we have roads like this
Norman Vine wrote: The thing to remember is that PostGIS is just a normal PostGRES extension module so you still have the power of a general purpose relational DB to use. Correct, but the solution by referring from PostGIS shapes to BLOBs that contain the raster data is far not as smart as a 'native' storage method for geo-referenced raster data would be. I wonder (and I'l love to know because I assume there _is_ a strong reason) why the creators of the OpenGIS specs didn't cover raster data but only shapes (and their metadata) instead. That doesn't make sense to me because the need for a standard interface to raster data appears to be as urgent as the interface to vector data. Right ? If you'd agree to call PostGIS as sort of an implementation of shapefile in a database, the analogue geotiff in a database would be nice, too. To other spatially enabled database servers cover raster data as well ? 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] When can we have roads like this
Norman Vine wrote: Martin Spott writes: Norman Vine wrote: I would suggest adding them to a PostGIS database which when appropriately indexed has *quick* respones. http://postgis.refractions.net Is there a converter which generates SQL-scripts for PostGIS similar to 'shp2pgsql' ? see ogr2ogr utility that comes with GDAL to convert from tiger to shape Actually it looks as if ogr2ogr can now go directly from tiger to pgsql $ ogr2ogr Usage: ogr2ogr [-skipfailures] [-append] [-update] [-f format_name] [-select field_list] [-where restricted_where] [-spat xmin ymin xmax ymax] [-preserve_fid] [-fid FID] [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def] [[-dsco NAME=VALUE] ...] dst_datasource_name src_datasource_name [-lco NAME=VALUE] [-nln name] [-nlt type] layer [layer ...]] -f format_name: output file format name, possible values are: -f ESRI Shapefile -f TIGER -f S57 -f MapInfo File -f DGN -f Memory -f GML -f PostgreSQL If you have troubles ask over on the GDAL or PostGIS lists [EMAIL PROTECTED] [EMAIL PROTECTED] Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] When can we have roads like this
Norman Vine wrote: Actually it looks as if ogr2ogr can now go directly from tiger to pgsql Thanks for the hint - I'll start building GDAL right now, 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] When can we have roads like this
Martin Spott writes: Norman Vine wrote: The thing to remember is that PostGIS is just a normal PostGRES extension module so you still have the power of a general purpose relational DB to use. Correct, but the solution by referring from PostGIS shapes to BLOBs that contain the raster data is far not as smart as a 'native' storage method for geo-referenced raster data would be. I wonder (and I'l love to know because I assume there _is_ a strong reason) why the creators of the OpenGIS specs didn't cover raster data but only shapes (and their metadata) instead. That doesn't make sense to me because the need for a standard interface to raster data appears to be as urgent as the interface to vector data. Right ? If you'd agree to call PostGIS as sort of an implementation of shapefile in a database, the analogue geotiff in a database would be nice, too. To other spatially enabled database servers cover raster data as well ? This is a popular topic of discussion that is often answerd by (1) BLOB storage is inherently different then Table Storage (2) Reprojection of Raster Data is usually *much* more expensive then Vector data and isn't handled by any GIS enabled DB that I am currently aware of. ReProjection capability is a requirement, in fact sort of a definition of the OpenGIS spec. For reprojection one can use gdalwarp but I reccomend using OSSIM esp if one has access to a network or cluster or want an interactive tool instead of 'batch' mode only. I hope to have a lot more to say about networked Raster enabled GIS DataBases in a few months :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), 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] When can we have roads like this
Norman Vine wrote: (2) Reprojection of Raster Data is usually *much* more expensive then Vector data and isn't handled by any GIS enabled DB that I am currently aware of. Hmmm, how would any DB-based map-server do the job ? Simply by referring to BLOBs in the DB as you already described ? Is OSSIM developing into part of a common use, maybe sort of 'standard' approach. I hope to have a lot more to say about networked Raster enabled GIS DataBases in a few months :-) Oh, nice. Is there any chance to track your way which leads you to this goal ? 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] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Martin Spott wrote Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), I would think that a side effect of putting Nimitz in the scenery. Remember, YASim gear doesn't 'see' the deck right now. You will only get the proper effects by using a JBsim aircraft. Mathias is doing some work for YASim. But it's not ready yet. Try using it as it was designed, and you should see what I mean. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
* Vivian Meazza -- Tuesday 16 November 2004 18:06: Melchior FRANZ wrote: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 It should work just with the ai... /ai stuff in my earlier post. Yes. Changed that now. Mathias has put all the necessary stuff here: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ The code that he sent me works well, but I haven't tried it from that location yet. I applied all the stuff and it worked very well. My first carrier landing with the FA-18A succeeded already. The gear code is great! It's fun to taxi over slopes and actually see the aircraft follow them, rather than strangely sliding up with the nose gear below ground. And the FA-18 is very well done and has a nice cockpit with nice night lighting. The only problems I've encountered: * not really surprisingly, the carrier doesn't replay in replay mode. When I watched my landing in replay, the carrier had already moved along. Tricky to fix. * I observed one segfault that I hadn't seen before. The bt, however, didn't look like it had anything to do with the new code. I haven't saved the core file but will do so if I run into that problem again. Now I hope that I will soon be able to land the bo105 realistically on slight slopes ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Data/AInimitz_demo.xml, NONE, 1.1
Melchior FRANZ wrote Mathias has put all the necessary stuff here: ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ The code that he sent me works well, but I haven't tried it from that location yet. I applied all the stuff and it worked very well. My first carrier landing with the FA-18A succeeded already. The gear code is great! It's fun to taxi over slopes and actually see the aircraft follow them, rather than strangely sliding up with the nose gear below ground. And the FA-18 is very well done and has a nice cockpit with nice night lighting. The only problems I've encountered: * not really surprisingly, the carrier doesn't replay in replay mode. When I watched my landing in replay, the carrier had already moved along. Tricky to fix. This seems to be the case for all AI objects. Fixing it is certainly beyond me. * I observed one segfault that I hadn't seen before. The bt, however, didn't look like it had anything to do with the new code. I haven't saved the core file but will do so if I run into that problem again. This is a new fault, and may be related to the new code, but Erik reported a segfault as well, so any help you can give in running it down would be welcome. We have to solve the problem before the code can be committed to CVS. Now I hope that I will soon be able to land the bo105 realistically on slight slopes ... Mathias is working on it, but he's been diverted to real work for a while! We should be able to land the Hunter or Seahawk on Nimitz soonish, unrealistic but fun. Back to projector landing sights Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
This is probably unrelated, but with the 0.9.6 win32 binaries, if you start up with a large FOV (?90), then until you reset, 3d-cockpits are unusable. Giles Robertson -Original Message- From: Martin Spott [mailto:[EMAIL PROTECTED] Sent: 17 November 2004 09:29 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
Ampere K. Hardraade wrote: On November 16, 2004 09:56 pm, Curtis L. Olson wrote: Andy Ross wrote: Sure: http://plausible.org/nasal/flightgear.html This should probably move to the FlightGear site, I suppose. Ahhh, thanks for the url ... it's been too long since the last time I looked at nasal. I can copy it into the source/docs-mini/ directory. Looking through the webpages, I'm still having difficulties understanding how OOP is done on nasal. It's pretty straight-forward and there are even examples at plausible.org: http://www.plausible.org/nasal/sample.html - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Switching from 2D panel - 3D panel - 2D panel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)
Giles Robertson wrote: This is probably unrelated, but with the 0.9.6 win32 binaries, if you start up with a large FOV (?90), then until you reset, 3d-cockpits are unusable. I can confirm something that seems related: if I switch from 2D panel mode to 3D panel mode and use the mouse to change the perspective, I don't seem to be able to switch back to the 2D panel mode without having to reset the current 'situation' - tried it with different panels, seems to be a common problem. Can anybody else confirm that ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] local build problems with latest CVS
Building yesterday's CVS version, I get the following errors (clean checkout): -8---8---8---8---8---8---8---8---8---8---8---8-- ../../src/Main/libMain.a(fg_commands.o)(.bss+0x0):/usr/local/include/simgear/props/props.hxx:336: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0):/usr/local/include/simgear/threads/SGThread.hxx:129: first defined here ../../src/Main/libMain.a(fg_init.o)(.bss+0x0):/usr/local/include/simgear/structure/callback.hxx:35: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Aircraft/libAircraft.a(aircraft.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(cockpit.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(hud_ladr.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/hud.hxx:318: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(panel.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/stl_tree.h:288: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(panel_io.o)(.bss+0x0): In function `SGPropertyNode_ptr* std::__uninitialized_copy_aux__gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , SGPropertyNode_ptr*(__gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , __gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , SGPropertyNode_ptr*, __false_type)': /usr/local/include/c++/3.3/bits/stl_uninitialized.h:83: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/built_in/libBuilt_in.a(FGMagRibbon.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/built_in/FGMagRibbon.hxx:35: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/GUI/libGUI.a(gui_funcs.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/GUI/libGUI.a(mouse.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Input/libInput.a(input.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Model/libModel.a(panelnode.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 -8---8---8---8---8---8---8---8---8---8---8---8-- - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] local build problems with latest CVS
Boris Koenig wrote: Building yesterday's CVS version, I get the following errors (clean checkout): [...] Please disregard this for the moment, it seems to be building now - obviously I had to explicitly specify the other SimGear version (keeping different versions of FG, SimGear etc. around). Will report back when things are working (or not). Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Switching from 2D panel - 3D panel -2Dpanel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)
Curtis L. Olson wrote: Giles Robertson wrote: I think that's a result of the standard problem that if you move the view with the mouse in 2d panel mode, you can't see the panel, and it can be very difficult to get back to the original location; resetting resets the viewpoints back to normal, and the panel reappears. would it then be sufficient to reset the panel-location per default when switching back to 2D panel mode ? Do you get any actual graphical corruption (which is what I get - all triangles seem to be drawn to infinity - everything comes from a point at the centre of the screen) To be honest: I don't care for such problems anymore ;-) With the ATI Rage 128 that gives me a better framerate than my nvidia GeForce4 I keep seeing graphical corruption every now and then - but mostly it's either cockpit-specific (e.g. A320) or specific to certain environment settings, so I simply try to avoid using those features that seem to cause such problems. In mouse-pans-view mode, you can simply left-click to recenter the view, then you can get the 2d panel back. As it stands, the 2d panel isn't displayed when you pan the view. Thanks, I will try that - but I think it would make sense to recenter the view automatically when switching back to 2D mode ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw-0.2.3 released
I've put TaxiDraw-0.2.3 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. This is purely a bug-fix release - there is another version in the works with some more features. Changes from 0.2.2 to 0.2.3 are: * Heliports can now be loaded and saved in both X-Plane and FlightGear format. * A bug that could result in bogus tower viewpoints (code 14) being written during X-Plane format save or export has been fixed. * A bug that could result in displaced-threshold or stopway lengths being shortened by a foot has been fixed (thanks to Martin Spott for finding this). 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] TaxiDraw-0.2.3 released
David Luff wrote: I've put TaxiDraw-0.2.3 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. IRIX binary is here: ftp://ftp.uni-duisburg.de/FlightGear/Devel/taxidraw-0.2.3-IRIX.bz2 I can confirm the stopway length bug to be fixed, 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] TaxiDraw-0.2.3 released
Martin Spott wrote: David Luff wrote: I've put TaxiDraw-0.2.3 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. IRIX binary is here: ftp://ftp.uni-duisburg.de/FlightGear/Devel/taxidraw-0.2.3-IRIX.bz2 Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 10:29, Martin Spott wrote: Melchior FRANZ wrote: It isn't anywhere in the scenery yet -- just in cvs. You have to add it yourself, or replace the saratoga with it. I added this in file $FG_ROOT/Scenery/Terrain/w130n30/w123n37/942057.stg: OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90 Thanks, Melchior. This has a funny effect here: After starting FG, I see the BO105 sitting _below_ the flight deck right on the water surface. After hitting 'Reset' in the 'File' menu, the BO105 gets placed properly on the flight deck (man, what a small bird, what a large carrier ), It is thought to work with the ai configuration Vivian was talking about. That means you need to apply the carrier-data.diff from ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ as well as put the nimitz_demo.xml into the Data/AI/ directory. But then, YASim's physics cannot yet 'see' the carrier deck. Changing YASim and the others to see the ground cache is one of the next steps. You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Dienstag 16 November 2004 18:25, Martin Spott wrote: into CVS is the addition of the Nimitz - no change to any FDM yet. Did I miss a mail ? True. There are many things to do. I would like to have the basic infrastructure in flightgears cvs. This way I can add the code safely to JSBSim's cvs, work on an update to YASim, etc ... But up to now, Erik gets a segfault. That is a showstopper, not only in Erik's eyes ... I want to know what the cause is. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
On Mittwoch 17 November 2004 11:29, Melchior FRANZ wrote: I applied all the stuff and it worked very well. My first carrier landing with the FA-18A succeeded already. The gear code is great! It's fun to taxi over slopes and actually see the aircraft follow them, rather than strangely sliding up with the nose gear below ground. And the FA-18 is very well done and has a nice cockpit with nice night lighting. The only problems I've encountered: * not really surprisingly, the carrier doesn't replay in replay mode. When I watched my landing in replay, the carrier had already moved along. Tricky to fix. :) I observed that too. From my point of view, do one by one ... But help is allways welcome :) * I observed one segfault that I hadn't seen before. The bt, however, didn't look like it had anything to do with the new code. I haven't saved the core file but will do so if I run into that problem again. If you see that again, could you please try to find out where that happens? Thanks! Now I hope that I will soon be able to land the bo105 realistically on slight slopes ... Stay tuned :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
* Mathias Fröhlich -- Wednesday 17 November 2004 21:42: On Mittwoch 17 November 2004 11:29, Melchior FRANZ wrote: * I observed one segfault that I hadn't seen before. The bt, however, didn't look like it had anything to do with the new code. I haven't saved the core file but will do so if I run into that problem again. If you see that again, could you please try to find out where that happens? Thanks! Sure. Actually, I do know where it happened. I checked the backtrace, and wasn't thrilled: It was at program exit when freeing property nodes. That's why I didn't really attribute it to the new changes, although I hadn't seen that before. It was a failure not to save the core file, but I had run fgfs in gdb, and this doesn't produce them automatically. Have tried to reproduce the segfault, but it didn't happen again yet. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear build break: Mac OS X
With CVS src from 2100 GMT Wednesday, 17 XI 2004, network/ATC-inputs.cxx requires #ifdef __APPLE__ #include fcntl.h #endif before: #include ATC-Inputs.hxx to build flightgear successfully. I'd appreciate it if someone with developer authority could make this small change. Otherwise constants like O_RDWR are not defined. This might be required for other BSD unix variants, I am not sure. Thanks! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Mathias Fr??hlich wrote: You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Well, this statement appears to be maybe mostly, but not entirely correct ;-) Apparently different rules apply when you put the carrier into the scenery: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg 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] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Mittwoch 17 November 2004 22:20, Martin Spott wrote: Mathias Fr??hlich wrote: You will only be able to taxi on the carrier's deck with that JSBSim-dropin.tar.gz from the same ftp location. Well, this statement appears to be maybe mostly, but not entirely correct ;-) Apparently different rules apply when you put the carrier into the scenery: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg That's when you put that carrier statically into the scenery. Then it is in the scenery branch and SSGTRAV_HOT is set in the traversal mask. This is not true for AI models. And a AI carrier will be an AI model. But nice pic anyway :) Did you manage to take off? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AInimitz_demo.xml, NONE, 1.1
Hi, On Mittwoch 17 November 2004 21:52, Melchior FRANZ wrote: Sure. Actually, I do know where it happened. I checked the backtrace, and wasn't thrilled: It was at program exit when freeing property nodes. That's why I didn't really attribute it to the new changes, although I hadn't seen that before. It was a failure not to save the core file, but I had run fgfs in gdb, and this doesn't produce them automatically. Have tried to reproduce the segfault, but it didn't happen again yet. Ok, thanks! Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal
I'm working on a new cockpit for the T6; the T6's altimeter displays barometric pressure in both inches HG and MB. I want to add a small amount of script that converts from the HG reading in the property tree to MB for the gauge (I need this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Thanks, Vance ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Mathias Fr??hlich wrote: On Mittwoch 17 November 2004 22:20, Martin Spott wrote: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Carrier_01.jpg [...] Did you manage to take off? With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea 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] Nasal
Vance Souders wrote: I'm working on a new cockpit for the T6; the T6's altimeter displays barometric pressure in both inches HG and MB. I want to add a small amount of script that converts from the HG reading in the property tree to MB for the gauge (I need this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Actually, the instrument definitions themselves cannot yet contain Nasal statements, at least that's what I learnt about 3 weeks ago when I made a quick stab at another new instrument, I was also somewhat surprised but found my assumptions confirmed when I looked into the source code - so, in that regard FG is currently somehwat inconsistent, because it doesn't seem to support Nasal scripts in any PropertyList file. As a workaround you could simply place that script into a separate nasal module and put that into the Nasal sub folder, so that it gets automatically loaded - you can then refer to the code in that module by using the file's name (without extension) to access functions/objects. For debugging purposes it might be helpful to use print statements in order to see whether a function is actually called. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
On Thursday 18 November 2004 00:06, Vance Souders wrote: I'm working on a new cockpit for the T6; the T6's altimeter displays barometric pressure in both inches HG and MB. I want to add a small amount of script that converts from the HG reading in the property tree to MB for the gauge (I need this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Yes you can put nasal scripts in the action tags of the gauge's xml file: action ... commandnasal/command script![CDATA[ # Your nasal script for converting from InHG to mBar. ]] /script /binding /action -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Stall warning
I just tried this on a freshly updated CVS build: Take off in the 172 (I used the c172r-3d) and climb to say, 2500'. Trim the aircraft and with the wings level, pull the power back to idle. Hold the nose up to allow the speed to decay and enter the stall. The stall warner goes off as expected at about the right speed, IMO. Now drop the nose a little and let the air speed build to above Vs still with idle power. I repeatably get the stall warner to well over 70kt indicated. Are other people seeing this? Is it normal? (I've never just dunked the nose on a 150 or 152, but I'm sure the stall warning would go as soon as the flow re-attached to the wing... I tried looking in the property tree to see what the fdm was using but I didn't manage to sustain the attitude and airspeed without a joystick I'm afraid. All the best, Matthew ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Stall warning
On Thu, 18 Nov 2004 00:05:33 +, Matthew Law [EMAIL PROTECTED] wrote: Now drop the nose a little and let the air speed build to above Vs still with idle power. I repeatably get the stall warner to well over 70kt indicated. Are other people seeing this? Is it normal? (I've never just dunked the nose on a 150 or 152, but I'm sure the stall warning would go as soon as the flow re-attached to the wing... ... or at least when you go below the angle of attack that the stall horn is set to. That does seem strange -- you shouldn't hear it even if you have got yourself into an accelerated stall somehow, because stall horns don't tend to actually know about loss of laminar flow. 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: [Flightgear-cvslogs] CVS: data/Data/AI
On Donnerstag 18 November 2004 00:32, Martin Spott wrote: With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea ... wait until the c172 gets a launchbar :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Thu, 18 Nov 2004 08:15:43 +0100, Mathias wrote in message [EMAIL PROTECTED]: On Donnerstag 18 November 2004 00:32, Martin Spott wrote: With a BO105 it's pretty easy, it is feasible with the C172 but for the TSR-2 the strip is too short. I was too lazy to shift the starting position to the beginning of the 'runway', otherwise it _might_ have worked out. So I crashed into the sea .. wait until the c172 gets a launchbar :) ..and for the TSR-2, a nuke AB? ;-) -- ..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
