Re: [Flightgear-devel] Dynamic Scenario's
Hi Paul, I think I haven't been mentioned in this discussion yet but I started to work on an ATC interface together with Dave. My original thought was that it would be nice if the ATC system wouldn't have to differ between the player and AI aircrafts, i.e. both type of planes send transmission in text form (or the player maybe later even as wave files) to the ATC system which are then analyzed by a parser and the answer is sent back as in real life. I think this would fit in your ideas quite nicely. I also thought about doing the ATC stuff in a separat program but I'm not experienced enough with this kind of programming to know how to establish the communication between the programs. Therefore, I started to do it within FlightGear. Cheers Alexander Hi David, I have been reviewing the current situation, I am not here to try to take over and start redoing stuff, BUT what I am proposing is a radical change to what is men't by Dynamic Scenario. As said when I first joined in, I work for a very large flight simulation company, where we have a dynamic flight simulation server. I know there are two concerns with having a server: 1) Communicating with the main system (latency) 2) Some peopele don't have ethernet connections thus how will it work on a stand-alone machine (like a laptop). My proposal solution to the above questions are that we use shared memory or ethernet communications (user selectable), the main flight-gear app will not really contain the AI code, it will be done by the server, which updates lat, long, altitude, heading etc, this is sent to flight-gear that then does the displaying, sounds etc. The server (dynamic scenario) could then be used to manage plane routes, knowledge bases for the flight dynamics etc. comments? Paul - Original Message - From: David Luff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 11:46 AM Subject: Re: [Flightgear-devel] Dynamic Scenario's Hi Paul, As others have pointed out, there has been a small amount of AI traffic development going on, and as the guilty party I'd better pipe up sooner rather than later :-) I'll describe what I've been doing and leave it up to you whether you want to join in with that or start afresh. I've started from the premise that if there's going to be a number of planes in the sky at once, then they should take up as few CPU cycles each as possible. Hence my vision is for very simplified mechanics of flying - basically known ranges of speed, bank, climb etc for a given flight condition, and a bit of smoothing of transitions in between. Also only very near AI planes to the viewer to be updated every frame, the rest to be updated 1 per frame, and hence robust to variable times between updating. I'm pretty sure that not everyone agrees with that, and that some would go for coupled autopilot/fdms flying the planes as if they were another user-fidelity flight-model, but the simplified route is the one I started down. Then my basic structure is that an AI manager iterates through a list of AIEntity classes, and updates one per frame. The AIEntity has the minimum logic necessary to be drawn on the screen, and progressivly more complex classes are derived from it - for instance a plane that can taxi, then a light plane that can fly circuits could be derived from that and would already know how to taxi, and then a light plane that flys from one airport to another could be derived from that and would already know how to fly circuits and taxi. Having said all that, I've basically hardly started! I've got one hardwired AI plane in so far, that can be seen by starting FlightGear with: fgfs --airport-id=KEMT --prop:/sim/ai-traffic/enabled=true --prop:/radios/comm/frequencies/selected-mhz[0]=121.2 --heading=10 You do need to download the w120n30 scenery block as well. This will start you at El Monte behind a light single (no, NOT cheese!!!) that takes off, flys a circuit, and then taxis back to a parking spot. It's great fun to try following it round. You can make it fly touch and go's by changing line 54 in AIMgr.cxx: local_traffic-FlyCircuits(1, true); to a larger value than 1. The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. Anyway, the nub of the matter is that you can either join in with what's started, where the best separation of work is probably to go for planes that fly from one airport
Re: [Flightgear-devel] Dynamic Scenarios
[... Paul Morriss wrote ...] My proposal solution to the above questions are that we use shared memory or ethernet communications (user selectable), the main flight-gear app will not really contain the AI code, it will be done by the server, which updates lat, long, altitude, heading etc, this is sent to flight-gear that then does the displaying, sounds etc. The server (dynamic scenario) could then be used to manage plane routes, knowledge bases for the flight dynamics etc. This would support the idea of a general interface abstaction between FDM on one and the whole I/O stuff (keyboard, mouse, joystick, sound, screen) on the other end. This might fit for different purposes: 1.) Exchangeable FDM on local machine 2.) remote FDM with 'stupid' front-end 3.) multiplayer-server 4.) AI ... Paul's idea resembles me of the way X clients communicate with the server. Local clients prefer shared memory (at least on several commercial Unices, I believe it's the same on XFree86), remote clients use TCP/IP. I don't know how portable this could be ? 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
Fwd: Re: [Flightgear-devel] Dynamic Scenarios
I have created a portable ethernet library that supports both Linux and Windows, this would give us total portability, although you would have to watch out for big-endian conversion between Linux and Window. The second reason I am in support of an external server is that ai can start to eat processing time, specially if you have lots of stuff going on, where as if you are just sending an update message across the network you are keeping the logic out of the main code base. Also as Martin pointed out, this would also aid multi player support, as several flight-gear users can talk to the same scenario, thus they can fly around in unison. Ohh and I am in total support of well defined interface ;) Paul This would support the idea of a general interface abstaction between FDM on one and the whole I/O stuff (keyboard, mouse, joystick, sound, screen) on the other end. This might fit for different purposes: 1.) Exchangeable FDM on local machine 2.) remote FDM with 'stupid' front-end 3.) multiplayer-server 4.) AI ... Paul's idea resembles me of the way X clients communicate with the server. Local clients prefer shared memory (at least on several commercial Unices, I believe it's the same on XFree86), remote clients use TCP/IP. I don't know how portable this could be ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Fwd: Re: [Flightgear-devel] Dynamic Scenarios
Ohh and I am in total support of well defined interface ;) Curt will be happy ;-) 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
[Flightgear-devel] FlightGear vs. X/ Cygwin
Hi, I've been building FlightGear under Cygwin for quite a time now, and it works great. I know I had to completely remove X Windows from Cygwin for avoiding interference with FlightGear. I noticed problems included (at least) incompatible opengl libs being linked against in case of X windows being installed, but there may be more trouble hidden. Now with time there's a growing number of alternative (in my case TeX related) graphical programs requiring Cygwin's X server and X libs for building. I understand the fathers of FlightGear don't want to port Flight Gear to Cygwin's X port, which they may have good reason for. I certainly could donate another 1 GB to a second Cygwin tree, which is neither an elegant nor an effective solution, though. Thus, here's my simple question: Would it be hard to modify FlightGear's build system (i.e. the Cygwin part of it) to not link against Cygwin's X libs in case they are installed? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear vs. X/ Cygwin
Michael Basler writes: I've been building FlightGear under Cygwin for quite a time now, and it works great. I know I had to completely remove X Windows from Cygwin for avoiding interference with FlightGear. I noticed problems included (at least) incompatible opengl libs being linked against in case of X windows being installed, but there may be more trouble hidden. Now with time there's a growing number of alternative (in my case TeX related) graphical programs requiring Cygwin's X server and X libs for building. I understand the fathers of FlightGear don't want to port Flight Gear to Cygwin's X port, which they may have good reason for. I certainly could donate another 1 GB to a second Cygwin tree, which is neither an elegant nor an effective solution, though. Thus, here's my simple question: Would it be hard to modify FlightGear's build system (i.e. the Cygwin part of it) to not link against Cygwin's X libs in case they are installed? My understanding of the issue was that the Cygwin X11 included a version of opengl that was broken. If that's not the case, then someone needs to sit down and figure out what the issues are and then hopefully we can find solutions and build automatic detection into the configure.ac script. 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: Fwd: Re: [Flightgear-devel] Dynamic Scenarios
Paul Morriss writes: I have created a portable ethernet library that supports both Linux and Windows, this would give us total portability, although you would have to watch out for big-endian conversion between Linux and Window. Just so you know, plib also has a portable network library that works across, linux, windows, macos, sgi, etc. We have been using that with good success for many aspects of the FlightGear project. The second reason I am in support of an external server is that ai can start to eat processing time, specially if you have lots of stuff going on, where as if you are just sending an update message across the network you are keeping the logic out of the main code base. I think this makes a lot of sense. Also as Martin pointed out, this would also aid multi player support, as several flight-gear users can talk to the same scenario, thus they can fly around in unison. Ohh and I am in total support of well defined interface ;) (As long as I get to define it.) :-) :-) 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] FlightGear vs. X/ Cygwin
Michael Basler writes: Thus, here's my simple question: Would it be hard to modify FlightGear's build system (i.e. the Cygwin part of it) to not link against Cygwin's X libs in case they are installed? Michael I do not have Cygwin's X installed and I doubt if I ever will so I can not test any changes to the configure system to allow FGFS to work in a Cygwin X enviroment , but see this message for a WAG http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-November/013469.htm l Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenarios
Martin Spott writes: This would support the idea of a general interface abstaction between FDM on one and the whole I/O stuff (keyboard, mouse, joystick, sound, screen) on the other end. This might fit for different purposes: 1.) Exchangeable FDM on local machine 2.) remote FDM with 'stupid' front-end 3.) multiplayer-server 4.) AI ... Paul's idea resembles me of the way X clients communicate with the server. Local clients prefer shared memory (at least on several commercial Unices, I believe it's the same on XFree86), remote clients use TCP/IP. I don't know how portable this could be ? The ExternalNet FDM is a reasonable first stab at a generalized remote FDM interface. FlightGear can send over initial condition and reset commands, and the remote FDM passes data back. There's certainly a lot of room for improvements and extensions, but it does work. 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] Dynamic Scenario's
Paul Morriss writes: Hi all, I am new to Flight Gear, but not to flight simulation, thats my line of business ;) Anyway I would like to propose (and develop) a server or system that can be used to manage the environment. What I mean is that the scenario system manages: * Other plans in the air, these can add the reality of busy airspace near large airports. * Weather system controlled through scenarios, this would include clouds, rain etc... * Ground vehicles movement (aircraft ready to taxi for takeoff etc. I would be really intrested in your comments Paul, This sounds all too reasonable. :-) What we need is to build up a bit of infrastruture in FlightGear to maintain a list of objects, (positions, orientations, animation states, etc.) and then be able to render them. The object states could be updated internally or remotely depending on the situation. If they were tied to the property tree this would give us a lot of flexibility for interfacing, scripting, etc. The interfaces and infrastructure should already be there for an external weather module. All the weather elements are tied to the property tree, so an external module would just need to change property values to accomplish real time weather changes. 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] FlightGear vs. X/ Cygwin
Curtis L. Olson writes: My understanding of the issue was that the Cygwin X11 included a version of opengl that was broken. If that's not the case, then someone needs to sit down and figure out what the issues are and then hopefully we can find solutions and build automatic detection into the configure.ac script. AFAIK Cygwin XFree OpenGL is based on an unaccelerated MESA installation However AFAIK you are not forced to use XFree even if installed and running so this should not be an issue. The problem is that the FGFS configure scripts make assumptions which force using X if it finds an X installation which is not necessarily what is desired for a Cygwin FGFS. see my WAG in previous message Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear vs. X/ Cygwin
Norman, I do not have Cygwin's X installed and I doubt if I ever will so I can not test any changes to the configure system to allow FGFS to work in a Cygwin X enviroment , but see this message for a WAG http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-November/013469.htm l I vaguely remember there was a discussian and that message... Obviously not much came out of it at that time. Actually, the number of apps ported to Cygwin/X seems to grow recently (e.g., Lyx and Texmacs, only to name two TeX related programs which I'd need), now that the Cygwin X server seems to be more or less stable. Certainly, this is not an urgent problem, but one which has to be dealt with at one point, IMHO. My understanding of the build system is not sufficient to modify the scripts myself, but I'd be gladly help testing if anyone will step forward with this. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear vs. X/ Cygwin
Michael Basler wrote: Hi, I've been building FlightGear under Cygwin for quite a time now, and it works great. I know I had to completely remove X Windows from Cygwin for avoiding interference with FlightGear. I noticed problems included (at least) incompatible opengl libs being linked against in case of X windows being installed, but there may be more trouble hidden. Now with time there's a growing number of alternative (in my case TeX related) graphical programs requiring Cygwin's X server and X libs for building. I understand the fathers of FlightGear don't want to port Flight Gear to Cygwin's X port, which they may have good reason for. I certainly could donate another 1 GB to a second Cygwin tree, which is neither an elegant nor an effective solution, though. Thus, here's my simple question: Would it be hard to modify FlightGear's build system (i.e. the Cygwin part of it) to not link against Cygwin's X libs in case they are installed? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hello, As a lurker, I can't explain why things (mis)behave, but here is an observation or two. Of the 3 systems here that I build FlightGear on, all are following the latest CVS. Two are under Cygwin, and 1 on a linux system. One Cygwin system has the X packages installed, and run once or twice to verify it works. Since (very roughly) 6 weeks ago, it has been building (and running) without problems. That includes plib, SimGear, and FlightGear. A few months earlier I pulled a lot of hair getting the build working, with SimGear giving the most trouble. One thing that helped was the --without-x option to configure in all packages. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear vs. X/ Cygwin
William, all are following the latest CVS. Two are under Cygwin, and 1 on a linux system. One Cygwin system has the X packages installed, and run once or twice to verify it works. Since (very roughly) 6 weeks ago, it has been building (and running) without problems. That includes plib, SimGear, and FlightGear. A few months earlier I pulled a lot of hair getting the build working, with SimGear giving the most trouble. One thing that helped was the --without-x option to configure in all packages. I already thought about a clean install of a very recent Cygwin with GC 3.2 (the hassle is I'll have to rearrange and rebuild anything, obviously). Maybe I'll include X then and try to build all FG related stuff --without-x. Thanks for the hint. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Turbulence redux
I've made some minor adjustments to the turbulence support for JSBSim in FlightGear: 1. The /environment/turbulence-norm property for JSBSim is now squared before scaling; that way, the hard stuff doesn't hit until fairly late, and more of the range is flyable (I think it's more intuitive). 2. Turbulence does a linear fade-out within two wingspans of the ground. The second item is there merely to annoy Jon into implementing something more realistic. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
David Megginson wrote: 2. Turbulence does a linear fade-out within two wingspans of the ground. The second item is there merely to annoy Jon into implementing something more realistic. Actually, that sounds pretty good to me. Doing realistic turbulence models near the ground is essentially impossible, for all the same reasons that doing realtime fluid dynamics doesn't work. The only augmentation I can think about is that you might consider fading out only the turbulence component perpendicular to the ground. Horizontal turbulence (wind gusts) can and does happen in reality. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
David Megginson wrote: As long as I have you on the line, Andy, how hard would it be for you to adapt the FGAtmosphere::Turbulence() function (in src/FDM/JSBSim/FGAtmosphere.cpp) for YASim? It looks like it should be fairly clean. You would take the per-iteration turbulence vector and add it to the wind at setup time. This happens in YASim.cxx, lines 235-237. Just move the turbulence value to somewhere accessible from the YASim FDM object (properties or whatnot) and add it in. The value gets converted into YASim's internal coordinate system later on; this part is in NED coordinates and should accept Jon's output without change (well, units might need twiddling). Really the only significant code that would have to be written is a patch to get FGAtmosphere::Turbulence() to export the velocity vector. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
Andy Ross writes: As long as I have you on the line, Andy, how hard would it be for you to adapt the FGAtmosphere::Turbulence() function (in src/FDM/JSBSim/FGAtmosphere.cpp) for YASim? It looks like it should be fairly clean. You would take the per-iteration turbulence vector and add it to the wind at setup time. This happens in YASim.cxx, lines 235-237. Just move the turbulence value to somewhere accessible from the YASim FDM object (properties or whatnot) and add it in. The value gets converted into YASim's internal coordinate system later on; this part is in NED coordinates and should accept Jon's output without change (well, units might need twiddling). Really the only significant code that would have to be written is a patch to get FGAtmosphere::Turbulence() to export the velocity vector. I meant to integrate it by cut and paste. FGAtmosphere is a JSBSim class, so it won't run when YASim is the current FDM. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
On Wed, 12 Feb 2003 14:24:29 -0500
David Megginson [EMAIL PROTECTED] wrote:
Sounds good -- I was hoping to provoke Jon into doing something like
that. Note that we do also model horizonal wind gusts (of longer
duration) through FGEnvironment.
Here is what's in Turbulence(), now:
--- start ---
vDirectiondAccelDt(eX) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
vDirectiondAccelDt(eY) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
vDirectiondAccelDt(eZ) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
MagnitudedAccelDt = 1 -
2.0*(((double)(rand()))/RAND_MAX);
MagnitudeAccel+=
MagnitudedAccelDt*rate*State-Getdt();
Magnitude +=
MagnitudeAccel*rate*State-Getdt();
vDirectiondAccelDt.Normalize();
vDirectionAccel +=
vDirectiondAccelDt*rate*State-Getdt();
vDirectionAccel.Normalize();
vDirection +=
vDirectionAccel*rate*State-Getdt();
vDirection.Normalize();
vTurbulence = TurbGain*Magnitude * vDirection;
vTurbulenceGrad = TurbGain*MagnitudeAccel *
vDirection;
--- end ---
I think this is what should be done to make the turbulence
account for ground proximity:
vDirectiondAccelDt(eX) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
vDirectiondAccelDt(eY) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
vDirectiondAccelDt(eZ) = 1 -
2.0*(((double)(rand()))/RAND_MAX);
MagnitudedAccelDt = 1 -
2.0*(((double)(rand()))/RAND_MAX);
MagnitudeAccel+=
MagnitudedAccelDt*rate*State-Getdt();
Magnitude +=
MagnitudeAccel*rate*State-Getdt();
vDirectiondAccelDt.Normalize();
vDirectionAccel +=
vDirectiondAccelDt*rate*State-Getdt();
vDirectionAccel.Normalize();
vDirection +=
vDirectionAccel*rate*State-Getdt();
// new stuff here:
if (altitude GroundProximityAltitude) {
vDirection(eZ) *=
(altitude/GroundProximityAltitude);
}
/// end new stuff
vDirection.Normalize();
vTurbulence = TurbGain*Magnitude * vDirection;
vTurbulenceGrad = TurbGain*MagnitudeAccel *
vDirection;
--- end ---
It's easy and worth a try. Mind you, this is a really
off-the-cuff quick-and-dirty stab. There may be a far
better way to do it. I haven't looked at the turbulence
code in some time.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup error GLXBadRenderRequest
Rick wrote: Hi, I put the following message on the users mailing list and it doesn't seem that anyone there can help. Can anyone here give any insight? The 3D demos all work and I'm running Mandrake 9.0 with a NVIDIA GeForce4 Ti 4200. FlightGear-0.9.1 Finally got FG to complie, but when I try to start it, I get the following message. This is after it sets up the default airplane(C172) and airport(KSFO). Any ideas? Take a look at this NVidea FAQ: http://www.mcdownloads.com/old/do_q.php?q_id=20 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenarios
I have created a portable ethernet library that supports both Linux and Windows, this would give us total portability. The second reason I am in support of an external server is that ai can start to eat processing time, specially if you have lots of stuff going on, where as if you are just sending an update message across the network you are keeping the logic out of the main code base. Also as Martin pointed out, this would also aid multi-player support, as several flight-gear users can talk to the same scenario, thus they can fly around in unison. Ohh and I am in total support of well defined interface ;) Paul This would support the idea of a general interface abstaction between FDM on one and the whole I/O stuff (keyboard, mouse, joystick, sound, screen) on the other end. This might fit for different purposes: 1.) Exchangeable FDM on local machine 2.) remote FDM with 'stupid' front-end 3.) multiplayer-server 4.) AI ... Paul's idea resembles me of the way X clients communicate with the server. Local clients prefer shared memory (at least on several commercial Unices, I believe it's the same on XFree86), remote clients use TCP/IP. I don't know how portable this could be ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
Jon S Berndt writes: Here is what's in Turbulence(), now: Well, two CVS checkins ago, anyway. I've integrated your change into the current code base, but still (for now) basing it on HOverBMAC (as used for ground effect) rather than absolute altitude AGL. It seems to work well -- thanks. Jon: check out the latest FlightGear and play with the turbulence at bit -- there a slider to adjust it in the dialog linked to the Weather/Winds menu entry. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate Symbols in FGTurbine?
I did a make distclean; autogen.sh; ./configure; make and I still have the problem. I'm not too worried since I am using the UFO FDM and it does not prevent me from getting an executable. It is odd that the problem even showed up, but we'll see. Maybe Apple will upgrade their developer tools to gcc 3.2 on the next release. Thanks for the help, Jonathan Polley On Monday, February 10, 2003, at 09:39 PM, Norman Vine wrote: Jonathan Polley writes: It beats me. I did a make clean and make distclean and both yielded the same results as before. The current development tools contain gcc 3.1. Is anyone else running that version of gcc, or has everyone jumped to 3.2? Hmm... You could try deleting the JSBSim directory then try the desparate man's approach % cvs up % autogen.sh; ./configure; make if that doesn't work then you have got me stumped too Norman ___ 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
