Re: [Flightgear-devel] Animation Was: jsbsim airstream info
Josh Babcock wrote: > Jon Berndt wrote: > >>It's alpha and beta. >> >>in radians: >> >>aero/alpha-rad >>aero/beta-rad >> >>in degrees: >> >>aero/alpha-deg >>aero/beta-deg >> >>Jon >> >> >> >>>OK, I'm trying to find what the air velocity relative to the fuselage of >>>a jsbsim plane is. I'm pretty sure the info is in >>>/fdm/jsbsim/atmosphere, but I don't know which values are which. >>>Ultimately this will be used to make a ribbon indicate the wind. If I'm >>>cool, I will be able to make it flap faster as the speed increases. >>>Any help? >> >> >> >>___ >>Flightgear-devel mailing list >>Flightgear-devel@flightgear.org >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel >>2f585eeea02e2c79d7b1d8c4963bae2d >> > > > OK, got it working. On another note, are interpolation tables supposed > to work everywhere factor tags do? They don't for spin animations, which > would be handy for me right now. > > Josh > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Hmm, it appears that these only show the aircraft's angles relative to it's own velocity vector. I also need to sum in the crosswind so that I get the angles relative to the air mass. I know I not getting this because when I land and switch the weather to "thunderstorm" the ribbon doesn't move. Anybody know where I can find the wind angles relative to the aircraft? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
Curtis L. Olson wrote: > Jim Wilson wrote: > >>> From: Josh Babcock >>> >>> Did someone change the property browser so you can't watch the values >>> change in real time? How do I get this back? >>> >>> Josh >>> >> >> >> Which property are you looking at? It has been a very long time, so I >> might be a little off here. IIRC the a property node is only updated >> if the responsible subsystem (e.g. the FDM interface) writes to it. >> If that subsystem does not write to the property then the property >> only gets updated when the property picker does a read which is bound >> to a getter in the responsible subsystem. >> >> My guess is something changed in the subsystem you want data from, >> probably by someone trying to save cpu cycles. >> >> BTW, if this is what has happened, developers should note that the >> flightgear will in many cases (probably most cases) run FASTER if the >> subsystem that owns a property updates it once every frame. >> >> Of course there might be a bug in the latest property system >> work...but the code I have, which is fairly recent, still shows some >> real time updates in the property picker. >> >> > > As I understand it, here is how things have always worked. Properties > that are "tied" to C++ variables don't update automatically. You can > click on the "." at the top to "refresh" the values. Properties that > exist soley within the property system will update "live" in the > property browser. > > Regards, > > Curt. > Yeah, I guess I'm just used to looking at stuff that gets constantly updated. Anyway, I figured it out by just tyeing objects to properties by trial and error. It's all sorted out now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
Jim Wilson wrote: From: Josh Babcock Did someone change the property browser so you can't watch the values change in real time? How do I get this back? Josh Which property are you looking at? It has been a very long time, so I might be a little off here. IIRC the a property node is only updated if the responsible subsystem (e.g. the FDM interface) writes to it. If that subsystem does not write to the property then the property only gets updated when the property picker does a read which is bound to a getter in the responsible subsystem. My guess is something changed in the subsystem you want data from, probably by someone trying to save cpu cycles. BTW, if this is what has happened, developers should note that the flightgear will in many cases (probably most cases) run FASTER if the subsystem that owns a property updates it once every frame. Of course there might be a bug in the latest property system work...but the code I have, which is fairly recent, still shows some real time updates in the property picker. As I understand it, here is how things have always worked. Properties that are "tied" to C++ variables don't update automatically. You can click on the "." at the top to "refresh" the values. Properties that exist soley within the property system will update "live" in the property browser. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property browser
> From: Josh Babcock > > Did someone change the property browser so you can't watch the values > change in real time? How do I get this back? > > Josh Which property are you looking at? It has been a very long time, so I might be a little off here. IIRC the a property node is only updated if the responsible subsystem (e.g. the FDM interface) writes to it. If that subsystem does not write to the property then the property only gets updated when the property picker does a read which is bound to a getter in the responsible subsystem. My guess is something changed in the subsystem you want data from, probably by someone trying to save cpu cycles. BTW, if this is what has happened, developers should note that the flightgear will in many cases (probably most cases) run FASTER if the subsystem that owns a property updates it once every frame. Of course there might be a bug in the latest property system work...but the code I have, which is fairly recent, still shows some real time updates in the property picker. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Too slow on Solaris 10
Martin Spott a écrit : If you want the robustness of Solaris, so why do aim at replacing significant subsystems that _do_ implement this robustness ? The question is extlactly to understand, how works the normal X11-Solaris display : about this, i think that it has a little changed between Solaris 8 , 9, and 10. For this goal, i have today one way : kdmconfig. And i found this : As my machine fresh standard installed is, kdmconfig is switched by default on X86, not on Xsun : and the reason for this resides probabily in my graphic board, an Ati Radeon 9200 ; in the driver list (kdm) we can only find a ... "X86-radeon" driver (also selected by default), because, i means, not any other was written from Sun or from Radeon for Sun. A also found a command (an executable) /usr/X11/bin/xorgconfig, if i good remember, which generate a correct xorg.conf for Solaris : the interest is, of course, that with the options it's possible to activate same acceleration features, wich is actually for me the one need for FlightGear works fine. But... But that all, i will only use if the other possibility itself don't works ! And this other possibility, it's simply ... Xsun. Preparing my machine, i switched kdm to Xsun (=Sun/X11), with the corrects display settings (1280 x 1024, 24 bits) and ... X86-radeon, because i don't have other by hand. And it works, without error message at the boot. - the display is a little not so wonderful as with Sun/Xfree (!), but better as under Linux and, which important here is, it seems that it has a better acceleration (comparing with standard Xfree on Sun). Now i can proceed to experiment this with FlightGear, but i stand because your annunced update to Sol 10. I have also another CAD program (Ayam), which requires acceleration for display NURBScurves. But one problem after the other ! If FlightGear works fine, OK. If not : 1) the first thing will be to know, if it's possible to find any acceleration setting in Xsun, or another driver for my Radeon. 2) the second, for a moment ... Xfree, and other hand to forward the learning (and the help !) to Xsun... 3) the third, to buy a 2500 biprocessor with many accelerators and to transport it at home in my Stuttgart-low-cost car... Best regards, Sergio ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Josh Babcock wrote: > Gerard ROBIN wrote: > >>Le vendredi 03 juin 2005 à 19:42 -0400, Josh Babcock a écrit : >> >> >>>Josh Babcock wrote: >> >> >>>OK, model's done, same address. Now I'm going to do the animation XML. >>>If I'm really cool I'll be able to make the wind ribbon look good. >>>Otherwise, just controls and control surfaces. >>> >>>Also, I didn't know what the rudder pedals looked like, so I left them >>>out. I would assume that it's just a stick on a pivot which would be >>>super easy to add. I'm not sure about historical accuracy though. Of >>>course, the entire inside of the cockpit is a WAG anyway. Thoughts? >>> >>>Josh >>> >> >>Oh, it is better and better, >>Only a little PB with "texture wood-dark" which crashed my fgfs, solved >>by a read write of that texture in Gimp. >>AND may be Colditz need to be scaled, it seems very tall. > > > I'll take a look at the textures. Yes, it needs to be scaled. I forgot I > modeled it in feet, it needs to be put into meters. > > Josh > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > All done. Production version of the model at http://jrbabcock.home.comcast.net/flightgear/colditz/colditz.tgz This includes a set file and a whole new Models directory. The only thing that needs to be done is put an AC_VRP in the jsbsim file to make sure the model is centered properly. I will let Steve do that so I don't have to muck with anymore of his files. Besides, I don't know where the CG is. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] msvc71 compiling
while compiling fg i get these errors. i ignored libcmtd.lib, libcmt.lib and errors reduced to these ..additional libs are; sg.lib sl.lib ssg.lib pui.lib ssgaux.lib psl.lib puaux.lib pw.lib fnt.lib ul.lib net.lib sl.lib js.lib zlib.lib simgear.lib alut.lib openal32.lib pthreadvc.lib. please help obj : error LNK2019: unresolved external symbol ___argc referenced in function [EMAIL PROTECTED] bootstrap.obj : error LNK2019: unresolved external symbol ___argv referenced in function [EMAIL PROTECTED] libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol __malloc_dbg referenced in function __Getctype libcpmtd.lib(xdebug.obj) : error LNK2001: unresolved external symbol __malloc_dbg libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol __free_dbg referenced in function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t const &,char *,int)" ([EMAIL PROTECTED]@std@@[EMAIL PROTECTED]) .\Release/FlightGear.exe : fatal error LNK1120: 4 unresolved externals Discover Yahoo! Find restaurants, movies, travel & more fun for the weekend. Check it out!___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Animation Was: jsbsim airstream info
Jon Berndt wrote: > It's alpha and beta. > > in radians: > > aero/alpha-rad > aero/beta-rad > > in degrees: > > aero/alpha-deg > aero/beta-deg > > Jon > > >>OK, I'm trying to find what the air velocity relative to the fuselage of >>a jsbsim plane is. I'm pretty sure the info is in >>/fdm/jsbsim/atmosphere, but I don't know which values are which. >>Ultimately this will be used to make a ribbon indicate the wind. If I'm >>cool, I will be able to make it flap faster as the speed increases. >>Any help? > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > OK, got it working. On another note, are interpolation tables supposed to work everywhere factor tags do? They don't for spin animations, which would be handy for me right now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Too slow on Solaris 10
Sergio wrote: > Ok : i finally found "kdmconfig", what provides : > > - either to generate a proper xorg.conf (with any accel-options) ; > > - or simply to switch to Xsun, what i will now experiment with FlightGear.. I still wonder why you insist on cluttering your OS with stuff that doesn't belong there. If you want to make Solaris to be a lookalike of your favourite Linux distribution, why then don't you stick to Linux ? If you want the robustness of Solaris, so why do aim at replacing significant subsystems that _do_ implement this robustness ? This resembles of buying a Mercedes and replacing the interior with that of a [insert the name of a common low-cost car manufacturer], Regards, Martin. P.S.: Yes, I know, Mercedes doesn't meet the expected quality standards for several years now -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim airstream info
It's alpha and beta. in radians: aero/alpha-rad aero/beta-rad in degrees: aero/alpha-deg aero/beta-deg Jon > OK, I'm trying to find what the air velocity relative to the fuselage of > a jsbsim plane is. I'm pretty sure the info is in > /fdm/jsbsim/atmosphere, but I don't know which values are which. > Ultimately this will be used to make a ribbon indicate the wind. If I'm > cool, I will be able to make it flap faster as the speed increases. > Any help? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] property browser
Did someone change the property browser so you can't watch the values change in real time? How do I get this back? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] jsbsim airstream info
OK, I'm trying to find what the air velocity relative to the fuselage of a jsbsim plane is. I'm pretty sure the info is in /fdm/jsbsim/atmosphere, but I don't know which values are which. Ultimately this will be used to make a ribbon indicate the wind. If I'm cool, I will be able to make it flap faster as the speed increases. Any help? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] range animation
I'm running into this same bug again with the colditz glider. The range animation only works for the first object listed, all the others listed in the animation disappear permanently. I have something like 10 objects to do LOD animations on, and it is already making the xml look pretty excessive. This is an even bigger problem with the superfort. Josh e.g. Works: range 0 1 Stick range 0 100 Headrest Breaks: range 0 1 Stick Headrest ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Help... aircraft texture
* Josh Babcock -- Saturday 04 June 2005 19:14: > Melchior FRANZ wrote: > > $ convert foo.jpeg -compress RLE sgi:foo.rgb > How does one strip out alpha channels again? Don't know with "convert", although I would be surprised if it weren't able to. I use KDE for that. You can load the image in kolourpaint and save it again, which makes some textures a lot smaller. I've got an external program (compilable under KDE only [1]) that does this from the command line (and even compress a little more). Doesn't look like you are a KDE guy, though. :-) m. [1] http://members.aon.at/mfranz/rle.tar.gz [5.5 kB] $ make rle Usage: rle [--description ] file(s) $ ./rle foo.jpg bar.png ... creates foo.rgb and bar.rgb ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Help... aircraft texture
Melchior FRANZ wrote: > * Melchior FRANZ -- Friday 03 June 2005 08:12: > >>* gimp: >> - save as foo.rgb and select "SGI" in the "Determine Filetype" selector >>(Don't use "By extension", because that creates some other *.rgb" format) >> >> - or save as foo.sgi and then rename to foo.rgb > > > When asked for the "Compression Type", choose "Aggressive RLE (Not supported > by SGI)". (This *is* supported by SGI, it's in SGI's own SGI image format > spec. This compression type is supported by GIMP, KDE, ImageMagick, Blender, > plib, ... and is the smallest that GIMP can write. (Could be made smaller > by other programs. Just ask. :-) > > > > >>* any graphics program. Save to any format. But then convert to SGI using >> ImageMagick's "convert: >> >>$ convert foo.jpeg sgi:foo.rgb > > > "convert" seems to use (non-"aggressive") RLE by default. If not, use the > "-compress RLE" option. > > $ convert foo.jpeg -compress RLE sgi:foo.rgb > > m. > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Yes, I remember this, but I can't seem to find it in the archives. How does one strip out alpha channels again? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Gerard ROBIN wrote: > Le vendredi 03 juin 2005 à 19:42 -0400, Josh Babcock a écrit : > >>Josh Babcock wrote: > > >>OK, model's done, same address. Now I'm going to do the animation XML. >>If I'm really cool I'll be able to make the wind ribbon look good. >>Otherwise, just controls and control surfaces. >> >>Also, I didn't know what the rudder pedals looked like, so I left them >>out. I would assume that it's just a stick on a pivot which would be >>super easy to add. I'm not sure about historical accuracy though. Of >>course, the entire inside of the cockpit is a WAG anyway. Thoughts? >> >>Josh >> > > Oh, it is better and better, > Only a little PB with "texture wood-dark" which crashed my fgfs, solved > by a read write of that texture in Gimp. > AND may be Colditz need to be scaled, it seems very tall. I'll take a look at the textures. Yes, it needs to be scaled. I forgot I modeled it in feet, it needs to be put into meters. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 2.37
> %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;C:\;C:\WINDOWS\system32;C:\YAFRAY_DIR;C:\Python24 You should not include both %SystemRoot% and C:\WINDOWS paths. %SystemRoot% will be defined to the correct place on all NT-based systems (I don't know about 3.1/95/98/ME); however, if, for any reason your systemroot is not C:\WINDOWS (as it might be if you have 2000 and XP installed, and are booting into 2000), you could be calling up system applications for the wrong windows version (but only if they don't exist in %systemroot%). The mantra used to be that "a short path is a fast path", but I think that consideration is probably now irrelevant. My practice is to have a path that looks like this: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;%userpath%; and to define everything else in a separate variable, %userpath%. However, there's no reason to do that except for greater aesthetics. Giles Robertson <>___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [ANN] Blender 2.37
Theo Reticle wrote: > I was getting that same No Python window in Blender 2.36, even though I had > followed all of the instructions for Python 2.4 for Windows. When I > installed Blender 2.37, all of the Python stuff worked. One thing I noticed > that's a little odd in XP: the Python instructions say to add Python to your > Path in the following manner: Here is the content of my Blender 2.37 text window under XP : Using Python version 2.3 'import site' failed; use -v for traceback No installed Python found. Only built-in modules are available. Some scripts may not run. Continuing happily. Trying to import AC3D model(s) from i:\modeles 3D\TourCBX\tour-cbx-fb.ac ... ... done! Data imported in 0.183 seconds. As you can see, although it complains it doesn't found Python, it was able to _import_ ( not load ) my ac model and the textures are all there ( they are in the same directory than the model ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
