RE: [Flightgear-devel] Multiplayer, the next steps
Mathias Fröhlich wrote Oliver Schroeder wrote: ...snip > > 3) sending properties for the carrier (Nimitz) > > In order to prepare flightgear to send abitary properties, I think the > > carrier is predestined. Everything we need is almost already there. What > we > > need is a method in FGAICarrier which I can call from the network code > and > > is able to extrapolate position, speed etc from network data. As far as > I > > know, it should be sufficient to send position, speed and rudder angle. > > There is possibly more to say (eg. how to "elect" the feeder and what > > happens when the feeder dies etc). I have ideas on that, but we will see > > how to cope with that when we know how we actually handle carrier > > properties. > To that topic, I might be able to help. > Positions and speeds (both linear and rotational) together with a > timestamp > when this state is valid should be enough. From that you should be able to > predict the position in some way. > That is the way the carrier is moved below the FDM during one timestep. > Ask if you have questions for the extrapolation ... AICarrier passes the initial position, base course and speed to AIShip, which then handles the positional and rotational updates, which it passes back to AICarrier for further manipulation. If the carrier needs to alter course in response to a command or its simple AI rules, AICarrier passes tgt course and/or tgt speed to AIShip which uses these data to adjust position and orientation using some pragmatic calculations involving rudder angle, speed and turn radius, and passes them back to AICarrier. AIShip is not a Ship Dynamic Model - it uses some voodoo to simulate reasonably realistic ship movements. We should be able to adapt and use this mechanism to both update the carrier position from the network and extrapolate the current position/orientation between network updates. This method might or might not need the network update to be timestamped. We might try without first since this avoid the need to time-synchronize all players. > Also I think we should not focus on the carrier itself, I think we should > send > the data of an object like an aircraft or carrier or whatever over the > net. > Such a thing has positions (position and orientation) and a timestamp (may > be > something to identify the object). > Additionally it has a list of properties it needs to send (Some > deflections - > whatever). > In a first stage, I think, we can send just the propery names together > with > the values in each packet. > > In a second stage, think about a scheme where we do not need to resend the > mapping between the property names and the values in each packet. > May be a separation between a 'realtime packet' only having a uuid to > identify > the model and some minimal binary data and a 'uuid description' which > provides the mapping between the property values in the 'realtime packet' > and > the property names which need to be set from that values. > > For the election which properties need to be sent, there must be a, at > best > generic, mechanism to get that from the specific object (carrier, FDM, > ...). > Also Ideas, comments? > In general, Oliver's work plan seems a sensible way forward, and is supported. The inclusion of the carrier in the multiplayer environment is in particular a very worthwhile enhancement, which I think could be built on existing code without too much difficulty (famous last words):-). By choosing to work on the carrier first we can move incrementally to the longer term aim of making all MP objects AI objects, thus making use of existing methods of setting properties and extrapolating position etc. We should not lose sight of this aim when designing the necessary messages. We need to ensure that there is only one carrier named Nimitz in the environment. (Other names are of course available). We also need to ensure that the carrier model is moved smoothly otherwise I think there remains the possibility that any aircraft on deck will become detached and fall off. This might pose particular problems when initiating and/or updating. While there is some low-pass filtering in AIShip, this might need enhancing. We only need send data on initiation and then on change. So far as election of the feeder is concerned, network latency might do that for us, although some there might be some risk that a deadlock might occur. Just some explanation and further thoughts, hopefully helpful Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer, the next steps
Hi Oliver, On Sonntag 23 Oktober 2005 23:56, Oliver Schroeder wrote: > after some discussions here on the list, but most of the time on irc, I > have drawn some conclusions on how to improve the multiplayer mode. So, > here they are. Feel free to flame me on any part which might be awfully > wrong. Well, I for myself do not like irc, because of the fact that you never know when something important will happen. Also due to the time difference, we will never have most people there. Mail is much better IMO, because you can read when you have time ... So thanks for asking on the list too! And appologies if I rethink what you might have already told about on irc ... > 3) sending properties for the carrier (Nimitz) > In order to prepare flightgear to send abitary properties, I think the > carrier is predestined. Everything we need is almost already there. What we > need is a method in FGAICarrier which I can call from the network code and > is able to extrapolate position, speed etc from network data. As far as I > know, it should be sufficient to send position, speed and rudder angle. > There is possibly more to say (eg. how to "elect" the feeder and what > happens when the feeder dies etc). I have ideas on that, but we will see > how to cope with that when we know how we actually handle carrier > properties. To that topic, I might be able to help. Positions and speeds (both linear and rotational) together with a timestamp when this state is valid should be enough. From that you should be able to predict the position in some way. That is the way the carrier is moved below the FDM during one timestep. Ask if you have questions for the extrapolation ... Also I think we should not focus on the carrier itself, I think we should send the data of an object like an aircraft or carrier or whatever over the net. Such a thing has positions (position and orientation) and a timestamp (may be something to identify the object). Additionally it has a list of properties it needs to send (Some deflections - whatever). In a first stage, I think, we can send just the propery names together with the values in each packet. In a second stage, think about a scheme where we do not need to resend the mapping between the property names and the values in each packet. May be a separation between a 'realtime packet' only having a uuid to identify the model and some minimal binary data and a 'uuid description' which provides the mapping between the property values in the 'realtime packet' and the property names which need to be set from that values. For the election which properties need to be sent, there must be a, at best generic, mechanism to get that from the specific object (carrier, FDM, ...). Also Ideas, comments? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
Am Saturday 15 October 2005 11:30 schrieb Jim Campbell: > Anyone transmitting un-encrypted data across a world wide internet (as > opposed to a "private" intranet) needs to think ahead a little. Every > hacker will be rubbing their hands with glee before trying to hit you > on these ports you have just announced. A server/client or even > peer-to-peer client can implement TLS/SSL fairly easily. For those with > restricted firewalls you can tunnel through SSH port 22 if you want to > keep it simple. Firewall/NAT configurations are difficult enough for > admins to configure without having to allow special FlightGear port > rules to allow access to ports on machines in-the-clear which may then > get hacked thus compromising the security of everyone behind the > firewall. You are addressing serveral security issues at once and suggest encryption as one solution to all possible threads. First we have to differentiate between possible security issues and provide a solution for every single issue. A hacker who wants to threaten flightgear multiplayer users can easily read the source code and may find several possible bugs he can exploit, either for a denial of service attack or for gaining access to the remote machine or whatever. Encryption does not help at all, the bugs (if there are any) are still in the flightgear source and can be exploited. Additionally the encryption itself may be buggy and can lead to exploits. In case of distributed denial of service attacks, we (either the server or a client) are on the wrong end anyway. There is nothing we can do about it at all. The only way encryption can help is, if we use any kind of authentication to participate in multiplayer sessions, to prevent unregistered users to join. Which is something we possibly will implement if there are really a lot of people joining multiplayer sessions, and too many of them don't apply to any rules. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
Jim Campbell wrote: > Anyone transmitting un-encrypted data across a world wide > internet needs to think ahead a little. Every hacker will be > rubbing their hands with glee before trying to hit you on these > ports you have just announced. > [...] This really isn't much of an issue. The attack you posit is requires a man in the middle, and this is a very rare failure mode -- it essentially requires a compromised router somewhere between the client and server. It's very much not a script kiddy kind of attack; the "announcement" you mention requires elaborate preparation and a special case vulnerability to detect. > Maybe I am paranoid (well known for it in my previous job!) but > a denial-of-service attack on your multi-player ports will soon > wreck your response times! No one is going to care about DoSing a single FlightGear multiplayer client or server. There's no payoff there for the attacker. The scarier doomsday scenario would be a bug in the MP code (on either side) allowing an attacker to compromise the affected machines. But this is a problem for almost all network software, and can be productively treated by careful coding. There's a *lot* of unencrypted UDP software out there. If you *really* want to avoid having unencrypted packets going over the public internet, you can always do it over an encrypted tunnel (IPsec, VPN, ppp-over-ssh, etc...) without changing the current code at all. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
> > Anyone transmitting un-encrypted data across a world wide internet (as > > opposed to a "private" intranet) needs to think ahead a little. Every > > > > hacker will be rubbing their hands with glee before trying to hit you > > on these ports you have just announced. A server/client or even > > peer-to-peer client can implement TLS/SSL fairly easily. For those > > with restricted firewalls you can tunnel through SSH port 22 if you > > want to keep it simple. Firewall/NAT configurations are difficult > > enough for admins to configure without having to allow special > > FlightGear port rules to allow access to ports on machines > > in-the-clear which may then get hacked thus compromising the security > > of everyone behind the firewall. > > ..yes, but can ssh give us any good udp tunnelling? Depends on what one means by "good". It will be bearing the characteristics of the underlying ssh/tcp retransmits/jitter/timeouts. > > Maybe I am paranoid (well known for it in my previous job!) but a > > denial-of-service attack on your multi-player ports will soon wreck > > your response times! If this becomes a problem, it's easy to extend a protocol to allow out-of-band (wrt the current UDP channel) player registration on a server. Whatever way the registration goes, when it happens, the server would know each player's IP and UDP port and dropping everything else. For linux-based server, it can be done more efficiently by allowing on the server the UDP traffic from the registered players only via a companion script that would reconfigure the local in-kernel firewall rules, based on the current registration. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
On Sat, 15 Oct 2005 10:30:44 +0100, Jim wrote in message <[EMAIL PROTECTED]>: > Hi guys, > Without wishing to start a flame war and perhaps starting another > thread!! > Anyone transmitting un-encrypted data across a world wide internet (as > opposed to a "private" intranet) needs to think ahead a little. Every > > hacker will be rubbing their hands with glee before trying to hit you > on these ports you have just announced. A server/client or even > peer-to-peer client can implement TLS/SSL fairly easily. For those > with restricted firewalls you can tunnel through SSH port 22 if you > want to keep it simple. Firewall/NAT configurations are difficult > enough for admins to configure without having to allow special > FlightGear port rules to allow access to ports on machines > in-the-clear which may then get hacked thus compromising the security > of everyone behind the firewall. ..yes, but can ssh give us any good udp tunnelling? > Maybe I am paranoid (well known for it in my previous job!) but a > denial-of-service attack on your multi-player ports will soon wreck > your response times! > cheers > Jim ..try put an outboard in your kettle and casually wield a chainsaw on asking the white coat guys for constructive critisism. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer Location Transformation toLat/Lon/Alt
Hi, > Is there a plan to switch to OSG? Just wondering. I didn't know. I do not know of concrete plans, but here and then there are roumors. I for my own would apprecheate that, since it looks very promising. ... also a few weeks ago a small cvs checkin with some 'flightgear' path in it slipped into osg's cvs. So there must be people on it behind the scenes. :) > I think the current math utilities are self-documented adequately. One of > my obstacles has been learning the definition of the multiplayer interface, > so I know where to start. I think I am beginning to understand now. > > It appears the position is cartesian (ecef), but is the difference between > the player location and the center of _his_ current tile. The position is > in the fourth row of the 4x4, in the first three columns. The upper left > 3x3 represents the orientation. That depends a bit. The scenery center is in current cvs now locateable at any position. This fixes problems with roundoff and jumpy 3d objects near the eyepoint. In fact it is allways near the current eyepoint. > There has been much talk here about reworking the multiplayer model. I'm > guessing that the assumption that the other players are all on the same > tile will not be required in future versions. Are the current thoughts > toward sending absolute position across the wire? Would that be geodetic > or cartesian? (just gathering current thoughts, not definitive answers for > where this is heading) It looks like they will be cartesian. And IMO this is the preferred way, even if people find lat/lon more intuitive, cartesian coordinates are much more handy for nearly every kind of computation required to be done in this area. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] multiplayer patch for enianess
Ok, this is *way* better than what was there before! Thanks so far! What I have problems with is that, as long as you use a struct for the whole message, the compiler is free to do alignment decisions different than your expectations on it. I posted, at the time of the first attempts to fix that, a xdr stream implementation from the c++ journal. That one would guarantee independence of struct alignment. The ip address of the sender is redundant. I do at the moment not know the actual implementation of the udp socket we use here, but there must be a way to get them from the recv call (at least for the udp/ip case). Is that address used to send a reply? If so, this will not work for everybody behind a nat gateway which rewrites the ip headers but cannot know something about flightgears internals. Also why do you use fixed length strings? It seems better to me if there is a length field in front of the string data which tells the implementation how much characters it can expect (within the limits of the current udp connection of course). Also that xdr stream would not have the problem with returning hardware doubles if floats are returned by declaration (your comment in timy_xdr.h). I have access to a DEC alpha. I don't believe that I can run flightgear on that machine successfully and I doubt that there is a single alpha left on this earth where flightgear will be run on. So if you just want to be complete, I can help you with that, but my be we can ignore the DEC's ... Objections? So all together this is good work, but as we are on it, we might be able to make it fool proof :) Greetings Mathias On Montag 15 August 2005 10:02, Oliver Schroeder wrote: > Hi, > > I've written a patch that _should_ solve issues with endianess in > multiplayermode, which can be found at: > > http://www.o-schroeder.de/fg_server/patch.php > > Please try it out. Multiplayermode will still be broken on non > IEEE-encoding platforms (eg. Motorola 68XXX, vax, some DEC-alphas). > Since I have no access to those machines I can't help it. If you have > such a computer you may be able to provide the nessacary information > (ie. internal representation of floats/doubles), so I can fix this, too. > > regards, > Oliver > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
Hi. [EMAIL PROTECTED] wrote: Hi all! Yes, I know this topic has already been discussed and I know also that someone of you is working on the FG multiplayer code... anyway I think that it will be an advantage to the FG comunity to interface to IVAO and/or VATSIM networks. To implement VATSIM at least one of us has to sign a Non-Disclosure Agreement, which is simply a no go. One way to provide compatibility with other simulations and improve multiplayermode in general is e.g. DIS (Distributed Inteactive Simulation) protocoll, or HLA (High Level Architecture) or similiar. However, Flightgear isn't ready to implement such protocolls due to lack of nessecary infrastructure. Other clients in multiplayer mode are not part of the simulation, they are only displayed. Flightgear has a long road to go, before "real" protocolls can be implemented. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
You might want to go back and check the email archives almost a year ago. We had discussions with the VATSIMfolks and it went nowhere. There was some thought of starting a development for FG using the TNL libraries, set up a small network test, but it all faded away due to lack of interest... JW Andy Ross wrote: It's not about security jvrvez wrote: Ok, They don't want that a GPL tools is used to interface their network for secutity reasons (I think this is understandable) anyway why can't we join their network with their own code? This is a non-starter. There is simply no way to make this work, sorry. They can make their code (or protocol) available under terms we can use, or not. It's not something about which we are able to compromise. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
It's not about security jvrvez wrote: > Ok, They don't want that a GPL tools is used to interface their > network for secutity reasons (I think this is understandable) > anyway why can't we join their network with their own code? This is a non-starter. There is simply no way to make this work, sorry. They can make their code (or protocol) available under terms we can use, or not. It's not something about which we are able to compromise. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
"[EMAIL PROTECTED]" wrote: > [...] I think that it will be an advantage to the FG comunity to > interface to IVAO and/or VATSIM networks. Ok, They don't want that a > GPL tools is used to interface their network for secutity reasons For security reasons ? What a joke Indeed, participating in a VATSIM betwork would be really beneficial for FlightGear - it's just that poeple obviously don't know from which direction the possible risk might come from, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
On Sunday 14 August 2005 21:56, Erik Hofman wrote: > [EMAIL PROTECTED] wrote: > > Hi all! > > Yes, I know this topic has already been discussed and I know > > also that someone of you is working on the FG multiplayer code... > > anyway I think that it will be an advantage to the FG comunity to > > interface to IVAO and/or VATSIM networks. Ok, They don't want that a > > GPL tools is used to interface their network for secutity reasons (I > > think this is understandable) > > I'm opposed to it because it imposes a security risk to FlightGear. > There's no way of knowing how secure their code is without the > possibility to look at it. > > Erik I'd be opposed to it to for the above mentioned and that VATSIM appear to only cater for the Windows OS. FlightGear has a diverse userbase using everything from SGI thru Linux to Mac so it would seem to be somewhat unsuitable for FlightGear. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
[EMAIL PROTECTED] wrote: Hi all! Yes, I know this topic has already been discussed and I know also that someone of you is working on the FG multiplayer code... anyway I think that it will be an advantage to the FG comunity to interface to IVAO and/or VATSIM networks. Ok, They don't want that a GPL tools is used to interface their network for secutity reasons (I think this is understandable) I'm opposed to it because it imposes a security risk to FlightGear. There's no way of knowing how secure their code is without the possibility to look at it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Multiplayer Location Transformation toLat/Lon/Alt
> Well, if my hackery here must server as a reference for that, I think we > should improove the framework around that stuff and we should > document that > better. > By improoving that framework, I can well imagine to abstract from > the vector > classes provided from plib, so that for that time we really > switch to Open > SceneGraph, we can just change that abstraction to be compatible with the > osg::* classes instead of changes several hundred places where > they occure. > > Added to my allways growing todo list. > :) > > Apart from that, you may look at > > http://www.flightgear.org/Docs/Scenery/CoordinateSystem/Coordinate > System.html > > Greetings > >Mathias > > -- > Mathias Fröhlich, email: [EMAIL PROTECTED] Thanks, Mathias. Is there a plan to switch to OSG? Just wondering. I didn't know. I think the current math utilities are self-documented adequately. One of my obstacles has been learning the definition of the multiplayer interface, so I know where to start. I think I am beginning to understand now. It appears the position is cartesian (ecef), but is the difference between the player location and the center of _his_ current tile. The position is in the fourth row of the 4x4, in the first three columns. The upper left 3x3 represents the orientation. There has been much talk here about reworking the multiplayer model. I'm guessing that the assumption that the other players are all on the same tile will not be required in future versions. Are the current thoughts toward sending absolute position across the wire? Would that be geodetic or cartesian? (just gathering current thoughts, not definitive answers for where this is heading) Highest Regards, Jim A ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer Location Transformation to Lat/Lon/Alt
On Donnerstag 11 August 2005 13:26, Vivian Meazza wrote: > Look in src/AIModel/AICarrier.cxx - there are several examples of > conversions from Cartesian co-ordinates to geodetic and vice versa. > > There are a wide range of utilities in simgear/math.cxx. The comments are > in the most part self-explanatory, so you will probably find what you need > there. Well, if my hackery here must server as a reference for that, I think we should improove the framework around that stuff and we should document that better. By improoving that framework, I can well imagine to abstract from the vector classes provided from plib, so that for that time we really switch to Open SceneGraph, we can just change that abstraction to be compatible with the osg::* classes instead of changes several hundred places where they occure. Added to my allways growing todo list. :) Apart from that, you may look at http://www.flightgear.org/Docs/Scenery/CoordinateSystem/CoordinateSystem.html Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: RE: [Flightgear-devel] Multiplayer Location Transformation to
> > From: "Vivian Meazza" <[EMAIL PROTECTED]> > Date: 2005/08/11 Thu AM 07:26:23 EDT > To: "'FlightGear developers discussions'" > Subject: RE: [Flightgear-devel] Multiplayer Location Transformation to > Lat/Lon/Alt > > Alberico Family > > > Jim Wilson did a good job of pointing me in the right direction toward > > making views attached to players in a multiplayer scenario. > > > > I attack it today and made good progress, but remain bogged down by the > > transformations required. Bottom line is I need to take the 4x4 player > > position matrix and convert that to what is needed by the view properties > > (lat/lon/alt, etc.) The objective is to dynamically alter custom view(s), > > based on player positions(/orientation). > > > > A 2-part question, with hopes no one has to spend much time answering: > > 1.) Can someone point me to a good writeup on the details of the various > > coordinate systems and transformations in FG? (sorry: I'm sure that's > > been > > asked many times) > > 2.) Is there a utility method existing somewhere in the code already to do > > these specific transformations? It seems unlikely this is the first time > > someone is interested in taking the player positions and converting them > > to > > lat/lon/alt. > > > > Thanks in advance. Maybe this will all become clear to me after tomorrow > > morning's coffee(s). > > Look in src/AIModel/AICarrier.cxx - there are several examples of > conversions from Cartesian co-ordinates to geodetic and vice versa. > > There are a wide range of utilities in simgear/math.cxx. The comments are in > the most part self-explanatory, so you will probably find what you need > there. > > Hope you succeed - we really need this one. > > Vivian > Thanks, Vivian. Oops on the silly name (Alberico Family) on this account. :-) I'll take a look at AICarrier.cxx for conversion examples. Only 1/4 of the way thru the 1st coffee, so far. ;-) Jim (just Jim) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Multiplayer Location Transformation to Lat/Lon/Alt
Alberico Family > Jim Wilson did a good job of pointing me in the right direction toward > making views attached to players in a multiplayer scenario. > > I attack it today and made good progress, but remain bogged down by the > transformations required. Bottom line is I need to take the 4x4 player > position matrix and convert that to what is needed by the view properties > (lat/lon/alt, etc.) The objective is to dynamically alter custom view(s), > based on player positions(/orientation). > > A 2-part question, with hopes no one has to spend much time answering: > 1.) Can someone point me to a good writeup on the details of the various > coordinate systems and transformations in FG? (sorry: I'm sure that's > been > asked many times) > 2.) Is there a utility method existing somewhere in the code already to do > these specific transformations? It seems unlikely this is the first time > someone is interested in taking the player positions and converting them > to > lat/lon/alt. > > Thanks in advance. Maybe this will all become clear to me after tomorrow > morning's coffee(s). Look in src/AIModel/AICarrier.cxx - there are several examples of conversions from Cartesian co-ordinates to geodetic and vice versa. There are a wide range of utilities in simgear/math.cxx. The comments are in the most part self-explanatory, so you will probably find what you need there. Hope you succeed - we really need this one. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] multiplayer doesn't work properly
On Wed, 9 Jun 2004 17:39:08 -0400 Ampere K. Hardraade wrote: > Could there be a connection between this and the problem pointed out by Dave > in the Air Refueling thread? There probably is a connection. Actually, to be more precise than in my last post, it's not the delay itself that causes the jitter, it's the randomness of the delay, which makes packets arrive just after or just before rendering. I think it happens with or without threading as far as the network is concerned, but only with threading if it's an AI model. Here's an explanation with numbers; at 50 fps, maximum time difference = 1/50 s, speed = 400kt = 200 m/s (approx), distance of the jitter = speed * time = 4m = 13ft. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer doesn't work properly
Could there be a connection between this and the problem pointed out by Dave in the Air Refueling thread? Regards, Ampere On June 9, 2004 02:02 pm, Jorge Van Hemelryck wrote: > I wouldn't say that "multiplayer doesn't work properly", I'd rather say > that it's still in early stages of development. The effect you see is > probably due to the delay due to sending packets across the network. You > see movement of the other aircraft along its axis because you try and > match the velocity. Network delays are converted into distance (d=v*t), > and it could probably be fixed by using interpolation on the receiver > side. I haven't had time to do it yet. Maybe a Kalman filter would be a > good idea. Is no one else working on it ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer doesn't work properly
I wouldn't say that "multiplayer doesn't work properly", I'd rather say that it's still in early stages of development. The effect you see is probably due to the delay due to sending packets across the network. You see movement of the other aircraft along its axis because you try and match the velocity. Network delays are converted into distance (d=v*t), and it could probably be fixed by using interpolation on the receiver side. I haven't had time to do it yet. Maybe a Kalman filter would be a good idea. Is no one else working on it ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer
Chris Horler wrote: Gents, Has anyone tried multiplayer? I haven't, but wondered if any representation of other a/c was in the property tree? Not yet, but if the multiplayer code starts using the AIModel code it will. This hasn't been done and (although I would like to) I don't think I can find enough time to get to that very soon. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer FlightGear
* Luca Masera wrote: > I'm new here. Welcome > I'm trying to use FlightGear as the core of a distribuited > flight simulator. I've a great problem about the loading > of more then one aircraft (I've read something about it in > the developers digest, but I didn't understand much) and > the lack of documentation about multiplayer settings of > FlightGear. I've the Win32 version of release 9.3 of the > sim, but I'm not able to undestand how to configurate the > network. There's someone that could help me? the docs is in docs-mini/README.multiplayer Unfortunately, current fgrun doesn't allow you to input the --multiplay option, so you have to start fgfs.exe from the command line. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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)? > It's a waste of bandwidth. The volume of data is immense and you want to make your data packets as efficent as possible. The smaller you can make your data, the less chance there is of warping, teleporting, etc. g. ___ 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] 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)? Regards, -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Tuesday 11 November 2003 09:46 am, Ima Sudonim wrote: > OK, while I'm an avowed lurker, I find that this thread has even more > possibilities Wow, is "Sudonim" our first troll, or have there been others? Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> > Well I feel like a total idiot right now. Everything I'm thinking about > > that needs to be done has already had the core done. *slaps forehead* > > The entire groundwork has been laid by the contents of the src/Network > > directory. The work done for OpenGC stands as a great example of building > > an external plug-in. I suspect that "generic.cxx" defines a method of > > building an interface via an XML configuration file, but I need to study > > (and understand!) it further. Is there anything that uses this generic > > interface? I'd like to see an example of the XML it reads if possible.. > > There is a configuration file in FlightGear/data/Protocol/ > At this moment it is an ASCII output protocol only implementation but it > wouldn't bee too hard to add input support also. > Thanks Erik. I'll take a look at it tonight when I get home. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle wrote: Well I feel like a total idiot right now. Everything I'm thinking about that needs to be done has already had the core done. *slaps forehead* The entire groundwork has been laid by the contents of the src/Network directory. The work done for OpenGC stands as a great example of building an external plug-in. I suspect that "generic.cxx" defines a method of building an interface via an XML configuration file, but I need to study (and understand!) it further. Is there anything that uses this generic interface? I'd like to see an example of the XML it reads if possible.. There is a configuration file in FlightGear/data/Protocol/ At this moment it is an ASCII output protocol only implementation but it wouldn't bee too hard to add input support also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status [now C++]
> If you start a project and need OO features, either do it properly (in > Python or Objective-C), or do it the hard way with GLib/GObject. > Naw, Object Pascal is my first love. :) > I'd better shut up on the mailing list of a giant project written in > C++... I still admire you folks for getting it this far even with C++! > Well look at it this way, maybe they're too brain fried to go after you. :) *gd&r* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status [now C++]
> If C++ doesn't scare you, you have no business using it.
>
> Sorry, but that was just too open. I had to take the shot. But
> seriously, there's more truth in that statement than a sarcastic
> retort like it deserves. The time to run screaming from a project is
> the moment the architect declares that it *has* to be written in C++
> because no other language will do. I'm serious; use with caution. :)
I fully second Andy here.
If you want to learn about object-oriented programming, C++, Java,
PHP, etc. is the wrong place to start. Get
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf
and read the introduction to OO programming. It really gives you the
insight you need to understand C++ and also what's wrong with it.
Pity Objective-C never really made it outside of {Next,Open,GNU}Step.
If you start a project and need OO features, either do it properly (in
Python or Objective-C), or do it the hard way with GLib/GObject.
I'd better shut up on the mailing list of a giant project written in
C++... I still admire you folks for getting it this far even with C++!
Andras
===
Major Andras
e-mail: [EMAIL PROTECTED]
www:http://andras.webhop.org/
===
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle wrote: > Paul Surgeon wrote: > > Why does C++ scare you? > > Well "scare" is probably too strong a word. :) I'm just unfamiliar > with it. I can follow C ok, but the object references tangle me for > some odd reason. If C++ doesn't scare you, you have no business using it. Sorry, but that was just too open. I had to take the shot. But seriously, there's more truth in that statement than a sarcastic retort like it deserves. The time to run screaming from a project is the moment the architect declares that it *has* to be written in C++ because no other language will do. I'm serious; use with caution. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle <[EMAIL PROTECTED]> said: > > 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 know you did :-) That was just a repeat for the benefit of others. Most everyting that has been discussed in this thread sounds very interesting. I am eagerly awaiting the results! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> > 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 :) > Well I feel like a total idiot right now. Everything I'm thinking about that needs to be done has already had the core done. *slaps forehead* The entire groundwork has been laid by the contents of the src/Network directory. The work done for OpenGC stands as a great example of building an external plug-in. I suspect that "generic.cxx" defines a method of building an interface via an XML configuration file, but I need to study (and understand!) it further. Is there anything that uses this generic interface? I'd like to see an example of the XML it reads if possible... I think that for non-visual systems, you could have "sub-assembly" programs running that all talk to FG via the already present network layer. Since it's basically "localhost" stuff, it should be as fast as it would ever need to be. Is that a valid assumption? > Now -- how much does one of these physical cockpits cost ?? I want one for > the basement :) The "correct" answer is "How much you got?" :) In all seriousness, you can spend as little or as much as you'd like. A first place to stop is http://www.simpits.org and join the mailing list. We're always happy to see a new vic^H^H^Hhobbiest join our little group. There are examples from my F-15C, to scratch build F-16s and a home-made 777. A recent discussion on rivets was started by pics of a new guys' "Vultee Vulture", a fictious WWII era airplane named for the Vultee logo that is on the rudder pedals he's using. (The seat came out of a BT-13) g. ___ 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] 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. :) g. ___ 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
> > > 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. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> I also come from a Delphi background but find the switch very easy. Great! I'll help you write the server in Delphi. We can cross compile with FPC. *laughs* > Why does C++ scare you? > Well "scare" is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. The last time I tried getting my feet wet in code here got me bitched out by the plib author for basically not doing something his way. Instead of giving him precise and graphic instructions about what he could do with "his way", I dropped it and walked away. These days I'd be just as likely to have verbally shot his high horse out from under him and beat him stupid with the corpse. :) I never have taken well to unhelpful criticism(sp!) > > Do you know of a small paper quick reference that's any good? > > A reference for the C++ language syntax or for C++ libraries? Just a syntax ref would be nice. O'Reilly makes a neat one for PHP but I don't know about any C++ offering they have. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> > > > > Thanks Paul. I pay my mortage with Delphi, VB & Pick. My C/C++ skills > > are just enough to be able to identify it on sight and begin running the > > other way. :) > > Sounds like you need a varient of the following t-shirt (credit to > Mark Barry.) > > http://www.markbarry.com/pictures/bombtech.jpg > Yep, pretty much. g. ___ 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
On Monday, 10 November 2003 23:40, Gene Buckle wrote: > Thanks Paul. I pay my mortage with Delphi, VB & Pick. My C/C++ skills > are just enough to be able to identify it on sight and begin running the > other way. :) I also come from a Delphi background but find the switch very easy. Both support OOP. Both support pointers (C++ does it MUCH more easily BTW) Both use similar language structures (just slight syntax differences) Why does C++ scare you? > Do you know of a small paper quick reference that's any good? A reference for the C++ language syntax or for C++ libraries? C++ apps tend to use many different libraries so you really need documentation for each of them. I use glibc docs, libstdc++ docs, opengl docs, etc and then if I can't find anything I search the library source code for key words. :) If you manage to find an all-in-one let me know! Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: > > > Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need > > > it. *g* > > > > Not sure if you're just kidding or serious ... > > There's plenty of free C++ info online but here are a couple of free books : > > > Thanks Paul. I pay my mortage with Delphi, VB & Pick. My C/C++ skills > are just enough to be able to identify it on sight and begin running the > other way. :) Sounds like you need a varient of the following t-shirt (credit to Mark Barry.) http://www.markbarry.com/pictures/bombtech.jpg 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 Server RFC -- Current Status
> > Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need > > it. *g* > > Not sure if you're just kidding or serious ... > There's plenty of free C++ info online but here are a couple of free books : > Thanks Paul. I pay my mortage with Delphi, VB & Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) > http://cpp-home.com/tutorials/ << excellent tutorials for n00bs to pro > This looks like what I'm after. Thanks! > I'm not a very good C++ programmer and I keep forgetting stuff so I'm forever > referring back to my library of downloaded tutorials, books, etc. > Maybe I'm not the only one. :) > Do you know of a small paper quick reference that's any good? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 22:40, Gene Buckle wrote: > Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need > it. *g* Not sure if you're just kidding or serious ... There's plenty of free C++ info online but here are a couple of free books : Bruce Eckel's Thinking in C++, 2nd Edition http://www.mindview.net/Books/DownloadSites If you're programming on the Linux platform Advanced Linux Programming (threads, processes, IPC, etc) http://www.advancedlinuxprogramming.com/downloads.html Good sites with links : http://www.thefreecountry.com/documentation/onlinecpp.shtml http://www.cprogramming.com http://cpp-home.com/tutorials/ << excellent tutorials for n00bs to pro I'm not a very good C++ programmer and I keep forgetting stuff so I'm forever referring back to my library of downloaded tutorials, books, etc. Maybe I'm not the only one. :) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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. > 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
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> > Hey Gene since I am the one who initially brought up the issue > I guess you are the one responsible for my ears burning :-) > Wasn't me. I'd chase down the guy with the matches. :) > > What I *was* objecting to and *will* continue to object to is a 'primary goal' > of 'blow them out of the sky' and any attempts at turning the goal of FGFS > into such !! > We both agree on this. My only concern is the blocking of shared technologies from the source repository simply because it's used by other portions to support combat features that are not practically implementable as a plug-in. g. ___ 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
> 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 glass 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. > We could also add some sort of online, persistent, dynamic, war engine for > multiplayer missions. > *eyes glaze over* Oooh. *wistful sigh* > 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! > What is the chief goal/aim of FG? > I thought it was trying to simulate just general and commercial aviation. > > However having said that I would love an F16 multiplayer simulation. :) > BUT not at the expense of general aviation. > Of course not. The two genres can live together quite well as long as there are not any squabbling about the glue points between the two worlds. Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: > > I read the whole post. Really! :) Hey Gene since I am the one who initially brought up the issue I guess you are the one responsible for my ears burning :-) However note I never objected to the presence of munitions in FlightGear. http://baron.flightgear.org/pipermail/flightgear-devel/2003-November/022301.html http://baron.flightgear.org/pipermail/flightgear-devel/2003-November/022310.html What I *was* objecting to and *will* continue to object to is a 'primary goal' of 'blow them out of the sky' and any attempts at turning the goal of FGFS into such !! Since FGFS is OpenSource with many parts designed to be library components it shoudn't be too hard for anyone wanting such a system to build it on top of FGFS. If there is 'dual use' code that would be useful in a general purpose SIM then it is probably better placed in FGFS then in another project but IMO any 'shoot em up' should be in another project as there is little to be gained from having it in FGFS and ptentially at least a lot to lose. Also please note our goals are succintly stated on our home page < actually the introduction page now > """ The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application """ Granted some may see Combat and Gaming as falling under 'other interesting' or 'sophisticated' flight simulation but that's a mighty *big* stretch in my book :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: > 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. I should just stay out of this, but let me just say one thing. I don't think the problem is so much the presence of virtual guns and virtual shooting. Most of us have played our share of video games over the years and starting with the Apple ][+ I've blown away more than my share of virtual bad guys. I think the problem is more that FlightGear could (or in a few small cases is/was) being used by companies in conjunction with developing military sims or developing things in support of military sims. Note I'm not saying that flightgear is being used in a full, all out military combat training setting ... I'm not aware of that being true. But as we move forward, the Flightgear structure is just as attractive to companies with military contracts as it is to companies with purely civilian goals. Personally, I don't think there's any way around that. I could be a bread maker and some of that bread could be fed to combat troops fighting for some cause I don't necessarily agree with. Does that mean I stop making bread altogether? The US military found that condoms were immensely useful for keeping sand out of their rifles in Iraq. They sent over truckfulls of condoms. Does that mean we should stop producing condoms? I'm guessing there are probably a lot of opinions on that subject, few having anything to do with the military applications. I think people have to weigh the pros and cons and ultimately make a decision based on their best conscience, and we need to in turn respect that. But FlightGear is open-source and licensed under the terms of the GPL, so anyone who abides by our terms is free to use it. That's part of the nature of a free society I guess. Personally, I think that if a person is opposed to war (which I believe is a reasonable position in most cases) they can probably find a lot more effective things to further there cause besides abandoning FlightGear. And I should say that personally, my focus for FlightGear is accurate, realistic, FAA certifiable civilian training simulators. I'll generally oppose anything that takes away from that, and generally be as flexible as possible for other people to achieve thier various goals within the FlightGear framework. 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 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. 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. We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. 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 ... What is the chief goal/aim of FG? I thought it was trying to simulate just general and commercial aviation. However having said that I would love an F16 multiplayer simulation. :) BUT not at the expense of general aviation. Paul ___ 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
> > > 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. 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. g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one if its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle <[EMAIL PROTECTED]> said: > > > 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 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. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
> An earlier thread mentioned some other things including a Reno race course > based game. That would be very interesting. > Agreed! It would be a great feature to spur the development of 1930's era racers too. > it offensive to even have source code included that discusses in weapon terms, > To me this is absurd to the extreme. I've been watching this discussion with _great_ interest. I'll freely admit that I would benefit to a great deal if combat features are added to FlghtGear. The benefit would be the ability to fully "enable" all the A/A & A/G features of my F-15C project. I can understand that there are those that don't like the idea of combat features in FG. That's fine, but don't even _think_ about making it difficult for people to add those features if they're willing to put the time into the project. If you don't want munitions available in your copy of FG, no problem. I'm sure the fine folks that are going to be working on this could go so far as to make it a compile time option. A plug-in feature would be a good idea for things like avionics systems, radar, TCAS, etc. Even a plug-in system that defined the flight model and guidance computers of an A/A missile would be a good idea. However, critical elements such as collision detection needs to be built into the core engine. Collision detection will be a core feature of both combat and non-combat situations. The simulator needs to know when to bust your nosegear when you accidentally run over a taxiway sign as well as foul up the FDM of the airplane I just sawed in half with my M61A1. There has been some mention of the potential problem of the non-combat types being engaged against their will on a multi-player server. This should be a non-issue simply by reason of a guns/no-guns flag on the server. That way even if John Q. Griefer decides to go bunny hunting with his F/A-18, he wouldn't be able to release anything or fire his guns, or for that matter even be able to collide with you on purpose. Problem solved. Another option could be to add a similar flag for the client so that people that have combat mode selected won't even see the non-combat players on the server. This would allow one server to be used by all. At any rate, when someone comes up to you and offers to add some neat features, don't slap 'em in the face over stuff you find "objectionable". If you don't like it, change the damn channel (./configure --with_combat=NO) and leave the rest of us to our toys. g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ 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
Jon Berndt <[EMAIL PROTECTED]> said: > > 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. > > 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". > > > 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. > > Are there *analogues* to combat that could be made an enjoyable and > ethically acceptable part of FlightGear such that those who wanted > "simulated combat training" or "historical battle reenactments" to be > present could make them be present? > An earlier thread mentioned some other things including a Reno race course based game. That would be very interesting. I tend to be in the non-weapons camp. There may be some (not myself) who find it offensive to even have source code included that discusses in weapon terms, so it might be wise to bring up an RFC thread on that when the time comes. It seems to me that generic the FDM and AI functions that have been discussed here could serve as an underlying layer for the type of things that both John and Lee mentioned. Perhaps these specific applications like a Reno race game, search and rescue, and combat features could be handled as seperate pluginable projects that run on top of a multi user simulation layer that has all the capabilities including Jon Berndt's child FDM concept. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
"John Barrett" <[EMAIL PROTECTED]> wrote: > What this gets us: [...] > 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 [...] I'd like to plug a possible scenario here that didn't get mentioned yet: People running FGFS on a machine without direct internet connection, no masquerading, not port-forwarding. These people read their web-pages via Squid and get their EMail from a local mail- gateway. These people would me delighted to see the FG server function as a proxy on their internet gateway - also a scenario that would fall under "distributed server environment". Just as a side note Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Sun, 9 Nov 2003, John Barrett wrote: > 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 :) Ahaaa, now you've reminded me of the fun I had in early versions of MSFS - the crop dusting game was extremely good fun. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett wrote: "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) -- This basically asks for an autopilot only FDM. It might be worth a few minutes of programming to extend the NULL FDM with autopilot functionallity. > 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 This is done in the ATC code of David Luff. 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) This doesn't sound too difficult either. 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) 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. 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett wrote: 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. SimGear provides random functions that give the same result on every platform provided they use the same seed and the same access order. That way we were able to synchronize the random objects across different displays in a multi-display system. Erik ___ 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
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes: > > Norman Vine writes > > > > Please - remember FGFS is not a flat earth system > > 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 Or perhaps use an appropriate global tesselation that just happens to make finding all entities within some distance trivial by just checking those buckets that are within the distance criteria. Then by just keeping track of which bucket all entities are in the operation is just a trivial check of the pertinent buckets lists :-) This mechanism would be useful for *many* related lookups and is an elegant solution to the spherical distance query. < it just happens to be similar to what is used in several actively pursued star search projects which have the exact same *heavily* researched problem albeit an inverted manifestation > AFAIK all such tesselations are built from either (1) spherical triangular facets or (2) their mathematical dual the corresponding spherical 'dirchlet' or 'vornoi' tesselation. There are several papers desribing these and other global grids at the link I posted recently in the Re: [Flightgear-devel] Some thoughts and ideas (LONG) thread trying-to-practice-what-Columbus-proved'ly yr's Norman ___ 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
On Sunday 09 November 2003 22:23, John Barrett wrote: > > - 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) > 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. 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. 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;) 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. 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. LeeE ___ 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
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 Norman ___ 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
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). -- Jon Stockill [EMAIL PROTECTED] ___ 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 5:54 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status > On Sun, 9 Nov 2003, John Barrett wrote: > > > 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) > > Presumably you could just have a client config which specified the area of > interest, and have the server send out only arcraft within that - > obviously this imposes a higher load on the server though - maybe it'd be > possible to do a very coarse cull on the main server, and output data to > regional machines - if the protocols are consistent throughout then you'd > end up with a scalable system which should (in theory) be able to cope > with an awful lot of aircraft, controllers, etc etc. > > As the system expanded then more "localised" features could be implemented > further down the chain. > 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Sun, 9 Nov 2003, John Barrett wrote: > 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) Presumably you could just have a client config which specified the area of interest, and have the server send out only arcraft within that - obviously this imposes a higher load on the server though - maybe it'd be possible to do a very coarse cull on the main server, and output data to regional machines - if the protocols are consistent throughout then you'd end up with a scalable system which should (in theory) be able to cope with an awful lot of aircraft, controllers, etc etc. As the system expanded then more "localised" features could be implemented further down the chain. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I think that is pretty much what I was angling for, just more clearly vocalized. :-) Thanks, Curt. John Barrett writes: > 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 ?? ) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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 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
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. LeeE ___ 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 ?? ) ___ 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
> 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. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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. 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 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
> 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. 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". > 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. Are there *analogues* to combat that could be made an enjoyable and ethically acceptable part of FlightGear such that those who wanted "simulated combat training" or "historical battle reenactments" to be present could make them be present? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Jonathan Richards writes: > What I value about FlightGear is that it attempts to *simulate* the > real world > and aviation in it. The landscapes and the airports are realistic, the > weather is (can be made) realistic, the celestial objects are realistic, the > flight dynamics themselves are realistic, and there is superb work done on > making the objects (scenery and planes) look good. > 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). I've just started reading through the multiplayer thread. Good to see some action on this front and it sounds like you guys know a lot more about it, and have a lot more experience with the issues than I do, so I'll generally just sit back and leave this to the experts. However, let me point out that some people have a big problem with even pretending to shoot people. Personally, I have no problems with shoot 'em up games as long as you don't play them so much you start dreaming about it. :-) We should recognize however that many people feel *very* strongly about this ... strong enough to leave this project if they sense we are trending towards a pure combat sim. 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. 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 -- 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] 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
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.
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.
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.
Andy
--
Andrew J. RossBeyond the OrdinaryPlausibility Productions
Sole Proprietor Beneath the Infinite Hillsboro, OR
Experience... the Plausible?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 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 :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
