Re: [Flightgear-devel] How FlightGear handles 3ds
Ampere K. Hardraade wrote: Is it possible to have something like this: light-mappath/mon-scheme-texture.RGB/light-map Using XML to define fading in places such as the landing light and taxi light is fine, but doing so in places such as the cockpit is too much I would think. It depends a bit on the future of plib. This is part of a discussion that has to be restarted after the 0.9.5 release. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 Sounds
Jim Wilson wrote: There is a modified sound config in cvs that at least partially addresses the problems. I hope Erik doesn't mind. Neh, it really needed an update anyway. If I find some time I will try to improve the sound quality also (probably getting to back to 16-bit audio), but if any one else feels like doing it then don't let me hold you back. 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: ...code last weekend, and did this: http://www.cs.yorku.ca/~cs233144/PROTOTYPE.jpg this: http://www.cs.yorku.ca/~cs233144/FINNAIR.jpg and this: http://www.cs.yorku.ca/~cs233144/KLM.jpg Very well done Ampere! I've put them in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Loading scenery message
I've got the FDMs waiting while the scenery loads on startup. Mid air starts are smooth again and even ground starts are a little nicer, especially if you've left the throttle on the joystick open full. The screen shows the scene as it always does, the aircraft just isn't moving. Someone mentioned putting up a Loading Scenery message while this is going on. What's the best way to do this? At the moment I'm not interested in doing a fuel gauge. Just a pop-up would suffice. Tomorrow night I'll look and see if the technique still makes sense when more awake (I have a slightly different approach in mind anyway). Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading scenery message
Jim Wilson wrote: I've got the FDMs waiting while the scenery loads on startup. Mid air starts are smooth again and even ground starts are a little nicer, especially if you've left the throttle on the joystick open full. The screen shows the scene as it always does, the aircraft just isn't moving. Someone mentioned putting up a Loading Scenery message while this is going on. What's the best way to do this? At the moment I'm not interested in doing a fuel gauge. Just a pop-up would suffice. It's easy to do with a tiny Nasal script, which remains visible when a property (/sim/initialized ?) is false. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightgear interface to OpenGC
Title: Flightgear interface to OpenGC I am trying to use the OpenGC interface to Flightgear to communicate with my own custom symbology display software via a network connection. The standard documentation that comes with Flightgear does not explain how to set up a connection, at least I don't understand. Any pointers to more documentation on the options would be most appreciated. Thanks Carl Swail Tel.: (613) 998-5581 | Fax: (613) 952-1704 E-Mail: [EMAIL PROTECTED] Web Site: www.nrcaerospace.com Senior Research Officer Institute for Aerospace Research National Research Council U-61, 1200 Montreal Road, Ottawa, ON K1A 0R6Government of Canada ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading scenery message
Erik Hofman said: Jim Wilson wrote: I've got the FDMs waiting while the scenery loads on startup. Mid air starts are smooth again and even ground starts are a little nicer, especially if you've left the throttle on the joystick open full. The screen shows the scene as it always does, the aircraft just isn't moving. Someone mentioned putting up a Loading Scenery message while this is going on. What's the best way to do this? At the moment I'm not interested in doing a fuel gauge. Just a pop-up would suffice. It's easy to do with a tiny Nasal script, which remains visible when a property (/sim/initialized ?) is false. Wouldn't that end up getting invoked every frame for the life of the program? This is just a one shot thing. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading scenery message
Jim Wilson wrote: Erik Hofman said: It's easy to do with a tiny Nasal script, which remains visible when a property (/sim/initialized ?) is false. Wouldn't that end up getting invoked every frame for the life of the program? This is just a one shot thing. No, a Nasal program is in essence a one-shot program. With some tricks it is possible to get it running forever (during FlightGear's execution time).. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
Hi, So, I've got structures I've modelled in Blender that look nice. However, once they're in FlightGear, they don't look so nice. plib doesn't read .blend files, of course, so I use Blender's AC3D export to create .ac files that plib can read. I take a look at how the object looks in FlightGear, I tweak material settings in Blender, I export . . .and I notice *no difference* in how it looks in FlightGear. As near as I can tell, AC3D export doesn't honor material shading parameters. For example, tweaking the diffuse/specular reflectivity parameters produces no change whatsoever to the .ac file exported, even though the .blend file does change. Even worse, once textures are assigned, the texture files don't get exported either. There they are in the Blender renderer, but there's no texture lines showing up anywhere in the .ac file after export. Is there something I'm stupidly missing here? Thanks, -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 pgpChg3SYe8mC.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
Chris Metzler wrote: For example, tweaking the diffuse/specular reflectivity parameters produces no change whatsoever to the .ac file exported, even though the .blend file does change. Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Even worse, once textures are assigned, the texture files don't get exported either. There they are in the Blender renderer, but there's no texture lines showing up anywhere in the .ac file after export. When I add textures with the Blender UV editor, they show up fine. I haven't tried using projected textures. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading scenery message
Jim Wilson wrote: Erik Hofman said: Jim Wilson wrote: Erik Hofman said: It's easy to do with a tiny Nasal script, which remains visible when a property (/sim/initialized ?) is false. Wouldn't that end up getting invoked every frame for the life of the program? This is just a one shot thing. No, a Nasal program is in essence a one-shot program. With some tricks it is possible to get it running forever (during FlightGear's execution time).. Ah ok. Sounds good. How do I launch the script then? One method (and probably the easiest one) is to put the file in FlightGear/data/Nasal. It will then automatically be invoked at startup. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear interface to OpenGC
Swail, Carl wrote: I am trying to use the OpenGC interface to Flightgear to communicate with my own custom symbology display software via a network connection. The standard documentation that comes with Flightgear does not explain how to set up a connection, at least I don't understand. Any pointers to more documentation on the options would be most appreciated. The last thing I've read is that OpenGC and FlightGear are not compatible anymore. But you may want to check the source code in FlightGear/src/Network and search for opengc* Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear interface to OpenGC
Erik Hofman wrote: Swail, Carl wrote: I am trying to use the OpenGC interface to Flightgear to communicate with my own custom symbology display software via a network connection. The standard documentation that comes with Flightgear does not explain how to set up a connection, at least I don't understand. Any pointers to more documentation on the options would be most appreciated. The last thing I've read is that OpenGC and FlightGear are not compatible anymore. But you may want to check the source code in FlightGear/src/Network and search for opengc* Depending on what you want to do, you may not need the opengc interface. You might get by just fine with the FGNativeFDM and FGNataiveCtrls interfaces. The structure definition is public domain so you can integrate these easily with your own external applications. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
On Wed, 21 Jul 2004 10:18:25 -0400 David Megginson [EMAIL PROTECTED] wrote: Chris Metzler wrote: For example, tweaking the diffuse/specular reflectivity parameters produces no change whatsoever to the .ac file exported, even though the .blend file does change. Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Ugh. Even worse, once textures are assigned, the texture files don't get exported either. There they are in the Blender renderer, but there's no texture lines showing up anywhere in the .ac file after export. When I add textures with the Blender UV editor, they show up fine. I haven't tried using projected textures. Well, in this case, I wasn't using UV mapping, but rather assigning materials to faces and then textures to materials, because it was straightforward to the task at hand. But I guess I'll UV map it. Thanks much, -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 pgpLDo0nFqc1j.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
Chris Metzler wrote: On Wed, 21 Jul 2004 10:18:25 -0400 David Megginson [EMAIL PROTECTED] wrote: Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Ugh. Indeed, that doesn't sound like fun to do ... but Blender does have a pretty active community, and if I remember correctly things like file exporting/converting are done using a subset of Python as scripting language, hence one might be lucky mentioning these requirements within the Blender community, possible one could find someone who knows how to easily add the necessary options to the relevant Python scripts. Otherwise, you could also attach the native blender file and the exported AC3D file to your next posting, possibly one could automatize the task by writing some small shell script, but I really don't know how feasible that would be, also with regards to the original Blender file format :-/ But if the Blender people could really add the necessary functionality, Blender might have the potential to replace AC3D for most tasks, which wouldn't be that bad, because Blender doesn't cost money ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear interface to OpenGC
Curtis L. Olson wrote: Depending on what you want to do, you may not need the opengc interface. You might get by just fine with the FGNativeFDM and FGNataiveCtrls interfaces. The structure definition is public domain so you can integrate these easily with your own external applications. ... but as I remember they're still platform dependent, or did anyone change that in the meantime ? 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] Blender question for FG modellers: AC3D export and materials/textures?
David Megginson wrote: Chris Metzler wrote: For example, tweaking the diffuse/specular reflectivity parameters produces no change whatsoever to the .ac file exported, even though the .blend file does change. Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. That's not totally true. You can change one parameter at the begining of the export script ( for version 2.28 that work also for newer version ). In http://members.aon.at/mfranz/ac3d_export.py , you have these two lines : MIRCOL_AS_AMB = 0 # export Mirror Color rgb triplet as ambient color? MIRCOL_AS_EMIS = 0 # export Mirror Color rgb triplet as emissive color? I usually set MIRCOL_AS_EMIS=1 so that I can set the emissive color directly in Blender by adjusting the Mir (ror ?) color. The shininess is hard coded in this version to 72. The normal color is the diffuse color. Even worse, once textures are assigned, the texture files don't get exported either. There they are in the Blender renderer, but there's no texture lines showing up anywhere in the .ac file after export. When I add textures with the Blender UV editor, they show up fine. I haven't tried using projected textures. No problem with texture references. I only use the UV editor. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
Boris Koenig wrote: Chris Metzler wrote: On Wed, 21 Jul 2004 10:18:25 -0400 David Megginson [EMAIL PROTECTED] wrote: Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Ugh. Indeed, that doesn't sound like fun to do ... but Blender does have a pretty active community, and if I remember correctly things like file exporting/converting are done using a subset of Python as scripting language, hence one might be lucky mentioning these requirements within the Blender community, possible one could find someone who knows how to easily add the necessary options to the relevant Python scripts. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Chris, have you seen some of my post processing scripts for ac3d export? I run one on pretty much every model that I made to play around with KADW. The bo105 has a makefile that does a lot of similar stuff too. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear interface to OpenGC
The last thing I've read is that OpenGC and FlightGear are not compatible anymore. But you may want to check the source code in FlightGear/src/Network and search for opengc* The answer is yes and no. Most likely the data structures (classes) defined in opengc_data.hxx tend to oscillate between releases; however the underlying socket communications are stable and working. The latest version in FG has a few additions that require the use of the JSBSim FDM to get a few more flight and engine parameters which you may or may not need. I've been working with any earlier version of OpenGC for my 747 simulator. If you find that you need the OpenGC, rather than some of the other protocols that do much the same thing, I'll be glad to help you with getting things in sync and pointing out where things might be a little out of kilter. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] segfault in AIManager
There appears to be something still broken in the AIManager::update(). I'm rebuilding without threads to see if I can get a better backtrace. The crash is moderately intermittent and somewhat random except that it always occurs early on, just a few frames after system initialization (but before scenery loading is complete). I have not been able to reproduce with --disable_ai_models on command line. Best, Jim #0 0x4207afcc in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ad24 in free () from /lib/i686/libc.so.6 #2 0x4006edc6 in __builtin_delete (ptr=0xc37) at ../../gcc/cp/new2.cc:-1 #3 0x084cc1f0 in SGTexMultipleAnimation::~SGTexMultipleAnimation (this=0xc1db498, __in_chrg=3) at animation.cxx:909 #4 0x085465c7 in ssgDeRefDelete (s=0xc1db498) at ssg.cxx:89 #5 0x085496d5 in ssgBase::~ssgBase (this=0xc36fee8, __in_chrg=0) at ssgBase.cxx:75 #6 0x0854d2ae in ssgEntity::~ssgEntity (this=0xc36fee8, __in_chrg=0) at ssgEntity.cxx:53 #7 0x08549bde in ssgBranch::~ssgBranch (this=0xc36fee8, __in_chrg=0) at ssgBranch.cxx:60 #8 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc36fee8, __in_chrg=0) at ssgBaseTransform.cxx:50 #9 0x0855b70d in ssgTexTrans::~ssgTexTrans (this=0xc36fee8, __in_chrg=3) at ssgTexTrans.cxx:53 #10 0x085465c7 in ssgDeRefDelete (s=0xc36fee8) at ssg.cxx:89 #11 0x08549d7a in ssgBranch::removeKid (this=0xc364c38, n=8) at ssgBranch.cxx:97 #12 0x08549dde in ssgBranch::removeAllKids (this=0xc364c38) at ssgBranch.cxx:112 #13 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc364c38, __in_chrg=3) at ssgBranch.cxx:59 #14 0x085465c7 in ssgDeRefDelete (s=0xc364c38) at ssg.cxx:89 #15 0x08549d7a in ssgBranch::removeKid (this=0xc254e58, n=0) at ssgBranch.cxx:97 #16 0x08549dde in ssgBranch::removeAllKids (this=0xc254e58) at ssgBranch.cxx:112 #17 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc254e58, __in_chrg=0) at ssgBranch.cxx:59 #18 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc254e58, __in_chrg=0) at ssgBaseTransform.cxx:50 #19 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc254e58, __in_chrg=3) at ssgTransform.cxx:53 #20 0x085465c7 in ssgDeRefDelete (s=0xc254e58) at ssg.cxx:89 #21 0x08549d7a in ssgBranch::removeKid (this=0xc07a3d8, n=0) at ssgBranch.cxx:97 #22 0x08549dde in ssgBranch::removeAllKids (this=0xc07a3d8) at ssgBranch.cxx:112 #23 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc07a3d8, __in_chrg=3) at ssgBranch.cxx:59 #24 0x085465c7 in ssgDeRefDelete (s=0xc07a3d8) at ssg.cxx:89 #25 0x08549d7a in ssgBranch::removeKid (this=0xc2e8fd8, n=0) at ssgBranch.cxx:97 #26 0x08549dde in ssgBranch::removeAllKids (this=0xc2e8fd8) at ssgBranch.cxx:112 #27 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc2e8fd8, __in_chrg=0) at ssgBranch.cxx:59 #28 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc2e8fd8, __in_chrg=0) at ssgBaseTransform.cxx:50 #29 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc2e8fd8, __in_chrg=3) at ssgTransform.cxx:53 #30 0x085465c7 in ssgDeRefDelete (s=0xc2e8fd8) at ssg.cxx:89 #31 0x08549d7a in ssgBranch::removeKid (this=0xc27f778, n=0) at ssgBranch.cxx:97 #32 0x08549dde in ssgBranch::removeAllKids (this=0xc27f778) at ssgBranch.cxx:112 #33 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc27f778, __in_chrg=0) at ssgBranch.cxx:59 #34 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc27f778, __in_chrg=0) at ssgBaseTransform.cxx:50 #35 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc27f778, __in_chrg=3) at ssgTransform.cxx:53 #36 0x085465c7 in ssgDeRefDelete (s=0xc27f778) at ssg.cxx:89 #37 0x08549d7a in ssgBranch::removeKid (this=0xbea9d08, n=73) at ssgBranch.cxx:97 #38 0x08549dde in ssgBranch::removeAllKids (this=0xbea9d08) at ssgBranch.cxx:112 #39 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbea9d08, __in_chrg=3) at ssgBranch.cxx:59 #40 0x085465c7 in ssgDeRefDelete (s=0xbea9d08) at ssg.cxx:89 #41 0x08549d7a in ssgBranch::removeKid (this=0xc08d868, n=0) at ssgBranch.cxx:97 #42 0x08549dde in ssgBranch::removeAllKids (this=0xc08d868) at ssgBranch.cxx:112 #43 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc08d868, __in_chrg=0) at ssgBranch.cxx:59 #44 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc08d868, __in_chrg=0) at ssgBaseTransform.cxx:50 #45 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc08d868, __in_chrg=3) at ssgTransform.cxx:53 #46 0x085465c7 in ssgDeRefDelete (s=0xc08d868) at ssg.cxx:89 #47 0x08549d7a in ssgBranch::removeKid (this=0xbe0ce50, n=0) at ssgBranch.cxx:97 #48 0x08549dde in ssgBranch::removeAllKids (this=0xbe0ce50) at ssgBranch.cxx:112 #49 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbe0ce50, __in_chrg=0) at ssgBranch.cxx:59 #50 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xbe0ce50, __in_chrg=0) at ssgBaseTransform.cxx:50 #51 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xbe0ce50, __in_chrg=3) at ssgTransform.cxx:53 #52 0x085465c7 in ssgDeRefDelete (s=0xbe0ce50) at ssg.cxx:89 #53 0x08549d7a in ssgBranch::removeKid (this=0xbea3fa0, n=0) at ssgBranch.cxx:97 #54 0x08549dde in ssgBranch::removeAllKids
R: [Flightgear-devel] Flightgear interface to OpenGC
I don't know if OpenGC is a constraint but I've used FGNativeFDM class and FGNativeCtrls to receive flight data from Flightgear and display them with my displays created with VAPS (it's a rapid prototyping software from a canadian society for generating Human Machine Interface - almost a 'de facto' standard in the military field) through a network connection. I've posted the source code for receiving the data earlier this month. The analogous for sending them is in the sourcecode under FlightGear/examples/netfdm. On FlightGear side just run it with the options (for example) --native-fdm=socket,out,5,server_name,5700,tcp --native-ctrls=socket,in,32,,5701,tcp where server_name is the name of the server that will receive the flight data 5 and 32 are the data rate (packets/sec) 5700 and 5701 are the socket port used by the slave and server tcp is the IP protocol (you can also use udp) to receive the control structure on a channel and send the flight data on another. If you need to use openGC you can find the relative header and source file under /src/Network in opengc.hxx, opengc_data.hxx and opengc.cxx. I think they are under GPL license. Finally in /docs-mini/readme.IO there is some more documentation. Roberto -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Swail, Carl Inviato: mercoledì 21 luglio 2004 13.19 A: '[EMAIL PROTECTED]' Oggetto: [Flightgear-devel] Flightgear interface to OpenGC I am trying to use the OpenGC interface to Flightgear to communicate with my own custom symbology display software via a network connection. The standard documentation that comes with Flightgear does not explain how to set up a connection, at least I don't understand. Any pointers to more documentation on the options would be most appreciated. Thanks Carl Swail Tel.: (613) 998-5581 | Fax: (613) 952-1704 E-Mail: [EMAIL PROTECTED] Web Site: www.nrcaerospace.com Senior Research Officer Institute for Aerospace Research National Research Council U-61, 1200 Montreal Road, Ottawa, ON K1A 0R6 Government of Canada Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! http://companion.yahoo.it ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.9.5pre OpenAL
Downloaded and installed 0.9.5.pre after finally getting a working basefile (net problems atm). When I run flightgear openal complains about volume greater than 1.0 and something about 'cough' - though it's not on my system (Gentoo 2.6.7 - Opteron 146). I thought I'd start fgfs with disable-sound but it still wants to load up OpenAL. Perhaps I have to configure OpenAL? Cheers, Al ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Driving a Flightgear Model with data
Mah Drawfire wrote: Is there a way to drive Flightgear with data from another source. That is, write some kind of wrapper or interface so that I can use flightgear to simply draw an aircraft (with moving surfaces, gear, etc.) using data that I supply it? I did a short look around and didn't see any prominent links stating how/if this was done. Any suggestions would be very helpful. Thanks Sure, There are probably a number of ways you could approach this, but the easiest from the FG perspective would be to set up a copy of flightgear as a slave (see docs-mini/README.IO) and then have your external source send over FGNativeFDM packets (and optionally FGNativeCtrls packets if you want the control surfaces to be animated in the chase/tower views.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in AIManager
Just took another look and realized the trace was fine. The bug really is in the animation code. I'll post the patch in a bit. Best, Jim Jim Wilson said: There appears to be something still broken in the AIManager::update(). I'm rebuilding without threads to see if I can get a better backtrace. The crash is moderately intermittent and somewhat random except that it always occurs early on, just a few frames after system initialization (but before scenery loading is complete). I have not been able to reproduce with --disable_ai_models on command line. Best, Jim #0 0x4207afcc in chunk_free () from /lib/i686/libc.so.6 #1 0x4207ad24 in free () from /lib/i686/libc.so.6 #2 0x4006edc6 in __builtin_delete (ptr=0xc37) at ../../gcc/cp/new2.cc:-1 #3 0x084cc1f0 in SGTexMultipleAnimation::~SGTexMultipleAnimation (this=0xc1db498, __in_chrg=3) at animation.cxx:909 #4 0x085465c7 in ssgDeRefDelete (s=0xc1db498) at ssg.cxx:89 #5 0x085496d5 in ssgBase::~ssgBase (this=0xc36fee8, __in_chrg=0) at ssgBase.cxx:75 #6 0x0854d2ae in ssgEntity::~ssgEntity (this=0xc36fee8, __in_chrg=0) at ssgEntity.cxx:53 #7 0x08549bde in ssgBranch::~ssgBranch (this=0xc36fee8, __in_chrg=0) at ssgBranch.cxx:60 #8 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc36fee8, __in_chrg=0) at ssgBaseTransform.cxx:50 #9 0x0855b70d in ssgTexTrans::~ssgTexTrans (this=0xc36fee8, __in_chrg=3) at ssgTexTrans.cxx:53 #10 0x085465c7 in ssgDeRefDelete (s=0xc36fee8) at ssg.cxx:89 #11 0x08549d7a in ssgBranch::removeKid (this=0xc364c38, n=8) at ssgBranch.cxx:97 #12 0x08549dde in ssgBranch::removeAllKids (this=0xc364c38) at ssgBranch.cxx:112 #13 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc364c38, __in_chrg=3) at ssgBranch.cxx:59 #14 0x085465c7 in ssgDeRefDelete (s=0xc364c38) at ssg.cxx:89 #15 0x08549d7a in ssgBranch::removeKid (this=0xc254e58, n=0) at ssgBranch.cxx:97 #16 0x08549dde in ssgBranch::removeAllKids (this=0xc254e58) at ssgBranch.cxx:112 #17 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc254e58, __in_chrg=0) at ssgBranch.cxx:59 #18 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc254e58, __in_chrg=0) at ssgBaseTransform.cxx:50 #19 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc254e58, __in_chrg=3) at ssgTransform.cxx:53 #20 0x085465c7 in ssgDeRefDelete (s=0xc254e58) at ssg.cxx:89 #21 0x08549d7a in ssgBranch::removeKid (this=0xc07a3d8, n=0) at ssgBranch.cxx:97 #22 0x08549dde in ssgBranch::removeAllKids (this=0xc07a3d8) at ssgBranch.cxx:112 #23 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc07a3d8, __in_chrg=3) at ssgBranch.cxx:59 #24 0x085465c7 in ssgDeRefDelete (s=0xc07a3d8) at ssg.cxx:89 #25 0x08549d7a in ssgBranch::removeKid (this=0xc2e8fd8, n=0) at ssgBranch.cxx:97 #26 0x08549dde in ssgBranch::removeAllKids (this=0xc2e8fd8) at ssgBranch.cxx:112 #27 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc2e8fd8, __in_chrg=0) at ssgBranch.cxx:59 #28 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc2e8fd8, __in_chrg=0) at ssgBaseTransform.cxx:50 #29 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc2e8fd8, __in_chrg=3) at ssgTransform.cxx:53 #30 0x085465c7 in ssgDeRefDelete (s=0xc2e8fd8) at ssg.cxx:89 #31 0x08549d7a in ssgBranch::removeKid (this=0xc27f778, n=0) at ssgBranch.cxx:97 #32 0x08549dde in ssgBranch::removeAllKids (this=0xc27f778) at ssgBranch.cxx:112 #33 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc27f778, __in_chrg=0) at ssgBranch.cxx:59 #34 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc27f778, __in_chrg=0) at ssgBaseTransform.cxx:50 #35 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc27f778, __in_chrg=3) at ssgTransform.cxx:53 #36 0x085465c7 in ssgDeRefDelete (s=0xc27f778) at ssg.cxx:89 #37 0x08549d7a in ssgBranch::removeKid (this=0xbea9d08, n=73) at ssgBranch.cxx:97 #38 0x08549dde in ssgBranch::removeAllKids (this=0xbea9d08) at ssgBranch.cxx:112 #39 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbea9d08, __in_chrg=3) at ssgBranch.cxx:59 #40 0x085465c7 in ssgDeRefDelete (s=0xbea9d08) at ssg.cxx:89 #41 0x08549d7a in ssgBranch::removeKid (this=0xc08d868, n=0) at ssgBranch.cxx:97 #42 0x08549dde in ssgBranch::removeAllKids (this=0xc08d868) at ssgBranch.cxx:112 #43 0x08549bc7 in ssgBranch::~ssgBranch (this=0xc08d868, __in_chrg=0) at ssgBranch.cxx:59 #44 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xc08d868, __in_chrg=0) at ssgBaseTransform.cxx:50 #45 0x0855c2d5 in ssgTransform::~ssgTransform (this=0xc08d868, __in_chrg=3) at ssgTransform.cxx:53 #46 0x085465c7 in ssgDeRefDelete (s=0xc08d868) at ssg.cxx:89 #47 0x08549d7a in ssgBranch::removeKid (this=0xbe0ce50, n=0) at ssgBranch.cxx:97 #48 0x08549dde in ssgBranch::removeAllKids (this=0xbe0ce50) at ssgBranch.cxx:112 #49 0x08549bc7 in ssgBranch::~ssgBranch (this=0xbe0ce50, __in_chrg=0) at ssgBranch.cxx:59 #50 0x0859bc0d in ssgBaseTransform::~ssgBaseTransform (this=0xbe0ce50, __in_chrg=0) at ssgBaseTransform.cxx:50 #51 0x0855c2d5 in
[Flightgear-devel] [PATCH] to fix SegFault in SimGear animation code
Correct a typo that produces segfault during cleanup on some systems.
Index: simgear/scene/model/animation.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/animation.cxx,v
retrieving revision 1.24
diff -u -r1.24 animation.cxx
--- simgear/scene/model/animation.cxx 20 May 2004 14:18:15 - 1.24
+++ simgear/scene/model/animation.cxx 21 Jul 2004 21:25:25 -
@@ -963,8 +963,7 @@
SGTexMultipleAnimation::~SGTexMultipleAnimation ()
{
- // delete _table;
- delete _transform;
+ delete [] _transform;
}
int
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
On Wed, 21 Jul 2004 12:00:23 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Boris Koenig wrote: Chris Metzler wrote: On Wed, 21 Jul 2004 10:18:25 -0400 David Megginson [EMAIL PROTECTED] wrote: Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Ugh. Indeed, that doesn't sound like fun to do ... but Blender does have a pretty active community, and if I remember correctly things like file exporting/converting are done using a subset of Python as scripting language, hence one might be lucky mentioning these requirements within the Blender community, possible one could find someone who knows how to easily add the necessary options to the relevant Python scripts. Chris, have you seen some of my post processing scripts for ac3d export? I run one on pretty much every model that I made to play around with KADW. D'oh! As soon as you said that, I went oh yeah, *tweak* and went and looked. Good catch. Thanks. -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 pgpBTWN61h8UL.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug in newgui code
On my system (CVS), the xml dialogs keep shrinking, just like Mike Teevee. To reproduce: 1) start flightgear 2) hit esc to bring up exit dialog 3) click cancel button 4) repeat step 2 3 six times. You'll see the dialog box shrink a couple pixels each time. Label and button positions or sizes don't change. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] Pause FDM while initial scenery load completes
This patch prevents FDM execution until intial scenery load completes making midair starts in the KSFO area possible again. Here is cvs diff: http://www.spiderbark.com/fgfs/sceneryloadpause.diff.gz Here is tar of whole files: http://www.spiderbark.com/fgfs/sceneryloadpause.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in newgui code
On Thu, 22 Jul 2004 02:47:52 - Jim Wilson [EMAIL PROTECTED] wrote: On my system (CVS), the xml dialogs keep shrinking, just like Mike Teevee. To reproduce: 1) start flightgear 2) hit esc to bring up exit dialog 3) click cancel button 4) repeat step 2 3 six times. You'll see the dialog box shrink a couple pixels each time. Label and button positions or sizes don't change. Confirmed (also CVS). Specifically, it appears that the lower left corner is anchored, while the upper right corner comes in -- resulting in the top and right margins shrinking, while the bottom and left margins stay OK. -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 pgp9D4HeiDJiV.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in newgui code
Confirmed. I have the latest CVS. Regards, Ampere On July 21, 2004 11:12 pm, Chris Metzler wrote: Confirmed (also CVS). Specifically, it appears that the lower left corner is anchored, while the upper right corner comes in -- resulting in the top and right margins shrinking, while the bottom and left margins stay OK. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Thank you. So, is there anyway to include more than one XML file? The reason I ask is because I have multiple mesh files, and each of them has its own XML animation file. I would like to tell all of them where the livery resides in in one single XML file. Regards, Ampere On July 21, 2004 02:50 am, Erik Hofman wrote: Very well done Ampere! I've put them in CVS. 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
