Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Dennis B. D'Annunzio wrote: I thought I successfully compiled and installed SimGear-0.3.1. However, whem making FlightGear-0.9.1 under cygwin (xwindows was removed), I get this message: nt/libEnvironment.a -lsgroute -lsgsky -lsgclouds3d -lsgephem -lsgtiming -lsgio - lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lop engl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinm m -lm Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
Paul Morriss wrote: Hi, Is there any procedure for software documents etc? I have an outline of how I intend to write the software, I will start with other planes in the sky for now. Like Bernie mentions, there are people working on some of those subjects, so it might be time for them to jump in and coordinate this effort some more. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] xml property documentation
Erez Boym wrote: Hi, Do we documentation of all the various properties that can be set through the xml setup files ? If not, I have tried to find the xml parser in the source tree with no luck, where would be the best place to start reverse engineer the xml parser to produce such documentation ? We had a discussion about this subject a few weeks back and came to the conclusion that automatic generation of the property lists probably won't give the desired result. If you insist on using this approach, you can find the xml parser in the simgear/xml directory of SimGear (esp. easyxml.?xx). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Updated set of goals?
Hi, Not being able to program much makes one think even harder. This is a new set of goals I came up with: Human factors - * Add language support back in * Add an international font * Sort the list of available aircraft when displaying * Improve exceptions support (or remove it) to provide usefull error messages * Improve the GUI - Rearrange for usabillity - Add aircraft selection menu FDM/Visual/Sound * Add a set terrain qualifiers - roughness for visual effects - friction for FDM and audio support Rendering - * Create a realistically coloured sky dome * Add (more) realistic night lighting * Improve star lightness - Add star light variations due to atmospheric effects * Blend plannets into the skydome during daytime * 3D cloud support (partially done) * Water reflections * Material edge blending TerraGear - * Improve natural land cover - steepness water: 50 degr. waterfall snow: 65 degr. glacier 80 degr. rock city: 30 degr. schrub default: 80 degr. rock 70 degr. grass + rock 60 degr. schrub + grass + rock 60 degr. everything - altitude n = (180-longitude)*5500 n glacier 0.63n rock + glacier 0.50n grass + rock + glacier 0.43n schrub + grass + rock + glacier 0.30n coniferous + schrub + grass + rock + galcier 0.30n everything Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
On Monday, February 10, 2003, at 10:09 am, Erik Hofman wrote: Rendering - snip * Material edge blending This one, and some fractal subdivision of soft-edges, would give far and away the best visual improvement for the current data set, in my opinion. The issues get fairly complex though (this is what I tried to do for my final year project, and didn't get very far at all). What you'd 'like' to do: - use a generic coastline texture for sea boundaries (and a 'narrower' one for non-tidal inland water) - use shore gradient to pick a rocky texture, and, just maybe, VMap sand/mudflat land coverage to get decent tidal zones (of course then people will demand correct tides ... yukc) - blend the major 'massy' land use types together, based on their type. - fields / agricultural areas have sharp edges and mostly straight boundaries - snow / rock / moorland / pasture tends to have very rough edges - urban areas have rough transitions of empty but non-agricultural land and smaller 'chunk' sizes. - forrest have varying edges based on whether they're natural or managed! So this gets to be quite a major task very quickly, and your polygon count is soaring through the roof all the time. The attribute data in the VMap files can help, eg it differentiates between parkland (hard edges) and open grassland, natural vs managed forests, and so on. Making sensible guesses is still a huge undertaking and guaranteed to go badly wrong in some places. HH James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Erik Hofman writes: Dennis B. D'Annunzio wrote: I thought I successfully compiled and installed SimGear-0.3.1. However, whem making FlightGear-0.9.1 under cygwin (xwindows was removed), I get this message: nt/libEnvironment.a -lsgroute -lsgsky -lsgclouds3d -lsgephem -lsgtiming -lsgio - lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lmk4 -lz -lop engl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinm m -lm Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Hmm... -lopengl is there in the link line -lopengl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lm *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. so in this case '-lopengl32' must come after '-lglut32' and '-lglu32' This was working correctly. has configure.ac changed this recently FWIW I won't have time to investigate this much deeper for a couple of days Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
Hi Paul, As others have pointed out, there has been a small amount of AI traffic development going on, and as the guilty party I'd better pipe up sooner rather than later :-) I'll describe what I've been doing and leave it up to you whether you want to join in with that or start afresh. I've started from the premise that if there's going to be a number of planes in the sky at once, then they should take up as few CPU cycles each as possible. Hence my vision is for very simplified mechanics of flying - basically known ranges of speed, bank, climb etc for a given flight condition, and a bit of smoothing of transitions in between. Also only very near AI planes to the viewer to be updated every frame, the rest to be updated 1 per frame, and hence robust to variable times between updating. I'm pretty sure that not everyone agrees with that, and that some would go for coupled autopilot/fdms flying the planes as if they were another user-fidelity flight-model, but the simplified route is the one I started down. Then my basic structure is that an AI manager iterates through a list of AIEntity classes, and updates one per frame. The AIEntity has the minimum logic necessary to be drawn on the screen, and progressivly more complex classes are derived from it - for instance a plane that can taxi, then a light plane that can fly circuits could be derived from that and would already know how to taxi, and then a light plane that flys from one airport to another could be derived from that and would already know how to fly circuits and taxi. Having said all that, I've basically hardly started! I've got one hardwired AI plane in so far, that can be seen by starting FlightGear with: fgfs --airport-id=KEMT --prop:/sim/ai-traffic/enabled=true --prop:/radios/comm/frequencies/selected-mhz[0]=121.2 --heading=10 You do need to download the w120n30 scenery block as well. This will start you at El Monte behind a light single (no, NOT cheese!!!) that takes off, flys a circuit, and then taxis back to a parking spot. It's great fun to try following it round. You can make it fly touch and go's by changing line 54 in AIMgr.cxx: local_traffic-FlyCircuits(1, true); to a larger value than 1. The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. Anyway, the nub of the matter is that you can either join in with what's started, where the best separation of work is probably to go for planes that fly from one airport to another, or start afresh if you think I'm on the wrong track. If you start afresh bear in mind you'll need some communication with the ATC system - both to send and recieve messages. Interactive communication with tower control (You are number 2, extend downwind for traffic on straight in / go-around I repeat go-around / cleared to land etc) should be comming quite soon and you'll need to respond to those. If you do you're own taxiing system then communication with ground control (in a programming logic sort of way rather than spoken transmission) is a right can of worms since we need to communicate a logical representation of a path to follow to and from tower and plane. James Turner has started some impressive work on implementing Flightplans in Flightgear, and an interface to the DAFIF data which includes loads of stuff such as airways, TMAs, SIDs, STARs, etc. I'd thoroughly recommend getting in touch with him before doing too much since you'll almost certainly want to use his stuff. Whatever you do, any logic on how to fly from one place to another will be useful whatever system to glue it in ends up getting used. Have fun, Cheers - Dave *** REPLY SEPARATOR *** On 2/9/03 at 5:59 PM Paul Morriss wrote: Hi, Is there any procedure for software documents etc? I have an outline of how I intend to write the software, I will start with other planes in the sky for now. Paul - Original Message - From: Jim Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 08, 2003 4:29 PM Subject: Re: [Flightgear-devel] Dynamic Scenario's Paul Morriss [EMAIL PROTECTED] said: Hi all, I am new to Flight Gear, but not to flight simulation, thats my line of business ;) Anyway I would like to propose (and develop) a server or system that can be used to manage the environment. What I mean is that the scenario system manages: * Other plans in the air, these can add the reality of busy airspace near large airports. * Weather system controlled through scenarios, this would include clouds, rain etc... *
re: [Flightgear-devel] xml property documentation
Erez Boym writes: If not, I have tried to find the xml parser in the source tree with no luck, where would be the best place to start reverse engineer the xml parser to produce such documentation ? The XML parser is in SimGear, but you don't need it -- FlightGear already holds the preparsed property tree in memory. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation problems.
Curtis L. Olson [EMAIL PROTECTED] said:
Ground elevation problems ...
I'm starting at KHAF (because it illustrates the problem pretty well.)
I'm using the A4, but the problem is with any aircraft.
Below is the fix for that bug. It's just a one line change. My apologies if
this mailer screws up the line feeds!
Also note that at some point whoever was working on optimizing the
FGTileMgr::Update also removed the bucket field from the FGLocation class.
This results in more calls to the tile scheduler. Not a big deal, but some
wasted cpu effort that could matter in certain situations.
Best,
Jim
Index: Scenery/tilemgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tilemgr.cxx,v
retrieving revision 1.12
diff -u -r1.12 tilemgr.cxx
--- Scenery/tilemgr.cxx 10 Dec 2002 20:50:52 - 1.12
+++ Scenery/tilemgr.cxx 10 Feb 2003 12:47:08 -
@@ -407,7 +407,7 @@
if ( longitude != last_longitude || latitude != last_latitude ) {
// update current elevation...
if ( updateCurrentElevAtPos( abs_pos_vector,
- globals-get_scenery()-get_center() ) )
+globals-get_scenery()-get_next_center() ) )
{
last_longitude = longitude;
last_latitude = latitude;
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #1367 - 11 msgs
Hi, Did anyone start to document these properties in another way, or do we have no documentation about these xml properties ? Erez We had a discussion about this subject a few weeks back and came to the conclusion that automatic generation of the property lists probably won't give the desired result. If you insist on using this approach, you can find the xml parser in the simgear/xml directory of SimGear (esp. easyxml.?xx). Erik __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: xml property documentation
Hi, Did anyone start to document these properties in another way, or do we have no documentation about these xml properties ? Erez We had a discussion about this subject a few weeks back and came to the conclusion that automatic generation of the property lists probably won't give the desired result. If you insist on using this approach, you can find the xml parser in the simgear/xml directory of SimGear (esp. easyxml.?xx). Erik __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Norman Vine wrote: Erik Hofman writes: Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 It looks to me like there isn't any linking of the OpenGL libraries. Did you see any warning message while running configure (for FlightGear)? Hmm... -lopengl is there in the link line -lopengl32 -lpthread -lm -lglut32 -lglu32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lm *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. so in this case '-lopengl32' must come after '-lglut32' and '-lglu32' This seems akay in the current source: LIBS=$LIBS -lglut32 -lglu32 -lopengl32 Maybe you should check there isn't any configure.in in the FlightGear source and run autogen.sh again. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: xml property documentation
Erez Boym wrote: Hi, Did anyone start to document these properties in another way, or do we have no documentation about these xml properties ? The documentation is scattered around a bit. Most of it lives in the FlightGear source under FlightGear/docs-mini But FDM speciffic propperties are (more or less) covered by their maintainers (although the FDM's should agree on some of them). As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
Erik Hofman [EMAIL PROTECTED] said: - Add aircraft selection menu Just to add to this. We should be able to plug and unplug FDM's at this point, or at least we are close. Being able to interrupt the simulation, select a different aircraft and FDM and then reiniting the entire system should be doable without too much effort. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: - Add aircraft selection menu Just to add to this. We should be able to plug and unplug FDM's at this point, or at least we are close. Being able to interrupt the simulation, select a different aircraft and FDM and then reiniting the entire system should be doable without too much effort. That is the intention. Selecting a new aircraft *during* flight, although fun, is not yet needed(*). Erik (*) Addidtion of ejection seats might actually require it at some point. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
Erik Hofman [EMAIL PROTECTED] said: That is the intention. Selecting a new aircraft *during* flight, although fun, is not yet needed(*). Yes, and it could be handy to turn a c172 into a c310 right after engine failure while flying through hells canyon. Or fun to get a jet up to mach 1.2 and then turn it into a cub. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
Jim Wilson writes: Erik Hofman [EMAIL PROTECTED] said: - Add aircraft selection menu Just to add to this. We should be able to plug and unplug FDM's at this point, or at least we are close. Being able to interrupt the simulation, select a different aircraft and FDM and then reiniting the entire system should be doable without too much effort. This is something that would be nice to have fairly high on someone's todo list ... haven't been able to find the time to look seriously at this myself. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Norman Vine wrote: -lopengl is there in the link line *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Actually, Unix-style compilers are sensitive to link order issues too. The only thing that makes it seems simpler under Linux is that shared libraries (unlike DLL's) can export their dependency information to the linker and automatically pull in the needed libraries in the proper order. For example, many OpenGL test programs link correctly if you simply specify -lglut on the command line. All the other libraries (GLU/GL/Xext/X11/m, off the top of my head) will get pulled in automagically. Something tells me that recent versions of GCC had some new features in this area, but I can't remember what they were. Maybe the link order isn't a problem any more? I was playing with this last week while writing an automatic dependency build tool for C/C++ projects. plug mode=shameless It's actually working pretty well, if anyone wants to see it. You just drop code into a local ./src directory and it all gets compiled magically into program files that have a prog- prefix. Saves a lot of annoying Makefile/autoconf drudgery; I got a little spoiled these past four years doing Java stuff at NextBus./plug Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
Jim Wilson writes: Yes, and it could be handy to turn a c172 into a c310 right after engine failure while flying through hells canyon. Or fun to get a jet up to mach 1.2 and then turn it into a cub. :-) We need to animate the fabric ripping off the wings just before the wooden spars snap. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Andy Ross wrote: *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Yes, it seemed to me that opengl wasn't getting linked, so I was moving the link order around in experimentation. The stock configuration has the libraries in the correct order. I apologize for the confustion on this aspect. BTW, the stock configuration provided the same message. I'm involved with the autopilot.sf.net project and we are exploring flightgear integration with our simulator. The helicopter flight model was written by Aaron Kahn and has a VERY realistic hover simulation. Optionally, a flybar component can be introduced into the model for further simulating R/C class helicopters. flight model is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-sim/ This is our focus as we are working on a GPS aided INS system for R/C helicopters and airplanes. The simulator allows us to work on the groundstation, kalman filter and other vehicle systems in virtual reality. The Kalman filter is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/imu-filter/ Navigation prototype is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/controller/ Trammell from the autopilot.sf.net project found an old flightgear-users message that detailed the cygwin build procedure. This email was enough to get flightgear compiling on my system. It seems cygwin is pretty messy with regards to OpenGL and X11 (three sets variations of GL headers!!). I don't know enough about flightgear yet to know how to integrate the flight model... Either internally or as an external driver? Although, I must admit that I have been having too much fun flying and using flightgear and not enough time looking at the code :-) Plib networking also looks attractive. We have a TCP/IP based state server on the sim and a UDP based state server onboard the vehicle. We are working to reconcile them (into UDP due to the nature of our wireless telemetry system) and someone mentioned Plib. Between flightgear and opengc, it would be great to adhere to some sort of open source simulation network standard. our TCP/IP networking is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/state/ Our UDP network is embedded in the onboard filter and ground station at the moment and isn't very modular (... hack ...) I got a little spoiled these past four years doing Java stuff at NextBus./plug I have done mostly Java work for the past 3 years. This has spoiled me in regards to build systems. Switching back to C/C++ multi-platform systems has been a rude awakening... Thanks for the responses on this cygwin issue. Dennis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: xml property documentation
As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. You probably hit the nail ;-) 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
Re: [Flightgear-devel] Re: xml property documentation
Martin Spott writes: As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. You probably hit the nail ;-) Aside from that, there will probably be a major restructuring when we add multi-vehicle support. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: xml property documentation
David Megginson writes: Martin Spott writes: As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. You probably hit the nail ;-) Aside from that, there will probably be a major restructuring when we add multi-vehicle support. Neither of which is a reason *not* to start a master list at least of new and changed items Seriously how much more work would it be to add/change an entry to the master list at the same time as the code was submitted into the CVS IMHO this should be a requirement for any change in the property tree and would help a lot As a wise man once said The long journey starts with the first step Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: xml property documentation
Norman Vine wrote: David Megginson writes: Martin Spott writes: As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. You probably hit the nail ;-) Aside from that, there will probably be a major restructuring when we add multi-vehicle support. Neither of which is a reason *not* to start a master list at least of new and changed items Seriously how much more work would it be to add/change an entry to the master list at the same time as the code was submitted into the CVS IMHO this should be a requirement for any change in the property tree and would help a lot As a wise man once said The long journey starts with the first step Hmm, I was just thinking we have something to start with: You can save the current state of the properties using the File menu. The output will be an XML file containing all the properties available in the curent session! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: xml property documentation
HI, Well, I'm new to FlightGear tweaking, but I find it strange that to use flight gear (Add objects, add aircrafts etc.) you have to search the source files, just to find these xml properties that will enable me to do that work. In my inexpert eyes it's something we must maintain otherwise we limit FlightGear usage to code reader experts that can tweak the source files. Normal users that only want to add things to flight gear would be left out or bug mailing lists for these properties. Erez __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
On Mon, 10 Feb 2003 10:58:37 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Jim Wilson writes: Yes, and it could be handy to turn a c172 into a c310 right after engine failure while flying through hells canyon. Or fun to get a jet up to mach 1.2 and then turn it into a cub. :-) We need to animate the fabric ripping off the wings just before the wooden spars snap. ...which of course might be a good time to consider ejecting. Hum, re-entry in a Cub? ;-) -- ..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
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
On Mon, 10 Feb 2003 11:56:36 -0500, Dennis B. D'Annunzio [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Andy Ross wrote: *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Yes, it seemed to me that opengl wasn't getting linked, so I was moving the link order around in experimentation. The stock configuration has the libraries in the correct order. I apologize for the confustion on this aspect. BTW, the stock configuration provided the same message. I'm involved with the autopilot.sf.net project and we are exploring flightgear integration with our simulator. The helicopter flight model was written by Aaron Kahn and has a VERY realistic hover simulation. Optionally, a flybar component can be introduced into the model for further simulating R/C class helicopters. ..aaah, another dream come true. Thank you and welcome onboard. :-) flight model is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-sim/ This is our focus as we are working on a GPS aided INS system for R/C helicopters and airplanes. The simulator allows us to work on the groundstation, kalman filter and other vehicle systems in virtual reality. The Kalman filter is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/imu-filter/ Navigation prototype is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/controller/ Trammell from the autopilot.sf.net project found an old flightgear-users message that detailed the cygwin build procedure. This email was enough to get flightgear compiling on my system. It seems cygwin is pretty messy with regards to OpenGL and X11 (three sets variations of GL headers!!). I don't know enough about flightgear yet to know how to integrate the flight model... Either internally or as an external driver? Although, ..would an external flight model be easier for you? It can then network with FlightGear both from the same box and from another. I must admit that I have been having too much fun flying and using flightgear and not enough time looking at the code :-) Plib networking also looks attractive. We have a TCP/IP based state server on the sim and a UDP based state server onboard the vehicle. We are working to reconcile them (into UDP due to the nature of our wireless telemetry system) and someone mentioned Plib. Between flightgear and opengc, it would be great to adhere to some sort of open source simulation network standard. our TCP/IP networking is at: http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/state/ ..and your video code? (more or less clueless coder-wannabe looking for a light weight alternative to OpenGL video for FlightGear ;-)) Can your video code be set up to read flight simulation over the network? Like in:... http://dsc.discovery.com/anthology/unsolvedhistory/redbaron/redbaron.html http://www.google.com/search?hl=enie=UTF-8oe=UTF8q=FlightGear+%22Red+Baron%22++Discovery ...which used FlightGear networked to another sim, we don't shoot. Our UDP network is embedded in the onboard filter and ground station at the moment and isn't very modular (... hack ...) I got a little spoiled these past four years doing Java stuff at NextBus./plug I have done mostly Java work for the past 3 years. This has spoiled me in regards to build systems. Switching back to C/C++ multi-platform systems has been a rude awakening... Thanks for the responses on this cygwin issue. Dennis -- ..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
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 11:46:04 + David Luff [EMAIL PROTECTED] wrote: [snip] The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. I've been experimenting in this area too, particularly user tools. To that end I've added a taxiway editor to FGSD, FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd. Data is saved to an xml file. The next step is to load this data into FlightGear and hook it into the ATC system. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: xml property documentation
Erez Boym wrote: HI, Well, I'm new to FlightGear tweaking, but I find it strange that to use flight gear (Add objects, add aircrafts etc.) you have to search the source files, just to find these xml properties that will enable me to do that work. In my inexpert eyes it's something we must maintain otherwise we limit FlightGear usage to code reader experts that can tweak the source files. Normal users that only want to add things to flight gear would be left out or bug mailing lists for these properties. In the contrary, most properties are defined in XML configuration files. To see what properties are available you can look in the properties browser when running FlightGear. What is missing here is the default layout of all the subsystems. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external flight model
Arnt Karlsen wrote: ..would an external flight model be easier for you? It can then network with FlightGear both from the same box and from another. I bet it would be easier. That is how our system works now. We start the flight model simulator which has an embedded vehicle state server. Then, the 3D renderer and the ground station connect to the flight model state server. The 3D renderer simply listens to the vehicle state and renders a couple differnet points of view (vehicle, groundstation, etc.). The groundstation listens to state to display the AI and guages and then sends actuator commands to the simulator from the joystick (manual control) or from the guidance program. Are there any external flight models currently implement for reference? I see the src/FDM/* and src/Network/*_fdm.* as a starting point. Our video is minimal - just a helicopter in a flat endless world. http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-3d/ Dennis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On 2/11/03 at 9:15 AM Bernie Bright wrote: On Mon, 10 Feb 2003 11:46:04 + David Luff [EMAIL PROTECTED] wrote: [snip] The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. I've been experimenting in this area too, particularly user tools. To that end I've added a taxiway editor to FGSD, FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd. Data is saved to an xml file. The next step is to load this data into FlightGear and hook it into the ATC system. Fantastic! If it works then I'll abandon my efforts in that field immediately :-) The current data I've been reading in from KEMT.taxi is reproduced below: N 0 -118.0372167 34.08178333 0.0 J E-01-19 rwy 01 N 1 -118.0321833 34.0907 0.0 J E-01-19 rwy 19 N 2 -118.0369167 34.0817 0.0 H E N 3 -118.0318534.0906 0.0 H E N 4 -118.0351534.0848 0.0 T E N 5 -118.0349667 34.08511667 0.0 T E N 6 -118.0348333 34.0847 0.0 T E G 7 -118.0347333 34.0848 0.0 GS 10 N 8 -118.0346534.08498333 0.0 T E N 9 -118.0346 34.08456667 0.0 T E G 10 -118.0345167 34.0847 0.0 GS 10 N 11 -118.0344167 34.0849 0.0 T E A 0 1 R N A 0 2 T N A 1 3 T N A 2 4 T N A 4 5 T N A 3 5 T N A 4 6 T N A 6 9 T Y A 5 8 T Y A 8 11 T Y A 6 7 T Y A 7 8 T Y A 9 10 T Y A 10 11 T Y [End] N is a node, each one has a number, position, elev, code [J = junction, H = hold, T = T-junction], an E-code since denotes any runways that they are exits fom, and the node name. G is a gate, similar, but with a code for airplane - GS = GA single. A is an arc, this has the numbers of the two nodes it connects, a type [R = runway, T = taxiway], and [Y/N] to whether it is 2-way, and a name. Obviously there's more stuff that could go in here, such as weight limits on the arcs, but that's what I started with. Is this the sort of thing I can load from the xml output from your program? If so I guess I'd better take your xml file loader and plug it into the ATC system (ground.[ch]xx). Is your code in fgsd CVS yet? If not could you email it to me? If you could bear to take a look at the brain-dump that masquerades for code in ground.[ch]xx perhaps you could have a look at my proposed node/arc structures and shout if you think I'm doing anything *really* silly before I get too far into it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external flight model
On Mon, 10 Feb 2003 17:34:07 -0500, Dennis B. D'Annunzio [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..would an external flight model be easier for you? It can then network with FlightGear both from the same box and from another. I bet it would be easier. That is how our system works now. We start the flight model simulator which has an embedded vehicle state server. ..heh, I agree. :-) Then, the 3D renderer and the ground station connect to the flight model state server. The 3D renderer simply listens to the vehicle state and renders a couple differnet points of view (vehicle, groundstation, etc.). The groundstation listens to state to display the AI and guages and then sends actuator commands to the simulator from the joystick (manual control) or from the guidance program. ..what sort of video is this? SVGA or VESA etc type framebuffers??? Are there any external flight models currently implement for reference? I see the src/FDM/* and src/Network/*_fdm.* as a starting point. ..yes, grep thru the docs and this list for --fdm=external. The most recent message is 03b901c2c56f$dda62490$dd36ba8c@sfdev3 by Norman, who on Sun, 26 Jan 2003 14:19:32 -0500 wrote: | Otherwise you need to run a slaved version of FGFS on the computer(s) | driving the other monitor(s) and adjust the view(s) accordingly | | from -- Readme.io | | Socket Communication: | | --native=socket,dir,hz,machine,port,style | | machine = machine name or ip address if client (leave empty if | server) port = port, leave empty to let system choose | style = tcp or udp | | example to slave one copy of fgfs to another | | fgfs1: --native=socket,out,30,fgfs2,5500,udp | fgfs2: --native=socket,in,30,,5500,udp --fdm=external | | This instructs the first copy of fgfs to send UDP packets in the | native format to a machine called fgfs2 on port 5500. | | The second copy of fgfs will accept UDP packets (from anywhere) | on port 5500. Note the additional --fdm=external option. This | tells the second copy of fgfs to not run the normal flight model, | but instead set the FDM values based on an external source (the | network in this case.) | Our video is minimal - just a helicopter in a flat endless world. ..will do fine fine me as a start, my hardware gave me 7 frames per minute ;-) last time I tried FG, ATI Mach64 video. Since then, the DRI guys has reportedly done some nice work over at dri.sf.net, while I've been drowning in work for my 802.11 isp client. http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/sim/src/heli-3d/ ..thanks, Dennis. Can this be coerced into showing terrain, or does it need its own terrain? http://decopter.sourceforge.net/ uses a funny way of generating terrain, from a texture, but it needs OpenGL. -- ..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
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:44:40 + David Luff [EMAIL PROTECTED] wrote: On 2/11/03 at 9:15 AM Bernie Bright wrote: On Mon, 10 Feb 2003 11:46:04 + David Luff [EMAIL PROTECTED] wrote: [snip] The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. I've been experimenting in this area too, particularly user tools. To that end I've added a taxiway editor to FGSD, FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd. Data is saved to an xml file. The next step is to load this data into FlightGear and hook it into the ATC system. Fantastic! If it works then I'll abandon my efforts in that field immediately :-) The current data I've been reading in from KEMT.taxi is reproduced below: N 0 -118.0372167 34.08178333 0.0 J E-01-19 rwy 01 N 1 -118.0321833 34.0907 0.0 J E-01-19 rwy 19 N 2 -118.0369167 34.0817 0.0 H E N 3 -118.0318534.0906 0.0 H E N 4 -118.0351534.0848 0.0 T E N 5 -118.0349667 34.08511667 0.0 T E N 6 -118.0348333 34.0847 0.0 T E G 7 -118.0347333 34.0848 0.0 GS 10 N 8 -118.0346534.08498333 0.0 T E N 9 -118.0346 34.08456667 0.0 T E G 10 -118.0345167 34.0847 0.0 GS 10 N 11 -118.0344167 34.0849 0.0 T E A 0 1 R N A 0 2 T N A 1 3 T N A 2 4 T N A 4 5 T N A 3 5 T N A 4 6 T N A 6 9 T Y A 5 8 T Y A 8 11 T Y A 6 7 T Y A 7 8 T Y A 9 10 T Y A 10 11 T Y [End] N is a node, each one has a number, position, elev, code [J = junction, H = hold, T = T-junction], an E-code since denotes any runways that they are exits fom, and the node name. G is a gate, similar, but with a code for airplane - GS = GA single. A is an arc, this has the numbers of the two nodes it connects, a type [R = runway, T = taxiway], and [Y/N] to whether it is 2-way, and a name. Obviously there's more stuff that could go in here, such as weight limits on the arcs, but that's what I started with. Is this the sort of thing I can load from the xml output from your program? If so I guess I'd better take your xml file loader and plug it into the ATC system (ground.[ch]xx). Is your code in fgsd CVS yet? If not could you email it to me? My changes are not in cvs yet. I still have to implement undo/redo/delete functionality. However I will email you what I have so far. If you could bear to take a look at the brain-dump that masquerades for code in ground.[ch]xx perhaps you could have a look at my proposed node/arc structures and shout if you think I'm doing anything *really* silly before I get too far into it. I used your structures as a starting point. However the needs of the editor and the xml format forced some changes. But we are in the same ballpark. Here are some snippets from a KSFO taxiway file with some commentary: nodes node latitude type=double37.615023/latitude longitude type=double-122.356881/longitude nodetype type=stringNormal/nodetype /node node n=4 latitude type=double37.620940/latitude longitude type=double-122.370852/longitude nodetype type=stringHold/nodetype /node /nodes There are two types of nodes, Normal and Hold-Short. Unlike yours they don't contain an elevation but that shouldn't be too hard to add if required, it is available from the underlying fgsd tile/airport object. They also don't have your E-code or a name. I think these properties belong to the connecting arc/segment. gates gate latitude type=double37.615096/latitude longitude type=double-122.381158/longitude gatetype type=stringGateHeavy/gatetype radius type=double0.00/radius heading type=double0.00/heading /gate /gates There are 11 gate types for commercial, cargo, GA, military and seaplane aircraft. I haven't got around to inputting the radius and heading values yet, hence the zeros. segments segment type type=stringtaxiway/type node1 type=int0/node1 node2 type=int1/node2 name type=stringC/name width type=int110/width /segment segment n=55 type type=stringrunway/type node1 type=int35/node1 node2 type=int41/node2 name type=string10R/28L/name width type=int200/width /segment What you call an
Re: [Flightgear-devel] Re: xml property documentation
I tried adding comments to the preferences.xml file, but they were not rolled into CVS. The problem, and I believe why my edits didn't make CVS, is that commenting each attribute causes diff to believe the entire file has changed. This makes it difficult for those people who have tailored .xml files. I would really like the .xml files to be fully commented (I'm strange that way), but I'm not going to hold my breath. Jonathan Polley On Monday, February 10, 2003, at 08:01 AM, Erez Boym wrote: Hi, Did anyone start to document these properties in another way, or do we have no documentation about these xml properties ? Erez We had a discussion about this subject a few weeks back and came to the conclusion that automatic generation of the property lists probably won't give the desired result. If you insist on using this approach, you can find the xml parser in the simgear/xml directory of SimGear (esp. easyxml.?xx). Erik __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GLXBadRenderRequest
Hi, I put the following message on the users mailing list and it doesn't seem that anyone there can help. Can anyone here give any insight? The 3D demos all work and I'm running Mandrake 9.0 with a NVIDIA GeForce4 Ti 4200. FlightGear-0.9.1 Finally got FG to complie, but when I try to start it, I get the following message. This is after it sets up the default airplane(C172) and airport(KSFO). Any ideas? Thanks in advance. First time, doing precise gst General Initialization === == FG_ROOT = /usr/local/data Initializing scenery subsystem Initializing basic built-in commands: null exit load save panel-load panel-mouse-click preferences-load view-cycle screen-capture tile-cache-reload lighting-update property-toggle property-assign property-adjust property-multiply property-swap property-scale gui presets_commit X Error of failed request: GLXBadRenderRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 44 Current serial number in output stream: 45 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
On Thu, Feb 06, 2003 at 10:22:18PM -0600, Curtis L. Olson wrote: So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. You might be thinking too hard about this. Yeah, I guess. But then, I'm too often a perfectionist ;-) $x = $w/2 + ($lon - $center_lon) * $deg_to_nm * $scale * $xfact; $y = $h/2 - ($lat - $center_lat) * $deg_to_nm * $scale; ($x, $y) is the coordinates (in screen space) where you should draw the object. This is known to work pretty well over a local area (assuming my typing is correct, I didn't overlook something, and you can get past the pseudo-perl syntax.) :-) Thanks, this will at least for the testing phase a good start. I have been thinking about something like this, but the ironing out the formulas above ... I just didon't how to put it all together. perl's no problem. I've did quite a bit of perl hacking some time ago. Thanks again, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Duplicate Symbols in FGTurbine?
When building on MacOS X, I got the following warnings. Since I don't use JSBSim too much, I wasn't too worried. Jonathan Polley ranlib: same symbol defined in more than one member in: libJSBSim.a (table of contents will not be sorted) ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doCombustorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doCombustorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doCompressorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doCompressorEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doTransitionEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine12doTransitionEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine18doConvergingNozzleEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine18doConvergingNozzleEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine22ThrottleToPowerCommandEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine22ThrottleToPowerCommandEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4LoadEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4LoadEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4rtauEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine4rtauEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine5DebugEi ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine5DebugEi ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine7doInletEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine7doInletEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine8PowerLagEdd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine8PowerLagEdd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9CalculateEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9CalculateEd ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9doTurbineEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine9doTurbineEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC1EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC1EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC2EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC2EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC4EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineC4EPNS_9FGFDMExecEPNS_12FGConfigFileE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD0Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD0Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD1Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD1Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD2Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD2Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD4Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbineD4Ev ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZTVN6JSBSim9FGTurbineE ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZTVN6JSBSim9FGTurbineE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: xml property documentation
Erez Boym writes: Well, I'm new to FlightGear tweaking, but I find it strange that to use flight gear (Add objects, add aircrafts etc.) you have to search the source files, just to find these xml properties that will enable me to do that work. You can also examine the tree live in the online property browser -- that's probably the best approach (it's the one I use). I agree that we need documentation, but no one has stepped forward and volunteered to write any. I disagree with Norm that all FlightGear development should stop until that documentation is written -- if we used that rule, we wouldn't have ATC, 3D cockpits, runway lighting, and just about everything else interesting that's appeared in FlightGear over the past couple of years. In my inexpert eyes it's something we must maintain otherwise we limit FlightGear usage to code reader experts that can tweak the source files. Normal users that only want to add things to flight gear would be left out or bug mailing lists for these properties. If you're volunteering, you're very welcome. I agree that the work is critical, and it's a good way for a non-coder to make a major contribution to the project. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Duplicate Symbols in FGTurbine?
When building on MacOS X, I got the following warnings. Since I don't use JSBSim too much, I wasn't too worried. Jonathan Polley ranlib: same symbol defined in more than one member in: libJSBSim.a (table of contents will not be sorted) ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv I'm wondering if you have a Makefile that is correct ... ? Jon JON S. BERNDT Coordinator, JSBSim Project www.JSBSim.org [EMAIL PROTECTED] smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Re: xml property documentation
David Megginson writes: I agree that we need documentation, but no one has stepped forward and volunteered to write any. I disagree with Norm that all FlightGear development should stop until that documentation is written -- if we used that rule, we wouldn't have ATC, 3D cockpits, runway lighting, and just about everything else interesting that's appeared in FlightGear over the past couple of years. David that is BS you are completely misrepresenting my position I am not saying stop development I am saying features need documentation as they are written The time to start this paractice is NOW and the properties need to be documented as much as if not more so then the 'C' code as there are fewer tools to automate this FlightGear is no one individual's project but a collective undertaking which requires good communication and documentation is a major part of this. It is the responsibility of the person introducing new features and or change to document said feature or change at least in a minimal way not the job of a post facto document writer because as history shows the documentation will never get written !! regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Thanks, Jonathan Polley On Monday, February 10, 2003, at 08:11 PM, Jon Berndt wrote: When building on MacOS X, I got the following warnings. Since I don't use JSBSim too much, I wasn't too worried. Jonathan Polley ranlib: same symbol defined in more than one member in: libJSBSim.a (table of contents will not be sorted) ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv ranlib: file: libJSBSim.a(FGTurbine.o) defines symbol: __ZN6JSBSim9FGTurbine11doBleedDuctEv I'm wondering if you have a Makefile that is correct ... ? Jon JON S. BERNDT Coordinator, JSBSim Project www.JSBSim.org [EMAIL PROTECTED] smime.p7s ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Duplicate Symbols in FGTurbine?
I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Delete all the .o files, and the libJSBSim.a, and libfiltersjb.a files. This will cause a rebuild of the JSBSim code. If you want to rebuild the make files ... I don't know. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Duplicate Symbols in FGTurbine?
Jon Berndt writes: I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Delete all the .o files, and the libJSBSim.a, and libfiltersjb.a files. This will cause a rebuild of the JSBSim code. If you want to rebuild the make files ... I don't know. try % make distclean % autogen.sh % ./configure % make Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
It beats me. I did a make clean and make distclean and both yielded the same results as before. The current development tools contain gcc 3.1. Is anyone else running that version of gcc, or has everyone jumped to 3.2? Thanks, Jonathan Polley On Monday, February 10, 2003, at 09:04 PM, Norman Vine wrote: Jon Berndt writes: I have the latest and greatest from CVS. I ran ./autogen.sh and ./configure, without any change. Is there something that I can do to force a rebuild (aside from deleting the Makefiles by hand, that is). Delete all the .o files, and the libJSBSim.a, and libfiltersjb.a files. This will cause a rebuild of the JSBSim code. If you want to rebuild the make files ... I don't know. try % make distclean % autogen.sh % ./configure % make Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Duplicate Symbols in FGTurbine?
Jonathan Polley writes: It beats me. I did a make clean and make distclean and both yielded the same results as before. The current development tools contain gcc 3.1. Is anyone else running that version of gcc, or has everyone jumped to 3.2? Hmm... You could try deleting the JSBSim directory then try the desparate man's approach % cvs up % autogen.sh; ./configure; make if that doesn't work then you have got me stumped too Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
Bernie Bright writes: I used your structures as a starting point. However the needs of the editor and the xml format forced some changes. But we are in the same ballpark. Here are some snippets from a KSFO taxiway file with some commentary: nodes node latitude type=double37.615023/latitude longitude type=double-122.356881/longitude nodetype type=stringNormal/nodetype /node node n=4 latitude type=double37.620940/latitude longitude type=double-122.370852/longitude nodetype type=stringHold/nodetype /node /nodes There are two types of nodes, Normal and Hold-Short. Borrowing from my driving sim experience. The approach I've seen is that the logical road network is composed of nodes and roads. Any number of roads can intersect at a node. In addition, a road section can be composed of multiple points defining any sort of shape, curve, straight, or combination of that. Each road section can define a number of lanes (and their direction.) (Probably not needed for us) :-) You attach things like signal lights, gates, (hold short points?) to any of the sub points in a road section. Unlike yours they don't contain an elevation but that shouldn't be too hard to add if required, it is available from the underlying fgsd tile/airport object. Elevation is an interesting debate. If you include elevation in the logical road network, then you don't need to query the terrain for all you different objects as they move around. Terrain intersection querying is pretty expensive so that's a consideration. But, if you store elevation in the LRN, then there is a chance for any number of reasons that it could diverge from the actual terrain then you run the risk of cars flying through air and 747's driving underground and that can get pretty wierd too. They also don't have your E-code or a name. I think these properties belong to the connecting arc/segment. gates gate latitude type=double37.615096/latitude longitude type=double-122.381158/longitude gatetype type=stringGateHeavy/gatetype radius type=double0.00/radius heading type=double0.00/heading /gate /gates There are 11 gate types for commercial, cargo, GA, military and seaplane aircraft. I haven't got around to inputting the radius and heading values yet, hence the zeros. segments segment type type=stringtaxiway/type node1 type=int0/node1 node2 type=int1/node2 name type=stringC/name width type=int110/width /segment segment n=55 type type=stringrunway/type node1 type=int35/node1 node2 type=int41/node2 name type=string10R/28L/name width type=int200/width /segment What you call an arc I call a segment. Don't know why but there it is. There are 3 types, taxiway, runway and gate. The values for node1 and node2 are indexes into the nodes array. In the case of a gate connector, node2 is an index into the gates array. I have a width instead of a weight but its purpose is the same. Thats it for now. There also needs to be some additonal logic for the ATC to determine how to navigate from a gate via one or more taxiways to a runway and vice versa. Departures could be hard wired into the xml file, eg Gate 4 via taxiways Alpha, Charlie, hold short runway 28R, but arrivals will probably have to be calculated at runtime. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GLXBadRenderRequest
The message you get indicates that probably something isn't installed right with the nvidia drivers ... but I'm not a mandrake user so I don't know for sure. Can you run the plib demos? Can you tell if the 3d demos you are running are being software rendered or are you getting fast hardware rendering (find a demo with texturing and you should be getting lightning fast frame rates ... if you are seeing 1fps or 5fps or something of that magnitude, you probalby need to investigate your drivers/config/setup.) Regards, Curt. Rick writes: Hi, I put the following message on the users mailing list and it doesn't seem that anyone there can help. Can anyone here give any insight? The 3D demos all work and I'm running Mandrake 9.0 with a NVIDIA GeForce4 Ti 4200. FlightGear-0.9.1 Finally got FG to complie, but when I try to start it, I get the following message. This is after it sets up the default airplane(C172) and airport(KSFO). Any ideas? Thanks in advance. First time, doing precise gst General Initialization === == FG_ROOT = /usr/local/data Initializing scenery subsystem Initializing basic built-in commands: null exit load save panel-load panel-mouse-click preferences-load view-cycle screen-capture tile-cache-reload lighting-update property-toggle property-assign property-adjust property-multiply property-swap property-scale gui presets_commit X Error of failed request: GLXBadRenderRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 44 Current serial number in output stream: 45 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Manuel Bessler writes: $x = $w/2 + ($lon - $center_lon) * $deg_to_nm * $scale * $xfact; $y = $h/2 - ($lat - $center_lat) * $deg_to_nm * $scale; ($x, $y) is the coordinates (in screen space) where you should draw the object. This is known to work pretty well over a local area (assuming my typing is correct, I didn't overlook something, and you can get past the pseudo-perl syntax.) :-) Thanks, this will at least for the testing phase a good start. I have been thinking about something like this, but the ironing out the formulas above ... I just didon't how to put it all together. perl's no problem. I've did quite a bit of perl hacking some time ago. I worked this stuff out as part of perl-tk moving map / approach deviation grapher I'm building for a side project. I hope to get authorized to release as open-source some day... been working a couple angles, we'll see... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D-modeling
Matt Thanks for the link, I just got blender going on my vector linux last week so the timing is perfect. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:17:27 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: [snip] Unlike yours they don't contain an elevation but that shouldn't be too hard to add if required, it is available from the underlying fgsd tile/airport object. Elevation is an interesting debate. If you include elevation in the logical road network, then you don't need to query the terrain for all you different objects as they move around. Terrain intersection querying is pretty expensive so that's a consideration. But, if you store elevation in the LRN, then there is a chance for any number of reasons that it could diverge from the actual terrain then you run the risk of cars flying through air and 747's driving underground and that can get pretty wierd too. Good point. The taxiway editor can get the node elevation from the underlying airport tile. Of course if the scenery is regenerated then the taxiways should be regenerated also. This may be no more than a load and save operation but currently must be performed manually. The other gotcha is that we would only know the elevation at either end of a segment. A vehicle travelling along the segment would still have to query the terrain engine. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:17:27 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: I used your structures as a starting point. However the needs of the editor and the xml format forced some changes. But we are in the same ballpark. Here are some snippets from a KSFO taxiway file with some commentary: nodes node latitude type=double37.615023/latitude longitude type=double-122.356881/longitude nodetype type=stringNormal/nodetype /node node n=4 latitude type=double37.620940/latitude longitude type=double-122.370852/longitude nodetype type=stringHold/nodetype /node /nodes There are two types of nodes, Normal and Hold-Short. Borrowing from my driving sim experience. The approach I've seen is that the logical road network is composed of nodes and roads. Any number of roads can intersect at a node. In addition, a road section can be composed of multiple points defining any sort of shape, curve, straight, or combination of that. Pretty much what I've done so far. Each road section can define a number of lanes (and their direction.) (Probably not needed for us) :-) Taxiway or runway are segment properties we would need to know. Some sort of width or weight property would be useful so that heavies don't try to taxi down a path not capable of handling them. You attach things like signal lights, gates, (hold short points?) to any of the sub points in a road section. Here is a link http://users.bigpond.net.au/bbright/fgsd.png to a screen dump of my current efforts. Taxiway F has been selected, highlighted in yellow. Red dots are hold-short nodes. Blue dots are normal nodes. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
