Re: [Flightgear-devel] Error message from the latest CVS
Ampere K. Hardraade wrote: Dialog scenery_loading not defined The message only appears when one is in KSFO. As for other airports, the message doesn't appear; neither does the scenery. All there is is an ocean. Is you base package in sync with FlightGear? Both FlightGear and the base package where modified for this feature. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Ampere K. Hardraade wrote: I'm sorry, but I still don't get it. Take a look at FlightGear/data/Aircraft/f16/Models/f16.xml: ?xml version=1.0? PropertyList pathf16.ac/path offsets z-m0.15/z-m pitch-deg0.3/pitch-deg /offsets !-- Submodels -- model nameRudderPedals/name pathAircraft/f16/Models/rudder_pedals.xml/path offsets x-m-5.05/x-m y-m0.0/y-m z-m0.14/z-m /offsets /model model nameThrottle/name pathAircraft/f16/Models/throttle.xml/path offsets x-m-4.25/x-m y-m-0.435/y-m z-m0.185/z-m /offsets /model !-- Panels -- model nameICP/name pathAircraft/f16/Models/icp.ac/path offsets x-m-4.635/x-m y-m0.0/y-m ... You can see it is possible to include another animation file in the main animation file just by pointing to the second order animation file (rudder pedals and throttle in this case) instead of pointing to the geometry file directly. I believe this is what you want, isn't it? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Is 'Scenery Loading...' mandatory ?
Is there a way to avoid the initial lock for scenery loading ? I understand this is a must have for users, but it slows down development speed dramatically when you have to test the apparence of a new building or landmark. Another point: FPS counter is off by default now. It was on before. Is it intended ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flight plan missing files
There is a caught exception ( so it is harmless ) in the XML reader because files are not in the base package. Those files are : Data/AI/FlightPlans/KSFO-KSEA.xml Data/AI/FlightPlans/KSEA-KSFO.xml Are the names generated randomly or are they really missing ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Is 'Scenery Loading...' mandatory ?
Another point: FPS counter is off by default now. It was on before. Is it intended ? Oh, I see it is in the rendering option dialog ( I was going to add it ;-) so it is probably better like that. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: Scenery Designer
Peter Larson wrote: Boris, thanks. It appears to be the Crease command. I created a box, removed the crease and it imported OK (now I have to work through how to save the scenery so that it gets picked up by the Sim!). As I said, I'm new to this (as in just the last 4 days) and have no experience with plib. Is there a list anywhere of the AC3d commands that plib doesn't support? This is the only one that is new to AC3d v4. If you have more specific question concerning fgsd, ask them on the fgsd mailing list. Are you able to send me privately a small model with the crease command so that I am able to see what is going on in fgsd ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight plan missing files
On Saturday 24 July 2004 10:13, Frederic Bouvier wrote: There is a caught exception ( so it is harmless ) in the XML reader because files are not in the base package. Those files are : Data/AI/FlightPlans/KSFO-KSEA.xml Data/AI/FlightPlans/KSEA-KSFO.xml Are the names generated randomly or are they really missing ? Neither, actually. For now, this is by design. The AIFlightplan constructor that the traffic manager calls tries first to open a pre-exsisting flightplan. If that doesn't work, however, it reverts to a fallback procedure that creates a flightplan dynamically. I would like to keep that functionality, although I'm not sure if using the exception mechanism is the best way to do this. I'm interested in your folks' opinions. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight plan missing files
Durk Talsma wrote: On Saturday 24 July 2004 10:13, Frederic Bouvier wrote: There is a caught exception ( so it is harmless ) in the XML reader because files are not in the base package. Those files are : Data/AI/FlightPlans/KSFO-KSEA.xml Data/AI/FlightPlans/KSEA-KSFO.xml Are the names generated randomly or are they really missing ? Neither, actually. For now, this is by design. The AIFlightplan constructor that the traffic manager calls tries first to open a pre-exsisting flightplan. If that doesn't work, however, it reverts to a fallback procedure that creates a flightplan dynamically. I would like to keep that functionality, although I'm not sure if using the exception mechanism is the best way to do this. I'm interested in your folks' opinions. My opinion is that exceptions are good if they are caught. It is just that it appeared few days ago that missing files were throwing uncaught exceptions and I was wondering if all mandatory files were included before the release. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
Peter Larson wrote: Not sure this is the right forum, I'm getting coloured apostraphe shapes around 200 pixels high on the screen. They appear to be related to runway lights. They also appear while the sim is in the air. I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte GA-7VT600 motherboard. Drivers all loaded within the last week. Any ideas? Regards Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I also have this problem, and have been having it for several months, using many different CVS versions and several different fglrx versions. You can make it go away by turning off enhanced runway lighting. Do you also get segfault s after flying at night for a few minutes? I have this problem as well, though it started later (I think), but not by much. I have no workaround for this one. I have a few straces that all end the same way laying around from this one, if anyone is interested in looking at them. Also, with the latest ATI driver, I started seeing random ground vertexes shifted around, sometimes leaving entire ground polys up in the air, and many holes in the terrain. These come and go as I move about and are most common over airports. I haven't gone back to an old driver to confirm that this is in fact the driver, and not a coincidence of updating the driver and fgfs source code at the same time, though I'm pretty sure it was the driver update that started it. display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 8500 DDR Generic OpenGL version string: 1.3 (X4.3.0-3.9.0) Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386 GNU/Linux Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
On Saturday 24 July 2004 14:38, Josh Babcock wrote: Peter Larson wrote: Not sure this is the right forum, I'm getting coloured apostraphe shapes around 200 pixels high on the screen. They appear to be related to runway lights. They also appear while the sim is in the air. I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte GA-7VT600 motherboard. Drivers all loaded within the last week. Any ideas? Regards Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I also have this problem, and have been having it for several months, using many different CVS versions and several different fglrx versions. You can make it go away by turning off enhanced runway lighting. Do you also get segfault s after flying at night for a few minutes? I have this problem as well, though it started later (I think), but not by much. I have no workaround for this one. I have a few straces that all end the same way laying around from this one, if anyone is interested in looking at them. Also, with the latest ATI driver, I started seeing random ground vertexes shifted around, sometimes leaving entire ground polys up in the air, and many holes in the terrain. These come and go as I move about and are most common over airports. I haven't gone back to an old driver to confirm that this is in fact the driver, and not a coincidence of updating the driver and fgfs source code at the same time, though I'm pretty sure it was the driver update that started it. display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 8500 DDR Generic OpenGL version string: 1.3 (X4.3.0-3.9.0) Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386 GNU/Linux Josh I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Are you able to fly at night i.e. when the sun is below the horizon? If I try flying in these conditions FG starts but crashes once I get a few hundred feet in the air and I think this is also due to the ATI drivers. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
On Saturday 24 July 2004 15:35, Lee Elliott wrote: On Saturday 24 July 2004 14:38, Josh Babcock wrote: Peter Larson wrote: Not sure this is the right forum, I'm getting coloured apostraphe shapes around 200 pixels high on the screen. They appear to be related to runway lights. They also appear while the sim is in the air. I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte GA-7VT600 motherboard. Drivers all loaded within the last week. Any ideas? Regards Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I also have this problem, and have been having it for several months, using many different CVS versions and several different fglrx versions. You can make it go away by turning off enhanced runway lighting. Do you also get segfault s after flying at night for a few minutes? I have this problem as well, though it started later (I think), but not by much. I have no workaround for this one. I have a few straces that all end the same way laying around from this one, if anyone is interested in looking at them. Also, with the latest ATI driver, I started seeing random ground vertexes shifted around, sometimes leaving entire ground polys up in the air, and many holes in the terrain. These come and go as I move about and are most common over airports. I haven't gone back to an old driver to confirm that this is in fact the driver, and not a coincidence of updating the driver and fgfs source code at the same time, though I'm pretty sure it was the driver update that started it. display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 8500 DDR Generic OpenGL version string: 1.3 (X4.3.0-3.9.0) Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386 GNU/Linux Josh I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Are you able to fly at night i.e. when the sun is below the horizon? If I try flying in these conditions FG starts but crashes once I get a few hundred feet in the air and I think this is also due to the ATI drivers. LeeE Oops! - I see you already have the night problem too - dunno why I missed that. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] create craters and smoke effect
On Thu, 22 Jul 2004 20:02:25 -, Jim wrote in message [EMAIL PROTECTED]: Andy Ross said: CHANDRASEKHAR ACHALLA wrote: I am doing a project for Boeing where I am trying to incorporate a few additional features they want into Flightgear. Initially I need to create a crater (hole) if a plane crashes (or a missile ). Boing wants craters? :) That's it! I'm flying on Aerobus airliners only from now on. ..it couldn't be their and not their own, they're modelling? ;-) snip Alternatively, I suppose you could alpha-blend a 2D crater image on top of the existing geometry; something along the lines of the bullet holes that first person shooter games like to draw on walls. For a flight simulator where the viewpoint isn't likely to be very near the crater, this might be sufficient. Yes and much easier. You could even just make a model that was mostly flat but had a crater lip with burnt dirt texture and all that and just plop it on the ground in the right spot. ..crater size and depht depends on impact energy etc in RL, so you're having your FG crater act accordingly? -- ..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] create craters and smoke effect
On Thu, 22 Jul 2004 21:27:02 -0400, Ampere wrote in message [EMAIL PROTECTED]: On July 22, 2004 02:13 pm, CHANDRASEKHAR ACHALLA wrote: I need to create a crater (hole) if a plane crashes Plane crash doesn't create craters. All there is is a black patch. ..depends on the what is hit by what, and how. ;-) (or a missile ) ... . I also need to simulate smoke and fire coming out of the crater. If you also want the aircraft to break apart, you can try using the MD11. I have designed it so that many parts are individual objects. If anyone wants to create realistic plane crash scene for the MD11, he or she can give one object after another an independent trajectory. ..ooo, that means FG can be used to reverse-engineer a wreakage trail. -- ..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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message [EMAIL PROTECTED]: On Friday 23 July 2004 15:23, Jim Wilson wrote: Sure enough, it's right there in Stroustrup. The strange part is never having noticed this before now. What is it with these developers at microsoft anyway? ;-) Since when have they had developers? ..define developer, the SCO Group claims to have 4000 world wide. ;-) -- ..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
[Flightgear-devel] compilation of current cvs version fails
Hello, Today i tried to compile the current cvs version of flightgear and get the following error messages: make[2]: Entering directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lopenal -ldl -lm /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x634): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:165: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x676):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:166: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6b4):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:167: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6f2):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:168: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x71f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:169: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x74f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:170: more undefined references to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' follow /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x8ac): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:180: undefined reference to `GetMinMaxBoxVerts(float const*, float const*, float (*) [3])' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src' make: *** [all-recursive] Error 1 Any ideas to fix this? I tried this on Slackware 10.0 with the current cvs version of SimGear, OpenAL and Plib. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: Laptop! - Frame Rate
Hi, Got my Laptop, installed Linux, installed the latest ATI driver (although only running SuSe's 9.1 updated kernel - 2.6.5) I'm running fgl_glxgears (probably not an unbiased test given it's ATIs code I would guess). I'm getting 490fps - looks good. I'm going to investigate exactly what ATI provide now. I started off with their packages this morning, had to do a few mods to get it compiling... then noticed that SuSe are providing a customised version that runs out of the box... now using that. I'll let you know fg frames rates in the short term future. Regards, Chris. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation of current cvs version fails
I'd start by recompiling and reinstalling all of simgear ... if you've upgraded your compilers recently, code compiled with the new C++ compiler may not be able to link against code compiled with an older version. Regards, Curt. Oliver C. wrote: Hello, Today i tried to compile the current cvs version of flightgear and get the following error messages: make[2]: Entering directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lopenal -ldl -lm /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x634): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:165: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x676):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:166: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6b4):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:167: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6f2):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:168: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x71f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:169: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x74f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:170: more undefined references to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' follow /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x8ac): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:180: undefined reference to `GetMinMaxBoxVerts(float const*, float const*, float (*) [3])' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src' make: *** [all-recursive] Error 1 Any ideas to fix this? I tried this on Slackware 10.0 with the current cvs version of SimGear, OpenAL and Plib. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED]
Re: [Flightgear-devel] lights flaring on runways in FG
Frederic Bouvier wrote: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel If someone gives me an ftp site to put them on. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
Lee Elliott wrote:
Are you able to fly at night i.e. when the sun is below the horizon? If I try
flying in these conditions FG starts but crashes once I get a few hundred
feet in the air and I think this is also due to the ATI drivers.
Yeah, that's the problem I get. Once the sun is below the horizon, I have about
one hundred seconds until it segfaults. With the old ATI driver, this would
hang X, but the latest one survives fgfs segfaulting. The end of the stack
trace always looks roughly the same too:
read(14, 0xa57f244, 8) = -1 EAGAIN (Resource temporarily
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xb668)= 0
getpid()= 4368
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1090465804, 754367}, {240, 0}) = 0
time(NULL) = 1090465804
time(NULL) = 1090465804
gettimeofday({1090465804, 754995}, {240, 0}) = 0
gettimeofday({1090465804, 755221}, {240, 0}) = 0
select(1024, [12 13], [13], NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 1090465804
read(14, 0xa57f244, 8) = -1 EAGAIN (Resource temporarily
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xb668)= 0
getpid()= 4368
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1090465804, 793631}, {240, 0}) = 0
time(NULL) = 1090465804
time(NULL) = 1090465804
gettimeofday({1090465804, 794071}, {240, 0}) = 0
gettimeofday({1090465804, 794347}, {240, 0}) = 0
gettimeofday({1090465804, 794391}, {240, 0}) = 0
time(NULL) = 1090465804
read(14, 0xa57f244, 8) = -1 EAGAIN (Resource temporarily
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
No. What I want to do is tell each of these animation file where the livery resides. I want to be able to tell all of them with in one single file, instead of having to create a new xml file for every animation file. Regards, Ampere On July 24, 2004 03:37 am, Erik Hofman wrote: I believe this is what you want, isn't it? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error message from the latest CVS
I believe so. I am using the 0.9.5-pre-2 base package . Regards, Ampere On July 24, 2004 03:29 am, Erik Hofman wrote: Ampere K. Hardraade wrote: Dialog scenery_loading not defined The message only appears when one is in KSFO. As for other airports, the message doesn't appear; neither does the scenery. All there is is an ocean. Is you base package in sync with FlightGear? Both FlightGear and the base package where modified for this feature. Erik ___ 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] lights flaring on runways in FG
Send them to me in an attachment. Regards, Ampere On July 24, 2004 12:04 pm, Josh Babcock wrote: If someone gives me an ftp site to put them on. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation of current cvs version fails
On Saturday 24 July 2004 17:41, Curtis L. Olson wrote: I'd start by recompiling and reinstalling all of simgear ... if you've upgraded your compilers recently, code compiled with the new C++ compiler may not be able to link against code compiled with an older version. Regards, Curt. Thank you very much, that worked. :) I forgot to do a make clean in my SimGear CVS directory. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Tried the Spitfire
Vivian Meazza wrote: Sent: 23 July 2004 20:15 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Tried the Spitfire Jim Wilson wrote: Sent: 23 July 2004 16:01 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Tried the Spitfire Very nice! Ok if I borrow the pilot dude for the p51 cockpit? Please do - but note that he's wearing RAF blue serge trousers (pants :- )), and 1940's pattern life jacket (vest) and the wrong flying helmet/goggles. I expect some smarty pants will notice. I'm going to animate him shortly. Now, should it come up running like the other A/C? My personal preference is to not, but I think in the past folks have prefered aircraft already started. Tough one, because when I get the propeller sorted there should be the possibility that the aircraft will nose over if started on full throttle. FWIW (after release) I think a preset e.g. --auto-start that defaulted to true, and was overridden as true automatically for mid air starts, but otherwise could be set false by the user so aircraft never come up running on the ground would be nice. Along this line it should be possible to have aircraft running after reset as well if --auto-start was enabled. I like it - it's the way that Flight2 does it. Personally, I like to start with the engine shut down. It forces pre-start checks, and makes the whole thing more realistic. I was also following the example of the Bo105. I'm just working on the fuel gauge for the Spitfire, when I ralised that I haven't modeled the fuel system correctly. At present both tanks feed into the engine. What should happen is that the upper tank feeds the lower tank which feeds the engine. Is there any built-in way of doing this? Advice would be most welcome, otherwise I guess it's some fairly complex NASAL? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Frederic Bouvier [EMAIL PROTECTED] writes:
Is there a way to avoid the initial lock for scenery loading ?
I understand this is a must have for users, but it slows
down development speed dramatically when you have to test the
apparence of a new building or landmark.
i think the fix for the scenery loading is not quite right. with it i
get a very strange spitfire cockpit (i.e. i can see through the
instrument panel and the body of the aircraft). looks like z-buffer
ordering is not done properly (screen depth is 16bp, using the radeon
freedesktop drivers). if i disable it, the cockpit looks normal again.
if could only figure out how to start the damn plane...
btw, the attached patch backs out of the scenery loading hack.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.173
diff -u -r1.173 main.cxx
--- main.cxx 23 Jul 2004 07:33:24 - 1.173
+++ main.cxx 24 Jul 2004 18:27:09 -
@@ -1209,13 +1209,13 @@
if ( global_multi_loop 0) {
// first run the flight model each frame until it is intialized
// then continue running each frame only after initial scenery load is complete.
-if (!cur_fdm_state-get_inited() || fgGetBool(sim/sceneryloaded)) {
+//if (!cur_fdm_state-get_inited() || fgGetBool(sim/sceneryloaded)) {
fgUpdateTimeDepCalcs();
-} else {
-// only during scenery load
-NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
-gui-showDialog(scenery_loading);
-}
+//} else {
+//// only during scenery load
+//NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
+//gui-showDialog(scenery_loading);
+//}
} else {
SG_LOG( SG_ALL, SG_DEBUG,
Elapsed time is zero ... we're zinging );
@@ -1339,12 +1339,12 @@
// END Tile Manager udpates
-if (!fgGetBool(sim/sceneryloaded) globals-get_tile_mgr()-all_queues_empty() cur_fdm_state-get_inited()) {
-fgSetBool(sim/sceneryloaded,true);
+//if (!fgGetBool(sim/sceneryloaded) globals-get_tile_mgr()-all_queues_empty() cur_fdm_state-get_inited()) {
+//fgSetBool(sim/sceneryloaded,true);
// probably not efficient way to popup msg, but is done only during scenery load
-NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
-gui-closeDialog(scenery_loading);
-}
+//NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
+//gui-closeDialog(scenery_loading);
+//}
if (fgGetBool(/sim/rendering/specular-highlight)) {
glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL, GL_SEPARATE_SPECULAR_COLOR);
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Tried the Spitfire
Ampere K. Hardraade wrote: Sent: 24 July 2004 18:58 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tried the Spitfire Can't you make it so that the engine feeds off the upper tank before it feeds on the lower tank? Regards, Ampere On July 24, 2004 01:42 pm, Vivian Meazza wrote: I'm just working on the fuel gauge for the Spitfire, when I ralised that I haven't modeled the fuel system correctly. At present both tanks feed into the engine. What should happen is that the upper tank feeds the lower tank which feeds the engine. Is there any built-in way of doing this? Advice would be most welcome, otherwise I guess it's some fairly complex NASAL? Regards, Vivian That is of course equivalent, and might well be the way to implement it in practice. How? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Alex Romosan wrote: Sent: 24 July 2004 19:35 To: FlightGear developers discussions Subject: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ? Frederic Bouvier [EMAIL PROTECTED] writes: Is there a way to avoid the initial lock for scenery loading ? I understand this is a must have for users, but it slows down development speed dramatically when you have to test the apparence of a new building or landmark. i think the fix for the scenery loading is not quite right. with it i get a very strange spitfire cockpit (i.e. i can see through the instrument panel and the body of the aircraft). looks like z-buffer ordering is not done properly (screen depth is 16bp, using the radeon freedesktop drivers). if i disable it, the cockpit looks normal again. if could only figure out how to start the damn plane... btw, the attached patch backs out of the scenery loading hack. It starts exactly the way it says in the POH. Magneto switches to on, advance throttle a little, press start button, keep pressed until engine fires. If it fails to fire, re-index the Coffman starter by pulling the ringpull, then try again. You have 6 cartridges. To stop, pull the cut-off ring pull. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Vivian Meazza [EMAIL PROTECTED] writes:
It starts exactly the way it says in the POH.
Magneto switches to on, advance throttle a little, press start button, keep
pressed until engine fires.
so, in terms of keyboard commands this should be { } (magneto switches
on) and then press space bar?
If it fails to fire, re-index the Coffman starter by pulling the ringpull,
then try again. You have 6 cartridges.
it does. so i press C and try space bar again. the propeller sputters
a bit and that's it.
To stop, pull the cut-off ring pull.
i'll deal with that once i manage to start the engine... :-)
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Let's get back to this one :-) Erik Hofman wrote: Boris Koenig wrote: I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels). Ok. Lets start a *minimal* list of items that really are needed for this and skip the implementation part for now. This is what I think what would be needed (feel free to add your ideas). Anything else (remember, this is the *absolute minimum*)? Besides the things that I mentioned already in the original short ;-) reply to your message, I think the two most important things would currently be: - basic functionality to deal with XML files (using Nasal) - dynamic creation population/modification of controls/dialogs using Nasal Also, some more customization of the current PUI XML-bindings might be necessary, in order to be able to tailor dialogs/controls (i.e. transparency/movable flag) - Andy mentioned something like this already - if you take a look at the screenshot on the FliteTutor concept webpage, you'll notice for example, that the combo box in the upper left corner opens upwards, while it should -in this case- actually open downwards (otherwise the menu contents aren't visible anymore). Using PUI directly it's afaIk possible to specify such details - hence it shouldn't be too complicated to add a corresponding option to the XML-PUI layer. I would be willing to make the necessary modifications myself, also to add things like basic font formatting - would these changes then be accepted for the official CVS version ? You know, that's the actual problem I was having, also regarding the whole plugin stuff that I mentioned: making such modifications directly to FlightGear sources would always require these things to be accepted for FlightGear itself, while having a separate library taking care of this stuff wouldn't require any direct access to FlightGear in most cases, hence one wouldn't rely on a particular FlightGear release/build to be able to use a new function, which is actually not even part of FlightGear itself... Regarding the standard FlightGear menubar, I think it might be useful to optionally make it auto-hide/show - that way it would only be displayed if the mouse is in the corresponding area, and fade out as soon as the mouse leaves that area. In the end, I don't mean to blow up Nasal, but rather use some scripts as backend library to load display a set of pages - but of course this would still require some additions to the current command set. But I don't think this would be too dramatic, on the other hand adding a couple of new functions/bindings might also create new possibilites, one might even start to create things like a FMC based on Nasal. Hope this mail was short enough ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --fog-fastest --fog-disabled - the latter w/o update below horizon ?
On Sat, 24 Jul 2004 21:32:25 +0200 Boris Koenig [EMAIL PROTECTED] wrote: A couple of other things: I *did* search, but didn't find a way to directly set the heading of an aircraft if you want to position it in air - if it's there already, please tell me where :-) If it isn't it might be worth to be added ? What did you search? Place #1: } stax:~-534 fgfs --help --verbose } } Usage: fgfs [ option ... ] } } General Options: } --help, -h Show the most relevant command line options } --verbose, -vShow all command line options when combined }with --help or -h } --fg-root=path Specify the root data path } --fg-scenery=pathSpecify the base scenery path; }Defaults to $FG_ROOT/Scenery } --language=code Select the language for this session [ snip ] } --lon=degreesStarting longitude (west = -) } --lat=degreesStarting latitude (south = -) } --altitude=value Starting altitude }(in feet unless --units-meters specified) } --heading=degreesSpecify heading (yaw) angle (Psi) ^^ Place #2: in Docs/getstart.pdf, Chapter 4 Takeoff: How to start the program, Section 4 Command Line Parameters, we come to 4.4.5, Initial Position and Orientation, which gives the same info as above. This can also be found in the HTML version of this document, at Docs/InstallGuide/html/getstart.html (click on 4.4, Command line parameters). Regarding the navaids discussion I'd like to know if airports are currently exclusively bound to the scenery, actually I was looking for some airports that FlightGear also finds, but didn't see any rwys - if airports should really depend on specific scenery to be installed, it might be worth to think about separating airports from scenery - at least the basics like runways etc ...or what else is the reason for not _seeing_ an airport which FlightGear actually knows of ? Can you rephrase this? I can't figure out what it is that you're saying here. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpXSqw8xqFYr.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Chris Metzler [EMAIL PROTECTED] writes: Regarding the navaids discussion I'd like to know if airports are currently exclusively bound to the scenery, actually I was looking for some airports that FlightGear also finds, but didn't see any rwys - if airports should really depend on specific scenery to be installed, it might be worth to think about separating airports from scenery - at least the basics like runways etc ...or what else is the reason for not _seeing_ an airport which FlightGear actually knows of ? Can you rephrase this? I can't figure out what it is that you're saying here. the graphics part of the airports _is_ part of the scenery. FlightGear looks up the latitude and longitude and the position and heading of the runways (in runways.dat) but if the scenery is not there there are no graphics to be loaded so you get positioned over the ocean. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Chris Metzler wrote: On Sat, 24 Jul 2004 21:32:25 +0200 Boris Koenig [EMAIL PROTECTED] wrote: A couple of other things: I *did* search, but didn't find a way to directly set the heading of an aircraft if you want to position it in air - if it's there already, please tell me where :-) If it isn't it might be worth to be added ? What did you search? sorry, I was reffering to the Set Position dialog within FlightGear, not any command line options, I do know that you can set these manually or use directly the property tree, but I thought it might make sense to directly include that option within the corresponding dialog. And that's where I was looking for that option, because I thought it would make sense to be there !? Can you rephrase this? I can't figure out what it is that you're saying here. lol, simple: FlightGear knows of various airports that I can pick to start at, but these airports aren't all *visible* within FlightGear, so - even if I am sure that I am at the right coordinates I don't see a specific airport or rather runway layout. This happens also with standard airports that are selectable from the corresponding dialog. My assumption was hence, that the airports are currently bound to the scenery, as I don't have much additional scenery installed. That's why I thought that not all airports/runways might already be available. So the question is, whether that's true or if there's anything else wrong with my base package. I was a bit surprised to learn that, since I thought FlightGear uses X-Planes Navaids/Airports info - and X-Plane deals with scenery and airports separately, so it doesn't matter if I have the necessary scenery installed or not, because the airports, including the proper runway aligment will always be available, even if that means that KLAS 25 R becomes an island within the ocean ;-) Just tell me if you need even another version of this :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Alex Romosan wrote: Chris Metzler [EMAIL PROTECTED] writes: Regarding the navaids discussion I'd like to know if airports are currently exclusively bound to the scenery, actually I was looking for some airports that FlightGear also finds, but didn't see any rwys - if airports should really depend on specific scenery to be installed, it might be worth to think about separating airports from scenery - at least the basics like runways etc ...or what else is the reason for not _seeing_ an airport which FlightGear actually knows of ? Can you rephrase this? I can't figure out what it is that you're saying here. the graphics part of the airports _is_ part of the scenery. FlightGear looks up the latitude and longitude and the position and heading of the runways (in runways.dat) but if the scenery is not there there are no graphics to be loaded so you get positioned over the ocean. Hey, thanks Alex - that's exactly what I wanted to know ... So, there's no way to have the airports/runways etc. available without installing the corresponding scenery ? Hmm, bu**er :-/ How about also separating the scenery from the actual airports data ? I will untar the archive and check if it's the same format as in X-Plane, if it is it should be possible to display basic airports even without having the necessary scenery installed. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Alex Romosan said: Frederic Bouvier [EMAIL PROTECTED] writes: Is there a way to avoid the initial lock for scenery loading ? I understand this is a must have for users, but it slows down development speed dramatically when you have to test the apparence of a new building or landmark. i think the fix for the scenery loading is not quite right. with it i get a very strange spitfire cockpit (i.e. i can see through the instrument panel and the body of the aircraft). looks like z-buffer ordering is not done properly (screen depth is 16bp, using the radeon freedesktop drivers). if i disable it, the cockpit looks normal again. if could only figure out how to start the damn plane... That has got to be a bug elsewhere. This only pauses the FDM. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Is 'Scenery Loading...' mandatory ?
Frederic Bouvier said: Is there a way to avoid the initial lock for scenery loading ? I understand this is a must have for users, but it slows down development speed dramatically when you have to test the apparence of a new building or landmark. Another point: FPS counter is off by default now. It was on before. Is it intended ? -Fred Hi Fred, Just look in main.cxx where it sets: fgSetBool(sim/sceneryloaded,false); This line could probably just be removed (afik it'll default to false), then if you set it true in your .fgfsrc file it won't pause the FDM. Otherwise you could use second configuration property and use an if/else to set the above flag true or false at initialization. An even better solution for development might be a variation of reset that dumps and reloads the scenery. Especially if it left your view position the same. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Alex Romosan wrote
Sent: 24 July 2004 20:51
To: FlightGear developers discussions
Subject: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Vivian Meazza [EMAIL PROTECTED] writes:
It starts exactly the way it says in the POH.
Magneto switches to on, advance throttle a little, press start button,
keep
pressed until engine fires.
so, in terms of keyboard commands this should be { } (magneto switches
on) and then press space bar?
Yup
If it fails to fire, re-index the Coffman starter by pulling the
ringpull,
then try again. You have 6 cartridges.
it does. so i press C and try space bar again. the propeller sputters
a bit and that's it.
Yup. WFM using the downloaded version. Do you have the throttle advanced a
little, and are the magneto switches in the down position?
To stop, pull the cut-off ring pull.
i'll deal with that once i manage to start the engine... :-)
try using a mouse on the instrument panel
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: ..Coffmann starters on Merlins: [Flightgear-devel] Re: Is 'SceneryLoading...' mandatory ?
Regards, Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:flightgear-devel- [EMAIL PROTECTED] On Behalf Of Arnt Karlsen Sent: 24 July 2004 21:33 To: FlightGear developers discussions Subject: ..Coffmann starters on Merlins: [Flightgear-devel] Re: Is 'SceneryLoading...' mandatory ? On Sat, 24 Jul 2004 19:58:30 +0100, Vivian wrote in message [EMAIL PROTECTED]: It starts exactly the way it says in the POH. Magneto switches to on, advance throttle a little, press start button, keep pressed until engine fires. If it fails to fire, re-index the Coffman starter by pulling the ringpull, then try again. You have 6 cartridges. ..did the Packard Merlins also used it? No - Packard Merlins had electric start. ..how many blades (or prop or crankshaft turns) per cartridge? Common cartridge-only rpm and decay turns and time to stop (on failed starts)? Hmmm. Best I can do with the current simulator. Try it and see :-) ..on successful starts, how many blades 'till the 1'st one fires, then how many misses until smooth running idle? See above. How long is a piece of string? Depends on many factors, but I think you'll find that it sounds about right. ..it commonly starts on first, 2'nd or 3'rd etc fired? Reputedly on 1st, provided primer pump used, which I haven't implemented yet. ..can 1, 2, or 3 etc Coffmans start a flooded engine? (Assuming no cround crew assistance but corrective action by the pilot.) No info in Pilot's notes. No flooded engine procedure given, so I assume that it was either a very rare occurrence, or so common that everyone knew how to do it, so it wasn't worth explaining. Come to think about it, I'm not sure how easy it would be for ground crew to turn over a 27 litre engine (impossible?). ..approximates, obviously, ideally, someone has talked with WWII tech or pilot veterans with relevant Merlin experience. Near enough for government work :-) ..btw, did anyone fix the boost b button bug? (2-speed supercharger clutch barometer triggered at 18,000 ft or somesuch on RR in Spit mkix and Packards in P-51B onwards etc) No, but I think we understand the problem. But there again, we haven't got the propeller gearing fixed yet. And we haven't done the boost cut-out control. The boost isn't right using legacy code either. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Saitek Cyborg-Evo.xml broken
Help! Since my CH Yoke and Pedals don't work with the new joydev driver in Suse 9.1, I need to use my Saitek Cyborg Evo joystick. Both js_demo and jstest show all it's axes and buttons working but ony the non DEFANGED functions work in FlightGear (that is aileron, elevator and rudder ... no buttons). I had to edit three things in Cyborg-Evo.xml 1. The name displayed by js_demo and jstest is Saitek Cyborg USB Stick so I changed the name in the xml file. 2. Axis for hat left/right was 4 (not 6) in jstest. 3. Axis for hat fore/aft was 5 (not 7) in jstest. With these changes, only the non-DEFANGED_script functions work. Is this xml a work in progress or have I broken something else? Some day I will learn not to upgrade a working very stable system! Best regards, Dave P. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
All I am saying is that it will be a good idea to look deeper into it instead of pushing it aside. After all, from what I have read on their site, the OpenRT library seems to offer some pretty neat capabilities that aren't in the current version of plib. At the very least, we should keep this real-time-raytracing technology in mind. The idea of Microsoft come out with games that utilize real time raytracing while Linux has nothing equivilent is... freightening. Regards, Ampere On July 20, 2004 03:23 am, Jim Wilson wrote: Hmmm... that 777 Model page didn't mention a GPU. In any case, I gather from reading just the first paragraph on the OpenRT page you'd be looking at having plib utilize the OpenRT API in lieu of OpenGL's. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
On July 20, 2004 03:23 am, Jim Wilson wrote: Hmmm... that 777 Model page didn't mention a GPU. In any case, I gather from reading just the first paragraph on the OpenRT page you'd be looking at having plib utilize the OpenRT API in lieu of OpenGL's. I may be wrong, but from what I've read, openRT is indeed supposed to make use of a specific GPU - or alternatively a (cluster of) CPU(s) @ ~40 GHZ :-) But, there seems to be a project related to openRT that is dedicated to developing the necessary hardware: http://www.saarcor.de/ Seemingly, also a project of the same German university. Ampere K. Hardraade wrote: All I am saying is that it will be a good idea to look deeper into it instead of pushing it aside. After all, from what I have read on their site, the OpenRT library seems to offer some pretty neat capabilities that aren't in the current version of plib. plib makes use of openGL while openRT is a different rendering approach which doesn't utilize rasterization anymore - so I think Jim is right in saying that one would really have to drop the entire openGL approach to make use of something like that. I don't know the details, but I doubt that it would be really simple to convert to such a new approach, which wouldn't rely on openGL anymore. In the long term the openRT folks probably hope to replace the openGL implementation in many 3D applications with openRT, because it could provide a performance boost in many cases, particularly because it would no longer be necessary to process all graphics data just in order to determine which parts are really visible or not ... At the very least, we should keep this real-time-raytracing technology in mind. The idea of Microsoft come out with games that utilize real time raytracing while Linux has nothing equivilent is... freightening. I agree, the whole idea is extremely fascinating: Having had a look at some of the screenshots or even videos, the stuff seems really to be pretty amazing and powerful, but currently it's probably really a bit beyond the scope of any game, to care too much for openRT, simply because of the lack of hardware support, I think - be it a relevant GPU board or the 40 GHZ requirement for openRT :-) And then I am not even sure if there's really yet an OPEN implementation available !? As long as FlightGear keeps getting modularized even more, it should not be that much of a problem, to consider new technologies - even though this unlikely to become an issue within the next 3-5 years ;-) But on the other hand, at http://graphics.cs.uni-sb.de/RTGames you can read: We are very much interested in evaluating new ways for computer games and therefore like to cooperate with the gaming industry. Thus if you are in such a position, please send us an email mailto:[EMAIL PROTECTED]! So, now it depends if FlightGear is considered part of the gaming industry :-) But if the openRT developers are really also looking for opensource projects, it would probably be not that bad for FlightGear to at least indicate some willingness ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Are you able to fly at night i.e. when the sun is below the horizon? If I try flying in these conditions FG starts but crashes once I get a few hundred feet in the air and I think this is also due to the ATI drivers. I'm very new on FG, only been running it for two weeks. Also, my PC was just recently rebuilt, so pretty much everything in new. I was getting the segfault when I exited FG, but this disappeared when I installed the latest driver from the ATI web site. I've seen some comments that there are problems with some VIA chipsets and the ATI Radeon cards, so I have also installed the latest drivers for the motherboard. My machine was hanging when the resolution was greater than 1024 x 768, just running windows, so there is obviously some clashes there. since I did this, I havn't tried higher than 1024 resolution, so I don't know if I've actually fixed the problem. Are you using an ATI card? The problems you described are similar, especially the long distance problems. I assumed at first that is was really bad sheet lightning graphics until I noticed they were coming from the ground! I've had FG hang once in a night flight, possibly around 100 seconds, as others indicated in this thread. I'll pay more detail from now on, as I've assumed most of my problems up until now have been motherboard/video clashes. Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
