Re: [Flightgear-devel] [Proposal] Class-based MP aircraft visibility
Csaba Halász wrote: > On Fri, May 21, 2010 at 11:26 AM, Stuart Buchanan wrote: >> My proposal is that users may optionally set a class or community they >> are flying in (say /sim/multiplay/class) that is exposed over MP. >> >> For example: >> Default - the default >> Newbie - for new flyers >> Student - those training - might be reseting regularly >> FGCom - those using FGCom - implies they will use realistic radio procedures >> Dogfight - for those engaged in mock dogfights (ignored by default) >> Ignore - for those who wish to be ignore (ignored by default) > > While you are at it, it might be a good idea to incorporate some other > class too, such as "single engine ga", "2 engine jet" and so on. Then, > even if a client doesn't have the model, it could pick a similar > replacement. > > "Your" class could simply be preassigned transponder codes (ranges), > thus achieving two goals for the price of one (I am thinking of more > realistic ATC/IFR). I think the class of aircraft you fly is really orthogonal to the way that you are flying. My aim here is to create broad classes which are largely mutually exclusive, so users only select one, to represent the type of flying they are doing. There is certainly a case for including a "aircraft class" as a separate property. However, that would better be represented as a per-aircraft property to be exposed over MP, so the receiver could then choose the generic model to use. Of course, such an aircraft-class would also allow us to group aircraft more effectively within a launcher. However, that is really another enhancement :) -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Proposal] Class-based MP aircraft visibility
On Fri, May 21, 2010 at 11:26 AM, Stuart Buchanan wrote: > > My proposal is that users may optionally set a class or community they > are flying in (say /sim/multiplay/class) that is exposed over MP. > > For example: > Default - the default > Newbie - for new flyers > Student - those training - might be reseting regularly > FGCom - those using FGCom - implies they will use realistic radio procedures > Dogfight - for those engaged in mock dogfights (ignored by default) > Ignore - for those who wish to be ignore (ignored by default) While you are at it, it might be a good idea to incorporate some other class too, such as "single engine ga", "2 engine jet" and so on. Then, even if a client doesn't have the model, it could pick a similar replacement. "Your" class could simply be preassigned transponder codes (ranges), thus achieving two goals for the price of one (I am thinking of more realistic ATC/IFR). -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Proposal] Class-based MP aircraft visibility
On Fri, 21 May 2010, Stuart Buchanan wrote: > The obvious downside of this is that it may fragment the user-base. > However, if by default everyone is able to see everyone else, I think > that risk can be > minimized. > > Thoughts? Hi, Sounds like a pretty good idea. One technical comment: Given the current MP protocol and its less than ideal string encoding I'd rather not see yet another (mostly) constant string property being sent in every packet. The maximum packet size is limited after all. I'd suggest an int either with a well defined class assignment or, less reliably, a hash of the class string. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Proposal] Class-based MP aircraft visibility
Hi All, My patch to hide other MP aircraft opens the door to providing a useful function to allow multiple different communities of flyers to use the global FG airspace independantly, without requiring additional sets of MP servers. The main use-case is a group of pilots wishing to practise flying in a ATC-controlled environment (e.g. TGA events) using FGCom. They would like all the aircraft in the area to be on FGCOM, and behave as realistically as possible. Furthermore, they would prefer for new aircraft not to spawn on the runway, even though there are no define parking positions. At present, this relies on going somewhere outside of the default tile, and an element of luck that someone doesn't randomly turn up. Note that this is not really anyones fault - it's just a side-effect of sharing a single virtual world. My proposal is that users may optionally set a class or community they are flying in (say /sim/multiplay/class) that is exposed over MP. Using some Nasal, other users may choose to automatically hide or show aircraft from specific classes. The class itself would be free-form, but I would expect to define some standard classes along with a GUI to allow selection of the user's own class and the visible classes. For example: Default - the default Newbie - for new flyers Student - those training - might be reseting regularly FGCom - those using FGCom - implies they will use realistic radio procedures Dogfight - for those engaged in mock dogfights (ignored by default) Ignore - for those who wish to be ignore (ignored by default) So, in the use-case above, all the aircraft using FGCom under ATC would select a class "FGCom", and use a dialog to only display other aircraft in that class. If a new aircraft wanted to take part, they could spawn on the runway (having not set their /sim/multiplay/class), taxi to the parking area, set their class to FGCom, thereby making themselves visible, and contact ATC for taxi instructions. Other pilots just wanting to fly around would be able to see all these aircraft. Other use-cases include 1) A developer testing some aircraft systems that rely on MP, but not wanting to disturb other people. By setting a class of "Ignore" they would by default be ignored by all other aircraft. 2) A group of pilots wanting to engage in a dog-fight over San Francisco without disturbing other pilots. The obvious downside of this is that it may fragment the user-base. However, if by default everyone is able to see everyone else, I think that risk can be minimized. Thoughts? -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
