Re: [Flightgear-devel] View hat on FlighSimYoke USB
Hi Andy, > This sounds to me as if one of the switches in your hat is bent, and > is in the "on" possition even when the hat it centered. I've seen > exactly this effect in the past on a Thrustmaster Top Gun stick. > Joystick hardware basically sucks. Run jscal and note all the > possibilities. What you "should" see is zero for both axes when you > don't touch the hat, and independant motion when you do. An 8-way hat > switch will also be able to report the corners (both axes at 1, for > example). I should mention that the problems occur under Linux 2.4.? (? < 10) and that the hat switch works ok under Windows though I don't know the mapping there as it is hidden. So I think that the explanation from David Megginson (bug in the kernel joystick code) sounds logical though I never would have thought of that. Alexander > Another possibility is that the analog joystick driver has > miscalibrated the axes; as I remember it applies the calibration > numbers even to digital axes like hats. > > What kind of stick do you have? > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > 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] Moving carrier, and Repositioning questions
Norman's intersection testing works just fine for the moving carrier as well. In fact this was discussed on the list almost six months ago. So you would not fly through the deck. Yes your FDM should recieve the current scenery altitude and compute landing gear reactions accordingly. All those issues of aircraft and carrier coordinates are easily handled as pointed out by Jon S Berndt. In fact I have implemented all of it in FORTRAN. I can steer on deck, launch from deck and land on deck and get arrested all the time with the carrier moving. The only hack I use is for the ski-jump. Although I recieve ski-jump ramp height from FlightGear intersection calculations, I dont use that since it is too coarse to accurately simulate ski-jump launch dynamics, so as long as the aircraft is within the deck (on or over) I use height over deck as computed by the FDM, until aircraft leaves the deck. This check is done using longitudinal and lateral coordinates of the deck, i.e a/c posn in deck coords. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: Friday, April 05, 2002 2:30 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Moving carrier, and Repositioning questions Justin Palamar writes: > 1) A design goal was to have a moving aircraft carrier within the simulator > with the option to land on its deck > Right not we have only been able to insert the static model by editing the > appropriate .stg scenery file, including > "OBJECT_STATIC saratoga.3ds -122.353617 37.624617 -130 0" > We know this has been done before, there is code in the main.cxx file that > refers to a carrier, and a model was included in the 0.7.8 release. Is > there any way to get this working using the higher level .xml files, and > avoid editing the C++ source code? You'll need the carrier to be in the main scene graph so that collision and ground detection works -- otherwise, you'll fly right on down through the deck. From an SSG perspective, all you need is an ssgTransform node between the carrier model and the rest of the scene graph, and then to updated that node with the carrier's new position and orientation (relative to scenery centre, which is the only tricky part). In fact, Curt's code in FGTileEntry::load (src/Scenery/tileentry.cxx) already creates the ssgTransform node when it loads the OBJECT_STATIC model. If you save a pointer to the transform (somehow) and update it in each frame, the carrier will move. Note especially this code: sgCoord obj_pos; WorldCoordinate( &obj_pos, center, lat, lon, elev, hdg ); ssgTransform *obj_trans = new ssgTransform; obj_trans->setTransform( &obj_pos ); You can use something similar in your update routine, using the current scenery centre and supplying new lat/long/elev/hdg params. > 2) When loading our blackhawk model (again by editing/adding .xml files > from the ./Aircraft directory our model appears about 3 meters into the > ground. We have attempted to reposition the model using the instructions > from the flighgear website (rather than pointing directly to the model, > point to a .xml wrapper file with repositioning information in it that also > points to the model) but we an ssgLOAD error: Unknown file type .xml. As > if it is trying to see a graphic file and sees an .xml and doesn't know > what to do with it. I'm not sure if this is a change in the newest > release, of if I'm missing something. Yes, you need the latest CVS code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Well I had something similar in mind when I wrote fgLoadDCS() and fgUpdateDCS() in main.cxx. I had used a limit of 32 objects since I guessed that more than that might affect frame rates. Presently repositioning is possible thro network, albeit tied to fdm=ada, but thats trivial to change to make it more widely usable. So far I have used scenery/objects.txt file instead of .xml for loading objects. Is what you have in mind drastically different from whats been implemented so far. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Friday, April 05, 2002 1:01 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Moving carrier, and Repositioning questions What I would like to see implimented is a 'standard' DCS system (where DCS stands for dyanamic coordinate system which is industry lingo for objects that move in the scene ... their local coordinate system is 'dyanamic'. I'm envisioning a DCS manager where you can register 'entities' with an associated 3d model and an associated 'behavior'. The behavior could be a preset path to follow, or something more AI-ish, or even something like JSBSim or YAsim (or perhaps entity positions could be driven externally from a server to produce a 'shared' world for collaborative flying.) I'm thinking we could create some simple "FDM's", one that replays a preset path, and one that impliments ultra-simple-light-weight flight dynamics which would be good enough for 'realistic' robot planes viewed from a distance, but simple enough so we can compute the dyanmics for "many" planes each frame. The DCS system would take care of loading and attaching the 3d models to the correct place in the scene graph and removing them. It would call the update() routine for each of their "engines". And it would probably provide some sort of property interface to the positions, orientations, and velocities of these dynamics entities. That doesn't solve all the problems and address all the issues, but I think it would be a good start. Anyone want to work on this? I could even give you your own subdirectory. :-) Regards, Curt. Andy Ross writes: > Justin Palamar wrote: > > 1) A design goal was to have a moving aircraft carrier within the > > simulator with the option to land on its deck > > There are actually two problems here. The first, making the object > move, is relatively easy. It will require C++ code, though. One way > I've thought about doing it is to put the object in the property tree > rather than the static scenery description. Something like: > > /scenery/objects[n]/model-file=Models/carrier.ac3 > /lat-deg=nn.nn > /lon-deg=nn.nn > /alt-ft=nnn > /hdg-deg=nnn > /speed-kt=nnn > > And then the "dynamic scenery" code would update the lat/lon > accordingly. This could be extended with extra orientation and > velocity parameters for a full 6DOF model animation, controllable via > properties. > > But there's another problem -- the current FDMs model gear force using > only the aircraft's velocity. They assume the ground is fixed and > unmoving. This means that you could land on the carrier, but would > then come to a stop relative to the earth, while the carrier slipped > smoothly out from under you. > > I'm not quite sure about the "right" way to do this -- doing it in the > low-level ssg "hitlist" collision detection is going to be rather > complicated, and won't perform well. Perhaps the best way to handle > it would be to special case "carrier deck" objects (more generally, > anything moving on which the gear are expected to rest), and expose > them directly to the FDMs via a "ground velocity" parameter. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, Apr 04, 2002 at 07:57:00PM -0500, David Megginson wrote:
> Tony Peden writes:
>
> > We'll have to talk about how to implement this. Right now, it would
> > all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of
> > handling both this sort of thing and xml-defined parameters.
>
> Here's what I've been thinking of (for a while):
>
> 1. Add methods something like these:
>
>SGPropertyNode * FGSubsystem::getBranch ();
>void FGSubsystem::setBranch (SGPropertyNode * branch);
>
> 2. Whenever tying or referencing properties specific to a vehicle,
>session, or whatever, reference them relative to the branch:
>
> double throttle = getBranch()->getDoubleValue("controls/throttle[0]");
>
> 3. At the top level, manage a separate branch for each vehicle.
>
> Perhaps an easier solution would be simply to swap property trees in
> and out for each vehicle, like process pages in a CPU. That makes it
> hard to access global (non-vehicle-specific) state, though.
>
> Comments?
>
The latter would certainly be easier, no code would need to be changed.
Wouldn't it have the effect of forcing client code to keep track of
which vehicle was being referenced in the tree? A good example here, I
think, would be the view manager. Another good example would be the
real-time plotting code Curt discussed a few weeks back. In both cases,
just blindly using the data in the tree would be likely to have some
interesting results.
>
> All the best,
>
>
> David
>
> --
> David Megginson
> [EMAIL PROTECTED]
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson writes:
>
>While we're talking about refactoring, I think that it might be time
>to consider creating something like an FGLocus class, to keep track of
>a single location. Its interface would look a lot like the viewer's:
>
> class FGLocus
> {
> public:
>FGLocus ();
>virtual ~FGLocus ();
>
>virtual double getLongitudeDeg () const;
>virtual double getLatitudeDeg () const;
>virtual double getAltitudeFt () const;
>
>virtual void setPosition (double lon_deg, double lat_deg,
>double alt_ft);
>
>virtual double getRollDeg () const;
>virtual double getPitchDeg () const;
>virtual double getHeadingDeg () const;
>
>virtual void setOrientation (double roll_deg, double pitch_deg,
> double heading_deg);
>
>virtual const sgMAT4 &getTransformMatrix () const;
>
> };
Good Idea but I don't know about the name
< sidebar >
it would behoove the project to stop thinking in spherical terms
xcept when doing user input / output. Converting back and forth
between sperical and cartesian representation is a time sink that
doesn't need to happen at all as far as the inner workings of the
program are concerned. The cartesian form of the position and
orientation is already put on the 'bus' in cartesian form USE IT
We ONLY want to make the conversion at the User <-> Machine
interface.
give the gfx hardware a chance to work :-)
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OpenGC Manual
Hi, A few folks have asked for it, so here it is; fresh off the presses. When you download the opengc package from the CVS repository you also receive, free of charge, a short tutorial on how to install, configure and run OpenGC with FlightGear Regards John W.
[Flightgear-devel] New class FG3DModel
I've moved the aircraft model code (FGAircraftModel) out of src/Main and into a new directory, src/Model. In that directory, I've separated out the code for managing a 3D model so that it can be used for *any* model in *any* location. Take a look at src/Model/model.hxx to see the interface (it's very simple -- just update the position and orientation and attach the SSG node to a scene graph or ssgRoot somewhere). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson <[EMAIL PROTECTED]> said: > > While we're talking about refactoring, I think that it might be time > to consider creating something like an FGLocus class, to keep track of > a single location. Its interface would look a lot like the viewer's: > Yes I was thinking the same thing. If you want to, go ahead, but for the time being I'm up to my ears in viewmgr and properties and would like to get that running with what is here now for a viewer. I'll bring FGLocus in next week. BTW I may need some help doing the property stuff "correctly" in view manager after its running. Still a little vague on some of the property code especially considering how much i've used it. No problem getting it working, it just might not be the best approach, but I'll let you look and make suggestions. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes:
> On second thought why don't we go with what you are doing for the
> time being. I think I can get by with my view manager and viewer
> changes as long as your model code is independent of the viewer and
> the view manager. Then if you want to go with the model
> position/orientation config that I described in the previous
> message, I can add that next week to the model and viewmanager
> code.
Sounds good. I'll check in my changes, then, as soon as they're
working.
While we're talking about refactoring, I think that it might be time
to consider creating something like an FGLocus class, to keep track of
a single location. Its interface would look a lot like the viewer's:
class FGLocus
{
public:
FGLocus ();
virtual ~FGLocus ();
virtual double getLongitudeDeg () const;
virtual double getLatitudeDeg () const;
virtual double getAltitudeFt () const;
virtual void setPosition (double lon_deg, double lat_deg, double alt_ft);
virtual double getRollDeg () const;
virtual double getPitchDeg () const;
virtual double getHeadingDeg () const;
virtual void setOrientation (double roll_deg, double pitch_deg,
double heading_deg);
virtual const sgMAT4 &getTransformMatrix () const;
};
I can create an instance of this for everything I want to place in
FlightGear (a viewpoint, a 3D model, scenery, etc.) and all the
transformation code is in one place, so Norm can easily optimize it.
We could also add XYZ/RPH offsets, as with the viewer.
Most of the work of creating this class would just be cutting and
pasting from your current viewer class. What do you think? There's a
lot of duplicate code right now doing exactly this including code in
the new FG3DModel class I'm about to check in, and it would be nice to
purge it.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Tony Peden writes:
> We'll have to talk about how to implement this. Right now, it would
> all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of
> handling both this sort of thing and xml-defined parameters.
Here's what I've been thinking of (for a while):
1. Add methods something like these:
SGPropertyNode * FGSubsystem::getBranch ();
void FGSubsystem::setBranch (SGPropertyNode * branch);
2. Whenever tying or referencing properties specific to a vehicle,
session, or whatever, reference them relative to the branch:
double throttle = getBranch()->getDoubleValue("controls/throttle[0]");
3. At the top level, manage a separate branch for each vehicle.
Perhaps an easier solution would be simply to swap property trees in
and out for each vehicle, like process pages in a CPU. That makes it
hard to access global (non-vehicle-specific) state, though.
Comments?
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: > Oops, yes it does, I've been doing a similar thing, althought > haven't done anything with the animations. Can you send me what > you've got and I'll try and merge with what I have? I'll send you what I've got a little later this evening. > Also: what I would like to do is setup a "/sim/model" property > structure that has the pointers to the position and orientation > data. That's an interesting suggestion. I've been thinking about something similar but with a little more information, perhaps something like this: Aircraft /position/longitude-deg /position/latitude-deg /position/altitude-ft /position/roll-deg /position/pitch-deg /position/heading-deg With the refactoring I've done today, supporting something like this is only a few lines of code away. This isn't a good solution for objects in general, but as Andy mentioned, it will be useful for adding the occasional aircraft carrier, etc. I'm not going to do this now, though -- I'd like to stabilize my other changes first. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Car Model
Sam Varner writes: > Hi Sam I downloaded VAMOS today and have just started looking at it NEAT STUFF !! >I already have a pretty complete car model with suspension, engine, >transmission, tires and all that good stuff. I was hoping to figure out >how to make this model run in FlightGear-land. My biggest questions >are: > >1) How do I add a model to FlightGear? Do I need to derive from a >specific class? How do I register the vehicle with the program? What >sort of initialization do I have to do? For now I would reccomend creating a new FDM that was constrained to the surface so to speak see the balloon and/or magic modules for good starter FDMs >2) How do I interact with the environment? How are collisions detected >and how are vehicles notified? How is information about surfaces >(grass, concrete, etc.) passed? The scenery module updates the elevation and surface normal of the 'current position' every frame see scenery.h for how to retrieve this and take a peek at the int FGTileMgr::update() function to see where this is determined and the above mentioned FDM's should also help show how to get at this FWIW - If you are familiar with PLib's HOT routines you will find the FGFS HOT routines quite familiar :-)) This should be enough to get you started and we can update this into querying this info for each wheel on you have got the simple case done :-) I don't think we are storing the surface properties yet but we should be and it is easy enough todo. I think that if you just put the hooks in place that you will eventually be able to get a pointer to the material properties along with the elevation and surface normal at each wheel We really don't have what is normally considered to be a general purpose collision detection routine Give me a couple of days to look at the VAMOS code and I will probably be able to speak on a 'better' wavelength :-) Welcome aboard !! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Car Model
On Wed, 2002-04-03 at 20:59, Michael Selig wrote: > At 4/2/02, you wrote: > >On 02 Apr 2002 15:45:18 -0500 > > Sam Varner <[EMAIL PROTECTED]> wrote: > >>I'm working on an automotive simulator, http://vamos.sourceforge.net A > >>while ago, Curt suggested that I try to make my car model work with > >>FlightGear. > > > >!! > > > >>I'd like to start working on that now, but I don't know > >>where to begin. Could somebody give me some tips on adding a vehicle > >>model to FlightGear? Thanks. > > > >You might start by looking at the ground dynamics / landing gear modeling > >code in the various FDMs (flight dynamics model). In JSBSim this would be > >FGGroundReactions.[cpp|h] and FGLGear.[cpp|h]. You should look at YASim > >and LaRCSim code, as well, to get the widest exposure to how ground > >reactions are modeled. > > > >Off the top of my head, after first being a bit clueless on where to > >start, I'd suggest that you ought to be able to get pretty far pretty fast > >in JSBSim by merely specifying in a config file an "aircraft" that had > >very poor aerodynamics ;-) Theoretically, this shouldn't be too hard to > >get a start with. The same is probably true with YASim, I'm sure Andy will > >direct you how to do this with YASim. > > > I tried this as well. I ended up w/ something that "simulated" driving on > a frozen lake bed --- a skating rink. But without too much more trouble, > it could work. I think the challenging part is going to be modeling the > suspension system. FWIW: I know that in motorsports people are using ADAMS > to model the system dynamics. This is a commercial product. I already have a pretty complete car model with suspension, engine, transmission, tires and all that good stuff. I was hoping to figure out how to make this model run in FlightGear-land. My biggest questions are: 1) How do I add a model to FlightGear? Do I need to derive from a specific class? How do I register the vehicle with the program? What sort of initialization do I have to do? 2) How do I interact with the environment? How are collisions detected and how are vehicles notified? How is information about surfaces (grass, concrete, etc.) passed? If anyone has info, docs, or examples that might help me out, please let me know. Thanks. Sam ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson <[EMAIL PROTECTED]> said: > > Oops, yes it does, I've been doing a similar thing, althought haven't done > anything with the animations. Can you send me what you've got and I'll try > and merge with what I have? David, On second thought why don't we go with what you are doing for the time being. I think I can get by with my view manager and viewer changes as long as your model code is independent of the viewer and the view manager. Then if you want to go with the model position/orientation config that I described in the previous message, I can add that next week to the model and viewmanager code. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
Christian Mayer wrote: > > "Curtis L. Olson" wrote: > > > > Bernie Bright has submitted a simplified boost distribution for > > SimGear and I have committed it to CVS. The boost web page is here: > > > > http://www.boost.org/ > > > > We will begin depending on this package soon. > > Well, *I* don't really understand what boost is usefull for. > > Can somebody tell me what boost does and why it's important for us, > please? Boost was begun by members of the C++ Standards Committee Library Working Group, although membership has expanded to include nearly two thousand members of the C++ community at large. Its aim is to develop "existing practice" and provide reference implementations of possible future additions to the C++ Standard Library. Several Boost libraries have already been presented to the library working group and have met with a favorable response (that is, it is quite likely that they will become part of the next C++ standard library). I have asked Curt to include a subset of Boost that includes just Boost.Function and Boost.Bind (plus required support and configuration files). These are all header files so there is nothing to compile. Boost.Function is a family of class templates that implement function objects. It generalises the idea of callback functions such that free functions and member functions are treated identically. This means that anywhere we store a function pointer or an object pointer plus pointer-to-member-function we can store a single boost::function object instead. Boost.Bind is a generalisation of std::bind1st(), std::bind2nd() and std::mem_fun(). It is used in conjunction with Boost.Function to "bind" an object and a pointer to a member function into a single function object. It is a smarter and more elegant replacement for our fg_callback. Boost has a lot to offer if you are doing any serious C++ development. For example smart pointers, a regex library, compile time assertions and threads have all been presented to the committee. Remember, what is in Boost today may appear in the C++ standard tomorrow :) Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
I just finished successfully building with MSVC. Thanks for the updates!
Jonathan Polley
On Thursday, April 4, 2002, at 03:22 AM, D Luff wrote:
> Jonathan Polley wrote:
>
>> Doing some more investigation, I found that there is a runways.cxx in
>> both
>> FlightGear/src/ATC and FlightGear/src/Airports. Are they the same?
>>
>
> OK, sorry for breaking things...
>
> runways.cxx shouldn't be in ATC - get rid of it. It was in there
> because I wasn't sure about the change to it and I thought Curt
> should look at it before overwriting the proper one.
>
> ground.[ch]xx is not meant to be compiling yet - remove it from
> makefile.am - its in there purely so others working on the ATC can
> see where its at.
>
> In ATC.cxx change:
>
> int FGATC::RemovePlane() {
> }
>
> to
>
> int FGATC::RemovePlane() {
> return 0;
> }
>
> to fix your compiler error.
>
> The problem in approach.cxx is the good old (for int i= ...
> business. Alexander - MSVC6 can't scope variable declarations
> within a for loop declaration properly so you need to do
>
> int i;
> for(i= ... {
> }
> for(i= ... {
> }
>
> instead of
>
> for(int i= ... {
> }
> for(int i= ... {
> }
>
> which works on conforming compilers.
>
> Cheers - Dave
>
>> Thanks,
>>
>> Jonathan Polley
>>
>> On Wednesday, April 3, 2002, at 07:30 PM, Jonathan Polley wrote:
>>
>>> I just updated to the latest CVS and tried to build.
>>>
>>> ATCmgr.cxx
>>> c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715:
>>> 'FGATCMgr::GetATCPointer' : not all control paths return a value
>>> JSBSim.cxx
>>> c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' :
>>> must return a value
>>>
>>> Linux complains as well, but generates a WARNING for the second problem
>>> instead of an error.
>>>
>>> I then fix the error, updated to Erik's version of uiuc_menu.cpp,
>>> rebuild,
>>> and I then get:
>>>
>>> approach.cxx
>>> c:\flightgear\src\atc\approach.cxx(360) : error C2374: 'i' :
>>> redefinition;
>>> multiple initialization
>>> c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
>>> c:\flightgear\src\atc\approach.cxx(366) : error C2374: 'i' :
>>> redefinition;
>>> multiple initialization
>>> c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
>>>
>>> ground.cxx
>>> c:\flightgear\src\atc\ground.hxx(28) : error C2065: 'vector' :
>>> undeclared
>>> identifier
>>> c:\flightgear\src\atc\ground.hxx(28) : error C2501: 'SG_USING_STD' :
>>> missing storage-class or type specifiers
>>> c:\flightgear\src\atc\ground.hxx(29) : error C2065: 'list' : undeclared
>>> identifier
>>> c:\flightgear\src\atc\ground.hxx(29) : error C2501: 'SG_USING_STD' :
>>> missing storage-class or type specifiers
>>> c:\flightgear\src\atc\ground.hxx(29) : error C2086: 'SG_USING_STD' :
>>> redefinition
>>> c:\flightgear\src\atc\ground.hxx(49) : warning C4091: 'typedef ' :
>>> ignored on left of 'struct arc' when no variable is declared
>>> c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
>>> missing ';' before '<'
>>> c:\flightgear\src\atc\ground.hxx(51) : error C2378: 'list' :
>>> redefinition;
>>> symbol cannot be overloaded with a typedef
>>> c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
>>> missing ';' before '<'
>>> c:\flightgear\src\atc\ground.hxx(52) : error C2653: 'arc_list_type' : is
>>> not a class or namespace name
>>> c:\flightgear\src\atc\ground.hxx(52) : error C2146: syntax error :
>>> missing ';' before identifier 'arc_list_itr'
>>> c:\flightgear\src\atc\ground.hxx(52) : fatal error C1004: unexpected end
>>> of file found
>>>
>>> runways.cxx
>>> c:\flightgear\src\atc\runways.cxx(40) : fatal error C1083: Cannot open
>>> include file: 'runways.hxx': No such file or directory
>>>
>>> I can fix the problem in approach.cxx, but the ones in ground.cxx I
>>> cannot (I love the STL problems). Also, I have no idea where
>>> runways.hxx
>>> went.
>>>
>>> Thanks,
>>>
>>> Jonathan Polley
>>>
>>
>>
>> ___
>> Flightgear-devel mailing list
>> [EMAIL PROTECTED]
>> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
>
>
> --
> [EMAIL PROTECTED]
>
> ___
> 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] Moving carrier, and Repositioning questions
On Thu, 2002-04-04 at 13:33, Jon S Berndt wrote: > On Thu, 4 Apr 2002 21:24:06 - > "Jim Wilson" <[EMAIL PROTECTED]> wrote: > >> believe. What are you doing with the way FDMs are > >> instantiated?! > >> > > > >Absolutely nothing. But if your mulitple FDM instances can publish > >position/orientation data into a seperate property tree location for > >each instance, we'll be golden in the viewer and model code. > > Phew! Good. Yes, I think we can (or will be able to) do > that (publish each instance position data). We have > _planned_ on being able to, anyway. Tony will have to > comment on the specifics, though. We'll have to talk about how to implement this. Right now, it would all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of handling both this sort of thing and xml-defined parameters. > > Jon > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson <[EMAIL PROTECTED]> said: > I started a model overhaul myself this afternoon (it's been a little > overdue). Basically, I'm separating the animation code out so that it > can be used for any 3D model (windsock, aircraft carrier, waving field > of grain, or what-have-you) rather than just for the aircraft. > Essentially, this should remove all dependencies on the viewer, since > the model will have to calculate its own matrices (it could be at any > location). I'll give up and revert if it gets too hard. > > Jim: does this conflict with anything you're doing? > Oops, yes it does, I've been doing a similar thing, althought haven't done anything with the animations. Can you send me what you've got and I'll try and merge with what I have? Also: what I would like to do is setup a "/sim/model" property structure that has the pointers to the position and orientation data. example: /position/longitude-deg /position/latitude-deg /positioin/altitude-ft ... same sort of thing for orientation values ... Then for lookat views (that have a target) I can simply reference that model in the viewer configs, rather than specifying "target" data locations for each view, as well as the model. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding an Airport
> Thanks, this works fine. Now I'm rebuilding the relevant parts of the > scenery - looks promising O.k., I give up with scenery. I manage to create the runway but I didn't manage to create scenery with the hole that is necessary to see the runway. Nice try ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Andy Ross writes: > True enough. I was really thinking more along the lines of a few > objects that need to be controllable and/or scripted. Moving carriers > are like this, consider a Python script or whatnot that handled the > battle group's movements through the property system. > > Other types of "dynamic" scenery will obviously have different > requirements. Stuff like FS2002's auto-generated tree models simply > can't go through the property system. But that's OK, since ephemeral > vegetation doesn't have a lot of functional overlap with warships. > We can handle both separately as different types of "DCS" objects. I'd just like to point out for the record, that most trees I've had experience with tend to have a fairly static position, although their would be some overlap in code for calculating an initial position and orientation. :-) > Well, the locking of the gear is easy -- just add the velocities and > the FDM will do the right thing. It's the storage of the velocities > that a mess. Doing this "right" would essentially mean storing a > velocity (normal and angular -- 6DOF) for every leaf of the SSG scene > graph. More, if the leaves are custom objects that have moving > sub-parts. Ick. Yes, something like this would be ambitious, even if you were God. You'd probably want to do this down at the atomic level to really get it right. Of course you'd have to model all the physics at that level too. The good news is that once we have all that working, things like the flight dynamics and landing on carriers and any other potentially moving or not moving surface pretty much come along for free. :-) > Like I said, specially casing train roofs as "aircraft carriers" > sounds more palatable. Yup, we need to scale our goals to what we can realistically handle on today's computers and with a finite amount of programming effort. 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] Moving carrier, and Repositioning questions
David Megginson wrote: > I've considered something similar, but I don't think it's scalable. > Imagine two year from now, if people have created tens of thousands of > custom objects for scenery around the world. This requires more > thought. True enough. I was really thinking more along the lines of a few objects that need to be controllable and/or scripted. Moving carriers are like this, consider a Python script or whatnot that handled the battle group's movements through the property system. Other types of "dynamic" scenery will obviously have different requirements. Stuff like FS2002's auto-generated tree models simply can't go through the property system. But that's OK, since ephemeral vegetation doesn't have a lot of functional overlap with warships. We can handle both separately as different types of "DCS" objects. > What about landing a helicopter on top of a moving train in a James > Bond emulator? This is a nasty problem. I do think that it should be > possible to locate the ssgVertexTable under the wheels, walk up to the > nearest branch, then lock the gear to the object's motion somehow. Well, the locking of the gear is easy -- just add the velocities and the FDM will do the right thing. It's the storage of the velocities that a mess. Doing this "right" would essentially mean storing a velocity (normal and angular -- 6DOF) for every leaf of the SSG scene graph. More, if the leaves are custom objects that have moving sub-parts. Ick. Like I said, specially casing train roofs as "aircraft carriers" sounds more palatable. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: > I've been working toward this sort of thing...slowly severing the > ties between the model code and the viewer so that we can have > multiples of both. I started a model overhaul myself this afternoon (it's been a little overdue). Basically, I'm separating the animation code out so that it can be used for any 3D model (windsock, aircraft carrier, waving field of grain, or what-have-you) rather than just for the aircraft. Essentially, this should remove all dependencies on the viewer, since the model will have to calculate its own matrices (it could be at any location). I'll give up and revert if it gets too hard. Jim: does this conflict with anything you're doing? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] c172-3d-set.xml removed from CVS
Frederic Bouvier writes: > Removed Files: > ^ > c172-3d-set.xml > ^^^ > Log Message: > Raised the default eyepoint and slanted it down slightly. Previously, > the pilot was peering level just over the top of the panel. > > Moved the panel instruments accordingly. That was removed by accident and then put right back again. Sorry about that. You should still see it in the CVS repository. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-3d-set.xml removed from CVS
Curtis L. Olson writes: > Yes, it appears that this file was removed from CVS. What is the > recommended way to fly the 3d cessna? I had created a temporary c172-yasim-3d-set.xml and meant to delete it again, then accidentally deleted c172-3d-set.xml instead. I put it back, I thought, but I'm not online while I'm writing this message and cannot check. If it's not there, I'll put it right back as soon as I'm online. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Moving carrier, and Repositioning questions
Justin Palamar writes: > 1) A design goal was to have a moving aircraft carrier within the simulator > with the option to land on its deck > Right not we have only been able to insert the static model by editing the > appropriate .stg scenery file, including > "OBJECT_STATIC saratoga.3ds -122.353617 37.624617 -130 0" > We know this has been done before, there is code in the main.cxx file that > refers to a carrier, and a model was included in the 0.7.8 release. Is > there any way to get this working using the higher level .xml files, and > avoid editing the C++ source code? You'll need the carrier to be in the main scene graph so that collision and ground detection works -- otherwise, you'll fly right on down through the deck. From an SSG perspective, all you need is an ssgTransform node between the carrier model and the rest of the scene graph, and then to updated that node with the carrier's new position and orientation (relative to scenery centre, which is the only tricky part). In fact, Curt's code in FGTileEntry::load (src/Scenery/tileentry.cxx) already creates the ssgTransform node when it loads the OBJECT_STATIC model. If you save a pointer to the transform (somehow) and update it in each frame, the carrier will move. Note especially this code: sgCoord obj_pos; WorldCoordinate( &obj_pos, center, lat, lon, elev, hdg ); ssgTransform *obj_trans = new ssgTransform; obj_trans->setTransform( &obj_pos ); You can use something similar in your update routine, using the current scenery centre and supplying new lat/long/elev/hdg params. > 2) When loading our blackhawk model (again by editing/adding .xml files > from the ./Aircraft directory our model appears about 3 meters into the > ground. We have attempted to reposition the model using the instructions > from the flighgear website (rather than pointing directly to the model, > point to a .xml wrapper file with repositioning information in it that also > points to the model) but we an ssgLOAD error: Unknown file type .xml. As > if it is trying to see a graphic file and sees an .xml and doesn't know > what to do with it. I'm not sure if this is a change in the newest > release, of if I'm missing something. Yes, you need the latest CVS code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Andy Ross writes: > There are actually two problems here. The first, making the object > move, is relatively easy. It will require C++ code, though. One way > I've thought about doing it is to put the object in the property tree > rather than the static scenery description. Something like: > > /scenery/objects[n]/model-file=Models/carrier.ac3 > /lat-deg=nn.nn > /lon-deg=nn.nn > /alt-ft=nnn > /hdg-deg=nnn > /speed-kt=nnn I've considered something similar, but I don't think it's scalable. Imagine two year from now, if people have created tens of thousands of custom objects for scenery around the world. This requires more thought. > But there's another problem -- the current FDMs model gear force using > only the aircraft's velocity. They assume the ground is fixed and > unmoving. This means that you could land on the carrier, but would > then come to a stop relative to the earth, while the carrier slipped > smoothly out from under you. I hadn't thought of that -- interesting. > I'm not quite sure about the "right" way to do this -- doing it in the > low-level ssg "hitlist" collision detection is going to be rather > complicated, and won't perform well. Perhaps the best way to handle > it would be to special case "carrier deck" objects (more generally, > anything moving on which the gear are expected to rest), and expose > them directly to the FDMs via a "ground velocity" parameter. What about landing a helicopter on top of a moving train in a James Bond emulator? This is a nasty problem. I do think that it should be possible to locate the ssgVertexTable under the wheels, walk up to the nearest branch, then lock the gear to the object's motion somehow. Probably not this week, though. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
On Thu, 4 Apr 2002 16:36:18 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: >Boost has lots of good stuff and FWIW the Boost team does a >VERY good job of insuring compiler, STL and machine independance >see the compiler, platform and stdlib subdirectories in >the distribution Yes, they appear to be pretty good ensuring _compiler_ compatibility. However, the compiler status table shows that the resulting runtime executables can have problems. One thing that got my attention is the quaternion test .cpp program that was run after being compiled by Borland's latest (and very good) compiler v5.5. It failed. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S. Berndt wrote: > Jim Wilson wrote: > > The bigger problem (or so it seems to me :-)) is the one Andy > > brought up. How you model stopping on a moving runway. > > This really is not a big deal after all, I think Agreed. Inside the gear model, the problem is basically an extra addition to the relative velocities. The problem is how to represent that to the rest of the architecture without making a gooey mess. :) I'm becomming more and more convinced that the right solution is just to special case "carrier decks" rather than handle this generically. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
On Thu, 04 Apr 2002 23:26:06 +0200 Christian Mayer <[EMAIL PROTECTED]> wrote: >And IMHO an additional dependancy might be much worse than a event >manager that's a bit more flexible. But I don't know yet. That's what I thought initially. But, I guess I shouldn't rain on Bernie's parade and sound so negative before he has had his say. I guess it makes sense to leverage the good work done by others when it benefits us. Perhaps, also, Bernie only plans to use a small subset of BOOST which has wide compatibility. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 4 Apr 2002 21:24:06 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: >> believe. What are you doing with the way FDMs are >> instantiated?! >> > >Absolutely nothing. But if your mulitple FDM instances can publish >position/orientation data into a seperate property tree location for >each instance, we'll be golden in the viewer and model code. Phew! Good. Yes, I think we can (or will be able to) do that (publish each instance position data). We have _planned_ on being able to, anyway. Tony will have to comment on the specifics, though. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
Curtis L. Olson writes: > >Jon S Berndt writes: >> On Thu, 4 Apr 2002 15:03:33 -0600 (CST) >> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: >> >Hopefully Bernie Bright can address this, although he is running on >> >Australian time so I don't know how soon we'll here from him. >> >> I looked at it a few weeks ago and tossed out the idea >> that it might be useful to us (JSBSim), IMHO. > >This has uses for when you want to refer to function pointers or class >method pointers in a flexible way. > >Bernie wanted this included so he could rewrite the flightgear event >manager class to be a bit more flexible. Boost has lots of good stuff and FWIW the Boost team does a VERY good job of insuring compiler, STL and machine independance see the compiler, platform and stdlib subdirectories in the distribution Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
On Thu, 4 Apr 2002 15:18:02 -0600 (CST) "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: >Jon S Berndt writes: >Bernie wanted this included so he could rewrite the >flightgear event manager class to be a bit more flexible. > >I'm usually not an advocate of jumping on the hype bandwagon because >it sounds cool and it seems like everyone else is doing it, but when >there's an actual legitimate use, that's a different story. So, you are amenable to jumping on the hype bandwagon because there seems to be a legitimate use? ;-) Yet another library dependency. Oh, joy. I remember looking at the compiler compatibility table and thinking that this was asking for trouble. Oh, well, if he can make it work, great. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
"Curtis L. Olson" wrote: > > Jon S Berndt writes: > > On Thu, 4 Apr 2002 15:03:33 -0600 (CST) > > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > >Hopefully Bernie Bright can address this, although he is running on > > >Australian time so I don't know how soon we'll here from him. > > > > I looked at it a few weeks ago and tossed out the idea > > that it might be useful to us (JSBSim), IMHO. > > This has uses for when you want to refer to function pointers or class > method pointers in a flexible way. > > Bernie wanted this included so he could rewrite the flightgear event > manager class to be a bit more flexible. > > I'm usually not an advocate of jumping on the hype bandwagon because > it sounds cool and it seems like everyone else is doing it, but when > there's an actual legitimate use, that's a different story. Unless I know what we gain by using it I can only speculate. And IMHO an additional dependancy might be much worse than a event manager that's a bit more flexible. But I don't know yet. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt <[EMAIL PROTECTED]> said: > >I've been working toward this sort of thing slowly severing the ties > >between the model code and the viewer so that we can have multiples of > >both. The new viewer interface will make it possible to have multiple > >FDM's and changes I'm planning for the model code over the next week will > >make it entirely autonomous. > > Whoa! We'd better coordinate on this. I've got a mechanism > for multiple FDMs already figured out for JSBSim. It > doesn't break anything that any other FDM does, either, I > believe. What are you doing with the way FDMs are > instantiated?! > Absolutely nothing. But if your mulitple FDM instances can publish position/orientation data into a seperate property tree location for each instance, we'll be golden in the viewer and model code. > >The bigger problem (or so it seems to me :-)) is the one > >Andy brought up. How you model stopping on a moving runway. > > This really is not a big deal after all, I think. The gear > model calculates forces and moments imparted to the > aircraft based on the aircraft motion and elevation (and > we really should be modeling non-vertical-normal surfaces, > too). We simply need to change the elevation in a dynamic > way (and the aircraft will respond appropriately) and feed > the local frame runway motion to the aircraft so it can > calculate the relative motion of the aircraft wrt the > runway. The rest will work as is. The aircraft will have a > residual airspeed and forces/moments will be generated > appropriately. > Sounds good. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
Jon S Berndt writes: > On Thu, 4 Apr 2002 15:03:33 -0600 (CST) > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > >Hopefully Bernie Bright can address this, although he is running on > >Australian time so I don't know how soon we'll here from him. > > I looked at it a few weeks ago and tossed out the idea > that it might be useful to us (JSBSim), IMHO. This has uses for when you want to refer to function pointers or class method pointers in a flexible way. Bernie wanted this included so he could rewrite the flightgear event manager class to be a bit more flexible. I'm usually not an advocate of jumping on the hype bandwagon because it sounds cool and it seems like everyone else is doing it, but when there's an actual legitimate use, that's a different story. 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] Heads up: Boost - http://www.boost.org/
On Thu, 4 Apr 2002 15:03:33 -0600 (CST) "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: >Hopefully Bernie Bright can address this, although he is running on >Australian time so I don't know how soon we'll here from him. I looked at it a few weeks ago and tossed out the idea that it might be useful to us (JSBSim), IMHO. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 4 Apr 2002 20:50:18 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: >I've been working toward this sort of thing slowly severing the ties >between the model code and the viewer so that we can have multiples of >both. The new viewer interface will make it possible to have multiple >FDM's and changes I'm planning for the model code over the next week will >make it entirely autonomous. Whoa! We'd better coordinate on this. I've got a mechanism for multiple FDMs already figured out for JSBSim. It doesn't break anything that any other FDM does, either, I believe. What are you doing with the way FDMs are instantiated?! >The bigger problem (or so it seems to me :-)) is the one >Andy brought up. How you model stopping on a moving runway. This really is not a big deal after all, I think. The gear model calculates forces and moments imparted to the aircraft based on the aircraft motion and elevation (and we really should be modeling non-vertical-normal surfaces, too). We simply need to change the elevation in a dynamic way (and the aircraft will respond appropriately) and feed the local frame runway motion to the aircraft so it can calculate the relative motion of the aircraft wrt the runway. The rest will work as is. The aircraft will have a residual airspeed and forces/moments will be generated appropriately. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
Hopefully Bernie Bright can address this, although he is running on Australian time so I don't know how soon we'll here from him. Curt. Tony Peden writes: > > --- Christian Mayer <[EMAIL PROTECTED]> wrote: > > "Curtis L. Olson" wrote: > > > > > > Bernie Bright has submitted a simplified boost > > distribution for > > > SimGear and I have committed it to CVS. The boost > > web page is here: > > > > > > http://www.boost.org/ > > > > > > We will begin depending on this package soon. > > > > Well, *I* don't really understand what boost is > > usefull for. > > > > Can somebody tell me what boost does and why it's > > important for us, > > please? > > Excellent question. > > > > > CU, > > Christian > > > > -- > > The idea is to die young as late as possible. > > -- Ashley Montague > > > > Whoever that is/was; (c) by Douglas Adams would have > > been better... > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > > > __ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > ___ > 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] Heads up: Boost - http://www.boost.org/
--- Christian Mayer <[EMAIL PROTECTED]> wrote: > "Curtis L. Olson" wrote: > > > > Bernie Bright has submitted a simplified boost > distribution for > > SimGear and I have committed it to CVS. The boost > web page is here: > > > > http://www.boost.org/ > > > > We will begin depending on this package soon. > > Well, *I* don't really understand what boost is > usefull for. > > Can somebody tell me what boost does and why it's > important for us, > please? Excellent question. > > CU, > Christian > > -- > The idea is to die young as late as possible. > -- Ashley Montague > > Whoever that is/was; (c) by Douglas Adams would have > been better... > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: > I've been working toward this sort of thing...slowly severing the ties between > the model code and the viewer so that we can have multiples of both. The new > viewer interface will make it possible to have multiple FDM's and changes I'm > planning for the model code over the next week will make it entirely > autonomous. Already I have it generating its own local matrix (had to for the > tower view). Once this is done we can see what we have and figure out a > system for managing the components. > > As for Justin's project, rendering the moving ship should be quite easy once > all I have planned now for the viewer/model is done (probably within a week). > All that will be necessary is something that will update the position and > orientation values for the ship. It can be a simple as a script that updates > properties through the tcp interface every half second. > > The bigger problem (or so it seems to me :-)) is the one Andy brought up. How > you model stopping on a moving runway. That's for the FDM guys to worry about. :-) 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] Moving carrier, and Repositioning questions
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > The DCS system would take care of loading and attaching the 3d models > to the correct place in the scene graph and removing them. It would > call the update() routine for each of their "engines". And it would > probably provide some sort of property interface to the positions, > orientations, and velocities of these dynamics entities. > > That doesn't solve all the problems and address all the issues, but I > think it would be a good start. > I've been working toward this sort of thing...slowly severing the ties between the model code and the viewer so that we can have multiples of both. The new viewer interface will make it possible to have multiple FDM's and changes I'm planning for the model code over the next week will make it entirely autonomous. Already I have it generating its own local matrix (had to for the tower view). Once this is done we can see what we have and figure out a system for managing the components. As for Justin's project, rendering the moving ship should be quite easy once all I have planned now for the viewer/model is done (probably within a week). All that will be necessary is something that will update the position and orientation values for the ship. It can be a simple as a script that updates properties through the tcp interface every half second. The bigger problem (or so it seems to me :-)) is the one Andy brought up. How you model stopping on a moving runway. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
"Curtis L. Olson" wrote: > > Bernie Bright has submitted a simplified boost distribution for > SimGear and I have committed it to CVS. The boost web page is here: > > http://www.boost.org/ > > We will begin depending on this package soon. Well, *I* don't really understand what boost is usefull for. Can somebody tell me what boost does and why it's important for us, please? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A scenery tile question ?
Hello, I would like to convert cartesian vertices coordinates found in a binary tile files into WGS84 lon/lat/height coordinates. I know that Atlas already do that and there is a page on the web site ! What I want to know is the functions in simgear to call and the order to do that. I also want to convert normals as well ! Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] default.fix.gz
>From my Garmin GPS III pilot : > lat lon >ORTAC 49.595700-20018.00 N49°59,947' W002°00,300' >PEPIS 51.114800-11437.00 N51°11,798' W001°14,621' >PERLA 13.765000-88695.00 ??? >RIBOS 13.95-87651.00 ??? >SOMBU 5959.31 000.000540 N59°59,512' E000°00,896' > > 308 of the unique(?) identifiers have two entries with different location, e.g. > >CINDY 41.885522 -091.802431 >CINDY -15.700056 137.200250 N57°38,695' E012°48,367' -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding an Airport
> $FG_SRC / src / Airports / > gensimple > genrunways Thanks, this works fine. Now I'm rebuilding the relevant parts of the scenery - looks promising Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-3d-set.xml removed from CVS
As far as I know that file should still be in there (nothing to replace it yet). Why was it removed? Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > Yes, it appears that this file was removed from CVS. What is the > recommended way to fly the 3d cessna? > > Curt. > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-3d-set.xml removed from CVS
Yes, it appears that this file was removed from CVS. What is the recommended way to fly the 3d cessna? Curt. Frederic Bouvier writes: > Date: Wed Apr 3 17:55:30 EST 2002 > Author: cvsroot > > Update of /home/cvsroot/FlightGear/FlightGear/Aircraft > In directory bitless:/tmp/cvslck/cvs-serv23961/Aircraft > > Removed Files: > ^ > c172-3d-set.xml > ^^^ > Log Message: > Raised the default eyepoint and slanted it down slightly. Previously, > the pilot was peering level just over the top of the panel. > > Moved the panel instruments accordingly. > > > > How can I view the interior cockpit now ? > > Cheers, > > -Fred > > > > ___ > 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] Moving carrier, and Repositioning questions
On Thu, 04 Apr 2002 14:03:10 -0500 Justin Palamar <[EMAIL PROTECTED]> wrote: >Hello, flightgear devolpers, this is my first message to >this list, so please excuse any question that may sound >'stupid', I'm just a newbie. We all remember when we were newbies - no question is stupid. This *answer* may be, though ;-) And this is as good a place as any to post your question. >I am currently a member of a development team working on >a Senior Design project at Pennsylvania State University. PSU? Does John Anderson still teach aero there? > We were assigned to construct a Blackhawk flight >simulator for educational use within the Rotocraft >center. We decided early on to use flightgear as our >engine, due to its vast customizability. We were having >problems in a few areas, and if anyone could provide ANY >insight on any of these subjects I would greatly >appretiate it. Have you seen the rotorcraft-related technical reports at Richard McFarland's web site at Ames? >1) A design goal was to have a moving aircraft carrier >within the simulator with the option to land on its deck >Right now we have only been able to insert the static >model by editing the appropriate .stg scenery file, >including > "OBJECT_STATIC saratoga.3ds -122.353617 >37.624617 -130 0" The following statement is an off-the-top-of-my-head idea thrown out to the developer wolves for your amusement only. However, it is an approach that might be a decent hack. Note that I am vaguely aware of other most assuredly better ways to do this, but here goes, anyway: JSBSim will soon have the ability to model multiple flight vehicles - or rather, multiple _vehicles_. This design feature is specifically for carrying and dropping bombs, missiles, experimental aircraft, etc. and flying them out to completion, or staging a launch vehicle, etc. However, it could also be used for such things as an AI "spotter" plane flying a viewpoint "camera" near an aircraft of interest. Or, I am thinking, just perhaps, it could model an aircraft carrier at sea, given the right set of parameters. It would have few, if any, "aero" coefficients (instead they would be "fluid" coefficients), and the ground reactions (landing gear) would be a bit different than that of an aircraft, instead representing bouyancy? Or maybe that would be done by "fluid" coefficients. Norman might have some observations on this. In any case, the multi- capability is not quite "there", yet. I plan on having a bunch of time this weekend to program, and hope to get that stuff in JSBSim CVS at least in beta this weekend. Whether or not this might actually work for an aircraft carrier in JSBSim is unknown to me at the moment, but I think it could work OK. I might play with it once the time comes. In the meantime, I am sure there will be better ways presented here of doing what you want. How are you modeling the helicopter dynamics? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
What I would like to see implimented is a 'standard' DCS system (where DCS stands for dyanamic coordinate system which is industry lingo for objects that move in the scene ... their local coordinate system is 'dyanamic'. I'm envisioning a DCS manager where you can register 'entities' with an associated 3d model and an associated 'behavior'. The behavior could be a preset path to follow, or something more AI-ish, or even something like JSBSim or YAsim (or perhaps entity positions could be driven externally from a server to produce a 'shared' world for collaborative flying.) I'm thinking we could create some simple "FDM's", one that replays a preset path, and one that impliments ultra-simple-light-weight flight dynamics which would be good enough for 'realistic' robot planes viewed from a distance, but simple enough so we can compute the dyanmics for "many" planes each frame. The DCS system would take care of loading and attaching the 3d models to the correct place in the scene graph and removing them. It would call the update() routine for each of their "engines". And it would probably provide some sort of property interface to the positions, orientations, and velocities of these dynamics entities. That doesn't solve all the problems and address all the issues, but I think it would be a good start. Anyone want to work on this? I could even give you your own subdirectory. :-) Regards, Curt. Andy Ross writes: > Justin Palamar wrote: > > 1) A design goal was to have a moving aircraft carrier within the > > simulator with the option to land on its deck > > There are actually two problems here. The first, making the object > move, is relatively easy. It will require C++ code, though. One way > I've thought about doing it is to put the object in the property tree > rather than the static scenery description. Something like: > > /scenery/objects[n]/model-file=Models/carrier.ac3 > /lat-deg=nn.nn > /lon-deg=nn.nn > /alt-ft=nnn > /hdg-deg=nnn > /speed-kt=nnn > > And then the "dynamic scenery" code would update the lat/lon > accordingly. This could be extended with extra orientation and > velocity parameters for a full 6DOF model animation, controllable via > properties. > > But there's another problem -- the current FDMs model gear force using > only the aircraft's velocity. They assume the ground is fixed and > unmoving. This means that you could land on the carrier, but would > then come to a stop relative to the earth, while the carrier slipped > smoothly out from under you. > > I'm not quite sure about the "right" way to do this -- doing it in the > low-level ssg "hitlist" collision detection is going to be rather > complicated, and won't perform well. Perhaps the best way to handle > it would be to special case "carrier deck" objects (more generally, > anything moving on which the gear are expected to rest), and expose > them directly to the FDMs via a "ground velocity" parameter. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > 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
[Flightgear-devel] c172-3d-set.xml removed from CVS
Date: Wed Apr 3 17:55:30 EST 2002 Author: cvsroot Update of /home/cvsroot/FlightGear/FlightGear/Aircraft In directory bitless:/tmp/cvslck/cvs-serv23961/Aircraft Removed Files: ^ c172-3d-set.xml ^^^ Log Message: Raised the default eyepoint and slanted it down slightly. Previously, the pilot was peering level just over the top of the panel. Moved the panel instruments accordingly. How can I view the interior cockpit now ? Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Justin Palamar wrote: > 1) A design goal was to have a moving aircraft carrier within the > simulator with the option to land on its deck There are actually two problems here. The first, making the object move, is relatively easy. It will require C++ code, though. One way I've thought about doing it is to put the object in the property tree rather than the static scenery description. Something like: /scenery/objects[n]/model-file=Models/carrier.ac3 /lat-deg=nn.nn /lon-deg=nn.nn /alt-ft=nnn /hdg-deg=nnn /speed-kt=nnn And then the "dynamic scenery" code would update the lat/lon accordingly. This could be extended with extra orientation and velocity parameters for a full 6DOF model animation, controllable via properties. But there's another problem -- the current FDMs model gear force using only the aircraft's velocity. They assume the ground is fixed and unmoving. This means that you could land on the carrier, but would then come to a stop relative to the earth, while the carrier slipped smoothly out from under you. I'm not quite sure about the "right" way to do this -- doing it in the low-level ssg "hitlist" collision detection is going to be rather complicated, and won't perform well. Perhaps the best way to handle it would be to special case "carrier deck" objects (more generally, anything moving on which the gear are expected to rest), and expose them directly to the FDMs via a "ground velocity" parameter. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Moving carrier, and Repositioning questions
Hello, flightgear devolpers, this is my first message to this list, so please excuse any question that may sound 'stupid', I'm just a newbie. Also if this is posted to the wrong mailing list, I apologize, let me know and I'll redirect to the proper place. I am currently a member of a development team working on a Senior Design project at Pennsylvania State University. We were assigned to construct a Blackhawk flight simulator for educational use within the Rotocraft center. We decided early on to use flightgear as our engine, due to its vast customizability. We were having problems in a few areas, and if anyone could provide ANY insight on any of these subjects I would greatly appretiate it. 1) A design goal was to have a moving aircraft carrier within the simulator with the option to land on its deck Right not we have only been able to insert the static model by editing the appropriate .stg scenery file, including "OBJECT_STATIC saratoga.3ds -122.353617 37.624617 -130 0" We know this has been done before, there is code in the main.cxx file that refers to a carrier, and a model was included in the 0.7.8 release. Is there any way to get this working using the higher level .xml files, and avoid editing the C++ source code? 2) When loading our blackhawk model (again by editing/adding .xml files from the ./Aircraft directory our model appears about 3 meters into the ground. We have attempted to reposition the model using the instructions from the flighgear website (rather than pointing directly to the model, point to a .xml wrapper file with repositioning information in it that also points to the model) but we an ssgLOAD error: Unknown file type .xml. As if it is trying to see a graphic file and sees an .xml and doesn't know what to do with it. I'm not sure if this is a change in the newest release, of if I'm missing something. Sorry for such a long message, I wanted to make sure I provided enough information. If anyone could help me in any way with anything here, I would REALLY appretiate it. Thanks... Justin ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glass cockpit
- Original Message - From: "Martin Dressler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 04, 2002 7:46 AM Subject: Re: [Flightgear-devel] glass cockpit > > > Please, give me some advice how to run it with FG on the same machine. It > compiles fine but when I run it, it exit without error and don't open window. > I didn't found any comand line options. > Okay, the repository is working After compiling, edit the opengc.ini file to set the window size and gauge locations Start the program with "opengc". You might have to play with the locations of the nav database and arial.ttf font file. try /usr/local/NavBase for the nav data and if all else fails put the font file at the top -- "/" Start flightgear in a seperate window with the socket option fgfs --opengc=socket,out,30,127.0.0.0.1,5800,udp (+whatever else you need as options) Put the focus in the opengc window and type "!", FMC should move to state 1, type "@" and this will activate the UDP socket. Move the focus to the FG window and fly . You will see some latency between the fg state and the displays when running on a single machine and sharing resources. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Adding an Airport
Martin Spott writes: >[... Madr wrote ...] > >> IMHO You also need to update metakit databases runways.mk4 and simple.mk4, >> but I don't know how. Try to ask Curt. > >I already thought about it but he is overloaded with work and EMail - anyone >on the list who is not ? So I posted to the list ;-) >I already looked at the binaries that get produced when I compile FlightGear >but I didn't find any that might be suitable, see $FG_SRC / src / Airports / gensimple genrunways Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Alexander Kappes wrote: > Thanks, this solves part of my problem. However, I still have the > problem that for some reason the axis of the coolie hat (4 and 5 in > this example) are not uncorrelated for the FlightSimYoke. What I mean > with this is that for example if I don't touch the coolie axis 4 = 0 > but axis 5 = -1. If I push it up then axis 4 = 1 and axis 5 = 0 and > for left axis 4 = 0 and axis 5 = 1. This is not the real mapping but > if I want to control both the lan and the long view direction with the > coolie hat I have to use a combination of the two axis for each > property. Is this possible? This sounds to me as if one of the switches in your hat is bent, and is in the "on" possition even when the hat it centered. I've seen exactly this effect in the past on a Thrustmaster Top Gun stick. Joystick hardware basically sucks. Run jscal and note all the possibilities. What you "should" see is zero for both axes when you don't touch the hat, and independant motion when you do. An 8-way hat switch will also be able to report the corners (both axes at 1, for example). Another possibility is that the analog joystick driver has miscalibrated the axes; as I remember it applies the calibration numbers even to digital axes like hats. What kind of stick do you have? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Alexander Kappes wrote: > Yes, I looked at the page and that's how I actually do it at the > moment. The problem was they didn't know what properties to use. So > /sim/view/axes/lat and /sim/view/axes/long are the right properties > for this. Heh, I was hoping you'd already know, because I forget (forgive me, it's been way too long since I sat down and wrote code for FlightGear). It used to be that there was an euler angle property interface -- /sim/view/offset and /sim/view/pitch (I think). These would be better than lat/lon, as they correspond better to instantaneous rotations. I haven't looked since the change to see how these have been modified, if at all. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx,1.161,1.162 main.cxx,1.270,1.271 options.cxx,1.158,1.159
Curtis L. Olson writes: > It sounds like you are bypassing SG_LOG() because it isn't doing what > you want. This seems like a bandaid solution at best. Perhaps we > should put these messages back in as SG_LOG( SG_ALERT ) and then > default 'release' builds to a minimum logging level of SG_ALERT rather > than collapsing SG_LOG into nothing as we do now. That sounds reasonable. I wasn't sure what peoples' intentions were with SG_LOG, but it seemed like a bad idea to have situations where people might not get messages for catastrophic errors. What should we change to make SG_ALERT enabled by default? I haven't seen yet where that's happening (I configured with debug messages and still am not seeing any). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding an Airport
[... Madr wrote ...] > On Thu 4. April 2002 00:58, you wrote: >> sirius: 0:55:17 ~> fgfs >> [...] >> Attempting to set starting position from runway code FX01 heading 270 >> Failed to find FX01 in database. >> [...] > IMHO You also need to update metakit databases runways.mk4 and simple.mk4, > but I don't know how. Try to ask Curt. I already thought about it but he is overloaded with work and EMail - anyone on the list who is not ? So I posted to the list ;-) I already looked at the binaries that get produced when I compile FlightGear but I didn't find any that might be suitable, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glass cockpit
Hi, > Please, give me some advice how to run it with FG on the same machine. It > compiles fine but when I run it, it exit without error and don't open window. > I didn't found any comand line options. > mea culpa, mea maxima culpa --- if you've recently downloaded from the CVS site, the package has a bug. Working late last night, "something" got committed. Not sure where or how, but will try to get things back this morning. You can run on the same machine be using the loopback address 127.0.0.1 in the FG socket command to send UDP packets to the opengc displays. The downside is that performance is somewhat choppy and unpredictable as you have two mainglutloops running and the available frame rate is not shared equally between fgfs and opengc. Yes, there are no command line options. There is a small opengc.ini file used to specify window size and location and gauge size and placement. > I looked on some posibility of integration with our panel code, but it use > glViewport for some clipping. So we never can use it in panel :-( > It is primarily designed to run as a seperate app across a network. Integrating the displays into FG would be a major rework. When I get the new repository code working again, I'll post a short notice. You can download an older version from the sourceforge site which has not been clobbered. There is also some info on required font libraries and links on where to get the same. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding an Airport
On Thu 4. April 2002 00:58, you wrote: > After digging through several README's, FAQ's and Robin's manual I decided > to have a rough try with my so much desired airport. > > I did some calculation and then I added two lines to the default.apt(.gz) > file for a minimal airport definition - to have a 'proof of concept' before > I start working on the details. You can find it here: > > ftp://ftp.uni-duisburg.de/FlightGear/Devel/FX01.apt > > > There will be _lots_ of details to follow once I have a start. This picture > might tell you (I know the Airfiled from wandering around, so I know what's > valid on this picture ): > > http://www.xs4all.nl/~nvav/afb/rsa-kaartje-1.gif > > > > I know that I will not see the runway as long as I don't rebuild the > scenery but I understood that I should at least have the ability to sit on > the grass at the desired place. Unfortunately this is not the case: > > sirius: 0:55:17 ~> fgfs > [...] > Attempting to set starting position from runway code FX01 heading 270 > Failed to find FX01 in database. > [...] IMHO You also need to update metakit databases runways.mk4 and simple.mk4, but I don't know how. Try to ask Curt. Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx,1.161,1.162 main.cxx,1.270,1.271 options.cxx,1.158,1.159
David,
It sounds like you are bypassing SG_LOG() because it isn't doing what
you want. This seems like a bandaid solution at best. Perhaps we
should put these messages back in as SG_LOG( SG_ALERT ) and then
default 'release' builds to a minimum logging level of SG_ALERT rather
than collapsing SG_LOG into nothing as we do now.
It would be nice to be able to maintain a consistant approach
throughout the project.
Curt.
David Megginson writes:
> Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
> In directory seneca:/tmp/cvs-serv1516/src/Main
>
> Modified Files:
> fg_init.cxx main.cxx options.cxx
> Log Message:
> Let exceptions fall through to main, and use cerr to report them (in
> case logging is disabled). This way, when people specify a
> non-existant aircraft or have an error in a custom XML file, they'll
> get an error report, at least.
>
>
> Index: fg_init.cxx
> ===
> RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/fg_init.cxx,v
> retrieving revision 1.161
> retrieving revision 1.162
> diff -C2 -r1.161 -r1.162
> *** fg_init.cxx 3 Apr 2002 21:54:45 - 1.161
> --- fg_init.cxx 4 Apr 2002 15:51:40 - 1.162
> ***
> *** 232,243
> props_path.append("preferences.xml");
> SG_LOG(SG_INPUT, SG_INFO, "Reading global preferences");
> ! try {
> ! readProperties(props_path.str(), globals->get_props());
> ! } catch (const sg_exception &e) {
> ! string message = "Error reading global preferences: ";
> ! message += e.getFormattedMessage();
> ! SG_LOG(SG_INPUT, SG_ALERT, message);
> ! exit(2);
> ! }
> SG_LOG(SG_INPUT, SG_INFO, "Finished Reading global preferences");
>
> --- 232,236
> props_path.append("preferences.xml");
> SG_LOG(SG_INPUT, SG_INFO, "Reading global preferences");
> ! readProperties(props_path.str(), globals->get_props());
> SG_LOG(SG_INPUT, SG_INFO, "Finished Reading global preferences");
>
>
> Index: main.cxx
> ===
> RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/main.cxx,v
> retrieving revision 1.270
> retrieving revision 1.271
> diff -C2 -r1.270 -r1.271
> *** main.cxx 4 Apr 2002 03:03:18 - 1.270
> --- main.cxx 4 Apr 2002 15:51:40 - 1.271
> ***
> *** 32,35
> --- 32,40
>
> #include
> +
> + #include
> + SG_USING_STD(cerr);
> + SG_USING_STD(endl);
> +
> #include
> #include
> ***
> *** 1599,1605
> mainLoop(argc, argv);
> } catch (sg_throwable &t) {
> ! SG_LOG(SG_GENERAL, SG_ALERT,
> !"Fatal error: " << t.getFormattedMessage()
> !<< "\n (received from " << t.getOrigin() << ')');
> exit(1);
> }
> --- 1604,1612
> mainLoop(argc, argv);
> } catch (sg_throwable &t) {
> ! // We must use cerr rather than
> ! // logging, since logging may be
> ! // disabled.
> ! cerr << "Fatal error: " << t.getFormattedMessage()
> ! << "\n (received from " << t.getOrigin() << ')' << endl;
> exit(1);
> }
>
> Index: options.cxx
> ===
> RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Main/options.cxx,v
> retrieving revision 1.158
> retrieving revision 1.159
> diff -C2 -r1.158 -r1.159
> *** options.cxx 26 Mar 2002 01:38:15 - 1.158
> --- options.cxx 4 Apr 2002 15:51:40 - 1.159
> ***
> *** 943,954
> SG_LOG(SG_INPUT, SG_INFO, "Reading aircraft: " << arg.substr(11)
> << " from " << apath.str());
> ! try {
> ! readProperties( apath.str(), globals->get_props() );
> ! } catch (const sg_exception &e) {
> ! string message = "Error loading aircraft file: ";
> ! message += e.getFormattedMessage();
> ! SG_LOG(SG_INPUT, SG_ALERT, message);
> ! exit(2);
> ! }
> } else {
> SG_LOG( SG_GENERAL, SG_ALERT, "Unknown option '" << arg << "'" );
> --- 943,947
> SG_LOG(SG_INPUT, SG_INFO, "Reading aircraft: " << arg.substr(11)
> << " from " << apath.str());
> ! readProperties( apath.str(), globals->get_props() );
> } else {
> SG_LOG( SG_GENERAL, SG_ALERT, "Unknown option '" << arg << "'" );
>
>
> ___
> Flightgear-cvslogs mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flig
Re: [Flightgear-devel] glass cockpit
On Wed 3. April 2002 00:18, you wrote: > > What's the status of OpenGC integration with FlightGear? I > > have a thought in mind for something it might be used for, > > and I might be interested in trying it out. > > The network interface is alive and well. ( it is sync'd with the latest > CVS version of FG ) The FMC is "in the shop" for a major > overhaul. The display code builds and runs under linux. Limited > checks and tests for required libraries. Requires new freetype and > ftgl libraries. URLs provided with download package. Gauges are > functional but "incomplete" - some pieces/symbols under > development. > Please, give me some advice how to run it with FG on the same machine. It compiles fine but when I run it, it exit without error and don't open window. I didn't found any comand line options. I looked on some posibility of integration with our panel code, but it use glViewport for some clipping. So we never can use it in panel :-( Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hallo and questions
Thank you very much for this detailed description. I'm really glad that I never had a computer science professor, worrying too much is not very healthy. :-) Regards Alexander On Thu, 4 Apr 2002, Curtis L. Olson wrote: > Alexander Kappes writes: > > Hi David, > > > > > Just about any information you want is available in the property > > > tree. There's an interactive GUI browser built into FlightGear -- > > > choose "Properties" from the "View" drop-down menu. > > > > How do I have to imagine this property tree, I mean how is it realized in > > memory (C++) and what kind of things are stored in it? Is it something > > like an interface between different parts of FGFS? > > Another way to look at the property manager is as a 'key/value' hash. > Any part of the program can lookup a property name (key) and it's > associated value. Values can be of type integer, boolean, float, > double, and string. > > For convenience the property names (keys) are arranged in a way that > appears like a hierarchical tree structure. You can traverse the > property 'tree' in much the same way as you would traverse the > directories in a file system. > > The relative merits of this approach have been discussed at great > length and with great vigor on this list in the past so I'd rather not > replay that again now, but let me summarize. > > The upside of this approach is it is *very* convenient and flexible. > When you begin dealing with things like aircraft with vastly different > types of control inputs, flight model codes with vastly different > types of data outputs/inputs, instruments and instrument panels that > care about vastly different sets of parameters, the traditional > computer science taught approach to building interfaces (at best) > becomes extremely cumbersum and (at worst) starts to completely break > down. > > The downside of this is that now we have tossed out several key > principles drilled into our heads starting at day one by our computer > science professors. We now have things like 'global' shared state > that can change anywhere in the code. (Bye bye abstract data types.) > Properties aren't variables so they can't be type checked or even > 'spell' checked by the compiler. And people have brought up > performance concerns incurred by the extra layers of indirection. > > However, from a practical standpoint, we need *some* global state. > Much of this computer science theory works wonderfully in simple demo > programs, but doesn't always scale well to the practical needs of > large complex software projects. Profiling has shown us that at least > at this point, the performance of the property manager isn't a > problem. We have been bit on occasion by 'spelling' errors that the > compiler can no longer flag for us, but those have been pretty > straight forward to track down and fix. > > There are some definite trade off's that can be intelligently argued > either way. > > So the conclusion here is that 'practice' seems to have won the battle > over 'theory'. And all those evil things we were told would happen to > us if we disobeyed our computer science professors ... well as long as > we know and understand the dangers, we seem to have been able to > minimize, manage, and containt the problems. Life isn't so bad this > way and the project hasn't imploded upon itself. The longer we run > with the property manager without encountering a violent end to the > world, the more confidence we have in our approach. :-) > > 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 > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
David Megginson writes: > Andy Ross writes: > > > I'll chop the cockpit stuff out of YASim as soon as someone tells me > > it's OK. > > It's fine with me. Curt? Sure, sounds good to me. 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] YASIM/Viewer mismatch
David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson writes: > > > Err umm...what is it that won't be necessary? > > Using properties other than the /position ones. > Right from the start I've been planning to support that anyway. Two reasons: 1) Probably soon to be realized multiple instances of FDM and models. 2) Towers don't fly (usually). So their position and orientation needs to come from elsewhere. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights and fog
Roman Grigoriev writes: > Hi guys > I found some intresting arcticle on runway lights > check this out > http://www.opengvs.com/support/opengvs/howto/fog_atten/default.htm > read it please and maybe it should be implemented in flightgear its very > simple > so maybe someone who has flying practice can confirm this effect? > Thanx > Bye Yes, we are already implimenting something similar to this. Search for "fog_exp2_punch_through" in src/Main/main.cxx to see what is happening. 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] YASIM/Viewer mismatch
Jim Wilson writes: > Err umm...what is it that won't be necessary? Using properties other than the /position ones. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hallo and questions
Alexander Kappes writes: > Hi David, > > > Just about any information you want is available in the property > > tree. There's an interactive GUI browser built into FlightGear -- > > choose "Properties" from the "View" drop-down menu. > > How do I have to imagine this property tree, I mean how is it realized in > memory (C++) and what kind of things are stored in it? Is it something > like an interface between different parts of FGFS? Another way to look at the property manager is as a 'key/value' hash. Any part of the program can lookup a property name (key) and it's associated value. Values can be of type integer, boolean, float, double, and string. For convenience the property names (keys) are arranged in a way that appears like a hierarchical tree structure. You can traverse the property 'tree' in much the same way as you would traverse the directories in a file system. The relative merits of this approach have been discussed at great length and with great vigor on this list in the past so I'd rather not replay that again now, but let me summarize. The upside of this approach is it is *very* convenient and flexible. When you begin dealing with things like aircraft with vastly different types of control inputs, flight model codes with vastly different types of data outputs/inputs, instruments and instrument panels that care about vastly different sets of parameters, the traditional computer science taught approach to building interfaces (at best) becomes extremely cumbersum and (at worst) starts to completely break down. The downside of this is that now we have tossed out several key principles drilled into our heads starting at day one by our computer science professors. We now have things like 'global' shared state that can change anywhere in the code. (Bye bye abstract data types.) Properties aren't variables so they can't be type checked or even 'spell' checked by the compiler. And people have brought up performance concerns incurred by the extra layers of indirection. However, from a practical standpoint, we need *some* global state. Much of this computer science theory works wonderfully in simple demo programs, but doesn't always scale well to the practical needs of large complex software projects. Profiling has shown us that at least at this point, the performance of the property manager isn't a problem. We have been bit on occasion by 'spelling' errors that the compiler can no longer flag for us, but those have been pretty straight forward to track down and fix. There are some definite trade off's that can be intelligently argued either way. So the conclusion here is that 'practice' seems to have won the battle over 'theory'. And all those evil things we were told would happen to us if we disobeyed our computer science professors ... well as long as we know and understand the dangers, we seem to have been able to minimize, manage, and containt the problems. Life isn't so bad this way and the project hasn't imploded upon itself. The longer we run with the property manager without encountering a violent end to the world, the more confidence we have in our approach. :-) 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] YASIM/Viewer mismatch
David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson writes: > > > Ok, I think this means I can continue in the same direction with > > the viewer code. It would be just a matter of editing xml to > > switch from using /position/lat||lon||alt to somewhere else in the > > property tree, so if folks want to experiment they can. > > I don't know if that will be necessary. As long as we agree that the > lat/lon/alt give a fixed position (somewhere) on the plane, that's > good enough, and it becomes a convention to be agreed upon model by > model. I agree with Jon that when the manufacturer does specify an > origin, we should use that. > Err umm...what is it that won't be necessary? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
Alexander Kappes writes: > Ok, sorry for this. I will try to remember it for the future. Is anybody > going to fix this in the CVS tree? > > What do I have to do if I want the gcc compiler under Linux to return > an error if a routine of type non-void is defined but no value is > returned? > > BTW, how is updating of the CVS tree handled for this project? I suppose > there is a limited number of people who are allowed to upload, who is it? Lot's of stuff can get tossed about on the mailing lists and it can get a bit confusing as to what is actually supposed to happen... especially if a person isn't the original author and doesn't have time to dig in and get intimite with the code. What seems to work best is if the original author(s) of the code can monitor the discussion and submit the necessary changes to David or me. Thanks, 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] 3D Cockpit
Marcio Shimoda writes: > How do I see the 3D cockpit? fgfs --aircraft=c172-3d All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Alexander Kappes writes: > > The "high" and "low" bindings are invoked as keystrokes when the > > joystick enters the top 10% of travel in either direction. > > Yes, I looked at the page and that's how I actually do it at the moment. > The problem was they didn't know what properties to use. So > /sim/view/axes/lat and /sim/view/axes/long are the right properties > for this. No, in that case you'd want to increment or decrement /sim/view/goal-offset-deg. Note that all the view properties will probably be changing soon, since Jim is finishing a major overhaul of that subsystem. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hallo and questions
Erik Hofman writes: > > How do I have to imagine this property tree, I mean how is it realized in > > memory (C++) > > Yes, what you see is what you get. He could think of it as a virtual filesystem containing the internal state of the sim. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > I need to pick a less popular project to be involved in ... maybe a > python to cobol translator written in prolog. > Ooo ooo yeah. I've been looking for one of those :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Cockpit
Marcio Shimoda <[EMAIL PROTECTED]> said: > How do I see the 3D cockpit? > Run with --aircraft=c172-3d Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] View hat on FlighSimYoke USB
Thank you very much David. I would have never thought of that. I always wondered why the mapping was so weired. Regards Alexander On Thu, 4 Apr 2002, David Megginson wrote: > Alexander Kappes writes: > > > Thanks, this solves part of my problem. However, I still have the problem > > that for some reason the axis of the coolie hat (4 and 5 in this example) > > are not uncorrelated for the FlightSimYoke. What I mean with this is that > > for example if I don't touch the coolie axis 4 = 0 but axis 5 = -1. If I > > push it up then axis 4 = 1 and axis 5 = 0 and for left axis 4 = 0 and axis > > 5 = 1. This is not the real mapping but if I want to control both the lan > > and the long view direction with the coolie hat I have to use a > > combination of the two axis for each property. Is this possible? > > I'll guessing that you're using Linux 2.4. There is a bug in some > 2.4 kernel versions where joydev.c misassigns the hat axes. It seems > OK now in 2.4.17. > > > All the best, > > > David > > -- > David Megginson > [EMAIL PROTECTED] > > > ___ > 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] View hat on FlighSimYoke USB
Alexander Kappes writes: > Thanks, this solves part of my problem. However, I still have the problem > that for some reason the axis of the coolie hat (4 and 5 in this example) > are not uncorrelated for the FlightSimYoke. What I mean with this is that > for example if I don't touch the coolie axis 4 = 0 but axis 5 = -1. If I > push it up then axis 4 = 1 and axis 5 = 0 and for left axis 4 = 0 and axis > 5 = 1. This is not the real mapping but if I want to control both the lan > and the long view direction with the coolie hat I have to use a > combination of the two axis for each property. Is this possible? I'll guessing that you're using Linux 2.4. There is a bug in some 2.4 kernel versions where joydev.c misassigns the hat axes. It seems OK now in 2.4.17. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Arnt Karlsen writes: > ..a wee point: in sideslipping, will the responsible pilot > stare, towards the infinte end of the longitudal axis, or will > he watch/look out to where he is going? My .02, only. ;-) We are talking only about the default viewpoint location. It's up to the pilot to control the view orientation using the mouse, keyboard, joystick hat, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Andy Ross writes: > > You can control any property with the joystick, but to control the > > view direction, use something like this: > > This controls the absolute direction. I find it much more useful to > incrementally adjust the view offsets instead; this matches view > controls in consumer sims better, and doesn't limit you to a fixed set > of 8 (or even 4, if you have an old hat switch) views. Fair enough. I use the mouse for that, but the whole point of configurable input devices is to choose what works for you. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Andy Ross writes: > I'll chop the cockpit stuff out of YASim as soon as someone tells me > it's OK. It's fine with me. Curt? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson writes: > Ok, I think this means I can continue in the same direction with > the viewer code. It would be just a matter of editing xml to > switch from using /position/lat||lon||alt to somewhere else in the > property tree, so if folks want to experiment they can. I don't know if that will be necessary. As long as we agree that the lat/lon/alt give a fixed position (somewhere) on the plane, that's good enough, and it becomes a convention to be agreed upon model by model. I agree with Jon that when the manufacturer does specify an origin, we should use that. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Robert Deters wrote:
>>
> Can some one with MSVC or SGI please try the above? If it works, I'll
> change it.
After some testing Im confident something like the following should
indeed work:
uiuc_menu.cpp line 1429:
ALERT: Process [mozilla-bin] pid 13567 killed: process or stack limit
exceeded
/* call 2D File Reader with file name (CXfabetaf_file) and
moz_run_program[36]: 13567 Memory fault(coredump)f
elevator deflections (deArray) and corresponding
alpha (aArray) and delta CZ (CZArray) values and
max number of terms in alpha arrays (nAlphaArray)
and delfection array (nde) */
uiuc_2DdataFileReader(CXfabetaf_file,
CXfabetaf_aArray[CXfabetaf_index],
CXfabetaf_betaArray[CXfabetaf_index],
CXfabetaf_CXArray[CXfabetaf_index],
CXfabetaf_nAlphaArray[CXfabetaf_index],
CXfabetaf_nbeta[CXfabetaf_index]);
if (CXfabetaf_first==true)
{
if (CXfabetaf_nice == 1)
{
CXfabetaf_na_nice = *CXfabetaf_aArray[CXfabetaf_index][1];
CXfabetaf_nb_nice = CXfabetaf_nbeta[CXfabetaf_index];
memcpy(CXfabetaf_bArray_nice,
CXfabetaf_betaArray[CXfabetaf_index],
sizeof(CXfabetaf_bArray_nice));
memcpy(&CXfabetaf_aArray_nice[i+1],
CXfabetaf_aArray[CXfabetaf_index][1],
CXfabetaf_na_nice);
}
aeroDragParts -> storeCommands (*command_line);
CXfabetaf_first=false;
}
break;
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] runway lights and fog
Hi guys I found some intresting arcticle on runway lights check this out http://www.opengvs.com/support/opengvs/howto/fog_atten/default.htm read it please and maybe it should be implemented in flightgear its very simple so maybe someone who has flying practice can confirm this effect? Thanx Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
> In ATC.cxx change:
>
> int FGATC::RemovePlane() {
> }
>
> to
>
> int FGATC::RemovePlane() {
> return 0;
> }
>
> to fix your compiler error.
>
> The problem in approach.cxx is the good old (for int i= ...
> business. Alexander - MSVC6 can't scope variable declarations
> within a for loop declaration properly so you need to do
> int i;
> for(i= ... {
> }
> for(i= ... {
> }
>
> instead of
>
> for(int i= ... {
> }
> for(int i= ... {
> }
>
> which works on conforming compilers.
>
Ok, sorry for this. I will try to remember it for the future. Is anybody
going to fix this in the CVS tree?
What do I have to do if I want the gcc compiler under Linux to return
an error if a routine of type non-void is defined but no value is
returned?
BTW, how is updating of the CVS tree handled for this project? I suppose
there is a limited number of people who are allowed to upload, who is it?
Cheers Alexander
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] David Vs. 0.99.1
Hi, Cool, Davis is even more productive yet ;-) > Changes: An important bug that crashed David when creating new files for the >projects has been fixed. http://freshmeat.net/projects/david/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hallo and questions
Alexander Kappes wrote: > Hi David, > > >>Just about any information you want is available in the property >>tree. There's an interactive GUI browser built into FlightGear -- >>choose "Properties" from the "View" drop-down menu. >> > > How do I have to imagine this property tree, I mean how is it realized in > memory (C++) Yes, what you see is what you get. > and what kind of things are stored in it? Is it something > like an interface between different parts of FGFS? It replaces an extensive API for most parts of FlightGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with templates
Marcio Shimoda wrote: > Hi, > > When I try to compile the FG I got the following error > "Compiling... > fg_fx.cxx > c:\flightgear-cvs\src\sound\soundmgr.hxx(98) : see reference to > class template instantiation 'std::map std::char_traits,class std::allocator >,struct sample_ref > *,struct std::less sic_string,class std::allocator > > >>,class std::allocator >' being compiled >> > ..." > Does anybody have any idea of how to solve this?? Unfortunately this doesn't seem to be the complete error message, so I cannot se what's happening. You might want to post the complere error message, together with the OS and compiler you are using. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
Jonathan Polley wrote:
> Doing some more investigation, I found that there is a runways.cxx in both
> FlightGear/src/ATC and FlightGear/src/Airports. Are they the same?
>
OK, sorry for breaking things...
runways.cxx shouldn't be in ATC - get rid of it. It was in there
because I wasn't sure about the change to it and I thought Curt
should look at it before overwriting the proper one.
ground.[ch]xx is not meant to be compiling yet - remove it from
makefile.am - its in there purely so others working on the ATC can
see where its at.
In ATC.cxx change:
int FGATC::RemovePlane() {
}
to
int FGATC::RemovePlane() {
return 0;
}
to fix your compiler error.
The problem in approach.cxx is the good old (for int i= ...
business. Alexander - MSVC6 can't scope variable declarations
within a for loop declaration properly so you need to do
int i;
for(i= ... {
}
for(i= ... {
}
instead of
for(int i= ... {
}
for(int i= ... {
}
which works on conforming compilers.
Cheers - Dave
> Thanks,
>
> Jonathan Polley
>
> On Wednesday, April 3, 2002, at 07:30 PM, Jonathan Polley wrote:
>
> > I just updated to the latest CVS and tried to build.
> >
> > ATCmgr.cxx
> > c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715:
> > 'FGATCMgr::GetATCPointer' : not all control paths return a value
> > JSBSim.cxx
> > c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' :
> > must return a value
> >
> > Linux complains as well, but generates a WARNING for the second problem
> > instead of an error.
> >
> > I then fix the error, updated to Erik's version of uiuc_menu.cpp, rebuild,
> > and I then get:
> >
> > approach.cxx
> > c:\flightgear\src\atc\approach.cxx(360) : error C2374: 'i' : redefinition;
> > multiple initialization
> > c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
> > c:\flightgear\src\atc\approach.cxx(366) : error C2374: 'i' : redefinition;
> > multiple initialization
> > c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i'
> >
> > ground.cxx
> > c:\flightgear\src\atc\ground.hxx(28) : error C2065: 'vector' : undeclared
> > identifier
> > c:\flightgear\src\atc\ground.hxx(28) : error C2501: 'SG_USING_STD' :
> > missing storage-class or type specifiers
> > c:\flightgear\src\atc\ground.hxx(29) : error C2065: 'list' : undeclared
> > identifier
> > c:\flightgear\src\atc\ground.hxx(29) : error C2501: 'SG_USING_STD' :
> > missing storage-class or type specifiers
> > c:\flightgear\src\atc\ground.hxx(29) : error C2086: 'SG_USING_STD' :
> > redefinition
> > c:\flightgear\src\atc\ground.hxx(49) : warning C4091: 'typedef ' :
> > ignored on left of 'struct arc' when no variable is declared
> > c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
> > missing ';' before '<'
> > c:\flightgear\src\atc\ground.hxx(51) : error C2378: 'list' : redefinition;
> > symbol cannot be overloaded with a typedef
> > c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error :
> > missing ';' before '<'
> > c:\flightgear\src\atc\ground.hxx(52) : error C2653: 'arc_list_type' : is
> > not a class or namespace name
> > c:\flightgear\src\atc\ground.hxx(52) : error C2146: syntax error :
> > missing ';' before identifier 'arc_list_itr'
> > c:\flightgear\src\atc\ground.hxx(52) : fatal error C1004: unexpected end
> > of file found
> >
> > runways.cxx
> > c:\flightgear\src\atc\runways.cxx(40) : fatal error C1083: Cannot open
> > include file: 'runways.hxx': No such file or directory
> >
> > I can fix the problem in approach.cxx, but the ones in ground.cxx I
> > cannot (I love the STL problems). Also, I have no idea where runways.hxx
> > went.
> >
> > Thanks,
> >
> > Jonathan Polley
> >
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
