Re: [Flightgear-devel] latest AI tricks
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Saturday, November 29, 2003 7:32 AM Subject: Re: [Flightgear-devel] latest AI tricks Can't wait for you guys to add the AI for a Blue Angels routine. :-) Maybe someday. The present AIAircraft fdm won't do it though. It only handles normal maneuvers, like normal climbs, descents and turns. Would just about need a full FDM to pull that off, with the AI manipulating the stick and pedals directly.. something I talked about as a possibility for my script engine to accomplish. I'm using David's AIAircraft (as I believe Eric is for the Nasal interface), but a full FDM could be interfaced if needed :) Just a little more work and my PSL+EventHandling system will be ready for testing, possibly by mid week :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest cvs build error ??
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 28, 2003 12:09 PM Subject: Re: [Flightgear-devel] Latest cvs build error ?? John Barrett wrote: radiostack.cxx: In member function `virtual void FGRadioStack::init()': radiostack.cxx:81: error: `addTask' undeclared (first use this function) You need to update your SimGear. The SGEventManager API changed a little bit recently, and radiostack.cxx was updated along with it. That got it. Thanks !! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Latest cvs build error ??
just tried building latest cvs and got the following error: make[3]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/src/Cockpit' if ++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X 11R6/include -g -O2 -MT radiostack.o -MD -MP -MF .deps/radiostack.Tpo \ -c -o radiostack.o `test -f 'radiostack.cxx' || echo './'`radiostack.cxx; \ then mv -f .deps/radiostack.Tpo .deps/radiostack.Po; \ else rm -f .deps/radiostack.Tpo; exit 1; \ fi radiostack.cxx: In member function `virtual void FGRadioStack::init()': radiostack.cxx:81: error: `addTask' undeclared (first use this function) anyone else getting this one ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: AI merge
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 6:00 PM Subject: Re: [Flightgear-devel] Re: AI merge On 11/18/03 at 12:51 AM John Barrett wrote: Dont go too fast :) No chance of that - busy decorating the kids room, real work is spilling over into the evenings, and I've a sudden urge to hack at a taxiway editor! I'm working on my aiScript engine while I'm stuck in this hotel room house hunting Good luck, and make sure you buy one already decorated, or your coding time really will go down the tube! and dont have access to my other machines for working on my network code I should have the prototype engine up and running on top of PSL in a few days (I've parked the JS code for the time being, permanently if I can get a couple of new features added to PSL) FlightGear - an experiment to determine if an infinite number of monkeys typing at an infinite number of computers can produce an infinitely complex AI system ;-)) Thats my goal... infinite complexity through modular stucture :) Which brings up another issue... I'm I'm having a problem tracking down in aiPlane where everything happens so I can hook in and have my script engine drive the plane... want to work together to do a new version of aiPlane that will hook in with aiScript ?? For aiPlane, I guess I would need hooks for throttle, airspeed, turning the plane, position, etc... need to figure out an abstracted plane that the script can control, and the plane implementation will carry out a simple set of commands (turn, climb, dive, etc... would need to decide what level of abstraction we want to interface at) It occurred to me what a server would be *really* useful for the other day - load it up with full US airline timetables, and it should be able to generate approximately the right traffic at any portion of any airway or airport, with a bit of a random delay factor thrown in, and remove them when out of user range. I wonder if anyone has already compiled full airline timetable data in a freely available, digital form? I was actually lookin at that some today -- AirNav Systems will make the data available to you for $250 a month -- tell me where they source their data from and maybe we can sneak around them :) They have a nice semi-realtime ASD app that feeds off of FAA and other aircraft position reports Was thinking about doing a scenario that would have all the planes on that feed displayed using a multi-plane client to feed the server with data for all the active planes -- they have schedule and terminal/gate info available also -- would be better than just the schedules as this data would be actual traffic in real time ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cygwin js-server build error
make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: John Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:47 AM Subject: [Flightgear-devel] cygwin js-server build error make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: John Barrett [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 11:01 AM Subject: Re: [Flightgear-devel] cygwin js-server build error - Original Message - From: John Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 10:47 AM Subject: [Flightgear-devel] cygwin js-server build error make[2]: Entering directory `/cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/source/utils/js_server' g++ -g -O2 -L/usr/X11R6/lib -o js_server.exe js_server.o -lplibjs -lplibnet -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366): In function `_ZN10jsJoystick4openEv': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 99: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4): In function `_ZN10jsJoystick7rawReadEPiPf': /cygdrive/c/Documents and Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/plib/src/js/jsWindows.cxx: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am same change needed for 3dconvert ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin js-server build error
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 12:53 PM Subject: Re: [Flightgear-devel] cygwin js-server build error John Barrett wrote: 180: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [js_server.exe] Error 1 is there another lib that needs to be linked on cygwin to get this to compile ?? Forget that question -- needed $(audio_LIBS) added to js_server_LDADD in utils/js_server/Makefile.am same change needed for 3dconvert Odd. Anyhow, it's added to CVS. They both needed the windows multimedia library, and that was listed in $(audio_LIBS) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] automake question
I've got some code from another project that I'm trying to hook into FG... it uses a short compiled program to generate a header file used by the rest of the package... I've added the program to Makefile.am, and it builds, now, how do I get that program to execute before the library that depends on the header is compiled ?? (library code in the same folder and same Makefile.am as the header generator program) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] automake question
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 14, 2003 5:07 PM Subject: Re: [Flightgear-devel] automake question John Barrett writes: I've got some code from another project that I'm trying to hook into FG... it uses a short compiled program to generate a header file used by the rest of the package... I've added the program to Makefile.am, and it builds, now, how do I get that program to execute before the library that depends on the header is compiled ?? (library code in the same folder and same Makefile.am as the header generator program) This is starting to get into some tricky automake/autoconf voodoo if you want to run compiled programs in the middle of the build. Also consider that this could hose anyone who might want to cross compile. I don't know anyone who does, but last time I tried the win32 cross compiler on linux, it ran about 10x faster than natively on windows on the same hardware. That was years ago though and I'm sure cygwin has drastically improved it's performance on windows in the mean time. Anyway, this sort of stuff can really up the complexity of the build system so I'd *really* like to avoid it if at all possible. That said, the autoconf configure script works by generating little programs and executing them (or at least testing if they can be compiled, linked, etc.) So it might be possible to work something into the configure script if it was simple enough ... not that I'm excited about the idea ... Is there anyway you can restructure things to avoid needing to do this? Yes I could, later on... I'm integrating the SpiderMonkey JS engine and it uses this small program to detect compiler/cpu specific things, so I presume its pretty portable in and of itself ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 5:18 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) I not trying to put you off - I welcome all efforts in this area. I'm a believer in starting simple and getting some code out there though. Personally, for a first iteration of a multiplayer server, I'd turn the ATC and AI off in all the clients, and just get to the point where several of us could connect to the server, fly together at one airport without starting on top of each other, and possibly exchange messages. Once we can actually fly together on it, it'll seem much more tangible. Good luck! Cheers - Dave The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend -- there is a uhaul in front of my apartment stacked to the ceiling with stuff and we still got loading yet to do today :) Is there anything in the airport datasets that tells where the ends of the runways are ?? and perhaps where the taxiways leading up to the runway are so I can have the server stack up planes waiting for takeoff when they connect to the server ?? Putting me off is not possible :) I think I got this AI engine idea wired at the engine level -- and there is no reason that at the lowest level, the scripting language can't directly maniplulate the elevators/ailerons/rudder/flaps/etc just like the kb/stick controls do. Just means a larger core library of procedures needs to be created -- doesnt matter to me if those procedures are hard-coded (a.k.a autopilot c++ code) or scripted (directly drive the fdm like the kb/stick controls) -- just need to decide which one is the best for the initial implementation :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Jon Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:33 AM Subject: RE: [Flightgear-devel] ACScript RFC (or FGScript ??) The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend Good move. :-) ;-) Where in Texas? Jon (Houston) Plano -- just north of dallas :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 11:48 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
I would like to request your ideas and wishes for an aircraft AI
scripting
language sufficiently generic in scope to handle piloting any aircraft
running on FG.
My generalized AI airplanes were originally going to be defined in
preferences.xml (like the ai-tanker), something like this for each
instance
desired:
ai-plane
typeprop-transport/type
modelAircraft/DC6/Models/DC6-model.xml/model
start-time2.00/start-time
scriptScripts/ai_script01.xml/script
/ai-plane
The above would instantiate the plane (or truck, boat), assign it a visual
model, indicate how many minutes into the sim session it should appear,
and
indicate the path to this object's script. The script would look like:
script
entry
on
typeelapsed-time/type
value0.50/value
/on
lat35.35628/lat
lon125.573899/lon
elev369.5/elev
heading350.0/heading
/entry
entry
on
typemessage/type
valuetakeoff-you-hoser/value
/on
task
typetakeoff/type
altitude5000.0/altitude
/task
/entry
... and so forth.
The waypoints could be triggered by elapsed time, UTC time, reaching a
waypoint, or message. The details of the takeoff would be handled by the
FDM, knowing what speeds and climb rate are suitable for a
prop-transport.
Dave
--
David Culp
davidculp2[at]comcast.net
Ok -- all you have done is state that takeoff is a procedure to be followed
without defining the procedure (i.e. its hard coded and there is no
variation from that procedure)
procedure takeoff(heading, target_altitude) {
ground=altitude;
throttle=90;
brakes=off;
flaps=15;
on (speed = 140) {
elevators = 20; // pull back on the stick
}
on (alititude ground+50) {
gear=up; // if the plane has retractable gear
}
on (alititude ground+100) {
turnto(heading); // nested procedure, does its actions and
events
// note -- that events are stacked -- any events defined here
are
// still active unless overridden by the nested procedure. When
the
// nested procedure completes, overridden events take effect
again
// also note that since this is in an event check, it gets
checked every
// update loop to maintain the heading
}
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
on (altitude == target_altitude) {
levelplane(target_altitude); // yet another scritped procedure
return;
}
}
}
I'm sure there are further refinements that could be made, but you get the
general idea :)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 8:45 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
on (speed = 140) {
elevators = 20; // pull back on the stick
}
should have been:
on (speed == 140 altitude=ground) {
elevators = 20; // pull back on the stick
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --preliminary
- Original Message - From: Gerhard Wesp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:29 AM Subject: Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --preliminary Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Is there any specific reason not to use human readable messages (i.e., ASCII)? bandwidth and performance I could understand human readable for a limited system, but not for a setup that could potentially be handling 100s of planes, and while for GA sims, it may not be needed, I have a little more than that in mind :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) Actually, I don't see a need for the AI airplanes to have brakes, elevators, flaps and such. Our visions of AI traffic are much different. Dave -- David Culp davidculp2[at]comcast.net Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. Equally, the script engine output could be taken at a level where there is no FDM to control, for instance the AIPlane class, simply by defining hard coded procedures for that specific interface that override the low level FDM interface, and registering them with the script engine before starting a script. (thats getting complicated, but its much more possible if I know up front that I need to handle multiple aircraft interfaces) Hmmm -- that actually answers the problem I was trying to solve -- the class that interfaces the script engine to a specific aircraft class must define what low level is for the engine by registering the appropriate procedures to control the aircraft, the FDM interface would register routines to control elevators/ailerons/rudder/etc. The AIPlane interface would register turnto(heading) and other more abstract procedures, incidentally cutting out all the lower level scripting designed to control a plane via FDM. Therefore low level control procedures need to be defined in layers so that implementors can pick where to hook in, and have a well defined list of procedures that must be implemented to hook in at that level. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:15 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. I'm jumping into the middle of this conversation, but let me make a few comments. I envision a model where a single client computer will be responsible only for the location of it's single interactive aircraft. It sends it's the information about it's single aircraft to the server. From a multi-player standpoint. Any additional AI aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc. And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity. I dont see the AIplanes being used on an FG instance running a user plane all that often, but it may happen if a user is running a small server for a simple scenario and a few friends I think step #1 should be to get the client/server stuff working without worrying about any AI aircraft at all. Let's get the communication going so people can fly together. I'm almost there except that I'm packing to move -- I just wanted to talk ahead so I would know where I was going next and make sure the protocol was up to handling the planned usage scenarios Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side. A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled. I think this should be kept separate from any system where FlightGear populates it's own world with AI aircraft. I think that should get completely turned off when the multiplayer stuff is activated. I think it can all work together with minimal problems based on what I have gleaned from the code so far -- its a question of how the server scales up from a few buddies flying with no or few AI planes, up to 100s of flyers talking to a server managing 100s if not 1000s of human and AI driven aircraft. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:29 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote:
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:24 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
[Dave's message]
--
[- Dave's Signature]
David Culp
davidculp2[at]comcast.net
[John's message]
John, your email is malformed. :)
You include the original text inline, rather than quoted (prefixed by
some combination of and whitespace). It looks like you are
clicking forward rather than reply to compose your mail. This
might seem like a meaningless nit, but it actually causes problems.
some of my messages get the indents, some dont -- I dont know why
In this case, the line containing -- above is interpreted by my mail
reader (Mozilla) as the beginning of a signature, which get colorized
differently than the rest of the mail. There is nothing to tell the
reader where the .sig ends and where your message begins, so your
message ends up a dull, hard-to-read gray. Even worse, Mozilla
helpfully *removes* the signature (and therefore all of your text!)
when it quotes the mail into an editor buffer for a reply.
My apologies. I've never had a mail reader that messed with the message
content in that way, nor heard of one that did before today
Believe it or not, this stuff is actually specified in various RFCs.
Microsoft has a horrific record of compliance with those standards, of
course, but nonetheless I *have* seen correctly formatted quotes
emerge from Outlook Express users. :)
Like this message did it right, but sometimes it doesnt and I dont know why.
Sometime I even insert the indents by hand (when I notice it)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:46 AM Subject: [Flightgear-devel] ACScript RFC (or FGScript ??) [Starting a new thread. John's reply was burried in the parent thread] John Barret wrote: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. There is some support already in place for using Plib's psl language in FlightGear; it's a sane minilanguage with C-like syntax and semantics (basic types and functions, basically; no pointers, structs or arrays). It talks to the rest of FlightGear through the property tree. You will want to investigate this first; I haven't tried it yet. I dont know if you caught the post where I gen'd up a simple procedure to give some idea of the action/event structure that I would like the language syntax to describe. Everything is basically off of FDM variables and simple commands to the plane. I would need to get much deeper into PSL to see if it could be used as the core of a scripting engine that could handle nested/stacked event handlers. The C like syntax is a definite plus, but I'm trying to hide the details of the event management logic from the AI designers. Let them concentrate on flying the plane and not worrying about how to implement state/event code. I'd caution against a special-purpose language; these things are almost always just as hard to write as real languages are, and never quite do as much as you hoped. I'd stick with a general purpose language, whatever you do. I'd like all the basic features of C, but with the event extensions, A procedure should be nothing but a script that sets up the preconditions for the procedure and a set of event handlers that do the routine adjustments required until the termination event for the procedure occurs. Event handlers are sub-scripts that execute when certain conditions are met, and the conditions are tested every update() call to the engine. A procedure can use a nested procedure with its own setup and events that stack on top of the callers events. And lastly, when a nested procedure is called, the engine should check if there is already an instance of that procedure running, and if so, do nothing. (this can be determined by checking for any entries on the event stack that are tagged as belonging to the named procedure) And now the plug. :) I wrote a scripting language of my own at one point (http://www.plausible.org/nasal) which is closer to Perl or Javascript. It's semantically richer than PSL, supporting all the stuff you expect like vectors, hashes/objects, garbage collection, et. al. It's also quite small; a little over 100k of source code these days. No work has been done to integrate it into FlightGear/SimGear (I wrote it for my own game project last spring), but I'd be happy to do so if there was interest. If I'm going to use some other scripting engine as a basis to reduce development time, I'm equally open to your language or PSL as the language core, so long as some way can be found to graft on the event handler model outlined above :) The only requirement I would have for using an existing script engine as a core would be the ability to map script variables to C++ variables. The interface class that ties the engine to a specific aircraft class would be responsible for setting up those mappings, as well as registering any hard-coded procedures specific to that aircraft interface. Languages are like religions though. Some people are going to hate the idea, some people are going to like it except for one or two things that *have* to be fixed first, some will want to use a different language. No one seems to want to use PSL yet, though, so it seems to me like the door is still open for alternatives. :) And thats exactly where I'm at -- C/PSL is nice, but there are these darn features that I dont feel that I can live without :) Based on my experience working with the TCL and JS engines in other projects, what I want should not be horribly difficult to graft on to an existing engine. All that is required is the addition of a few new statements (procedure, on(event), and endproc) and the low level code to handle what they do, and the creation of an update_events() method to process the event tree. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 1:19 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 2:12 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) The AI already in place is little used because it's tied to one airport and needs some generalizing. I'm looking forward to network flying, including network AI, but I hope development of local machine AI continues, and that it's not superceded by network AI. Thats why I'm approaching an AI/Scripting language the way I am. So it is useful for both net and local usage, and why I'm not so interested in doing a stand-alone server only implementation, but rather tying into the existing aircraft modeling system (wether that is the FDM or AIPlane model, or both most likely). There are far too many usage scenarios to sharply delimit what is client and what is server in my opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 3:34 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. These are the sorts of things you might want/need if you are not connected to a MMP server ... as I understand it, the current focus of everything in the src/ATC/ directory is a stand alone fictitious environment not connected to any MP server. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) I suppose we can divide the work up and draw the line any place we like. But my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.% of the time in civilian aviation, you should never get that close to an airplane. Regards, Curt. I'll ask again -- why by default, why not under control of a loaded scenario which defines the planes and patterns -- then having ai planes is a question of did I load a scenario, even a generic one that states for any airport, when a plane gets close, spawn 3 planes doing touch-n-go circuits ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Multiplayer] Oh where Oh where .......
I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? (if its just the one plane, once I get it to fly multiplayer, my focus will be to add multiple/AI plane support to the code, so comments towards achieving that goal will be welcome also) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 4:22 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... Erik Hofman wrote: John Barrett wrote: I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? For the MultiPlayer module this is handled in the MPPlayer class located in FlightGear/src/MultiPlayer/mplayer.[ch]xx It just occurs to me, you want simulated aircraft (with each have it's own FDM) instead of updating the portion every frame don't you? I thank that needs a bit more thought. Most FDM's are just too heavy for having a lot of them work together. I think we need a NULL FDM with autopilot support for that. right -- I'll be stealing some code out of the src/Multiplayer re: handling displaying remote aircraft -- just worried about multiple a/c w/fdm running locally :) You'll recall I mentioned the --headless option. Doing multiple FDM would be much more reasonable if there were no OpenGL display at all -- still -- for single player or small groups -- a fast machine should be able to handle the display and say 2-4 AI planes (or at least I would hope that could be achieved) In any case -- that simplifies and complicates things a bit -- but at least I know what to do next :) when you say null fdm + autopilot -- it doenst appear the null FDM is a plane at all - wouldnt it make more sense to use the full FDM code with scripting to drive the existing autopilot code ?? i.e. script sets desired altitude, heading, speed, limits on pitch yaw roll rate of descent, etc allowed during manuevers, updates the desired settings in realtime based on positions of other planes and/or radio message traffic -- autopilot caries out those instructions -- isolates the AI from the actual complexities of controlling the aircraft ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: John Barrett [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 8:50 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... - Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 4:22 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... Erik Hofman wrote: John Barrett wrote: I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? For the MultiPlayer module this is handled in the MPPlayer class located in FlightGear/src/MultiPlayer/mplayer.[ch]xx It just occurs to me, you want simulated aircraft (with each have it's own FDM) instead of updating the portion every frame don't you? I thank that needs a bit more thought. Most FDM's are just too heavy for having a lot of them work together. I think we need a NULL FDM with autopilot support for that. right -- I'll be stealing some code out of the src/Multiplayer re: handling displaying remote aircraft -- just worried about multiple a/c w/fdm running locally :) You'll recall I mentioned the --headless option. Doing multiple FDM would be much more reasonable if there were no OpenGL display at all -- still -- for single player or small groups -- a fast machine should be able to handle the display and say 2-4 AI planes (or at least I would hope that could be achieved) In any case -- that simplifies and complicates things a bit -- but at least I know what to do next :) when you say null fdm + autopilot -- it doenst appear the null FDM is a plane at all - wouldnt it make more sense to use the full FDM code with scripting to drive the existing autopilot code ?? i.e. script sets desired altitude, heading, speed, limits on pitch yaw roll rate of descent, etc allowed during manuevers, updates the desired settings in realtime based on positions of other planes and/or radio message traffic -- autopilot caries out those instructions -- isolates the AI from the actual complexities of controlling the aircraft I was just poking through the code and want to confirm something -- everything appears to be working off of globals ?? there isnt an airplane object that coordinates all the fdm/opengl/autopilot functionality that can be instanced at need, and multiple instances created if neccessary ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 10:48 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... (if its just the one plane, once I get it to fly multiplayer, my focus will be to add multiple/AI plane support to the code, so comments towards achieving that goal will be welcome also) I think it would make sense to have the server handle any non-human controlled vehicles. It would keep the load off the client which already has its hands full doing a full systems simulation as well as doing graphics work. What I'm driving at here is having a headless client that does multiple fdm/autopilot sims on behalf of a server which may itself be handling several planes in addition to the net connections -- no graphics at all -- though a side effect will be to have a user controled plane + one or more AI planes -- it may not get used that way -- but someone might what I'm asking is everything looks like it works through globals rather than discrete instances of aircraft+fdm+autopilot -- am I looking at a serious architectural change to get multiple independent ac+fdm+ap simulated concurrently ?? wether or not the discrete aircraft code gets used in a single user, or server only environment isnt relevant :) how much work am I looking at to make it happen :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 7:51 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
In the current code -- there is just the single airplane being simulated
on
the display ?? or where could I find a list/array of a/c that are being
managed so I can register each plane with the server and have the server
relay updates for all of them ??
Look in the src/ATC directory. There you will find an FGAIMgr class that
instantiates aircraft. The aircraft themselves are derived from FGAIEntity
via FGAIPlane. Presently the only AI airplane in the base package is a
cessna flying out of KEMT (in the Los Angeles basin).
(if its just the one plane, once I get it to fly multiplayer, my focus
will
be to add multiple/AI plane support to the code, so comments towards
achieving that goal will be welcome also)
You can add more AI aircraft to the FGAIMgr's list:
// Activate AI traffic at an airport
void FGAIMgr::ActivateAirport(string ident) {
ATC-AIRegisterAirport(ident);
// TODO - need to start the traffic more randomly
FGAILocalTraffic* local_traffic = new FGAILocalTraffic;
//local_traffic-Init(ident, IN_PATTERN, TAKEOFF_ROLL);
local_traffic-Init(ident);
local_traffic-FlyCircuits(1, true); // Fly 2 circuits with touch go in
between
FGAITanker* tanker = new FGAITanker;
tanker-Init();
ai_list.push_back(local_traffic);
ai_list.push_back(tanker);
activated[ident] = 1;
}
Here I've added another AI plane, a KC-135 called FGAITanker, that orbits
over
the LA basin. Presently the AI traffic's FDM is contained within the class
derived from FGAIPLane. So the Cessna and the tanker use entirely different
FDMs. A more generalized approach would be to move the FDM into FGAIPlane.
I started working on a generalized and scriptable version of my tanker, but
have been sidetracked by other stuff. Let me know if you want the tanker
code and I'll send it to you.
Dave
--
David Culp
davidculp2[at]comcast.net
Sounds good -- like most of what I'm looking for is there -- would definitly
like to look over the code and see how much work to hook it into my network
setup
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 8:20 PM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... On 11/12/03 at 8:08 PM John Barrett wrote: Sounds good -- like most of what I'm looking for is there -- would definitly like to look over the code and see how much work to hook it into my network setup Sorry - I thought you were looking for an fdm-autopilot based solution, else I'd have mentioned this! It would actually be very useful for the AI logic development if Atlas could then work as a client and display all the traffic. Could be the basis of the human ATC station as well, by adding altitude labels to the display in Atlas. Cheers - Dave Yes I would prefer an ac+fdm+autopilot solution strictly for realism purposes -- but anything that instances planes controled by FG needs to be hooked into my network code so that ac status updates can be made visible to all other participants. AIPlane definitly meets some of my needs based on the descriptions and a quick peek at the code. The main area where AIPlane falls short IMO is the hard coded AI functionality -- so here we go: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. I can see right off that it must be event driven, able to interupt its current procedure/task in response to external inputs, able to process complicated nested procedures with completion of a statement based on the current aircraft state or external inputs such as radio message or radar. It must span every level of interaction from turn the plane to a specific heading or change altitude to a specified level at the low end, up to extremely abstract commands like fly the plane to to a specified airport and land which would encompass all the procedures and interactions neccessary to take off from one airport and land at another, including all standard interactions with ATC and other planes along the way. At the bottom end, the script module should generate commands suitable to feed to an autopilot, AIPlane or, if desirable, directly to the plane being simulated (I havent looked at how kb/stick inputs interface to the simulation - do they feed into the fdm ??) -- this may end up requiring multiple output interfaces for the scripting engine. The reason I was looking at ac+fdm+ap is the autopilot provided out-of-the-box low level code to manuever the plane without the AI code needing to know the specifics of how to make the plane perform a given manuever. Adding low level capabilities to the autopilot would the expand the range of capabilities for the AI scripts. (think of the autopilot as the hardcoded manuevers that form the core of the AI language -- anything more complicated than that would be handled by scripted AI procedures based on the core manuevers) Another thought just hit me -- the engine will have to handle the idea that different planes may have different low level routines, for instance, how you setup and perform a takeoff is different for every plane, so a generic script in common use by many planes must use the low level routines for the specific plane being controlled, wether or not that low level routine is hard coded or scripted (i.e. aircraft specific commands/procedures override more generic code in any shared command/procedure library) Any other ideas and suggestions of what such an aircraft scripting/AI language/engine might need ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Newbie needs a mentor(s)
- Original Message - From: Phil Spurr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 7:24 PM Subject: [Flightgear-devel] Newbie needs a mentor(s) Hi all I've recently (with help from Curt) managed to download and run the Win32 binaries and have been very impressed with all of your work in creating Flightgear. I would like to become involved with the project, but I'm looking at using Mandrake Linux as my platform. Is there someone out there who could answer my 'silly' questions as I'm new to using Linux as well - just to get me to the point of being able to compile successfully ! I'm no newcomer to programming, or flight sims / real flying / aircraft systems, but I'm struggling with two unknowns at once here. And if there's any reason to choose a different Linux/Windows platform, please tell me now before I go down the wrong avenue... Regards Phil You can do equally well with any linux release, or cygwin on windows just get the latest plib, simgear, and flightgear cvs release when you are ready to try compiling :) I'm equally at home on either platform if you have questions :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My first real patches...
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 8:27 PM Subject: [Flightgear-devel] My first real patches... Basically what I've done here is expanded upon the ejection seat properties to make them more flexible. I did this as a patch because it was something that a) needed to be done and b) looked simple enough for me to do without botching it too badly. :) The former property node was: /controls/seat/eject as a boolean value. Since there are a number of ejection seat equipped aircraft out there that have more than one seat, I've added code to track those. The tree now looks like this: /controls/seat/eject[%d]/initiate - bool If this becomes true, then the handles were pulled. /controls/seat/eject[%d]/status - int This describes the current status of each seat. SEAT_SAFED - seat won't fire if handles are pulled (no code behind this yet) SEAT_ARMED - the safety pins have been removed and the seat CAN be fired. SEAT_FAIL - initiator train has failed or instructor forced the seat not to operate. /controls/seat/cmd_selector_valve - int This holds the position of the Command Selector Valve that is used to control how 2 seat ejection functions. CMD_SEL_NORM - Rear seat fires and then front seat fires if front seat fires. If the rear seat is fired, it does not initiate the front seat. CMD_SEL_AFT - Rear seat fires first when triggered from either seat. CMD_SEL_SOLO - Front seat fires and then rear seat after a small delay. There's more technically descriptive detail about how the whole system is supposed to work, but for a basic first pass this should suffice. Note that the only real functionality is in the handling of the seat status condition when a seat is fired. No other programming has been done as yet. However, if someone adds a bang seat to one of the models, I'd be happy to get the routines fleshed out more. Questions? Comments? What'd I forget? FDM for a parachute ?? round or rectangular chute ?? joystick controls the shrouds ?? cutting loose the main and deploying the spare ?? skydiving ?? (ok -- not really related to the ejection code itself, but it would be nice :) ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Erik Hofman [EMAIL PROTECTED] I'm not sure I like the idea of FlightGear set up as a server. This will however keeps the code between the server and the client as close as possible. I felt there were too many instances where the current simulation code would be highly useful for a server (which could have been handled with a seperate executable linking what was needed), but the ability to have a running FG instance be a server for a small group of flyers (load up and fly with a few friends) without having to have a dedicated server made integrating the server worth while. Are any of these abilities in the current code, or how much work are we looking at to make it work this way ?? There already is an option to disable out of the window view which is used for the c172-610x/panel only aircraft, but this one still displays the panel. Doesn't sound like we have far to go, or that its going to take major architectural changes to make any of it happen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:14 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status it offensive to even have source code included that discusses in weapon terms, To me this is absurd to the extreme. To you maybe. This may not be the proper forum for you to be asserting judgements like that anyway (see alt.politics.*) :-D ...with cross-posts to alt.save.da.fwuffy.bunny and alt.wesley.crusher.die.die.die. :) And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. I read the whole post. Really! :) I guess my problem is that I'm totally unable to understand why someone would object to just the _presense_ of munitions code even being present. It completely baffles me. Even as I sit here pondering the why, all I can come up with is pejorative commentary and that's unfortunate. Same here -- I deleted the post before sending it -- tolerance and understanding of others ideas is what makes a community -- I've tried to do that by consenting to add code for strictly non-combat simulations -- I hope for the same from the non-combat folks about the combat code -- I'll leave it at that BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. Lets make their day !!! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, November 10, 2003 3:40 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Monday, 10 November 2003 21:14, Gene Buckle wrote: BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. I like the idea of FlightGear being able to support military type stuff but where do we draw the line? If there is too much military specific code hooking into core parts of FG then it could get messy and even slow things down both framerate wise and development wise. Understood. The only feature that I can think of that cannot be an external plug-in is collision detection. There are so many things that are specific to aircraft like the F16 that require more than just an instrument display. For instance ground radar and FLIR systems. Being able to acquire and lock onto ground targets has nothing to do with general aviation but is absolutely necessary for military simulations. That means there would have to be an interface between the panel system and terrain rendering system. This can be made a plug-in that uses the same terrain data that FG is using. All the code that is the FLIR (or LANTIRN, or LITENING II, etc) could (and should!) be implemented as an external plug in. If it's executing on the same host as the simulation, it would need write permission to the main frame buffer to allow its display to be shown. This same method could apply to a glatss flight director or ADI, engine displays, etc. A plug-in system like that would be a universal technology that could be applied to both military and civilian/commercial systems. I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. *eyes glaze over* Oooh. *wistful sigh* Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) One could go a step further and reason that FlightGear should support space simulation as well. (probably not that hard considering that FG simulates the celestial bodies pretty well) Take that far enough and we'll soon have lunar rovers and ... and ... and ... YES! MORE MORE MORE :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, November 10, 2003 4:29 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) Persistant world period. The benefits would be just too phenomenal to think about, especially from the just-wanna-have-fun user end of this thing. Here's a scenario for ya: User connects up, and picks where they want to fly from and what class of aircraft they want to fly. They're then deposited in the FBO, terminal building or AFB hangar on the field they're going to fly from. They could then pick what they wanted to fly by menu, _or_ by walking outside and picking the plane they wanted from a selection of them parked on the ramp. All the while seeing AI and real traffic above them and other users wandering around on the ground with them. Makes me all squishy-headed just thinking about the possibilities. *sigh* MORE MORE MORE :) NOW NOW NOW! :) g. ___ 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] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, November 10, 2003 5:37 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, November 10, 2003 6:19 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) I'm only guestimating based on the filenames :) Now -- how much does one of these physical cockpits cost ?? I want one for the basement :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile issues
I'm also runnng cygwin and hit that one -- you need latest CVS versions of plib and simgear for starters -- try that then build fg -- I recommend --prefix=/usr on both plib and simgear builds -- cygwin doesnt have /usr/local/lib in the ld search path :) - Original Message - From: JD Fenech [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 10, 2003 9:05 PM Subject: [Flightgear-devel] Compile issues Ok, I'm having a bit of trouble getting the release version of flightgear to compile under cygwin. I'm hardly an expert at getting major projects to compile, so I'm not quite sure what the problem even is. I've pasted the error at the bottom, so if anyone has any thoughts on it, maybe you can help. Also, where can I find an absolutely updated document which lists all of the configure options, as well as the currently required packages to compile the Release and CVS versions of FG (Do I need metakit or not? Zlib? You get what I mean). Error message follows, Thanks, JD $ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1$ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1 -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer -- wire protocol implementation
http://www.camelot-software.com/fgfs/fgmps.tar Here is the patch and source files for the preliminary wire protocol implementation -- comments and suggestions welcome -- untar in the directory containing the FGFS source directory, apply the patch, autogen, configure --with-multiserver, and make -- 2 executables (buftest and msgtest) will be created in src/Servers that demonstrate the wire protocol handling, and the base class for managing messages At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? And lastly, which is the best network module to use as a reference for creating the status messages that get sent out every call to process() so that I dont miss anything critical ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) The 'loop' is in netChanel.cxx SimGear sockets and are built ontop of PLib/Net as is the FGFS http server, which should make an applicable stress test easy to formulate :-) ok -- I give up :) total surrender :) Interestingly enough -- the classes are quite similar to mine -- even unto line terminator handling -- prime difference being that my socket instances must register with the server class in derived implementation code, since the core socket code can be used with or without the server loop -- looks like plib handles that automatically Guess I have enuf to do the server framework and initial handshake between client and server ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 11:59 AM
Subject: Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote:
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome
This sounds fun, so I grabbed it and had a peek. One bug report in
messagebuf.cxx, which has some code that I can't figure out:
void FGMPSMessageBuf::put(unsigned char byte, bool raw)
{
if (!raw) {
if ((byte 0xf0) == 0xf0) {
buf += 0xff;
byte = byte ^ 0xff;
}
}
buf += byte;
}
If I read this correctly, if raw is false (which is the default
argument), then values in the range 0-239 are passed normally, while
values in the range 240-255 cause an extra byte of 255 to be inserted
in the stream, followed by the bitwise negation of the original byte.
I don't see anywhere for the extra 255 to be interpreted on read,
though.
for cooked data, values 0xf0 to 0xff are protocol reserved values and are
escaped by prefixing with 0xff and inverting the data -- you can find the
corresponding decoding in the get method
unsigned char FGMPSMessageBuf::get(bool raw)
{
if (pos = buf.length())
throw FGMPSDataException( FGMPSMessageBuf: Read past end of buffer );
if (raw) return buf[pos++];
if ((unsigned char)buf[pos] == 0xff) {
pos++;
return ((unsigned char)buf[pos++] ^ 0xff);
}
return buf[pos++];
}
I'll admit that I have absolutely no idea what this code is supposed
to do. :) Are you maybe trying to handle 2's complement signed values
via an escaping mechanism? If so, you need to change the bit test to
0x80, and can elide the complement operation entirely. It's best to
leave signedness determination in the hands of the user code, though.
Trying to make the protocol resistant to changes in message structure, and
malformed messages due to transport layer errors (for instance if this
protocol is run over serial lines or modems) -- I thought it desirable that
protocol specific values never appear in the application data and that all
data elements in a message be typed so that malformed messages could be more
easily detected (we used a similar setup over at WorldForge to make the
client/server link more tolerant when the endpoints of a connection had
different application message versions)
One other nit is a collection of portability bugs in your type
declarations. A long value isn't guaranteed to be 32 bits, on an
LP64 platform (64 bit unices, but not Win64) it's a 64 bit quantity.
I also see some locations where you appear to be assuming that an
int is 16 bits, which was true on the PDP-11 and 8086, but nowhere
else; it's not clear if this extra precision will result in real bugs
or not.
I know -- I claim fatigue as an excuse - I'm packing to move next week while
I work on this -- I'll dig in and find the portable type declarations and
update the code in the next few days :)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 11:58 AM Subject: RE: [Flightgear-devel] Multiplayer -- wire protocol implementation John Barrett writes: From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) Guess I have enuf to do the server framework and initial handshake between client and server Might want to ask any questions or solicit ideas over on the PLib list as this Library has been used before in somewhat similar 'online' gaming apps :-) I think between the http network module and the other modules that actually move a/c data, I've got enough to get the basics in place -- my next question will be how do I add an a/c instance to the current scene and keep it updated but I can likely dig that out of the other multiplayer modules ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies for the cvs commits
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] I figured your changes would eventually return through proper channels so I just left that in for now. If you want me submitting patches, I will need the correct procedure for creating patches. I havent had any luck using cvs diff or diff off the command line to get the right output. The directions that were posted in the users list didnt work out either. For my approach to looking at change submissions and adding them to the source tree, it is most convenient for me to receive whole copies of any changed files. Others have different approaches and might prefer just the diff's. For submitting diff style patches, I'd recommend using cvs diff -c to get 'context' style diffs. Ok -- I'm currently setup to generate a diff on any existing files excluding my working directory plus my entire working directory (src/Server) in a tarball -- how do you want it submitted when its ready to go in the source tree ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] I would propose that the server be structured so that a purely civilian/non-combat version could be run. I don't want it to be possible for some idiot to come and blow me out of the sky when I'm practicing ILS approaches in my C172 at my local airport. When thinking about the design of such things, it would be good to consider what kind of separation we can keep between the military/combat features and the rest of the core simulation. Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) Jon Berndt wrote: I guess there ought to be an explicit flag the user can set at startup stating whether or not they want to be seen or not. THe default would be invisible. I disagree -- if they are hooking to a multiplayer server they should be visible by default, conversely, if they choose to be invisible on a combat active server, weapons should be disabled, as well as a/c collision detection (i.e. get a birds eye view of a running battle without actually being involved) -- this could be handled very easily by setting up a client connection that sends nothing to the server -- just monitors the active server traffic -- another option for the peer connection module :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Jon Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 4:24 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. That's fine, as long as when I start up my instance of FLightGear (on my Internet attached system) that I am my own self with no Internet connetivity whatsoever. absolutly -- you must --mp-client or --mp-server on the command line -- just like the other protocols ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 4:16 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. I'm talking more along the idea that the server operator will choose if the world is combat or not combat -- rather than trying to do both in the same world -- once I get the core online and move on to the community webserver, server config including combat/non-combat status will be displayed so you can choose the type of world you wish to participate in and no reason I can think of not to run multiple servers on a single machine, or multiple machines, some combat, some not, if, as a server operator, you wish to provide a broad range of environments for flyers thats getting into the scenario system and setting a startup scenario for the server -- for instance, starting at a particular airport with only single engine prop planes allowed for civilian GCA practice, or having multiple starting airports and full combat for a capture the enemy bases scenario like Air Warrior (anyone thought of doing a tank sim based on the FG core code ?? -- both pilotable and AI driven ?? EvilGrin ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 5:05 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Sunday 09 November 2003 21:16, Curtis L. Olson wrote: John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http:// www.flightgear.org Wouldn't it be better to have several instances of the server, running either a non-combat environment or a combat environment, but not trying to do both at the same time? Non-combat servers would talk to other non-combat servers, and like-wise with the combat servers. I'd be a bit concerned about problems with, for example, the combat environment affecting the non-combat environment, and visa-versa. Ohhh we arent even CLOSE to talking about distributed servers yet -- lets get a single server system online and tested first -- THEN we can talk about a distributed system that simulates the entire world !! (which I think would be ultimatly kewl -- non-combat, recent a/c, simulated ATC and RATC, etc) I'm already thinking about chopping off data updates for a/c that are not within visual/radar range to keep the message traffic reasonable for sims covering large terrain in the single server setup -- distributed servers will need much more than that :) Something along the lines of regional ATC servers covering large areas, then a server for each airport to handle approach control and ground traffic Though actually -- a single master server could handle all the position updates without that much trouble given the update limiter code and headless (no opengl display) operation -- offload the airport and regional ATC to stand alone apps that interface to the master server as clients. (thats going to take some work on the ATC system to make it interface to the system like a network peer, even for single user operation, such that you can startup instances of the ATC code for specific airports and RATC) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 6:13 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Sun, 9 Nov 2003, John Barrett wrote: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be Yeah, it's certainly a much faster calculation. very fast for the server to do that check before forwarding data to a given client Will clients be able to select relevant data types too? (Obviously you're gonna want different data for an ATC client and a sim client, although there will be a certain amount of overlap). Probably not for 1st cut -- but certainly possible ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 6:28 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be very fast for the server to do that check before forwarding data to a given client Please - remember FGFS is not a flat earth system so get rid of the degrees and the square degree block concepts, as these are very inefficient and inaccurate when operating on a sphere. Position is an ECF vector and distance can be degrees of arc if you insist, but 'chord distance' is a one to one mapping and is *much* quicker to compute. http://www.flightgear.org/Docs/Scenery/CoordinateSystem/CoordinateSystem.html whatever works -- if the computation gets too intense, it can always be handled periodically (every 60-120 seconds perhaps) and keep a list of entities for which we are interested in their updates -- entity IDs are going to be 32 bit integers, so we wont be hitting memory all that hard even with 100s of planes in the air -- or even reverse it -- each entity keeps a list of entities to which it will send updates -- list updated periodically -- then we dont have to walk the list of entities looking for those that are interested ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Lee Elliott [EMAIL PROTECTED] I read your later post after I'd sent that:) I agree that the server operator choosing the type of world is a good idea. However, there's potential for quite a wide range of realistic scenarios including elements of both non-combat and combat features. As I see it -- the client and server should both be capable of the full range of activities, the only question is then do weapons work or not ??. Practicing aircraft carrier landings does not require weapons :) For example, air/sea rescue missions (and their code infrastructure) would be appropriate in most multiplayer scenarios, both non-combat and combat - if you were flying ga into/out of, or in the vicinity of an airfield that hosted air/sea rescue services in a non-combat world it would be realstic for those operations to occur at the same time and even interfere with normal flying in that world, according to the appriopriate procedures. That applies to most everything one might do with FG except weapons code, and I consider the weapons code to be a small burden to non-combat users in terms of increased executable size and additional airplane information that wont get used in their scenarios -- the combat system doesnt need to be intrusive, but it needs to be there :) And except for specific items such as missiles and cannons, many parts of the combat system are useful for non-combat scenarios -- flying with drop tanks, changes in FDM based on changes in load -- crop dusting :) Hmm... perhaps the person who was thinking about puting some life on the ground might like to try shipping first as it might be easier than trying to follow roads;) Keep going -- lotsa other things that can be added :) One issue is consistency of display -- I would say making ship/vehicle positions determinstic based on time, so that all clients can use the server clock as a reference for controlling motion, and all the clients on a given server will see vehicles of this type at the same locations and with the same motions. Similarly, and bearing in mind that some work has been done on simulating failures, it could be possible for an a/c to declare an emergency, say an engine fire on a multiple, that disrupts all the other folk in the curcuit. Be interesting to see how AI ATC code could be setup to deal with that :) Realistically, civil airliners have also been shot down, but I can't see anyone really wanting to try that scenario as it's a bit pointless, or seems so to me. No 9/11 here please !!! Someone may want to do scenarios like that, its certainly possible, but not something I'm personally interested in. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Michael Matkovic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 10, 2003 12:07 AM Subject: [Flightgear-devel] Multiplayer Server RFC -- Current Status Could you describe the --headless option (Phase 1 changes)? Sounds a little like what I'm trying to get Flightgear to do. / /I was hoping to have multiple airplanes (each controlled by an individual program), each being updated once per video render instead of having independent execution frequency. Using version 0.9.2's multiplay option, I can get a number of planes visible but the 'once per video render' update still needs some work. Til now I've been viewing the group of planes from one of the players' views. I'm not sure if this idea can be done, but (considering what I'm trying to do) is it possible to have flightgear toggle between each player's view? For instance, starting up several 'players' but only having one screen... and being able to switch between each player's view. Sounds like a weird idea? maybe I should back on the coffee :-P headless would be without any graphical display at all multiplayer does multiple planes in the scene, but expects the controlling logic for all but the local plane (none in the case of headless) to be handled by processes over the network I would VERY much like to see the ability to have a plane instance not attached to an OpenGL scene updating at a set frequency (for AI driven planes at the server, rather than at the client) -- given that, having the plane able also to attach to an existing scene would achieve the 1st half of your requirements (attach as many planes as you like), then the input routines would need to be isolated from a specific plane instance, and made able to attach to any locally running plane instance via a menu for starters, we would need: 1. local plane instances that can operate with or without a local OpenGL scene, optionally with PSL scripting for AI 2. keyboard/mouse/joystick interface isolated from the plane instance, with the ability to attach to any local plane instance (i.e. you could detatch from all planes and only the menus would be active, or you could be attached) What this gets us: 1. a running FGFS instance can have multiple planes without multiplayer, with the planes scripted if desired to play out a scenario (civilian scenario: cope with a plane invading your airspace while on approach/combat scenario: obviously :) blow them outa the sky :) ) 2. running headless connected to a multiplayer server, the FGFS instance can handle multiple AI driven planes in the world on behalf of the server, creating a distributed server environment for larger simulations (would take a little tweaking of the multiplayer code to cope with multiple plane instances at the client, but very possible, and quite desirable IMO) Are any of these abilities in the current code, or how much work are we looking at to make it work this way ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Apologies for the cvs commits
Like to apologize to Curtis for the cvs commits using the cvsguest account (though I didnt do the ones to the ATC code -- just the configure.ac, src/Makefile.am, src/Main/Makefile.am, and the src/Server directory) Curtis -- you left the src/Server directory and my code in the repository -- could you remove it so I can make correct patch files, or set me up with a developers cvs account so I can legitimatly make changes ?? If you want me submitting patches, I will need the correct procedure for creating patches. I havent had any luck using cvs diff or diff off the command line to get the right output. The directions that were posted in the users list didnt work out either. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs guest oops ??
I was working on the directory layout and autoconf for my server module, and the CVS app I'm using requires that everything be added to the repository before a patch can be created -- without thinking, I added src/Server, and the cvs guest account allowed me to do it !! Doing patches is a new thing for me -- whats the correct diff command line to produce a patch given the current cvs tree and my modified tree ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Cameron Moore [EMAIL PROTECTED] To the folks that want combat, work real hard to support a --with-combat=no option, or you're gonna get shot down real fast. ;-) -- Already there and them some :) I'm working up the protocol base classes at the moment, and I went so far as to make the entire client/server code enabled/disabled by configure option, then, as added protection for those not interested in what I'm adding on, I added a new executable target to the Main makefile -- fgmp -- when you build, you get a stock FG binary, and if enabled, the multiplayer version that uses the client/server extensions. That should keep everyone happy who does not want a tainted binary, and allow easy performance/etc comparison between stock fgfs and fgmp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Bring on the eye candy :) and a good config gui to control how much candy you eat (along with everything else that a config gui should do -- joystick calibration, screen resolution, sounds and sound volume, load/save config) I personally have a problem with relying on a seperate project to create the config gui for FG, as there will always be lag from when FG releases new features until the gui catches up -- there needs to be a startup gui included that gets updated right along with each new feature -- nothing fancy, just enough to control all the features. Re: priority on fast frame rates -- I've always had a problem with the idea of frame rates faster than the display refresh speed - I've seen plenty of Quake III benchmarks that claim 150-300 fps, which technically is impressive, but as far as actual usage, seems pretty useless on a display that only updates 80 fps at best. Get FG up around 60-80 fps (on a 2ghz machine + GeForce2/64mb or better) with most if not all the eye candy options turned on, and I'll be very happy. - Original Message - From: Paul Surgeon [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 07, 2003 4:31 AM Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) That's odd - once I had set up and saved a default flight it was just a matter of starting the sim and away I went. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Well my point is that I'll do the development in the eye candy department. It does not have to detract from anyone elses time. :) I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. Thanks for your input though - I do understand where you are coming from even if I don't quite understand your reasons. Paul ___ 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] Some thoughts and ideas (LONG)
- Original Message - From: Jim Wilson [EMAIL PROTECTED] There are several people working on this stuff and more is certainly welcome. If you keep looking I think you'll find some pretty amazing visual work already in FlightGear. Have you headed north from the default runway yet (toward downtown)? Ok -- try this idea on for size -- we've already heard mention of handling different periods of time re: aircraft capabilities, extend that idea to terrain modeling -- i.e. you could have chicago details for each decade since 1930, have the scenario system decide which specific terrain overlay to apply to a region -- I'm not suggesting that there be an intensive effort on anyones part to create a broad range of overlays, just that the ability be there so that scenario designers can select existing overlays, or create them using an overlay editor BTW if you've got talent, be it in modeling or coding, it is hard for me to imagine that you won't get an enthusiastic response from at least some of the users. There will always be a wide range of interests here and I think flightgear provides the flexibility to satisfy many. Hehehe -- what gets me is the stay out of my sandbox crowd -- would rather find ways to work together :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:51 AM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On 11/6/03 at 1:36 AM John Barrett wrote: 3. Initial Radio Message set definition a. Tower ATC messages b. Regional ATC messages c. Ground Traffic Control There is current ongoing progress in this area within FlightGear. I haven't quite got my head round what the multiplayer server actually is yet, but at a guess I imagine you'd want the ability to replace arbitrary FG ATC services with real life humans, and for others with more than one multiplayer plane at them to be consistent in what they output to each user? replace with humans for ATC simulators (human or AI pilots -- there was a neet ATC game way back when on EGA PC that I really enjoyed -- you were the tower at chicago mdw :) or the other way around -- AI ATC for human or AI pilots and yes -- consistency is important, if FG is connectect to a server, then all AI functionality should be handled by the server, else it should be handled locally (which is where the idea of having the server so tightly integrated with the FG code comes into play) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:53 AM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On 11/5/03 at 2:42 AM John Barrett wrote: Any other ideas that I should include in this project ?? It would be nice if current MSFS clients could also connect and participate. I realise this could be a bit of a pipe dream though given the amount of work it'll probably take to get off the ground full stop. Is there a published specification for the MS FS wire protocol ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Jonathan Richards [EMAIL PROTECTED] I agree, though, that what is missing is other inhabitants of the simulated planet :) The biggest mismatch with reality is the absence of other air traffic, or even ground movement, and I know that people have started to address these. In the real world, though (modulo conflict zones) there is no air combat. I'd welcome other flyers in the FlightGear VR, but should the primary goal for a first interaction with them be to 'blow them outa the sky'? The spirit of simulation would rather suggest building in flight planning, ground- and air-traffic control, and generally relieving the loneliness. If I thought I could do it (and I might...) I'd begin to see if we can have FlightGear generate situation-relevant ATC radio messages by doing text-to-speech translation with Festival. Even if it only warns me about other traffic that I fail to see (so no change there :¬) I don't want you to get the idea that I have some moral objection to simulated violence, I've bought, played and enjoyed many combat sims, and I've rambled enough, so I'll just throw out some questions... where does the real-world information come from to =simulate= classified weapon and weapon platform performance? How will combat damage be modelled? Will the sim assess the location of e.g. cannon shell impacts and adjust the flight model, or put equipment out of commission? Multiplayer? Great idea, and I'd support it. Combat? Not yet... and please not in the core distribution (see Erik's earlier message). Full combat damage handling is a phase 3 effort, phase 1 is exactly what you are asking for -- get people in the world together, and enhance the ATC AI -- I would also love to see ground traffic simulation (up to and including cars on the roads in cities if you decide to turn that level of detail on !!) Seriously -- I'm more interested in WWII dogfight style combat -- guns/wing cannon, and dropped bombs only :) So we are really talking minimal changes for that type of combat. Guided weapons can wait :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Melchior FRANZ [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 6:34 AM Subject: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status * Norman Vine -- Thursday 06 November 2003 10:10: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. | | However, FlightGear does contain several military aircraft, albeit | without munitions. Doesn't sound like such a strong resistance. :- And I''m getting serious !! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 7:35 AM Subject: Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status Melchior FRANZ wrote: * Norman Vine -- Thursday 06 November 2003 12:56: If you want to simulate combat please make it a separate project [...] I'm worried, though, that fighting capabilities could mean tradeoffs for the civilian simulation, which would certainly not be acceptable. As long as the whole thing would be a separate module (like WeatherCM) that can be compiled in or not, I'd not see much of a problem. Good thinking. Erik I see no problems here -- everything discussed so far impacts the current FG code only if you are involved with a server, and having an additional config option or three to control what gets compiled in is easy enough Lets see if I can run down the areas of impact: 1. keyboard/joystick event bindings for weapons 2. FDM integration for disposable stores and expendables -- useful even for civil aviation sims -- what happens if an engine falls off the pylon on a 747 ?? :) 3. HUD overlay for text messaging, GUI for radio messages -- needed in any case for ATC simulations, adding text to speech would be a plus :) 4. client and server protocol modules (can be configured in or out independently) -- in fact, totally possible to have the build process do two binaries at output -- one with server code, one without 5. aircraft specification modifications for weapons stores and damage effects (if you get hit in a specific location, what gets damage and how can that effect plane performance) 6. balistics and incremental aircraft damage system (non-guided weapons... wing cannon and bombs, falling aircraft parts [getting back to the 747 that drops an engine :) ], falling aircraft :) ) did I miss anything ?? Some of it is relevant to any simulation, the rest can be handled as optional modules, or is so low impact that its not worth making it optional (event bindings for instance) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 1:08 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status Plus it'd allow modelling of other interesting things - how about being able to practice your fire fighting skills? (actually, a horrible thought just occurred to me - imagine trying to model a helicopter with a water tank swinging about under it :-) That would be pretty cool. Just imagine the fun you could have with a 747 water bomber. :) Something needs to be done about the terrain though - it's too clean. g. Call that phase 4: Extending terrain data for low level and ground level sim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
Here is a quick and dirty 1st cut at a wire protocol definition, and some requirements for the message handling classes that will implement the protocolPreliminary FlightGear Server (FGS) wire protocol specification 0xFFEscape prefix for 0xF? bytes in the data next byte is inverted, except for data type prefixes 0xFEBegin message, 8 bit message ID 0xFDBegin Message, 16 bit message ID CodeTypeC/C++ equivalent 0xF0byteunsigned char 0xF1wordunsigned int 0xF2dword unsigned long 0xF3qword unsigned long long 0xF4signed byte char 0xF5signed word int 0xF6signed dwordlong 0xF7signed qwordlong long 0xF832bit float float 0xF964bit doubledouble 0xFAundefined 0xFBundefined 0xFCstring, next byte is length char* unterminated binary data Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Messages are constructed by sending a Begin Message byte, followed by the message ID, and then each data element.. clients/servers that dont understand a given message should be able to skip past to the next start of message marker. the FGSMessage base class will define an array of type/pointer that identifies the type, and location to store each element of a message. Derived classes will load this array with the correct associations for the specific message being sent or recieved. Recieved messages must have the same types in the same order or the message is rejected as invalid. All platform specific data conversion will happen in the FGSMessage base class during packing/unpacking of the message. Message objects derived from the FGSMessage base class will register with base class using static methods to establish a factory style instantiation mechanism such that an inbound message can be passed to a static method of FGSMessage, and the return value will be a pointer to an object of the correct message type. FGSMessage::recieve will be equally able to handle UDP packets with multiple messages, or TCP packets with partial messages, buffering message fragments until the next time the recieve method is called.___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer Server RFC
I've just gotten FG cvs to build clean on my system and I would like to work on a basic multiplayer server and enhancements to FG to support the server that I have in mind. Features: 1. based on the current multiplayer code with an enhanced message set 2. optional authentication token to restrict access to the server 3. server able to force the FG client to start at an arbitrary location i.e. on taxiway behind the last player that connected to the server 4. multiple client type support (FGFS, ATC, etc) which will control what types of data get sent to the client based on XML client profiles 5. protocol version validation to prevent outdated clients from connecting 6. built in web interface to configure server and display status with security 7. optional posting of configuration summary/status to a remote webserver -- allows simple community servers to be created that list active FG servers 8. GUI launcher app which will interface with community servers and start FGFS with the correct settings to connect to an active FG server. Previously I have worked with the WorldForge MMORPG project on server design, and created client/server games for the IPlay.Net online games service. My sourceforge id is johnrbarrett. Any other ideas that I should include in this project ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
Martin Spott wrote I'd like to express a wish: _Please_ try - as long as possible - not to add redundant features. There are already three multiplayer extensions for FlightGear - partially unmaintained I'd love to see them merged somtime in later future, probably sharing common modules bus driving different protocols, if necessary. Please remember: This is only a wish, Martin. -- Ok -- lets run it down -- I'm aware of the basic raw multiplayer and the OLK code (which I peeked at and am still trying to figure out the details) and what is the 3rd one ?? Dont see anything in CVS for it.. I'm looking at creating a new protocol module to handle the low level details of the connection, and a hud overlay like the OLK code to handle radio messages and user input, enabled only when the protocol module is activated on the comand line, some gui to handle canned radio messages and adhoc message input (standard messages such as ID, traffic control requests and replies, etc .. the goal with canned messages is that they will be sent as unique messages that other programs can easily recognize and process, such as an ATC simulator if someone should write one) The HUD setup is going to be pretty basic, and could be used as a general HUD add-on for any network code since its main functionality will be displaying radio messages... suggestions on how to implement it to be usable by any module that needs to display a scrolling list of messages would be welcome Erok Hofman wrote: Excellent. I was thinking it would be a good idea to set this up as a side project and just sent the necessary code updates for inclusion in CVS. I can work via patches for the time being, but was really hoping for developers access to CVS at some point. Make my life a lot easier getting updates to the server machine (I work for an ISP and have several machines to play with :), and to the team that will be helping me test (I have already recruited a number of friends to help out :) I guess as a last resort I can fork the code and setup my own CVS server -- but that doesnt pay off in the long run :) Some things you might want to remember is to use plib/SimGear functions whenever possible because that makes it easier to maintain cross platform compatibility. Thats an absolute neccessity :) One of my long term ideas is to have the server load the terrain data around each aircraft in play for use by automation/AI code running at the server. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Paul Morriss [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 12:46 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC Hi John, A while ago I proposed (and been working on conceptial designs) for a scenario and multiplayer server (called Cumulas). Between my hectic work schedules (I am a Full Flight Simulator Software Engineer by trade) I have been putting together some basic design foundations, maybe we could lias and work together on the project to speed it along ? I'd be very interested, since thats exactly where I'm going -- eventually to add combat capabilities once the core multiplayer system is online -- my strengths are multiplayer server design and implementation, which is why I was looking for a good client off the shelf so I wouldnt have to do all the 3D and UI code, just add on what is needed :) Paul - Original Message - From: John Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:42 AM Subject: [Flightgear-devel] Multiplayer Server RFC I've just gotten FG cvs to build clean on my system and I would like to work on a basic multiplayer server and enhancements to FG to support the server that I have in mind. Features: 1. based on the current multiplayer code with an enhanced message set 2. optional authentication token to restrict access to the server 3. server able to force the FG client to start at an arbitrary location i.e. on taxiway behind the last player that connected to the server 4. multiple client type support (FGFS, ATC, etc) which will control what types of data get sent to the client based on XML client profiles 5. protocol version validation to prevent outdated clients from connecting 6. built in web interface to configure server and display status with security 7. optional posting of configuration summary/status to a remote webserver -- allows simple community servers to be created that list active FG servers 8. GUI launcher app which will interface with community servers and start FGFS with the correct settings to connect to an active FG server. Previously I have worked with the WorldForge MMORPG project on server design, and created client/server games for the IPlay.Net online games service. My sourceforge id is johnrbarrett. Any other ideas that I should include in this project ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 2:04 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC I hope it doesn't turn out to be as fun as Air Warrior III. That stupid game took over my life for a couple years :) UMM :) I'd like to try for MORE fun :) SVGA Air Warrior had me hooked for a long time too :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Paul Morriss [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 2:12 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC My principle skills include networking, I have been involved heavily with DIS and HLA (which are flight simulation network protocols) and interfacing to them. I have a lot of MySQL/SQL and web background which I think would be a really nice touch for the application. Same here :) I prefer PHP but am equally at home in Perl. Have also done a lot of C++ mysql -- any problems making Mysql++ a dependency to build the server ?? (You'll see how this fits in with other ideas later in this post) My initial design started on what will be passed across and how we represent it (I have to be very careful how I preceed - I don't want to reimplement what we have at work as it could upset them!).. Easily solved if I design the wire protocol Since your background is more lower level then me, what about if I worked on the internals of the server, such as player objects etc and you can worry about networking and the rest. I'm not gonna let you do all the internals :) protocol design and implementation wont take very long Additionally in my design I plan to have 'scenarios' which are created through a web interface. I'm planning a web interface for general control and stats integrated in the server, but dont believe that a complete scenario creator would be appropriate in the server code. I suggest having the scenario builder as php/perl running on a normal webserver, and using either mysql to store the scenarios for access by the server code, or having specialized urls on the server web interface that will allow the php/perl code to install a scenario on a running fg server. Also, it would be interesting to be able to download the scenario to a file for use with a local server, or for upload to a remote server via the web interface. If the multiplayer server is written in the right way it should be possible for many people to interact across the internet, BUT also it should be possible for 2 or more people to setup a server and have 'private' games. I want the server to be part of the base distribution, with a number of prebuilt scenarios, and the ability to load scenarios saved from the web scenario builder mentioned above, from disk, and possibly from database. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Jon S Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 2:41 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On Wed, 5 Nov 2003 13:38:23 -0500 John Barrett [EMAIL PROTECTED] wrote: I'm looking at creating a new protocol module to handle the low level details of the connection, and a hud overlay like the OLK code to handle Here's a red herring - er ... I mean side note: One thing I've been playing around with (OK, _played_ around with - about a year ago) in JSBSim was the ability to add child objects to the main aircraft. Each child would be a separate instance of a JSBSim FDM. The idea would be to provide a way to model an aircraft with attached stores. Each store would transmit forces and moments to the parent aircraft (for example a Mirage) until it was released, at which time the FDM for that child object (for example a Mk-82 or AIM-9) would start integrating and do its own flyout - the parent aircraft now free of the effects of the store. Sounds much more realistic than the much more simplistic no effect on the plane that I was planning for stores :) We will also need to look at upgrades to the panel/hud for combat planes to include stores information, and adding additional event bindings for weapons select and release Additionally, each store would have its own config file - and its own flight control system/autopilot/guidance. In theory, the possibilities are limitless for game playing, where one might PC set up a food drop tank to be released from an aircraft and make a mid-air connection to another aircraft, mid-flight/PC, or PC a water delivery tank could be guided by homing device to a precision landing extremely close to a hostile anti-aircraft battery or needy family (in some cases these are coincident)/PC. Very much needed for guided weapons -- have to discuss cannons and balistics too :) This is the point where we start deciding what goes on the client and what goes on the server to prevent hackers from modifying the client to gain an advantage... In other posts I mentioned having the server load the terrain data, but if we go that far with the server, there is also no reason not to use the full FG simulation code without display to handle guided weapons and cannon balistics. As mentioned in other posts about simple head to head, it may be worth considering the ability for an FGFS instance to be both client and server.. i.e. person loads up a scenario and publishes their server data to a community webserver so that other people can join the scenario -- gives us the most leverage for the stores system you have proposed to be used for both small scale and large scale sims -- offloading weapons dynamics to the server for large scale scenarios -- then the only question becomes is the server headless ?? I've been threatening to complete this for a long time, but one day we'll allwake up and I'll announce that it is finished. ;-) Can we threaten you if you dont finish it ?? Force you to fly a bi-plane against F-16s for a week if you dont cough up the code ?? EvilGrin ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:51 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On Wednesday 05 November 2003 19:44, John Barrett wrote: Have also done a lot of C++ mysql -- any problems making Mysql++ a dependency to build the server ?? Personally, I prefer Postgres - any chance of making it work with either? If we are going to be doing C++ code, we could support both using ODBC/UnixODBC as an abstraction layer, however, adding yet another dependency, and one as complicated to install as UnixODBC, is further than I would like to go We can write our own db layer code -- want to handle that part ?? I dont have any pgsql experience so I'm useless there (and IMHO, between php and c++ as dev tools, mysql is much easier to cope with and has better management tools -- namely phpmyadmin) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 8:56 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC Lee Elliott wrote: ODBC would be better than making it DB specific. Msql has it's pros cons. Are you guys sure a SQL database isn't overkill? Similar arguments were made by David a while back regarding the use of metakit for the navaid database. These days, a dataset needs to be truly gargantuan to justify putting it in a fancy persistent store. Most of the time the trivial load it all up at startup and use it until shutdown metaphor is simpler and faster. The database would be for storing scenario configurations and data used to generate scenarios, not for real time simulation data -- a task which can be equally well handled by text files, but when you start having large numbers of them, try to organize them into campaigns, or coordinate multiple concurrently running scenarios, then you have issues where the database can pay off just for the sake of having all the data in one place for multiple machines to access -- beats the heck outa NFS or other distributed file system in my book. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 8:45 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On Thursday 06 November 2003 01:30, John Barrett wrote: - Original Message - From: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:51 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On Wednesday 05 November 2003 19:44, John Barrett wrote: Have also done a lot of C++ mysql -- any problems making Mysql++ a dependency to build the server ?? Personally, I prefer Postgres - any chance of making it work with either? If we are going to be doing C++ code, we could support both using ODBC/UnixODBC as an abstraction layer, however, adding yet another dependency, and one as complicated to install as UnixODBC, is further than I would like to go We can write our own db layer code -- want to handle that part ?? I dont have any pgsql experience so I'm useless there (and IMHO, between php and c++ as dev tools, mysql is much easier to cope with and has better management tools -- namely phpmyadmin) LeeE ODBC would be better than making it DB specific. Msql has it's pros cons. What better admin tool do you want apart from sql? ;) PHPMyAdmin -- very nice tool for managing and editing mysql databases typing long sql command strings is a waste of my time when I'm managing schema and data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: Paul Morriss [EMAIL PROTECTED] 2) I agree it would be a good idea for you to design the protocol, I would recommend reviewing the DIS and HLA protocols to see how they work, HLA especially is actually powerful. Powerful it may be, accessable it is not -- there are supposedly existing C++ modules and other resources, however, attempting to access them yeilds broken links galore :) We'll need to establish an access account at DMSO to download the latest reference implementations of HLA and RTI (if that is even possible any more -- read THIS !!) *** Version 6 of the RTI 1.3 Next Generation (RTI 1.3 NG V6), now available on the HLA Software Distribution Center, will be the last freely available and supported RTI product to be released by the HLA program. In an effort to ease the transition from DoD-sponsored software to commercial products, RTI 1.3 NG V6 will remain available and freely supported by the RTI Helpdesk until 5 p.m., September 30, 2002. At that time all versions of the DoD sponsored RTI will be removed from the software distribution center and the RTI HelpDesk support will be terminated. *** all further HLA/RTI development has been commercialized -- we would have to start from scratch unless we somehow luck into copies of the DMSO software I cannot sign up to access the DMSO library because I do not have a reverse DNS lookup -- a requirement of their signup procedure In any case -- this is very ambitious without an existing code base to start from... I'd have to say pass unless we can dig up some HLA/RTI code that we can use out of the box ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer Server RFC -- Current Status
We have covered a LOT of territory the last couple of days, so I think we are due for a summary to date: Phase 1 1. Server implementation to be integrated with the current FG code a. --fgspeer= protocol module with HUD updates b. --fgsserv= protocol module and basic reflector server c. --headless option for standalone server operation d. --webserv= remote config/status module e. --commserv= community server publishing url 2. Protocol design and implementation a. TCP streaming protocol b. message packing/unpacking classes c. message base class 3. Initial Radio Message set definition a. Tower ATC messages b. Regional ATC messages c. Ground Traffic Control 4. Basic Community Server a. PHP based b. Mysql database backend if needed c. Netscape and IE launcher integration allows a link to start FG with correct settings primary goal: multiplayer flight Phase 2 1. weapons stores with FDM integration 2. dynamic shared library system for weapons behaviors 3. server extensions for ordinance instance management 4. scenario system design and initial implementation 5. web-based scenario builder design and prototype 6. community server enhancements primary goal: shoot and record hits (no damage) secondary goal: Red Flag scenarios Phase 3 1. damage system integration 2. incremental system damage effects 3. FDM damage effects 4. AI surface to air weapons (AA, SAM, etc) 5. dynamic shared library system for AI pilots 6. server extensions for AI aircraft instances 7. web based scenario builder functional for current features primary goal: blow them outa the sky !! There is a lot more to cover, but this should be more than enough to keep us busy for a while :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cygwin build from cvs
Having finally gotten a windows cvs client that can be configured not to
munge *nix eol :) I've just gotten plib, simgear, and flightgear cvs
versions and am trying to build each package. plib built up just fine, but
simgear is failing due to macro definitions in one of 2 places
[EMAIL PROTECTED] ~/Desktop/FlightSim/Devel/cvsroot/SimGear
$ grep -r min\( */*
simgear/metar/Local.h:# define min(x, y)(((x) (y)) ? (x) : (y))
simgear/timing/lowleveltime.cxx:#define min(a, b) ((a) (b) ? (a) :
(b))
[EMAIL PROTECTED] ~/Desktop/FlightSim/Devel/cvsroot/SimGear
$ grep -r max\( */*
simgear/metar/Local.h:# define max(x, y)(((x) (y)) ? (y) : (x))
simgear/timing/lowleveltime.cxx:#define max(a, b) ((a) (b) ? (a) :
(b))
One of those include files is causing THIS when I compile:
Making all in bucket
make[3]: Entering directory `/cygdrive/c/Documents and
Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/SimGear/simgear/bucket'
if
++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -g
-O2 -D_REENTRANT -MT newbucket.o -MD -MP -MF .deps/newbucket.Tpo \
-c -o newbucket.o `test -f 'newbucket.cxx' || echo './'`newbucket.cxx; \
then mv -f .deps/newbucket.Tpo .deps/newbucket.Po; \
else rm -f .deps/newbucket.Tpo; exit 1; \
fi
In file included from /usr/include/c++/3.3.1/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3.1/locale:47,
from /usr/include/c++/3.3.1/bits/ostream.tcc:37,
from /usr/include/c++/3.3.1/ostream:535,
from /usr/include/c++/3.3.1/iostream:45,
from newbucket.hxx:44,
from newbucket.cxx:31:
/usr/include/c++/3.3.1/limits:205:22: macro min requires 2 arguments, but
only 1 given
In file included from /usr/include/c++/3.3.1/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3.1/locale:47,
from /usr/include/c++/3.3.1/bits/ostream.tcc:37,
from /usr/include/c++/3.3.1/ostream:535,
from /usr/include/c++/3.3.1/iostream:45,
from newbucket.hxx:44,
from newbucket.cxx:31:
/usr/include/c++/3.3.1/limits:205: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:206:22: macro max requires 2 arguments, but
only 1 given
/usr/include/c++/3.3.1/limits:206: error: ISO C++ forbids defining types
within
return type
/usr/include/c++/3.3.1/limits:206: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:206: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:207: error: syntax error before `(' token
/usr/include/c++/3.1.1/limits is declaring a struct with several functions,
two of them named min() and max(), apparently intended to return the minimum
and maximum legal values of a given datatype -- from c++/.../limits:
struct numeric_limits : public __numeric_limits_base
{
static _Tp min() throw() { return static_cast_Tp(0); }
static _Tp max() throw() { return static_cast_Tp(0); }
static _Tp epsilon() throw() { return static_cast_Tp(0); }
static _Tp round_error() throw() { return static_cast_Tp(0); }
static _Tp infinity() throw() { return static_cast_Tp(0); }
static _Tp quiet_NaN() throw() { return static_cast_Tp(0); }
static _Tp signaling_NaN() throw() { return static_cast_Tp(0); }
static _Tp denorm_min() throw() { return static_cast_Tp(0); }
};
I would guess one of the simgear includes is getting loaded before the chain
of includes that loads limits, causing this error
in newbucket.hxx, moving the line
#include STL_IOSTREAM
just after compiler.h is included, but before constants.h is included fixes
the problem
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin build from cvs
Disregard -- I had SimGear-0.2 downloaded :)
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 10:06 PM
Subject: [Flightgear-devel] cygwin build from cvs
Having finally gotten a windows cvs client that can be configured not to
munge *nix eol :) I've just gotten plib, simgear, and flightgear cvs
versions and am trying to build each package. plib built up just fine, but
simgear is failing due to macro definitions in one of 2 places
[EMAIL PROTECTED] ~/Desktop/FlightSim/Devel/cvsroot/SimGear
$ grep -r min\( */*
simgear/metar/Local.h:# define min(x, y)(((x) (y)) ? (x) : (y))
simgear/timing/lowleveltime.cxx:#define min(a, b) ((a) (b) ? (a) :
(b))
[EMAIL PROTECTED] ~/Desktop/FlightSim/Devel/cvsroot/SimGear
$ grep -r max\( */*
simgear/metar/Local.h:# define max(x, y)(((x) (y)) ? (y) : (x))
simgear/timing/lowleveltime.cxx:#define max(a, b) ((a) (b) ? (a) :
(b))
One of those include files is causing THIS when I compile:
Making all in bucket
make[3]: Entering directory `/cygdrive/c/Documents and
Settings/jbarrett/Desktop/FlightSim/Devel/cvsroot/SimGear/simgear/bucket'
if
+ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -g
-O2 -D_REENTRANT -MT newbucket.o -MD -MP -MF .deps/newbucket.Tpo \
-c -o newbucket.o `test -f 'newbucket.cxx' || echo './'`newbucket.cxx; \
then mv -f .deps/newbucket.Tpo .deps/newbucket.Po; \
else rm -f .deps/newbucket.Tpo; exit 1; \
fi
In file included from /usr/include/c++/3.3.1/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3.1/locale:47,
from /usr/include/c++/3.3.1/bits/ostream.tcc:37,
from /usr/include/c++/3.3.1/ostream:535,
from /usr/include/c++/3.3.1/iostream:45,
from newbucket.hxx:44,
from newbucket.cxx:31:
/usr/include/c++/3.3.1/limits:205:22: macro min requires 2 arguments,
but
only 1 given
In file included from /usr/include/c++/3.3.1/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3.1/locale:47,
from /usr/include/c++/3.3.1/bits/ostream.tcc:37,
from /usr/include/c++/3.3.1/ostream:535,
from /usr/include/c++/3.3.1/iostream:45,
from newbucket.hxx:44,
from newbucket.cxx:31:
/usr/include/c++/3.3.1/limits:205: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:206:22: macro max requires 2 arguments,
but
only 1 given
/usr/include/c++/3.3.1/limits:206: error: ISO C++ forbids defining types
within
return type
/usr/include/c++/3.3.1/limits:206: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:206: error: syntax error before `throw'
/usr/include/c++/3.3.1/limits:207: error: syntax error before `(' token
/usr/include/c++/3.1.1/limits is declaring a struct with several
functions,
two of them named min() and max(), apparently intended to return the
minimum
and maximum legal values of a given datatype -- from c++/.../limits:
struct numeric_limits : public __numeric_limits_base
{
static _Tp min() throw() { return static_cast_Tp(0); }
static _Tp max() throw() { return static_cast_Tp(0); }
static _Tp epsilon() throw() { return static_cast_Tp(0); }
static _Tp round_error() throw() { return static_cast_Tp(0); }
static _Tp infinity() throw() { return static_cast_Tp(0); }
static _Tp quiet_NaN() throw() { return static_cast_Tp(0); }
static _Tp signaling_NaN() throw() { return static_cast_Tp(0); }
static _Tp denorm_min() throw() { return static_cast_Tp(0); }
};
I would guess one of the simgear includes is getting loaded before the
chain
of includes that loads limits, causing this error
in newbucket.hxx, moving the line
#include STL_IOSTREAM
just after compiler.h is included, but before constants.h is included
fixes
the problem
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cygwin build problems
I've just acquired FG from CVS -- autogen.sh appeard to run perfectly, but right at the end of ./configure, I get: configure: creating ./config.status config.status: creating \ .infig.status: error: cannot find input file: \ and thats all she wrote :) I've previously built FG from the 0.9.2 sources without problems, and was getting prepared to join the team and contribute some multiplayer improvements, possibly including a basic multiplayer server (though not quite as basic as the simple packet forwarding suggested in README.multiplayer) Has anyone seen this before or do I need to start digging into the autoconf setup ?? I'm working with the latest cygwin release on a toshiba P4/2.0g laptop with 512 megs ram, Windows XP/Home, and ATI Radeon/Mobility GPU ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
