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 ___ 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] [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
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett wrote: > 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 ??" Pretty sure, yeah. :) The last time I looked at FlightGear's "core internals" (most of my work, like the YASim FDM, is peripheral) was about a year ago, doing the 2D-panel-in-3D-cockpit hack. Lots of existing code was written to reference "The Panel" and some work had to be done to enable the notion of multiple panel objects. Likewise, there was no easy notion of "this aircraft" within the rendering tree (all you get is an ssg node walk back). I just hacked around this one and put in a global array of panel objects with a (hopefully obvious) comment that these should be per-aircraft when that capability arrived. FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either. The problem with some great new features is that they show up with code that is "ready" to integrate, but without the integration work done. So they languish in the CVS tree until everyone forgets about them. I can recall at least one occasion where a unused module got replaced by a simpler (and arguably less functional) one precicely because the original never got integrated very well and the replacement actually worked. The extreme programming cult manages to get this idea right (every religion has a kernal of truth, right?) with their insistence on constant refactoring and integration. Features are useless in isolation. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
Erik Hofman writes: > I vote for pushing NetworkOLK to the bitkeeper by now. Yes, I'll second that, with appropriate thanks to Oliver for being the first one forge his way down that path. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
Andy Ross wrote: Erik Hofman wrote: I think 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. Exactly. It seems to me like we're swimming in half-finished multiplayer/multiaircraft/network-data/network-interface implementations. What we need really isn't another one to plug into the mess, it's someone to *finish* the whole project and (if possible) throw out all the old junk that isn't used anymore. I vote for pushing NetworkOLK to the bitkeeper by now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett wrote: > 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 ?? Um, isn't that the hard part? If FlightGear was all set with a clean interface to plug multiple animation-ready aircraft models, I dare say someone would have plugged it in already. :) Erik Hofman wrote: > > 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. Exactly. It seems to me like we're swimming in half-finished multiplayer/multiaircraft/network-data/network-interface implementations. What we need really isn't another one to plug into the mess, it's someone to *finish* the whole project and (if possible) throw out all the old junk that isn't used anymore. Andy ___ 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 .......
John Barrett writes: > 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 The NullFDM is just a place holder that does nothing. This is useful for cases when you want to update all the FDM variables from some other source (like an external program communicating via the net.) It doesn't do any interpolation or anything like that. Attaching the autopilot to it doesn't make sense. NullFDM does exactly nothing which is useful when you want the FDM functionality to come from somewhere else. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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. g. ___ 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: "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 .......
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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
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 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
