Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?
On Friday, February 7, 2003, at 03:57 am, Norman Vine wrote: John A. Gallas I was just wondering if the subroutine SGRoute.distance_off_route() calculates accurate results (or even reasonably usable results for navigation in fgfs) for waypoints on a wgs84 system. I've run some tests and it seems okay, but I'm no expert - can someone verify this? This is a *much* better approximation http://williams.best.vwh.net/avform.htm#XTE Just to add, in my local tree I've got an FGRouteBase which (I hope) supersedes the SGRoute stuff totally. I spent ages trying to come up with a better 'distance off route' calculation (trigonometry not being my strong point), clearly I should just have asked here. Whatever I do is going to have to be compatible with SGRoute (but I don't think inheritance from it is going to work, since my routes aren't 'flat', as they can incorporate chunks of other routes, i.e airways and procedures), but let me know if you'd like to see the code (it's alpha-quality and incomplete but loads a route from XML fine, and basic traversal is working too. Adding the distance and course and distance-off-route computations could be done tonight if it would be of interest). H&H James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Norman Vine writes: > This works fine for a 'map' but straight lines will not be great circles > which AFAIK is still the standard for *most* aviation 'charts', both > paper and electronic versions It depends on scale. World Aeronautical Charts (1:1,000,000) and VNCs/Sectionals (1:500,000) use Lambert Conformal Conic projection, so that (as Norm suggests) a straight line drawn on the chart will really be a great circle. VFR terminal area charts (1:250,000) use Transverse Mercator projection since they cover a smaller area. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?
James Turner writes: > > On Friday, February 7, 2003, at 03:57 am, Norman Vine wrote: > > > John A. Gallas > >> > >> I was just wondering if the subroutine > >> SGRoute.distance_off_route() calculates accurate > >> results (or even reasonably usable results for > >> navigation in fgfs) for waypoints on a wgs84 system. > >> I've run some tests and it seems okay, but I'm no > >> expert - can someone verify this? > > > > This is a *much* better approximation > > http://williams.best.vwh.net/avform.htm#XTE > > Just to add, in my local tree I've got an FGRouteBase which (I hope) > supersedes the SGRoute stuff totally. I spent ages trying to come up > with a better 'distance off route' calculation (trigonometry not being > my strong point), clearly I should just have asked here. Note that I said 'better approximation' in that the above is a spherical solution not an ellipsoidal one One way to get an ellipsoidal solution is to find the rotation that transforms the track segment you are checking into a meridian < line of longitude >, then after applying said transform to the point in question the solution can be found using the geodetic inverse function from SimGear and the original point and the found point rotated by the inverse of the transform Note the needed rotations only need to be computed when the track segment changes. Easiest to visualize why this works when you are looing at a ball :-) Another perhaps easier way to improve the spherical approximation is to use the mean latitude of the test point and the point of intersection of the perpendicular from that point to the track segment to determine a relative flattening factor of the sphere or an 'effective earth radius' Note if the distance is 'small', as should be the case when computing cross track error, the latitude of the test point can be substituted for the mean with no 'harm' Note sgGeodToGeoc() function returns the sea level radius spherical-geomentry-is-fun-as-is the-ellipsoidal-variety'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Fokker 70 to get produced again?
Hi It looks like the Fokker 70 Jetliner, one of the flagship aircrafts of the oldest aircraft manifacturer of the world, which sadly got bankrupt in 1995, is about to get relaunched again: http://www.rekkof.nl/fokker70/index_fokker_70.htm This is especially good news for the dutch aircraft enthausiasts. Erik (This is another good reason to get a flying model for FlightGear) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Fokker 70 to get produced again?
Erik Hofman writes: > It looks like the Fokker 70 Jetliner, one of the flagship aircrafts of > the oldest aircraft manifacturer of the world, which sadly got bankrupt > in 1995, is about to get relaunched again: > > http://www.rekkof.nl/fokker70/index_fokker_70.htm > > This is especially good news for the dutch aircraft enthausiasts. I know someone was working on a JSBSim based 737, but I don't think that has shown up in the base package yet. It would be nice to see a few more of these smaller regional jets modeled in FlightGear. There is a Beech99 for UIUCsim which flies pretty well. Someone ought to take a look at the 3d model and see about animated the props and gear and control surfaces. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Fokker 70 to get produced again?
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > I know someone was working on a JSBSim based 737, but I don't think > that has shown up in the base package yet. It would be nice to see a > few more of these smaller regional jets modeled in FlightGear. > The ERJ-135 (35 passenger) is one my favorites these days. They've started using them quite a bit in Bangor so it might very well be possible to snap some cockpit photos next time I fly. http://users.pandora.be/tim.cools/facts/erj135.html http://home.hccnet.nl/de.bock/Specifications/specifemb.htm If someone is interested in configuring a yasim model for it that could persuade me to make a 3D :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewer suggestion: acceleration effects
For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration might tilt the head forward about the same amount. Sideways accelerations would cause the head to tilt sideways similarily (the view roll angle). Vertical accelerations are trickier, since they're roughtly perpendicular to the spine. The best thing here would be to adjust the vertical view offset by half an inch or so down for a strong upwards acceleration (being pushed down into your seat) or up for a strong downwards acceleration (straining up against your lap belt). If we want these to be useful and not cheesy, they'll have to be very subtle in most normal flight (i.e. a fraction of a degree) except for special situations like the initial part of the takeoff roll or heavy braking. On the other hand, if the plane is being flown by a ham-fisted sim driver, we could rock things around a little more as would be happening with real passengers (Alex has also suggested splattering the panel with virtual vomit). Jim: are you interested in adding this to the viewing architecture, or would you like me to take a try in a week or two? I don't claim to fully understand how to use these, but you can look at src/Instrumentation/slip_skid_ball.cxx for a sideways-acceleration example I ripped off from Alex's old steam code. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 11:51:29 -0500 David Megginson <[EMAIL PROTECTED]> wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration I think this is a great idea. You might try treating the pilot eyepoint as a spring/mass/damper system in the XY plane and assume no Z motion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gear-handle
John I did simple gear handle for the c310-ifr panel if you or any-one want to use it. It should work on any of the 2d panels. Thanks Paul screenshot http://members.verizon.net/~vze3b42n/gear.jpeg package http://members.verizon.net/~vze3b42n/gear.tar.gz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 02:10 pm, David Megginson wrote: I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. I'm happy to have a go at this, or do you (David) want to take a look? i agree it's far and away the best suggestion I've heard in terms of non-impact on the code, efficiency and so forth. -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear-handle
Ok, that looks perfectly reasonable. I have added it to cvs. Thanks, Curt. paul mccann writes: > John > > I did simple gear handle for the c310-ifr panel if you or any-one want to use > it. > It should work on any of the 2d panels. > > Thanks Paul > > screenshot > http://members.verizon.net/~vze3b42n/gear.jpeg > > package > http://members.verizon.net/~vze3b42n/gear.tar.gz > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
[Chiming in because the subject is cool, and because I'm currently stuck debugging a parser that is giving me fits and need a break.] David Megginson wrote: > For the cockpit view, it might be interested to add optional > acceleration effects to make up for the lack of full motion -- I think > I first noticed this trick in Battle of Britain. The FDMs already > publish the required information in the property tree: Why not just model the "head" as a highly damped spring? You'd need to fiddle with the constants a little to make it look right, but once it's fixed up it should work right for all heads. :) Almost exactly the same thing technique can be used for orientation. I distinicly remember from my few flights in light planes that turbulence (especially yaw oscillations) felt more like the plane was rotating around me. It would be (I think) really cool for the view direction to "lag" the planes reference frame a little in the same way that the view position lags the real position. I'd give this more general idea a shot first, before trying axis-specific code. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Andy Ross writes: > [Chiming in because the subject is cool, and because I'm currently > stuck debugging a parser that is giving me fits and need a break.] > > David Megginson wrote: > > For the cockpit view, it might be interested to add optional > > acceleration effects to make up for the lack of full motion -- I think > > I first noticed this trick in Battle of Britain. The FDMs already > > publish the required information in the property tree: > I'd give this more general idea a shot first, before trying > axis-specific code. A Quaternion representation for the head orientation anyone :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner writes: > > I think that we can centralize this and make it invisible to JSBSim > > and other suppliers of property values. Polling inside the property > > manager makes sense, since > > > > a) it will be done only on demand (when someone assigns a listener to > > a property), > > > > b) it will be done only once for each property, no matter how many > >other routines are listening to it, > > > > c) it will create no extra work for anyone. > > > > I'm happy to have a go at this, or do you (David) want to take a look? > i agree it's far and away the best suggestion I've heard in terms of > non-impact on the code, efficiency and so forth. Go for it -- I probably won't be able to get to it right away. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Andy Ross writes: > I'd give this more general idea a shot first, before trying > axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 13:29:34 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Andy Ross writes: > I'd give this more general idea a shot first, before trying > axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. *Spring/mass/damper* system, as I mentioned before. This is similar to how fuel slosh is modeled in spacecraft sims (and I'm not making a comment on anyone's brain consistency, in particular ;-). Break the aircraft acceleration into X and Y components and model it in a "head" axis that is parallel to the aircraft body axis. This is a cool problem to work, but I don't have time now either. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
David Megginson <[EMAIL PROTECTED]> said: > Andy Ross writes: > > > I'd give this more general idea a shot first, before trying > > axis-specific code. > > The axis-specific stuff is easier for me to understand -- perhaps > someone with a stronger physics background could work with Jim to do a > generalized, spring implementation. > Hehe...Thanks David. I've still got a nasty bug that was reported last week to deal with. So I'll be in the code. My recommendation would be to model this head thing, probably in its own class, and then publish data in the position or orientation path that the viewer would read in. We could have a class FGPilot with properties: ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Hmmm...not sure how that happened but this message got away from me half finished.
David Megginson <[EMAIL PROTECTED]> said:
> Andy Ross writes:
>
> > I'd give this more general idea a shot first, before trying
> > axis-specific code.
>
> The axis-specific stuff is easier for me to understand -- perhaps
> someone with a stronger physics background could work with Jim to do a
> generalized, spring implementation.
>
Hehe...Thanks David. I've still got a nasty bug that was reported last week
to deal with. So I'll be in the code.
My recommendation would be to model this head thing, probably in its own
class, and then publish data in the position or orientation path that the
viewer would read in.
We could have a class FGPilot with properties:
head {
double head_roll;
double head_pitch;
double head_Xoffset;
double head_Yoffset;
double head_Zoffset;
}
stomach {
double breakfast;
double lunch;
bool antacid;
}
vision {
bool on;
bool blur;
}
And methods:
FGPilot::chg_head_roll;
FGPilot::chg_head_pitch;
...
FGPilot::Vomit;
FGPilot::BlackOut;
etc, etc.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, Feb 07, 2003 at 09:43:59AM -0800, Andy Ross wrote: > > Why not just model the "head" as a highly damped spring? You'd need > to fiddle with the constants a little to make it look right, but once > it's fixed up it should work right for all heads. :) Since this is simply a visual effect, let's start by trying a linear system. If it turns out to be too simple we can simply add a nonlinearity. If that is still not good enough (most likely due to the head snapping back too fast), it isn't difficult to model a damped spring system undergoing all the relevant effects. Since I imagine that a jet fighter can generate head motion due to both linear acceleration and pitch I've included both terms for head pitch. Since I don't know what coordinate system FG uses, I used words for the accelerations. Also, the 'spring constants' (Ka, Kp, Kr and Ky) are really fudge factors representing both the mass of the head and the resistance to rotation. The coder will need to experiment. angle of head pitch = forward accel / Ka + (d^2/dt^2 pitch) / Kp angle of head roll = (d^2/dt^2 roll) / Kr angle of head yaw = (d^2/dt^2 yaw) / Ky Having never flown on a high performance aircraft, it is unknown to me whether the yaw effect is important. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Jim Wilson writes:
>
> My recommendation would be to model this head thing, probably in its own
> class, and then publish data in the position or orientation path that the
> viewer would read in.
>
> We could have a class FGPilot with properties:
Which is just a 'classic' rigid body'
>head {
double heading;
> double roll;
> double pitch;
> double Xoffset;
> double Yoffset;
> double Zoffset;
double dx,dy,dz; // linear velocities
double dh, dp, dr; // angular velocities
>}
or more simply expressed using PLIB
head {
sgCoord pos ;
sgCoord velocity ;
}
where
struct sgCoord
{
sgVec3 xyz ;
sgVec3 hpr ;
} ;
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gear-handle
Curt Thanks and if you want me to add it to the other c310-2d panels let me know. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 15:00:41 -0500 "James A. Treacy" <[EMAIL PROTECTED]> wrote: On Fri, Feb 07, 2003 at 09:43:59AM -0800, Andy Ross wrote: Since I imagine that a jet fighter can generate head motion due to both linear acceleration and pitch I've included both terms for head pitch. The acceleration vector AT the pilot eyepoint should probably be used. Use the X and Y components - I've mentioned this before. Aircraft rotations about all axes will potentially play a part in this, it depends on where the pilot is in relation to the CG. In fact, rotational accels will be largely responsible for the "jostle" effect in calm air in cruise. I wouldn't change the orientation of the head (the view) due to motion, though. I think that would be too disturbing, too distracting. But the motion of the head should be driven by the X and Y axis accelsat the pilot position, whether due to aircraft CG translational acceleration or translational accels at the pilot position due to rotational motion about the CG. Jon Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
I forgot another possible effect: spinal compression. This one, if necessary, can almost certainly be considered as being uncoupled from any head rotations. delta z = z-accel / Kspine Also, it may be that the equation for pitch of the head is too simple as the two terms can cancel each other out(*) and it would a good idea if the model got this correct. It may be that the linear model is close enough that picking the constants correctly will allow for this. Unfortunately once you start rotating things intuition doesn't work well. (*)for example a forward acceleration while pulling back on the stick. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Norman Vine <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
> >
> > My recommendation would be to model this head thing, probably in its own
> > class, and then publish data in the position or orientation path that the
> > viewer would read in.
> >
> > We could have a class FGPilot with properties:
>
> Which is just a 'classic' rigid body'
>
> >head {
> double heading;
> > double roll;
> > double pitch;
> > double Xoffset;
> > double Yoffset;
> > double Zoffset;
> double dx,dy,dz; // linear velocities
> double dh, dp, dr; // angular velocities
> >}
Oh yeah forgot that. Actually I was half kidding on that idea. One could
argue that the viewer is the representation of the pilot's eye and therefore
should incorporate this functionality. If we wanted Vomit capability then it
should be elsewhere.
But if head movement becomes a complex thing that needs to be varied according
to aircraft seat and restraint configuration, maybe it should be somewhere else.
It really comes down to what the viewer's capabilities should include.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 15:21:20 -0500, "James A. Treacy" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > I forgot another possible effect: spinal compression. This one, if > necessary, can almost certainly be considered as being uncoupled from > any head rotations. > > delta z = z-accel / Kspine > > Also, it may be that the equation for pitch of the head is too simple > as the two terms can cancel each other out(*) and it would a good idea > if the model got this correct. It may be that the linear model is > close enough that picking the constants correctly will allow for this. > Unfortunately once you start rotating things intuition doesn't work > well. > > (*)for example a forward acceleration while pulling back on the stick. ...and then the reclining seat's effect on the spine _angle_. ..some (most?) game sim's also model grey|black|red-out etc, this angle is a factor here too. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Dynamic Scenario's
Hi all, I am new to Flight Gear, but not to flight simulation, thats my line of business ;) Anyway I would like to propose (and develop) a server or system that can be used to manage the environment. What I mean is that the scenario system manages: * Other plans in the air, these can add the reality of busy airspace near large airports. * Weather system controlled through scenarios, this would include clouds, rain etc... * Ground vehicles movement (aircraft ready to taxi for takeoff etc. I would be really intrested in your comments Paul __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)
Hmm, that's odd. Out of the box, the version of the Mac joystick code that is in CVS does not compile. As I reported to the plib group, if I incorporate the non-CVS versions of jsMacOSX.cxx and js.h, I get the following errors in the FlightGear joystick code: ld: Undefined symbols: jsJoystick::read(int*, float*) _CFArrayApplyFunction _CFArrayGetCount _CFArrayGetTypeID _CFDictionaryGetTypeID _CFDictionaryGetValue _CFGetTypeID _CFNumberGetValue _CFRelease _CFStringGetCString _CFStringGetSystemEncoding _CFUUIDGetConstantUUIDWithBytes _CFUUIDGetUUIDBytes _IOCreatePlugInInterfaceForService _IOIteratorNext _IOIteratorReset _IOMasterPort _IOObjectRelease _IORegistryEntryCreateCFProperties _IOServiceGetMatchingServices _IOServiceMatching ___CFStringMakeConstantString _kCFAllocatorDefault I've been trying to help David Drum get his FlightGear to build and he discovered that adding -framework Carbon to the Makefile reduces the link errors down to ld: /Users/david/FlightGear/FlightGear-CVS/lib/libplibjs.a(jsMacOSX.o) illegal reference to symbol: _IOCreatePlugInInterfaceForService defined in indirectly referenced dynamic library /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit If I restore the plib code back to 1.6, then I can finally get a link. Since I don't use a joystick, that works for me. Jonathan Polley On Wednesday, February 5, 2003, at 07:48 AM, James Turner wrote: On Wednesday, February 5, 2003, at 01:22 pm, Jonathan Polley wrote: The solution, for me at least, was to revert back to the CVS version of plib and overwrite the src/js directory with plib 1.6's (as the current Mac joystick code is in a major broken state). Hopefully, David will have a chance to see if it fixes his build problem as >> well. Err, the JS code is fine for me now (and for Ima too, I think), once you replace js.h and jsMacOSX.cxx with the ones I posted to plib-devel a few days ago. If these do not fix any problems you're having, then **please** post something to plib-devel or email me directly. Since getting things checked into plib CVS seems to be rather slow, I'd rather get the files confirmed working for people before requesting another commit. FWIW, CVS of 'everything' is working on my iBook, updated today, but I have a bunch of local mods to simgear/flightgear (in addition to the plib JS updates) : let me know if you want them. (I'll start feeding them to Curt / David soonish anyway I think) H&H James -- They are laughing with me, not at me. ___ 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] Viewer suggestion: acceleration effects
At 2/7/03, David Megginson wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration might tilt the head forward about the same amount. Sideways accelerations would cause the head to tilt sideways similarily (the view roll angle). Vertical accelerations are trickier, since they're roughtly perpendicular to the spine. The best thing here would be to adjust the vertical view offset by half an inch or so down for a strong upwards acceleration (being pushed down into your seat) or up for a strong downwards acceleration (straining up against your lap belt). If we want these to be useful and not cheesy, they'll have to be very subtle in most normal flight (i.e. a fraction of a degree) except for special situations like the initial part of the takeoff roll or heavy braking. On the other hand, if the plane is being flown by a ham-fisted sim driver, we could rock things around a little more as would be happening with real passengers (Alex has also suggested splattering the panel with virtual vomit). Jim: are you interested in adding this to the viewing architecture, or would you like me to take a try in a week or two? I don't claim to fully understand how to use these, but you can look at src/Instrumentation/slip_skid_ball.cxx for a sideways-acceleration example I ripped off from Alex's old steam code. Sounds useful. Can I suggest that this feature be enabled/disabled at the option of the user? Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
