Re: [Flightgear-devel] Why ZERO
Ampere K. Hardraade wrote: Oh... I have to learn Fortran next year. Fortran is pretty much just like BASIC but the line numbers are optional. You can get the feel of it here: http://www.westnet.com/mirrors/99bottles/beer_d_h.html#f90 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] Why ZERO
Oh... I have to learn Fortran next year. Regards, Ampere On May 12, 2004 07:51 pm, Bruce Finney wrote: > Andy Ross wrote: > > stuff cut > > > the way software systems are expected to act. Real Programmers count > > from zero. Always have, always will. > > NOTE: FORTRAN programmers count from 1, always have, always will!!! > > > Andy > > > > ___ > > 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] Why ZERO
Ok Andy I thought this maybe the case but I guess I was hopeing against hope that it was not. Cheers Innis Andy Ross writes This can't be fixed. The underlying software engines (property system, C++, Nasal, all of it really) all use zero based indexing in accordance with (very) long standing software engineering convention. There's no reason the user should ever be exposed to internal indexing anyway, so the best we can do is present a consistent picture to the developers. As confused as you might be, I assure you it would only be worse if we all had to remember which subsystem used which array indexing convention. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Jonathan Richards wrote: Oi! Somewhere here I've got a stack of Hollerith cards with my first ever program, in Fortran, on it. Not Fortran77, though, because I punched it sometime in 1974. Yes, I wrote my first programs in Fortran as well -- I was 13 in 1977, and used to sneak into the Queen's University computer centre at night with a, well, borrowed password, to run my card batches. I dropped a big pile of cards on my second visit, giving me my first lesson in the importance of good interfaces. Later that year my high school got a TRS-80 with BASIC, and I never looked back. Sure, the language was not optimal, but I didn't have any cards to drop and I could write video games for the other kids to play. > There's still lots of scientific stuff in Fortran. There's still lots of business stuff in COBOL. Old code never dies: it just becomes someone else's problem. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 01:24, Jonathan Richards wrote: > There's still lots of scientific stuff in Fortran. > And there are plenty of Zeroth laws in science. Cheers, Al ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 12:57 am, David Megginson wrote: > Bruce Finney wrote: > >> the way software systems are expected to act. Real Programmers count > >> from zero. Always have, always will. > > > > NOTE: FORTRAN programmers count from 1, always have, always will!!! > > Does that apply to both of them? > Oi! Somewhere here I've got a stack of Hollerith cards with my first ever program, in Fortran, on it. Not Fortran77, though, because I punched it sometime in 1974. There's still lots of scientific stuff in Fortran. Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
On Thursday 13 May 2004 12:51 am, Bruce Finney wrote: > Andy Ross wrote: > > stuff cut > > > the way software systems are expected to act. Real Programmers count > > from zero. Always have, always will. > > NOTE: FORTRAN programmers count from 1, always have, always will!!! > ...and APL programmers can choose, by assigning a value to the system variable IO (index origin). The default is 1, though. Sorry, Andy! Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Bruce Finney wrote: the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! Does that apply to both of them? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Bruce Finney wrote: > Andy Ross wrote: > > Real Programmers count from zero. Always have, always will. > > NOTE: FORTRAN programmers count from 1, always have, always will!!! So we agree. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Andy Ross wrote: stuff cut the way software systems are expected to act. Real Programmers count from zero. Always have, always will. NOTE: FORTRAN programmers count from 1, always have, always will!!! Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Bruce Finney [EMAIL PROTECTED] Auburn, WA ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Why ZERO
* Ampere K. Hardraade -- Thursday 13 May 2004 00:56:
> hmm... if FlightGear is to be as realistic as possible, it will be a good idea
> to simulate everything down to the very last detail.
>
> Perhaps a translator of some sort can be written?
Yes, sure:
$ cat engine-number-translator
#!/usr/bin/perl -w
use strict;
sub help() {
print "Usage: $0 [--to-index|--to-engine] \n";
exit 0;
}
&help unless @ARGV == 2;
if ($ARGV[0] eq "--to-index") {
print $ARGV[1] - 1 . "\n";
} elsif ($ARGV[0] eq "--to-engine") {
print $ARGV[1] + 1 . "\n";
} else {
&help();
}
exit 0;
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Ampere K. Hardraade wrote:
> hmm... if FlightGear is to be as realistic as possible, it will be a
> good idea to simulate everything down to the very last detail.
>
> Perhaps a translator of some sort can be written?
I can't quite tell if this is a joke or not. If it is, then accept my
apologies.
In the real world, you don't use a property browser to configure your
engine. Nor do real landing gear behave differently when the pilots
secretly start referring to them with different indexing conventions.
("Whatever you do, don't call the nose gear 'zero', it doesn't like
that...")
When you do "realistic" things like move levers, push buttons, and
examine stuff in the cockpit, the FlightGear behavior should be
expected to match real life. When you peek under the hood with the
property browser and/or configure the simulator via XML files, you are
looking at a software system, not an aircraft. IMHO, it should act
the way software systems are expected to act. Real Programmers count
from zero. Always have, always will.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
hmm... if FlightGear is to be as realistic as possible, it will be a good idea to simulate everything down to the very last detail. Perhaps a translator of some sort can be written? Regards, Ampere On May 12, 2004 10:31 am, Andy Ross wrote: > Innis Cunningham wrote: > > I am just wondering is there a very good reason that we use zero to > > number things in FG. Engines tanks and the like. Because in the real > > world of aviation nothing is numbered zero as far as I know. > > > > Why does it matter you may ask. Well it seems a bit strange that a > > four engined aircraft has engines numbered 0-3 and a three engined > > aircraft has engines numbered 0-2 and so on. As FG grows and more > > systems are added it would seem to me that the confusion could > > multiply. > > This can't be fixed. The underlying software engines (property > system, C++, Nasal, all of it really) all use zero based indexing in > accordance with (very) long standing software engineering convention. > There's no reason the user should ever be exposed to internal indexing > anyway, so the best we can do is present a consistent picture to the > developers. > > As confused as you might be, I assure you it would only be worse if we > all had to remember which subsystem used which array indexing > convention. > > Andy > > ___ > 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] A/C turns without power
I think it happens on the 737 as well. Regards, Ampere On May 12, 2004 09:40 am, Innis Cunningham wrote: > I was using the c172(dont know what it uses) and the > MD-11 with JSBSim aeromatic generated FDM ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On May 12, 2004 02:10 am, Innis Cunningham wrote: > Hi Ampere > If I gave the impression that I wanted to do some or all > of the animations that was not my intention. > I just ran a bit of animation code to see if FG had any > problems reading 3DS scripts and it did not. > I put the code below into the animation file and it > seems to work fine if that is any help to you. > As you seem to have it well under control I will leave it > in your capable hands. > > Cheers > Innis I see. I think I will need help when I get around to do the cockpit. I have been reading the read-me file in the mini-doc directory as well as some actual code. So far, the process of creating the cockpit seem to be very complicated, not to mention confusing. Speaking of the cockpit, is it possible to create a stand alone mesh file for the cockpit, or must I integrate the cockpit model into the aircraft's mesh file? > > Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs > > sideway. > > No, that's not weird, that's standard in aeronautical engineering! > (with the z-axis pointing down, btw.) > > Cheers, > -Gerhard Oh, alright. I was just wondering. > > Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis > > runs sideway. > > What convention would you have chosen? :) > > Coordinate systems are like cuisines. There's no accounting for > taste, and you can't fix things by mixing them together. > > Andy I thought y-axis should be the one that goes length-wise. If x-axis running length-wise is the standard in engineering, then I will have to follow convention. =) > On Wednesday 12 May 2004 16:20, Andy Ross wrote: > > Mathias Fröhlich wrote: > > > May be this 'do not use a leading slach' should also show up in that > > > model animation HOWTO? > > > > Or even generate a runtime warning during parsing. This is a really > > easy typo to make. > > I guess both are excellent ideas. I consulted David Culp's 737 config file > to find out why the MD11 animation didn't work initially, and I didn't even > spot the difference in leading slash between his configuration file and the > animation section I had just I copied from Ampere's email until Erik's > message. > > Cheers, > Durk Actually, I copy that particular code directly from http://flightgear.org/Docs/fgfs-model-howto.html . All I did was changing the values for the x, y, and z coordinates. May be someone should go and fix the tutorial as soon as possible. Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek Cyborg Evo joystick xml file done
Phillip Jones wrote: I witnessed a lot of discussion about joysticks with flightgear under windows, and the swapped axis problem. But when I connected this one, the only problem I had was that the default joystick mapping didn't include rudder control! Anyway, I made an xml based off of the Cyborg Gold 3D USB xml file and it works pretty well for me. If anyone wants a copy, I'll send it to you. Should this maybe go in the CVS? Off course. Please sent it to me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tue, 2004-05-11 at 23:16, Durk Talsma wrote: > On Tuesday 11 May 2004 08:31, Innis Cunningham wrote: > > Well Ampere the good news is that FG is quite happy > > to animate using the 3DS file. > > Another piece of good news is that the ground trimming problems have been > solved by Mathias Frolich. His proposed solution is currently under > investigation by Tony Peden and will hopefully traverse it's way from JSBSim > cvs to FlightGear cvs wthin the next few days/weeks. It's in JSBSim CVS now, just needs to get into FG. > > Cheers, > Durk > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Giles Robertson wrote: How often do people need to specify the state of gear etc globally? I can't, offhand, think of a point at which you want all the aircraft in the world how drop the gear. Considering this, is the typo easy enough to make that we ought to change the behaviour? - or is this mucking up the established system too much? Or perhaps, /property/value should reference to the aircraft currently under user control, which would extend compatibility if we ever implement a 'switch which aircraft you are flying in mid-air' feature. The problem is that this is only required for certain parts of the property tree (animation and maybe sound related), but other parts of the property tree should be accessible globally (time, sun positions, etc). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MingW, GUI, and build errors
Giles Robertson wrote: > Just got an error on the following compile: > > In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, > from layout-props.cxx:1: > C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or > directory My fault; I Forgot to test the build on a glutless system. Fixed. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: RE: K-Class Blimp Blueprints]
[Note: forwarded from non-subscriber ] Original Message Subject: RE: K-Class Blimp Blueprints Date: Wed, 12 May 2004 17:58:22 + From: Christopher Daniels Corbett <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Heard mention of some K-class USN bluprints around these parts... I'm gmax modeler making aircraft models for CFS3. I just found out about Flightgear *yesterday*--sounds interesting, and sounds like building a gmax ac for it just follows FS 2k2/4 procedures, correct? Open source, eh...cool! At present, I am working on a K-class blimp for the devil I know (CFS3) based on the few photos I could find on the internet. Details and working images of my progress to date can be found here: http://www.sim-outhouse.com/forums/showthread.php?s=&threadid=12153 My screen name in those posts is "Manymegs". If anybody still has those blueprints, or any other useful information about USN blimps and would be willing to share them, I would be most grateful to you! Anything from a simple line drawing to full engineering bluprints would be welcome and would be a great help to me in realizing a final model, which will be free to anyone who wishes to download it. I just discovered Flightgear and need to find out all the details, what is involved with aircraft modeling and conversion from gmax, etc. I can't promise to make a conversion to Flightgear since I know so little about it but I will promise, at mimimum to make the gmax files available to anybody who does want to make a conversion to Flightgear (someone who knows what they're doing.) Just need some plans to enusre the details are accurate. I do hope that you can help out, so we can share a combat-ready K-class blimp that might bring back some memories of Navy airships-- for all who are interested. Let's see the 'K' fly again! Regards, Chris [EMAIL PROTECTED] -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MingW, GUI, and build errors
Just got an error on the following compile: This is an automated build using the MSYS command line environment and GCC 3.3.3 of FlightGear and SimGear This compile was started by user: giles.robertson on 05/12/04-20:14:57-UTC And simgear compiled fine (with the usual heap of errors in clouds3d - I've never got that file to compile cleanly, or the feature to work) Flightgear went through with the usual set of errors, but hiccupped here: Making all in GUI trackball.c:18: warning: ignoring #pragma warning AirportList.cxx: In constructor `AirportList::AirportList(int, int, int, int)': AirportList.cxx:22: warning: embedded `\0' in format In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, from layout-props.cxx:1: C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or directory In file included from C:/msys/1.0/fg/include/plib/pu.h:2140, from layout-props.cxx:1: C:/msys/1.0/fg/include/plib/puGLUT.h: In function `int puGetWindowGLUT()': C:/msys/1.0/fg/include/plib/puGLUT.h:42: `glutGetWindow' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:42: (Each undeclared identifier is reported only once for each function it appears in.) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puSetWindowGLUT(int)': C:/msys/1.0/fg/include/plib/puGLUT.h:47: `glutSetWindow' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puGetWindowSizeGLUT(int*, int*)': C:/msys/1.0/fg/include/plib/puGLUT.h:52: `GLUT_WINDOW_WIDTH' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:52: `glutGet' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h:53: `GLUT_WINDOW_HEIGHT' undeclared (first use this function) C:/msys/1.0/fg/include/plib/puGLUT.h: In function `void puSetWindowSizeGLUT(int, int)': C:/msys/1.0/fg/include/plib/puGLUT.h:58: `glutReshapeWindow' undeclared (first use this function) make[1]: *** [layout-props.o] Error 1 make: *** [all-recursive] Error 1 It's just occurred to me that a probable reason for this error may be that we now need PLIB cvs to build FGFS cvs (I'm still using 1.8.1), and I'll deal with it once I've reinstalled windows, but I thought you lot might like to know, especially as, should that be the case, this is the first time since 0.9.4 we have moved from being dependent on Plib 0.8.x :) Giles Robertson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
On Wednesday 12 May 2004 20:04, Andy Ross wrote: > Lee Elliott wrote: > > Was the stencil shadow stuff for generating object shadows? How far > > off usable was it, and did it only work with your terrain engine? > > It was decidedly "demo" quality. But it was part of the model code, > not the terrain engine. Doing shadows on terrain is sort of a 2D > problem, and actually a little simpler (computationally faster, if not > algorithmically easier) than doing a full-on general shadow > implementation. > > Basically, there are two general techniques for doing shadows with 3D > hardware: > > The first is to draw the object casting the shadow into a > 1-bit-plus-depth "shadow buffer" from the point of view of the light > source. You then use this buffer as a modulating texture for the > light source when drawing the objects on which the shadow falls. This > is a relatively straightforward process (although it requires some > form of rendering to a texture, which wasn't standardized in OpenGL > until recently) and works fast. The problems are that the resolution > is limited to what you pick for the texture, so you can see pixelation > effects if the viewer is close to an object which is "far" from the > shadow caster. More seriously, you cannot use this technique for > objects which cast shadows on *themselves* since the depth information > in the shadow buffer isn't precise enough. > > Stenciling is the other trick. This is a geometric technique where > you draw the "shadow volume" of an object into the stencil buffer. > For each triangle, for example, you draw a tetrahedron containing its > vertices and a vertex projected "infinitely" far away from the light > source. You then use some nifty tricks involving the stencil buffer > to tell which screen pixels are lit by the light source. This is a > great technique, and works correctly in a very nice general way for > every surface on the screen. > > It's also abysmally slow when implemented naively. Every (!) polygon > ends up beign drawn as a big swath from its real position to one edge > of the screen. This eats fill rate like there's no tomorrow. > Production implementation need to do lots of bookeeping work to > optimize the shadow volume such that only polygons on the silouette of > the object are drawn (others are essentially useless). This is the > part I didn't finish. :) > > Andy Thanks for the info. It's something I've wondered about, in a 'how do they do that?' sort of way, but it's a bit beyond my programming ability to do anything practical about it. Something to look forwards to, perhaps;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
Erp! - I don't mind top or bottom posting, but both in a single e-mail confuses me;) Those screen shots were taken using the old photo scenery for KSJC, together with the old scenery data. I don't think it's been re-worked for the new scenery data - I no longer have it installed. So it's a bit of artistic license really;) LeeE On Wednesday 12 May 2004 19:54, Giles Robertson wrote: > Lee - > There's no way that the screenshots on your site look like my standard > FG scenery - I've never seen proper joins of taxiways to runways etc. > How did you take them? > > Giles Robertson > > > -Original Message- > > From: Lee Elliott [mailto:[EMAIL PROTECTED] > > Sent: 12 May 2004 18:38 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] A/C turns without power > > > > On Wednesday 12 May 2004 14:16, David Culp wrote: > > > > > While playing around tonight I > > > > > noticed that the models on the > > > > > groung with no engines running > > > > > will turn in a circle left or right depending > > > > > on which way the rudder/steering is pointing. > > > > > if the steering is straight ahead(rudder centered) > > > > > then the A/C does not turn. > > > > > > > > Which FDM(s)? > > > > > > I see it happening in JSBSim, with engines running or not. Could be > > due > > > to > > > > > the jitter, or residual "u-fps", which never gets to zero > > (fluctuates > > > > around 0.002 to 0.007). The new ground reactions system might fix > > that. > > > > As for Yasim, I tried the A-10, but it either sits on its tail, or > > > > bounces > > > > > continualy on its gear. Maybe I have an old config. > > > > > > > > > Dave > > > > Re the A-10 problem: is this with the cvs version? > > > > There's an updated package available at > > > > http://www.overthetop.freeserve.co.uk/FlightGearAC.html > > > > It's still not textured properly atm - just converted to .ac format > > and > > > coloured, but as it's been re-named it'll co-exist with the version > > currently > > in cvs. This version should sit on it's u/c ok, even with no fuel in > > it;) > > > LeeE > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Saitek Cyborg Evo joystick xml file done
I witnessed a lot of discussion about joysticks with flightgear under windows, and the swapped axis problem. But when I connected this one, the only problem I had was that the default joystick mapping didn't include rudder control! Anyway, I made an xml based off of the Cyborg Gold 3D USB xml file and it works pretty well for me. If anyone wants a copy, I'll send it to you. Should this maybe go in the CVS? -Phillip ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Shadows
Lee Elliott wrote: > Was the stencil shadow stuff for generating object shadows? How far > off usable was it, and did it only work with your terrain engine? It was decidedly "demo" quality. But it was part of the model code, not the terrain engine. Doing shadows on terrain is sort of a 2D problem, and actually a little simpler (computationally faster, if not algorithmically easier) than doing a full-on general shadow implementation. Basically, there are two general techniques for doing shadows with 3D hardware: The first is to draw the object casting the shadow into a 1-bit-plus-depth "shadow buffer" from the point of view of the light source. You then use this buffer as a modulating texture for the light source when drawing the objects on which the shadow falls. This is a relatively straightforward process (although it requires some form of rendering to a texture, which wasn't standardized in OpenGL until recently) and works fast. The problems are that the resolution is limited to what you pick for the texture, so you can see pixelation effects if the viewer is close to an object which is "far" from the shadow caster. More seriously, you cannot use this technique for objects which cast shadows on *themselves* since the depth information in the shadow buffer isn't precise enough. Stenciling is the other trick. This is a geometric technique where you draw the "shadow volume" of an object into the stencil buffer. For each triangle, for example, you draw a tetrahedron containing its vertices and a vertex projected "infinitely" far away from the light source. You then use some nifty tricks involving the stencil buffer to tell which screen pixels are lit by the light source. This is a great technique, and works correctly in a very nice general way for every surface on the screen. It's also abysmally slow when implemented naively. Every (!) polygon ends up beign drawn as a big swath from its real position to one edge of the screen. This eats fill rate like there's no tomorrow. Production implementation need to do lots of bookeeping work to optimize the shadow volume such that only polygons on the silouette of the object are drawn (others are essentially useless). This is the part I didn't finish. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] A/C turns without power
Lee - There's no way that the screenshots on your site look like my standard FG scenery - I've never seen proper joins of taxiways to runways etc. How did you take them? Giles Robertson > -Original Message- > From: Lee Elliott [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 18:38 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] A/C turns without power > > On Wednesday 12 May 2004 14:16, David Culp wrote: > > > > While playing around tonight I > > > > noticed that the models on the > > > > groung with no engines running > > > > will turn in a circle left or right depending > > > > on which way the rudder/steering is pointing. > > > > if the steering is straight ahead(rudder centered) > > > > then the A/C does not turn. > > > > > > Which FDM(s)? > > > > I see it happening in JSBSim, with engines running or not. Could be due > to > > the jitter, or residual "u-fps", which never gets to zero (fluctuates > > around 0.002 to 0.007). The new ground reactions system might fix that. > > > > As for Yasim, I tried the A-10, but it either sits on its tail, or > bounces > > continualy on its gear. Maybe I have an old config. > > > > > > Dave > > Re the A-10 problem: is this with the cvs version? > > There's an updated package available at > > http://www.overthetop.freeserve.co.uk/FlightGearAC.html > > It's still not textured properly atm - just converted to .ac format and > coloured, but as it's been re-named it'll co-exist with the version > currently > in cvs. This version should sit on it's u/c ok, even with no fuel in it;) > > LeeE > > ___ > 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] GUI Layout Management
On Wednesday 12 May 2004 16:37, Andy Ross wrote: [snip...] > * FWIW, this is almost the last of my useful code from last spring. > Nasal and the Plib vertex splitting code are two other bits that > were useful in isolation. I also had a terrain engine and stencil > shadow implementation, but those weren't really production quality. > > Andy Was the stencil shadow stuff for generating object shadows? How far off usable was it, and did it only work with your terrain engine? It would be nice to have generated shadows - After trying them for a while, I've come to the conclusion that using fake shadow objects doesn't really cut it and I've started removing them from my models. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
On Wednesday 12 May 2004 14:16, David Culp wrote: > > > While playing around tonight I > > > noticed that the models on the > > > groung with no engines running > > > will turn in a circle left or right depending > > > on which way the rudder/steering is pointing. > > > if the steering is straight ahead(rudder centered) > > > then the A/C does not turn. > > > > Which FDM(s)? > > I see it happening in JSBSim, with engines running or not. Could be due to > the jitter, or residual "u-fps", which never gets to zero (fluctuates > around 0.002 to 0.007). The new ground reactions system might fix that. > > As for Yasim, I tried the A-10, but it either sits on its tail, or bounces > continualy on its gear. Maybe I have an old config. > > > Dave Re the A-10 problem: is this with the cvs version? There's an updated package available at http://www.overthetop.freeserve.co.uk/FlightGearAC.html It's still not textured properly atm - just converted to .ac format and coloured, but as it's been re-named it'll co-exist with the version currently in cvs. This version should sit on it's u/c ok, even with no fuel in it;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
I wrote: > Curtis L. Olson wrote: > > I can't seem to set autothrottle speed with the new autopilot > > dialog. It keeps reverting 1.0 (might there be anyway to > > trim the trailing zeros?) > > A better solution would be to either write some Nasal to keep the > values synchronized or else think of a new layout that works with only > one input for both radio buttons... I just checked in a version that eliminates one of the fields and "rowspan's" the remaining one to center it over both lines. Ugly, maybe, but it should work for now. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Andy Ross wrote: I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) Whoo hoo! Now I can take that off my ever longer to-do list. Note to self: procrastination pays. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Curtis L. Olson wrote: > I can't seem to set autothrottle speed with the new autopilot > dialog. It keeps reverting 1.0 (might there be anyway to > trim the trailing zeros?) Oh, whoops. Sorry, I meant to fix this before I checked it in but forgot. Both the pitch and speed input fields are mapped to the same property. I left two input fields in for symmetry, but the Nasal code that runs before the dialog-update command always sets the pitch one last, so it overrides. The immediate workaround is to set the value in the second field. A better solution would be to either write some Nasal to keep the values synchronized or else think of a new layout that works with only one input for both radio buttons... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI Layout Management
Andy Ross wrote: I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) I've redone a few of the dialogs using the new scheme (I'm especially proud of the autopilot dialog: http://plausible.org/andy/autopilot-new.png), so you can see what the possibilities look like. I can't seem to set autothrottle speed with the new autopilot dialog. It keeps reverting 1.0 (might there be anyway to trim the trailing zeros?) 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
[Flightgear-devel] GUI Layout Management
I just commited an implementation of GUI layout management, ported over from my game project last year*. What this means is that you no longer need to position your widgets manually in dialogs, and can instead lay them out in tables and boxes like the pros do. :) I've redone a few of the dialogs using the new scheme (I'm especially proud of the autopilot dialog: http://plausible.org/andy/autopilot-new.png), so you can see what the possibilities look like. * FWIW, this is almost the last of my useful code from last spring. Nasal and the Plib vertex splitting code are two other bits that were useful in isolation. I also had a terrain engine and stencil shadow implementation, but those weren't really production quality. Basically, the implementation is a preprocessor on top of the existing dialog properties, which sets x/y/width/height values based on constraints. The objects, including the top-level one which represents the whole dialog, can now have a property, which can be "hbox", "vbox", or "table". The boxes simply lay out their children in order, either top-to-bottom or left-to-right. The box name comes from Qt and Gtk, but this is also the same thing that Java calls a "flow layout", or what the Tk "packer" does. You can set "constraint" properties on the children, to give the layout manager hints as to how to place the children. For the boxes, these are: equal: The box manager makes sure that all the widgets with this constraint set to true get equal sizes big enough to fit the largest one. This is very useful for button boxes to make the "OK" and "Cancel" buttons match, for example. stretch: Cells with "stretch" set to true get all the extra space, if any, the box has to allocate. These are useful for alignment purposes, especially when combined with "widgets" (which are ignored by the dialog creation code, but honored by the layout engine). The table layout will be a little more familiar to anyone with HTML experience. Children of tables get the following constraints: row: The row number containing the upper left corner of the widget. Table rows are zero-indexed. col: The column number containing the upper left corner of the widget. Table columns are zero-indexed. rowspan: The number of rows spanned by the widget. Defaults to one. colspan: The number of columns spanned by the widget. Defaults to one. Inside of each "cell", regardless of parent layout, there are some constraints that are used to position the widget within the space available: halign: The horizontal alignment. Can be "left", "right", "center", or "fill" (i.e. stretch to available space). valign: The vertical alignment. Can be "top", "bottom", "center", or "fill". padding: The number of pixels to leave between the edge of the cell and the widget. pref-height: pref-width: Overrides the default preferred size of the widget. Note that this is the size of the widget only, not the cell (which includes padding). Also, the padding values for cells in a group can be set to a default value with a property on the group widget. Some will ask why didn't I implement this as part of Pui. The problem is the pui just isn't set up for it. Not only is there no notion of "preferred" size for a widget, there isn't anything remote like a "constraint" system for attaching arbitrary values to widgets. With the property system, I have that for free (the original code was written to work with Nasal objects, btw). I can do the layout with the properties and on the properties, and our existing dialog code hardly needs to change at all. Anyway, give it a try and see if I've broken anything. Also, note that some of these changes *do* modify the visual appearance of the GUI. I think it looks better, but opinions will no doubt vary. Shout if you hate it. And finally, the text alignment doesn't quite look right with current plib due to some minor rendering bugs. Bug Steve to apply the patch I submitted a week or so ago. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Wednesday 12 May 2004 16:20, Andy Ross wrote: > Mathias Fröhlich wrote: > > May be this 'do not use a leading slach' should also show up in that > > model animation HOWTO? > > Or even generate a runtime warning during parsing. This is a really > easy typo to make. > I guess both are excellent ideas. I consulted David Culp's 737 config file to find out why the MD11 animation didn't work initially, and I didn't even spot the difference in leading slash between his configuration file and the animation section I had just I copied from Ampere's email until Erik's message. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Mathias Fröhlich wrote: > May be this 'do not use a leading slach' should also show up in that > model animation HOWTO? Or even generate a runtime warning during parsing. This is a really easy typo to make. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MD-11 Good News
How often do people need to specify the state of gear etc globally? I can't, offhand, think of a point at which you want all the aircraft in the world how drop the gear. Considering this, is the typo easy enough to make that we ought to change the behaviour? - or is this mucking up the established system too much? Or perhaps, /property/value should reference to the aircraft currently under user control, which would extend compatibility if we ever implement a 'switch which aircraft you are flying in mid-air' feature. Giles Robertson > -Original Message- > From: Andy Ross [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 14:21 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] MD-11 Good News > > Mathias Fröhlich wrote: > > May be this 'do not use a leading slach' should also show up in that > > model animation HOWTO? > > Or even generate a runtime warning during parsing. This is a really > easy typo to make. > > Andy > > > ___ > 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] Why ZERO
Innis Cunningham wrote: > I am just wondering is there a very good reason that we use zero to > number things in FG. Engines tanks and the like. Because in the real > world of aviation nothing is numbered zero as far as I know. > > Why does it matter you may ask. Well it seems a bit strange that a > four engined aircraft has engines numbered 0-3 and a three engined > aircraft has engines numbered 0-2 and so on. As FG grows and more > systems are added it would seem to me that the confusion could > multiply. This can't be fixed. The underlying software engines (property system, C++, Nasal, all of it really) all use zero based indexing in accordance with (very) long standing software engineering convention. There's no reason the user should ever be exposed to internal indexing anyway, so the best we can do is present a consistent picture to the developers. As confused as you might be, I assure you it would only be worse if we all had to remember which subsystem used which array indexing convention. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Why ZERO
Innis Cunningham wrote: I am just wondering is there a very good reason that we use zero to number things in FG.Engines tanks and the like.Because in the real world of aviation nothing is numbered zero as far as I know. Property files were originally for use by (semi-) programmers, who are used to working with zero-based arrays. Over the past couple of years, we have hard-coded engines, etc., based on their positions in the property table, but it's probably time to move to a more elegant solution and specify engine numbers (etc.) explicitly. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Why ZERO
Because 0 is used in computing, if not aeronautics. (Small explanation for the non-technical: Originally, for complex and obscure technical reasons, array elements were numbered (indexed) starting at 0. This is still the case for c & c++ and most other languages. There is no real reason for doing so at present that I've ever found, apart from tradition. That said, some of the fastest binary tree implementations take advantage of this, but with the processing power we play with these days it can't be really relevant) Giles Robertson > -Original Message- > From: Innis Cunningham [mailto:[EMAIL PROTECTED] > Sent: 12 May 2004 13:30 > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Why ZERO > > Hi Guys > I am just wondering is there a > very good reason that we use > zero to number things in FG.Engines > tanks and the like.Because in the real > world of aviation nothing is numbered > zero as far as I know. > Why does it matter you may ask. > Well it seems a bit strange that a four > engined aircraft has engines numbered 0-3 > and a three engined aircraft has engines > numbered 0-2 and so on. > As FG grows and more systems are added > it would seem to me that the confusion > could multiply. > Is there a good reason that we do this > and how hard would it be to change. > I guess this applies to the FDM's to. > > Cheers > Innis > > _ > Personalise your phone with chart ringtones and polyphonics. Go to > http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp > > > ___ > 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] A/C turns without power
Innis Cunningham wrote: While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. It also seemed the lighter A/C turned at a faster rate then the bigger ones. Just an observation. Yes, it's part of the ground-reactions hell on the physics-engine side. Did you notice whether the problem was worse with the YASim or the JSBSim engine? I think there are some small differences in how they handle the stationary situation. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Ampere K. Hardraade wrote: > Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis > runs sideway. What convention would you have chosen? :) Coordinate systems are like cuisines. There's no accounting for taste, and you can't fix things by mixing them together. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
On Mittwoch, 12. Mai 2004 15:40, Innis Cunningham wrote: > >I see it happening in JSBSim, with engines running or not. Could be due > > to the jitter, or residual "u-fps", which never gets to zero (fluctuates > > around > >0.002 to 0.007). The new ground reactions system might fix that. > > Ok I have not got the latest CVS so don't know if its been fixed > already.This is just the 9.4 version Is in the works. Is not yet in JSBSim mainline ... Greetings Mathias -- Mathias FrÃhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
Hi David David Culp writes > > > Which FDM(s)? I was using the c172(dont know what it uses) and the MD-11 with JSBSim aeromatic generated FDM I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual "u-fps", which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. Ok I have not got the latest CVS so don't know if its been fixed already.This is just the 9.4 version As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. I have been aware for a long time now that with the park brake set the A/C jumps around with the stall warning horn sounding all the time. Dave -- Cheers Innis _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Why ZERO
Hi Guys I am just wondering is there a very good reason that we use zero to number things in FG.Engines tanks and the like.Because in the real world of aviation nothing is numbered zero as far as I know. Why does it matter you may ask. Well it seems a bit strange that a four engined aircraft has engines numbered 0-3 and a three engined aircraft has engines numbered 0-2 and so on. As FG grows and more systems are added it would seem to me that the confusion could multiply. Is there a good reason that we do this and how hard would it be to change. I guess this applies to the FDM's to. Cheers Innis _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
> > While playing around tonight I > > noticed that the models on the > > groung with no engines running > > will turn in a circle left or right depending > > on which way the rudder/steering is pointing. > > if the steering is straight ahead(rudder centered) > > then the A/C does not turn. > > Which FDM(s)? I see it happening in JSBSim, with engines running or not. Could be due to the jitter, or residual "u-fps", which never gets to zero (fluctuates around 0.002 to 0.007). The new ground reactions system might fix that. As for Yasim, I tried the A-10, but it either sits on its tail, or bounces continualy on its gear. Maybe I have an old config. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A/C turns without power
> While playing around tonight I > noticed that the models on the > groung with no engines running > will turn in a circle left or right depending > on which way the rudder/steering is pointing. > if the steering is straight ahead(rudder centered) > then the A/C does not turn. Which FDM(s)? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A/C turns without power
Hi All While playing around tonight I noticed that the models on the groung with no engines running will turn in a circle left or right depending on which way the rudder/steering is pointing. if the steering is straight ahead(rudder centered) then the A/C does not turn. It also seemed the lighter A/C turned at a faster rate then the bigger ones. Just an observation. Cheers Innis _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple windows - offset setting not working
Keeyoung Choi wrote: I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. In current versions you need to use something like: --prop:/sim/view/config/heading-offset-deg=45 --prop:/sim/view/config/pitch-offset-deg=3 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
[Flightgear-devel] multiple windows - offset setting not working
Hi, I posted this message to the user's group, but no one responded there. My department has a 3-screen setup for flightgear. With the old versions, it was possible to set the viewing angles for the right and left screen using command line option. However, with the current version (or recent few versions maybe), it doesn't work. I have to mannually adjust the offset. Could any developer take a look at this? Thanks. - Keeyoung ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Mathias Fröhlich wrote: On Mittwoch, 12. Mai 2004 09:56, Erik Hofman wrote: Just a heads up for every body again, Don't add the leading slash to the animation property (/controls/flight/rudder) but use relative paths instead (controls/flight/rudder) This allows the AIModel code to animate the model based on the property system for the particular AIModel rather than for the main aircraft (controlled by the user). Since the AIModel code will probably be used for ATC models and by the multiplayer code in the future this will give a much nicer view. For one thing that would mean that if the users extends the gear, all the AIModel will continue with gear up, instead of lowering the gear at the same time! May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Yes, that would be a good idea. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Mittwoch, 12. Mai 2004 09:56, Erik Hofman wrote: > Just a heads up for every body again, Don't add the leading slash to the > animation property (/controls/flight/rudder) but > use relative paths instead (controls/flight/rudder) > > This allows the AIModel code to animate the model based on the property > system for the particular AIModel rather than for the main aircraft > (controlled by the user). > > Since the AIModel code will probably be used for ATC models and by the > multiplayer code in the future this will give a much nicer view. > > For one thing that would mean that if the users extends the gear, all > the AIModel will continue with gear up, instead of lowering the gear at > the same time! May be this 'do not use a leading slach' should also show up in that model animation HOWTO? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
Durk Talsma wrote: Hi Ampere, I just tried your animation file. All I had to change were the lines that read /controls/rudder to /controls/flight/rudder and then I saw a nicely animated rudder appearing. Just a heads up for every body again, Don't add the leading slash to the animation property (/controls/flight/rudder) but use relative paths instead (controls/flight/rudder) This allows the AIModel code to animate the model based on the property system for the particular AIModel rather than for the main aircraft (controlled by the user). Since the AIModel code will probably be used for ATC models and by the multiplayer code in the future this will give a much nicer view. For one thing that would mean that if the users extends the gear, all the AIModel will continue with gear up, instead of lowering the gear at the same time! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tue, May 11, 2004 at 07:04:03PM -0400, Ampere K. Hardraade wrote: > Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs > sideway. No, that's not weird, that's standard in aeronautical engineering! (with the z-axis pointing down, btw.) Cheers, -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
