RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/Lockheed1049/Models
> That was my understanding of it, but it seemed to not work with ___'s > Connie model. Upon further review it looks like ___'s Connie model has > an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my > investigation of it. > > Dave :-) Once we get the new JSBSim FDM into FGFS CVS I'll have a look at it (there's always something _just_before_ the good stuff on my todo list). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 08:56 pm, Jon Berndt wrote: > No. The VRP defines the location of an agreed-upon reference point in > structural coordinates. The CG, eyepoint, gear locations, etc. are all > defined (in JSBSim) in structural frame. > ... That was my understanding of it, but it seemed to not work with ___'s Connie model. Upon further review it looks like ___'s Connie model has an x-offset of about 14 meters, and I can't figure out why. So, I'll drop my investigation of it. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
> One thing that may be confusing is that the VRP setting given by aeromatic is > wrong. In the JSBSim configuration file If the CG location is X, Y, Z, > then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the > location of the VRP, however it actually defines the location of the VRP > *from* the CG (?). I never noticed it in the T-38 and other smaller > airplanes because the effect is hard to see. In a big airplane like the 1049 > you can see it. > > The above may seem authoritative, but I'm really only 90% sure it's correct :) > I know you have all been waiting impatiently for another VRP thread. > > Dave No. The VRP defines the location of an agreed-upon reference point in structural coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) in structural frame. By convention, we've agreed that the nose is typically a good reference point, because it is (or should be obvious) to both the 3D model designer and the FDM designer. The CG generally cannot be used, because it moves - sometimes that movement could be profound. Think of it this way: the structural frame is a fixed, solid, coordinate frame that permeates the aircraft structure. The structural frame we use MUST have X positive out the back, and Y out the right wing. The Z axis completes the right-handed system positive upwards. The _origin_ is what is usually found to be confusing. Often, the origin is located by having the X axis be coincident with the fuselage centerline, with X=0 at the tip of the nose - but THAT IS NOT A REQUIREMENT. If the origin is 200 inches in front of the nose, then the VRP could be defined as (200, 0, 0). If the 3D model designer understands that, the aircraft model can be placed with the nose at the location pointed to by JSBSim. The VRP is the "registration mark" that relates what is reported by JSBSim and what part of the 3D model is placed at what location in the 3D world. Within JSBSim, the equations of motion are all done relative to the CG. However, JSBSim can send to FlightGear the lat/lon/alt of ANY desired point on the aircraft, at any time, in any orientation (it's not hard). We just have to agree on WHICH point is being sent. That's what the VRP is all about. I pray to God that explains it for the last time! :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049 - New
> The Constellation looks pretty nice, but has a significant drawback: > The author has forgotten to implement the offset between FDM center and > visual reference point. This means the aircraft rotates around it's > nose which makes it almost impossible to accurately rotate for liftoff. > Furtheron it looks really funny when the aircraft wags the whole > body when you use the elevator ;-) > > Syd, I presume this is your work. Would you mind adding this offset ? > > Thanks, > Martin. I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for noticing the VRP aspect. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Quoting Vivian Meazza : > > The patch has been committed to plib CVS. Now we only (...) need to > > convince them to release a new stable version. > > > > Excellent news, what about the joystick problem? not committed yet, but I just asked again on the plib list. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: Erik Hofman wrote: The policy is not meant for the binary releases. A binary-release maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. The policy is to make it _work_ with the latest official plib release. Now I'm confused. Make what work? Sorry, I meant: ... make sure FlightGear will work at least with ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Erik Hofman wrote: > Vivian Meazza wrote: > > > > So we have the situation where at least some of the current binary > releases, > > do not follow this policy. The Windows for one seems to accept the > crease > > token. > > The policy is not meant for the binary releases. A binary-release > maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. > The policy is to make it _work_ with the latest official plib release. Now I'm confused. Make what work? > > We speak of Mathias' crease patch, but we should remember that it also > > produced around 40% increase in performance, certainly for Cygwin. I > would > > not like to go back to the status quo ante, but I realize the very good > > rationale for it. > > The patch has been committed to plib CVS. Now we only (...) need to > convince them to release a new stable version. > Excellent news, what about the joystick problem? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: > So we have the situation where at least some of the current binary releases, > do not follow this policy. The Windows for one seems to accept the crease > token. Binary releases, by definition, are not meant to be rebuild, so the hassle of collecting patches and making all work is only supported by one volunteer, not the average user that want to compile from scratch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. The policy is not meant for the binary releases. A binary-release maintainer may even chose to use plib-1.7.3 if he/she wishes to do so. The policy is to make it _work_ with the latest official plib release. We speak of Mathias' crease patch, but we should remember that it also produced around 40% increase in performance, certainly for Cygwin. I would not like to go back to the status quo ante, but I realize the very good rationale for it. The patch has been committed to plib CVS. Now we only (...) need to convince them to release a new stable version. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Curt wrote: > As a project, FlightGear needs to depend on the stable releases of the > stuff it depends on, not cvs development trees. That get's to be too > big of a mess. Many distributions include the latest stable version of > plib, and that is often easier to build. It's ok for developers to use > cvs versions of our dependencies, as long as they don't break > compatibility with the latest stable version. After about 1 second's consideration, I realized that of course this is the only reasonable policy. Unfortunately, now I remember why I changed to using crease: >Martin Spott wrote: >> "Curtis L. Olson" wrote: >> >>>Update of /var/cvs/FlightGear-0.9/releases >>>In directory baron:/tmp/cvs-serv18174 >> >> >>>Added Files: >>>FlightGear-0.9.6.tar.gz >>>Log Message: >>>Official source release for v0.9.6 >> >> >> I'm asking just to find out: Do we all agree that it makes much sense >> to build the upcoming binary releases with a "crease-patched" version >> of current PLIB CVS ? > > >I will > >Erik So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. We speak of Mathias' crease patch, but we should remember that it also produced around 40% increase in performance, certainly for Cygwin. I would not like to go back to the status quo ante, but I realize the very good rationale for it. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Curtis L. Olson wrote: > Perhaps as a direct suggestion to the immediate issue of the crease > patch, we should get more FG people onboard as plib contributors with > cvs access so we can make direct contributions and get this fixed? I looked at the developer list of the plib project ( http://sourceforge.net/project/memberlist.php?group_id=382 ) and was amazed that a project with so many developers ( 23 ) has so much difficulties to commit the simple patch. I even don't speak about the crease patch, but the windows joystick was broken and my one liner never got commited even with multiple reminders. Among the list of plib registered developers, some are frequently contributing to the flightgear project : - Alex Perry - Curtis Olson - Norman Vine -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
"Curtis L. Olson" wrote: > We all are busy. Steve is extremely busy. It doesn't hurt to follow up > on these things (more than once if needed.) If done in a "sensitive" > way, you can usually accomplish reasonable things with reasonable people. I don't think anyone here is attempting to blame Steve for being extremely busy. The simple question is - trying to get back to the starting point - if it makes sense to hold back valuable improvement in FlightGear just because you rely on a scene graph library where you have to wait several months until 1.) someone is convenient with having a look at your submission and 2.) this submission _might_ show up in a release. I created my private PLIB packages in an attempt to circumvent this 'lock' - until some better solution comes up. These packages carry a 'time stamp' and everyone is free to reference these. > Perhaps as a direct suggestion to the immediate issue of the crease > patch, we should get more FG people onboard as plib contributors with > cvs access so we can make direct contributions and get this fixed? This might be the ultimate solution. Until you/we are there, feel free to rely on the 'intermediate', 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Vivian Meazza wrote:
Martin Spott
No, it's just a matter of stability. We don't want FlightGear
releases to have to depend on prerelease CVS versions of plib, so we
have to wait until the next plib official release.
I'm not convinced that this actually is the point. FlightGear has a
history of depending on a moving PLIB CVS target - Curt has 'convinced'
Steve Baker more than once to issue a PLIB release right before the
next FlightGear release. My "custom patched versions of plib"-package
is far more stable than PLIB CVS trees that have been mandantory many
times in the past - it even carries a time stamp :-)
So it is, and it works with Cygwin.
[...] By the way, are
you certain now that the crease patch is in the plib CVS?
This is the key point: PLIB folks ("core developers") typically don't
feel much urge to commit a patch that they didn't invent themselves or
that servers their own purpose. Steve decided that he didn't have much
use for Mathias' patch so no one actually bothered to commit,
As I thought - NIH. I'm underwhelmed. So where do we go from here - do our
own loaders? Maintain our own version of PLIB?
Don't forget we are all open-source developers here. The plib guys are
volunteers just like us. It's pretty easy to be critical and jump ship
(so to speak.) It's harder to live with each other and work towards the
common good of everyone ... especially with the weird characters that
show up on the open-source scene.
We all are busy. Steve is extremely busy. It doesn't hurt to follow up
on these things (more than once if needed.) If done in a "sensitive"
way, you can usually accomplish reasonable things with reasonable people.
Just keep in mind that we are all volunteers, all have day jobs, many of
us have families, we can't all sit and monitor the FG or plib mailing
lists 24/7 and drop everything to address every issue that comes up
immediately when it comes up.
And also, please be aware that with the volume of mail that most of us
get, if we can't do something right away (which is often/usually the
case) the email quickly gets buried beneath a flood of newer requests
and problems. I'm always waiting for that lull in the action which
would allow me to go back through my inbox(s) and address some of the
backlog, but such a lull never (or rarely) happens.
Perhaps as a direct suggestion to the immediate issue of the crease
patch, we should get more FG people onboard as plib contributors with
cvs access so we can make direct contributions and get this fixed?
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
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Martin Spott
>
> > No, it's just a matter of stability. We don't want FlightGear
> > releases to have to depend on prerelease CVS versions of plib, so we
> > have to wait until the next plib official release.
>
> I'm not convinced that this actually is the point. FlightGear has a
> history of depending on a moving PLIB CVS target - Curt has 'convinced'
> Steve Baker more than once to issue a PLIB release right before the
> next FlightGear release. My "custom patched versions of plib"-package
> is far more stable than PLIB CVS trees that have been mandantory many
> times in the past - it even carries a time stamp :-)
So it is, and it works with Cygwin.
> > [...] By the way, are
> > you certain now that the crease patch is in the plib CVS?
>
> This is the key point: PLIB folks ("core developers") typically don't
> feel much urge to commit a patch that they didn't invent themselves or
> that servers their own purpose. Steve decided that he didn't have much
> use for Mathias' patch so no one actually bothered to commit,
>
As I thought - NIH. I'm underwhelmed. So where do we go from here - do our
own loaders? Maintain our own version of PLIB?
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
David Megginson wrote:
> On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza
> No, it's just a matter of stability. We don't want FlightGear
> releases to have to depend on prerelease CVS versions of plib, so we
> have to wait until the next plib official release.
I'm not convinced that this actually is the point. FlightGear has a
history of depending on a moving PLIB CVS target - Curt has 'convinced'
Steve Baker more than once to issue a PLIB release right before the
next FlightGear release. My "custom patched versions of plib"-package
is far more stable than PLIB CVS trees that have been mandantory many
times in the past - it even carries a time stamp :-)
> [...] By the way, are
> you certain now that the crease patch is in the plib CVS?
This is the key point: PLIB folks ("core developers") typically don't
feel much urge to commit a patch that they didn't invent themselves or
that servers their own purpose. Steve decided that he didn't have much
use for Mathias' patch so no one actually bothered to commit,
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
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. As a project, FlightGear needs to depend on the stable releases of the stuff it depends on, not cvs development trees. That get's to be too big of a mess. Many distributions include the latest stable version of plib, and that is often easier to build. It's ok for developers to use cvs versions of our dependencies, as long as they don't break compatibility with the latest stable version. 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza <[EMAIL PROTECTED]> wrote: > Sorry guys, I sent today's Nimitz before I realized that Curt was removing > crease tokens. Mind you, after all the effort we went to get it in ... I'm a > bit confused here. Mathias submitted a patch to plib, and I thought that > Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) > or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. By the way, are you certain now that the crease patch is in the plib CVS? Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Melchior FRANZ > * Jon Stockill -- Tuesday 30 November 2004 16:39: > > At 03:47 today. > > > > Modified Files: > > nimitz.ac > > Log Message: > > Remove "crease" tag so that people without custom patched versions of > > plib can still run FlightGear. :-) > > Yes, and at ... um ... right *now*: > > $ cd $FG_ROOT/Models/Geometry/Nimitz/ > $ find -name \*.ac|xargs grep crease|wc -l > 248 > > so today's Nimitz has all the "crease"s again. And FWIW: > > $ cd $FG_ROOT/Aircraft/ > $ find -name \*.ac|xargs grep crease|wc -l > 890 > Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Data/AInimitz_demo.xml, NONE, 1.1
Melchior FRANZ wrote > > Mathias has put all the necessary stuff here: > > > > ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ > > > > The code that he sent me works well, but I haven't tried it from that > > location yet. > > I applied all the stuff and it worked very well. My first carrier landing > with the FA-18A succeeded already. The gear code is great! It's fun to > taxi over slopes and actually see the aircraft follow them, rather than > strangely sliding up with the nose gear below ground. And the FA-18 is > very well done and has a nice cockpit with nice night lighting. > > The only problems I've encountered: > > * not really surprisingly, the carrier doesn't replay in replay mode. > When I watched my landing in replay, the carrier had already moved > along. Tricky to fix. This seems to be the case for all AI objects. Fixing it is certainly beyond me. > * I observed one segfault that I hadn't seen before. The bt, however, > didn't > look like it had anything to do with the new code. I haven't saved the > core > file but will do so if I run into that problem again. This is a new fault, and may be related to the new code, but Erik reported a segfault as well, so any help you can give in running it down would be welcome. We have to solve the problem before the code can be committed to CVS. > > Now I hope that I will soon be able to land the bo105 realistically > on slight slopes ... > Mathias is working on it, but he's been diverted to real work for a while! We should be able to land the Hunter or Seahawk on Nimitz soonish, unrealistic but fun. Back to projector landing sights Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/bo105/Models bo105.ac, 1.8,
Jim Wilson > > > "Curtis L. Olson" said: > > > Jim Wilson wrote: > > > > >How about this one? ;-) > > > > > >http://www.spiderbark.com/fgfs/barneymobile.png > > > > > > > > > > Is that the don't-ask-don't-tellicopter. > > > > Haha! Is this what they call aviation innuendo? What about > these folks: > > http://www.harrierpilot.com/oct01/purple.jpg > > They must be British. :::duck::: ;-) > Reckon that's a USMC Harrier. I would definitely duck if I were you ! Regards Vivian M. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Melchior FRANZ wrote: > > Could the prop pitch be the problem > > Unlikely -- it's already maximum by default. > > > > > - I can't find any method of controlling it > > Either via http/telnet/property browser: > > /controls/engines/engine[n]/propeller-pitch > > Some joystick configs support it. And finally, you can add a > key definition to you personal config, e.g.: > > > > q > Decrease prop pitch. > > nasal > controls.adjPropeller(-1) > > > > > Q > Increase prop pitch. > > nasal > controls.adjPropeller(1) > > > > m. Thanks - I'll add suitable bindings to my joystick. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel]Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
* Vivian Meazza -- Friday 13 February 2004 13:19: > Could the prop pitch be the problem Unlikely -- it's already maximum by default. > - I can't find any method of controlling it Either via http/telnet/property browser: /controls/engines/engine[n]/propeller-pitch Some joystick configs support it. And finally, you can add a key definition to you personal config, e.g.: q Decrease prop pitch. nasal controls.adjPropeller(-1) Q Increase prop pitch. nasal controls.adjPropeller(1) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson wrote > > Vivian Meazza <[EMAIL PROTECTED]> said: > > > > Josh Babcock > > > > > Vivian Meazza wrote: > > > > > > > > > > >I enter the loop in a shallow dive, 2nd stage boost on, 350 > > > kts, pull > > > >baaack the stick and the model rolls violently and does not > > > enter the > > > >loop ... Works fine in other models so it's not the obvious - the > > > >joystick. But I expect I'm doing something wrong. > > > > > > > > > > > > > > > Yup. Specifically, you are doing a snap roll. If you can > > > keep the the > > > AOA down, the plane won't stall and go into a snap roll. You > > > could also > > > try adding some flaps, but I'm not sure if that would bleed > > > off too much > > > energy. Best to just make the loop bigger. Remember, > pull back a > > > little, and the plane goes up. Pull back a lot, and the > > > plane goes down > > > ... fast. > > > > Thanks for the advice. It's not easy without Pilot's Notes > specifying > > some entry conditions. I was guessing 350 kts I was > probably pulling > > back too hard, difficult to remember. Too slow, and the model falls > > off the top, of course. Back to the Hunter - it's much > easier - but I > > designed it that way, and it flew that way too :-). > > It sure is fun doing those, I just tried it for the first > time in a while on the p51. You want to get up in the air > (4500-5000ft agl). Manfold pressure should be in the 50-55 > range, and prop pitch at max rpm. Go into a nice dive and > pull back in the low 2000ft range. Once you get it the > aircraft going good you can actually pull back pretty > hard...and you can do multiple loops if your pilot has the > stomach. You'll stall it quicker if you do a large loop, it > gives gravity too much time to bleed off your momentum. > Flaps will increase drag and not really help much with those stalls. > > The FDM is probably a little off. Andy just made a prop > gearing change to YASim a couple weeks ago that should be > useful in making the P51-D more accurate with a little tinkering. > Still can't do it. Could the prop pitch be the problem - I can't find any method of controlling it - could you give me a hint (other than RTM :-)) Thanks for you help Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > > Josh Babcock > > > Vivian Meazza wrote: > > > > > > > >I enter the loop in a shallow dive, 2nd stage boost on, 350 > > kts, pull > > >baaack the stick and the model rolls violently and does not > > enter the > > >loop ... Works fine in other models so it's not the obvious - the > > >joystick. But I expect I'm doing something wrong. > > > > > > > > > > > Yup. Specifically, you are doing a snap roll. If you can > > keep the the > > AOA down, the plane won't stall and go into a snap roll. You > > could also > > try adding some flaps, but I'm not sure if that would bleed > > off too much > > energy. Best to just make the loop bigger. Remember, pull back a > > little, and the plane goes up. Pull back a lot, and the > > plane goes down > > ... fast. > > Thanks for the advice. It's not easy without Pilot's Notes specifying some > entry conditions. I was guessing 350 kts I was probably pulling back too > hard, difficult to remember. Too slow, and the model falls off the top, of > course. Back to the Hunter - it's much easier - but I designed it that way, > and it flew that way too :-). It sure is fun doing those, I just tried it for the first time in a while on the p51. You want to get up in the air (4500-5000ft agl). Manfold pressure should be in the 50-55 range, and prop pitch at max rpm. Go into a nice dive and pull back in the low 2000ft range. Once you get it the aircraft going good you can actually pull back pretty hard...and you can do multiple loops if your pilot has the stomach. You'll stall it quicker if you do a large loop, it gives gravity too much time to bleed off your momentum. Flaps will increase drag and not really help much with those stalls. The FDM is probably a little off. Andy just made a prop gearing change to YASim a couple weeks ago that should be useful in making the P51-D more accurate with a little tinkering. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
> Josh Babcock > Vivian Meazza wrote: > > > > >I enter the loop in a shallow dive, 2nd stage boost on, 350 > kts, pull > >baaack the stick and the model rolls violently and does not > enter the > >loop ... Works fine in other models so it's not the obvious - the > >joystick. But I expect I'm doing something wrong. > > > > > > > Yup. Specifically, you are doing a snap roll. If you can > keep the the > AOA down, the plane won't stall and go into a snap roll. You > could also > try adding some flaps, but I'm not sure if that would bleed > off too much > energy. Best to just make the loop bigger. Remember, pull back a > little, and the plane goes up. Pull back a lot, and the > plane goes down > ... fast. Thanks for the advice. It's not easy without Pilot's Notes specifying some entry conditions. I was guessing 350 kts I was probably pulling back too hard, difficult to remember. Too slow, and the model falls off the top, of course. Back to the Hunter - it's much easier - but I designed it that way, and it flew that way too :-). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson asked > Vivian Meazza <[EMAIL PROTECTED]> said: > > > I moved the origin, then applied an equal and opposite offset. When > > one differential brake is applied and the model is viewed in or > > helicopter view tower view it appears to be turning around its axis > > rather than around the braked wheel. That said, in chase > view and in > > chase view wo (without) yaw it looks good. This is seems to be the > > case if the model origin is either the nose (and with > offset) or with > > the CofG as the origin. Am I seeing some artefact of the > view perhaps? > > Seem just fine in cockpit view however. > > Hmmm...I'm not sure about that. It sounds like it is a view > problem. Can you post your latest files so I can take a look > after I get home from work? > Delighted to that Jim, but how does that help, and how do I do it. Sorry to be dull. I'd really like to be able to show you a video ... Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza wrote: I enter the loop in a shallow dive, 2nd stage boost on, 350 kts, pull baaack the stick and the model rolls violently and does not enter the loop ... Works fine in other models so it's not the obvious - the joystick. But I expect I'm doing something wrong. Yup. Specifically, you are doing a snap roll. If you can keep the the AOA down, the plane won't stall and go into a snap roll. You could also try adding some flaps, but I'm not sure if that would bleed off too much energy. Best to just make the loop bigger. Remember, pull back a little, and the plane goes up. Pull back a lot, and the plane goes down ... fast. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > I moved the origin, then applied an equal and opposite offset. When one > differential brake is applied and the model is viewed in or helicopter view > tower view it appears to be turning around its axis rather than around the > braked wheel. That said, in chase view and in chase view wo (without) yaw it > looks good. This is seems to be the case if the model origin is either the > nose (and with offset) or with the CofG as the origin. Am I seeing some > artefact of the view perhaps? Seem just fine in cockpit view however. Hmmm...I'm not sure about that. It sounds like it is a view problem. Can you post your latest files so I can take a look after I get home from work? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson added > Vivian Meazza <[EMAIL PROTECTED]> said: > > > Tried that. Looks just the same to me. As I said some time ago: yer > > pays yer money and yer takes yer choice. Neither is right on the > > ground for differential braking: with one brake full on the > aircraft > > more or less rotates around that wheel. The model doesn't! When the > > aircraft is moving the forward the CofG should rotate about > some point > > outboard of the braked wheel. All to do with tyre slip > angles, but I'm > > not sure if the FDM's know about those, and I would need to > consult my > > race engineering handbooks. > > > > But, hey, we're building flight simulator, not a ground handling > > simulator. If it's good enough that'll do me. > > The ground handling is all part of it. I'm not sure what you > are seeing...but if you moved the origin then the aircraft > should have at least moved the same amount. It might "look" > the same but look closer. Are the wheels in the same > spot on startup? Basically with you need to make sure the > gear is in the > right spot, etc, etc. I moved the origin, then applied an equal and opposite offset. When one differential brake is applied and the model is viewed in or helicopter view tower view it appears to be turning around its axis rather than around the braked wheel. That said, in chase view and in chase view wo (without) yaw it looks good. This is seems to be the case if the model origin is either the nose (and with offset) or with the CofG as the origin. Am I seeing some artefact of the view perhaps? Seem just fine in cockpit view however. > With YASim fdm configs you can > configure gear animation so that when it compresses in yasim > the gear compresses visually too. YASim will drop the > altitude by an amount relevant to the modeled gear > compression so the aircraft will drop, but the wheels will go > "through the pavement" if you don't amimate the compression > in the 3D model. Been there done that, no probs. > > > PS why in an external view does the Hunter appear to do an > upward roll > > in the up leg of a loop. And a downward roll in the down > leg? And why > > can't I loop the P51? > > I'm not sure what you mean. but there is no problem looping > the p51d. I've done it many times. You might need to hit > ctrl+b to get the manifold pressure up to second stage level. > Am I understanding your question? I enter the loop in a shallow dive, 2nd stage boost on, 350 kts, pull baaack the stick and the model rolls violently and does not enter the loop ... Works fine in other models so it's not the obvious - the joystick. But I expect I'm doing something wrong. > > > PPS the B52 rolls very nicely. Of course the real wings might fall > > off. Not sure I'd like to go to war in an aircraft whose wings fall > > off. > > I'm not sure I'd like to go to war in an aircraft whose wings > did not fall off either. No...wait...I'm sure. I wouldn't. > Hah! No sense of adventure. Spinning around Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > Tried that. Looks just the same to me. As I said some time ago: yer pays yer > money and yer takes yer choice. Neither is right on the ground for > differential braking: with one brake full on the aircraft more or less > rotates around that wheel. The model doesn't! When the aircraft is moving > the forward the CofG should rotate about some point outboard of the braked > wheel. All to do with tyre slip angles, but I'm not sure if the FDM's know > about those, and I would need to consult my race engineering handbooks. > > But, hey, we're building flight simulator, not a ground handling simulator. > If it's good enough that'll do me. The ground handling is all part of it. I'm not sure what you are seeing...but if you moved the origin then the aircraft should have at least moved the same amount. It might "look" the same but look closer. Are the wheels in the same spot on startup? Basically with you need to make sure the gear is in the right spot, etc, etc. With YASim fdm configs you can configure gear animation so that when it compresses in yasim the gear compresses visually too. YASim will drop the altitude by an amount relevant to the modeled gear compression so the aircraft will drop, but the wheels will go "through the pavement" if you don't amimate the compression in the 3D model. > PS why in an external view does the Hunter appear to do an upward roll in > the up leg of a loop. And a downward roll in the down leg? And why can't I > loop the P51? I'm not sure what you mean. but there is no problem looping the p51d. I've done it many times. You might need to hit ctrl+b to get the manifold pressure up to second stage level. Am I understanding your question? > PPS the B52 rolls very nicely. Of course the real wings might fall off. Not > sure I'd like to go to war in an aircraft whose wings fall off. I'm not sure I'd like to go to war in an aircraft whose wings did not fall off either. No...wait...I'm sure. I wouldn't. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson wrote > Vivian Meazza <[EMAIL PROTECTED]> said: > > > > > > > Martin wrote: > > > > > > David Megginson <[EMAIL PROTECTED]> wrote: > > > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > > > In directory baron:/tmp/cvs-serv12589 > > > > > > > Modified Files: > > > > pa28-161-yasim-set.xml > > > > Log Message: > > > > Change camera position so that model doesn't rotate around the > > > > nose. > > > > > > I can't withstand the impression that changing the _camera_ > > > position didn't lead to the intended success. Take a simple > > > stick and rotate it around one of its ends. For an observer > > > the phenomenon is still the same even when he changes his > > > viewpoint. If you want to rotate the stick around its middle > > > you really have to change the centre of rotation which means, > > > that one end of the stick goes up and the other end goes down. > > > > > > At least in the _outside_ views the PA-28 still rotates > > > around its nose after the recent changes, > > > > > > > We've been here before haven't we? In developing the Hunter model I > > first put the model origin at the nose to conform to the > YASIM origin, > > but the model then rotated about the nose - most disconcerting in > > outside views! I moved the model (not the YASIM) origin to > the CofG - > > the model behaves nicely in all views. It's not strictly correct on > > the ground, because the model has differential braking, and should > > more or less rotate around the braked wheel, but you would have to > > have a very sharp eye to spot the deliberate :-) mistake. > > > > If you put the model back to the nose and use the method that > the p51d and the pa28-161 use (the target offset) you'll look > better on the ground. Tried that. Looks just the same to me. As I said some time ago: yer pays yer money and yer takes yer choice. Neither is right on the ground for differential braking: with one brake full on the aircraft more or less rotates around that wheel. The model doesn't! When the aircraft is moving the forward the CofG should rotate about some point outboard of the braked wheel. All to do with tyre slip angles, but I'm not sure if the FDM's know about those, and I would need to consult my race engineering handbooks. But, hey, we're building flight simulator, not a ground handling simulator. If it's good enough that'll do me. PS why in an external view does the Hunter appear to do an upward roll in the up leg of a loop. And a downward roll in the down leg? And why can't I loop the P51? PPS the B52 rolls very nicely. Of course the real wings might fall off. Not sure I'd like to go to war in an aircraft whose wings fall off. Curiously confused Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > > > Martin wrote: > > > > David Megginson <[EMAIL PROTECTED]> wrote: > > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > > In directory baron:/tmp/cvs-serv12589 > > > > > Modified Files: > > > pa28-161-yasim-set.xml > > > Log Message: > > > Change camera position so that model doesn't rotate around the nose. > > > > I can't withstand the impression that changing the _camera_ > > position didn't lead to the intended success. Take a simple > > stick and rotate it around one of its ends. For an observer > > the phenomenon is still the same even when he changes his > > viewpoint. If you want to rotate the stick around its middle > > you really have to change the centre of rotation which means, > > that one end of the stick goes up and the other end goes down. > > > > At least in the _outside_ views the PA-28 still rotates > > around its nose after the recent changes, > > > > We've been here before haven't we? In developing the Hunter model I first > put the model origin at the nose to conform to the YASIM origin, but the > model then rotated about the nose - most disconcerting in outside views! I > moved the model (not the YASIM) origin to the CofG - the model behaves > nicely in all views. It's not strictly correct on the ground, because the > model has differential braking, and should more or less rotate around the > braked wheel, but you would have to have a very sharp eye to spot the > deliberate :-) mistake. > If you put the model back to the nose and use the method that the p51d and the pa28-161 use (the target offset) you'll look better on the ground. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/pa28-161
Martin wrote: > > David Megginson <[EMAIL PROTECTED]> wrote: > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > In directory baron:/tmp/cvs-serv12589 > > > Modified Files: > > pa28-161-yasim-set.xml > > Log Message: > > Change camera position so that model doesn't rotate around the nose. > > I can't withstand the impression that changing the _camera_ > position didn't lead to the intended success. Take a simple > stick and rotate it around one of its ends. For an observer > the phenomenon is still the same even when he changes his > viewpoint. If you want to rotate the stick around its middle > you really have to change the centre of rotation which means, > that one end of the stick goes up and the other end goes down. > > At least in the _outside_ views the PA-28 still rotates > around its nose after the recent changes, > We've been here before haven't we? In developing the Hunter model I first put the model origin at the nose to conform to the YASIM origin, but the model then rotated about the nose - most disconcerting in outside views! I moved the model (not the YASIM) origin to the CofG - the model behaves nicely in all views. It's not strictly correct on the ground, because the model has differential braking, and should more or less rotate around the braked wheel, but you would have to have a very sharp eye to spot the deliberate :-) mistake. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/fokker100 - New directory
Jim Wilson wrote: Erik Hofman <[EMAIL PROTECTED]> said: Update of /var/cvs/FlightGear-0.9/data/Aircraft/fokker100 In directory baron:/tmp/cvs-serv5280/Aircraft/fokker100 Log Message: Directory /var/cvs/FlightGear-0.9/data/Aircraft/fokker100 added to the repository Hi Erik, Think we're still missing the engine file. Oops. It was marked for addition but wasn't committed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
