Re: [Flightgear-devel] Ignoring MP pilots
Rob Shearman, Jr. wrote: Martin Spott: plus, maybe, one button to ignore the entire chat (if that one doesn't already exist), Off the top of my head, I think there's a checkbox with that effect in the rendering options panel? -R. (MD-Terp) Quite right, there's one in Display Options. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Tom, I don't think there is anything particularly wrong with your suggestion, just that it does not meet the original remit, which was to be able to ignore players who were not following the rules, either intentionally or through ignorance. We already almost have what you propose with ports 5000/5002. Which reminds me: IIRC 5001 is reserved for telnet. We rarely use 5002 for development nowadays, so I suppose there is nothing stopping a bunch of like-minded guys using that. However, I just have a final reservation - MP was meant to be the global picture of the airspace - not just a part. That said perhaps we do need a ban/kick/ignore like IRC for MP. We have stepped around this issue in the past. Vivian -Original Message- From: Tom P [mailto:zomm...@gmail.com] Sent: 15 November 2009 20:32 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Ignoring MP pilots Hi Vivian I think that a majority of users configures MP through a launcher interface, so the convention would be enforced through the UI. The launcher (fgrun or other) would show a drop-down menu with the Groups (their name) that a user can join. The port numbers that I showed were an example, I showed 5000-5005 to keep backward compatibility with the current setup (5000 = beginners seems like a good default group for the current installed base), but any consecutive range of 5 or 10 available ports will do. About non-complying users, I don't think it would be a great problem. By choosing a particular group, they choose to comply with the intent of the group, and we can write down such intent explicitly in a UI text box based on the selected group, if you feel like. An example: Beginners Welcome to FG. This group allows you to get familiar with FG and learn from fellow pilots. Under Air Traffic Control In this group, pilots fly under Air Traffic Control. By joining, you are required to comply with ATC rules, please see the details at http://wiki.flightgear.org/. http://wiki.flightgear.org/ .. Fighters on a mission This group is dedicated to flying military aircrafts, simulating missions and dogfights. Tom On Sat, Nov 14, 2009 at 1:56 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Pete Morgan Tom P wrote: Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom I like this idea a lot :-) Nice theory - in practice how do you ensure that users both know about, and, more importantly, observe the convention? And, what do you do if they don't? IIRC 5001 is used for telnet, but 5002 is rarely used for development. I suppose that some serious users could use that port by mutual agreement, accepting that some less serious players might try to join in as well. The client side ignore device seem to have more practical merit to me. Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Pete Morgan wrote: Seperate ports are gonna be a problem with firewalls. Is there a way to create a group using the callsign? eg my_group:callsign ? just a thought. Pete My personal preference is to simply to expand the Ignore option to hide the AI model on the client-side. Should be pretty straightforward to do and doesn't require any messing around with the MP connection. Adding an additional check-box to the pilot dialog to hide the model separately from the chat feels a bit overly complicated. If I want to ignore someone on chat, chances are I don't particularly want to see them either, so a single checkbox on the pilot dialog could serve both purposes. On a related note, I believe Jester finished the work that I had originally intended in the MP chat to provide per-frequency chat, rather than a single global frequency. Now that we have FGCom, I suspect there's a lot less need for this than there was, but it would be a nice addition, and a simple way to ignore all the MP chat traffic at KSFO ;) If we feel that groups are a good idea, an enhancement to Pete's suggestion above would be easy to implement and provide a very flexible function if we have client-side ignore: 1) Each client transmits a /sim/user/group property over MP 2) A dialog backed by some Nasal allows selection of your group (freeform/dropdown) and selection/deselection of specific groups to display or ignore. 3) As new MP clients join, the Nasal code ignores them automatically based on their group and your rules. This would allow very flexible filtering for a number of useful scenarios: 1) People wanting to fly in a specific group without any other MP people can simply create an ad-hoc group and select to display only that group. 2) Some pre-defined groups (FGCom, ATC, Beginners, Default) would allow standard groups to be displayed/ignored easily -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
On Mon, 16 Nov 2009, Stuart Buchanan wrote: Pete Morgan wrote: My personal preference is to simply to expand the Ignore option to hide the AI model on the client-side. Should be pretty straightforward to do and doesn't require any messing around with the MP connection. Adding an additional check-box to the pilot dialog to hide the model separately from the chat feels a bit overly complicated. If I want to ignore someone on chat, chances are I don't particularly want to see them either, so a single checkbox on the pilot dialog could serve both purposes. Hi all, I agree. /aol In addition to that mp_broadcast.nas, which is the communication layer of WildFire (among other things), can easily be extended to use the same ignore property to ignore selected users. If we feel that groups are a good idea, an enhancement to Pete's suggestion above would be easy to implement and provide a very flexible function if we have client-side ignore: 1) Each client transmits a /sim/user/group property over MP With the current state of our MP system I would strongly suggest that we let the group property be an integer if we decide to add it. Strings are still expensive (in terms of size) to send. The number could e.g. be a hash of the group name. Besides, 2^32 groups ought to be enough for anyone ;) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Stuart Buchanan wrote -Original Message- From: [mailto:stuart_d_bucha...@yahoo.co.uk] Sent: 16 November 2009 12:44 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Ignoring MP pilots Pete Morgan wrote: Seperate ports are gonna be a problem with firewalls. Is there a way to create a group using the callsign? eg my_group:callsign ? just a thought. Pete My personal preference is to simply to expand the Ignore option to hide the AI model on the client-side. Should be pretty straightforward to do and doesn't require any messing around with the MP connection. Adding an additional check-box to the pilot dialog to hide the model separately from the chat feels a bit overly complicated. If I want to ignore someone on chat, chances are I don't particularly want to see them either, so a single checkbox on the pilot dialog could serve both purposes. On a related note, I believe Jester finished the work that I had originally intended in the MP chat to provide per-frequency chat, rather than a single global frequency. Now that we have FGCom, I suspect there's a lot less need for this than there was, but it would be a nice addition, and a simple way to ignore all the MP chat traffic at KSFO ;) If we feel that groups are a good idea, an enhancement to Pete's suggestion above would be easy to implement and provide a very flexible function if we have client-side ignore: 1) Each client transmits a /sim/user/group property over MP 2) A dialog backed by some Nasal allows selection of your group (freeform/dropdown) and selection/deselection of specific groups to display or ignore. 3) As new MP clients join, the Nasal code ignores them automatically based on their group and your rules. This would allow very flexible filtering for a number of useful scenarios: 1) People wanting to fly in a specific group without any other MP people can simply create an ad-hoc group and select to display only that group. 2) Some pre-defined groups (FGCom, ATC, Beginners, Default) would allow standard groups to be displayed/ignored easily My understanding is that Csabá didn't get that to work. I wanted to use it for Carrier Controlled Approaches, but had to (mis)use the Approach Channel instead. Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
On Mon, Nov 16, 2009 at 2:44 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Stuart Buchanan wrote On a related note, I believe Jester finished the work that I had originally intended in the MP chat to provide per-frequency chat, rather than a single global frequency. My understanding is that Csabá didn't get that to work. I wanted to use it for Carrier Controlled Approaches, but had to (mis)use the Approach Channel instead. I wouldn't say finished but I suppose it has worked a year ago when I posted the patch: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18244.html There were some further ideas but no followups. -- Csaba/Jester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
On Mon, 16 Nov 2009 09:25:57 -, Vivian wrote in message 6e5e9a144a174d9c84057da9eff57...@main: Tom, I don't think there is anything particularly wrong with your suggestion, just that it does not meet the original remit, which was to be able to ignore players who were not following the rules, either intentionally or through ignorance. We already almost have what you propose with ports 5000/5002. Which reminds me: IIRC 5001 is reserved for telnet. We rarely use 5002 for development nowadays, so I suppose there is nothing stopping a bunch of like-minded guys using that. However, I just have a final reservation - MP was meant to be the global picture of the airspace - not just a part. That said perhaps we do need a ban/kick/ignore like IRC for MP. We have stepped around this issue in the past. ..in the GNU spirit; Why not simply _use_ IRC for FG MP??? It'll be fast paced etc alright, but it allows e.g. #FG-ATC, #FG-newbies, #FG-dogfight etc, e.g. on the same ports we use now. -- ..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. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Jacob Burbach wrote: [...] On the pilots list next to each client should be two buttons, one for ignoring chat, and one for ignoring the model as well. plus, maybe, one button to ignore the entire chat (if that one doesn't already exist), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Arnt Karlsen: ..in the GNU spirit; Why not simply _use_ IRC for FG MP??? It'll be fast paced etc alright, but it allows e.g. #FG-ATC, #FG-newbies, #FG-dogfight etc, e.g. on the same ports we use now. The additional benefit here would be that anyone with access to an MPMap and an IRC client (even a web-based one like mibbit.com) could log on from any PC, even a non-FG-capable one, and act as an ad-hoc text-only air traffic controller. (And I use the word benefit somewhat loosely, as it opens up the possibility for more abuse of power of that role by the uninformed and unprofessional, as we occasionally encounter now.) The question that immediately brings to mind is: how would range-testing be incorprorated into that? Or would it be abandoned? Or would the interface need to be driven similarly to FGCom, where virtual channels get opened and joined in some dynamic fashion? Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Martin Spott: plus, maybe, one button to ignore the entire chat (if that one doesn't already exist), Off the top of my head, I think there's a checkbox with that effect in the rendering options panel? -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Hi James, hi Jon Why geek-appeal, if I must ask? My idea was to provide a very clean interface for the user. In Fgrun, beside the multiplayer check flag, you would have a drop-down menu specifying the Group that you want to join instead of the current port number. Pretty natural as far as user experience goes. And Jon, I wouldn't expect a large number of groups, so the idea would imply a small set of port numbers. I'm thinking that 10 consecutive ports would suffice, and it shouldn't be too difficult to choose a range like that. If I got it right, the alternative is to hide traffic based on the group it belongs to, but using the same MP instance on the server. But it's not just traffic, you also need to : - hide events that change the environment (wildfires started by crashes, and am sure other state-ful features will be added in the future) - hide additional effects generated by aircrafts (smoke trails, contrails, ...) - hide state of MP vehicles, like aircraft carriers and so on. In my humble opinion, multiple MP instances, one per group (and identified by a different port number), would make it easier to support different states for different groups on the MP server side. Tom On Sat, Nov 14, 2009 at 1:43 PM, James Turner zakal...@mac.com wrote: On 14 Nov 2009, at 21:35, Jon Stockill wrote: I would suggest that this is a bad idea - ever increasing port requirements are simply going to annoy the people running the servers. It's really not the right way to solve the problem. Indeed, this is a geek-appeal solution, not a good-user-experience solution. James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Hi Vivian I think that a majority of users configures MP through a launcher interface, so the convention would be enforced through the UI. The launcher (fgrun or other) would show a drop-down menu with the Groups (their name) that a user can join. The port numbers that I showed were an example, I showed 5000-5005 to keep backward compatibility with the current setup (5000 = beginners seems like a good default group for the current installed base), but any consecutive range of 5 or 10 available ports will do. About non-complying users, I don't think it would be a great problem. By choosing a particular group, they choose to comply with the intent of the group, and we can write down such intent explicitly in a UI text box based on the selected group, if you feel like. An example: Beginners Welcome to FG. This group allows you to get familiar with FG and learn from fellow pilots. Under Air Traffic Control In this group, pilots fly under Air Traffic Control. By joining, you are required to comply with ATC rules, please see the details at http://wiki.flightgear.org/... Fighters on a mission This group is dedicated to flying military aircrafts, simulating missions and dogfights. Tom On Sat, Nov 14, 2009 at 1:56 PM, Vivian Meazza vivian.mea...@lineone.netwrote: Pete Morgan Tom P wrote: Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom I like this idea a lot :-) Nice theory - in practice how do you ensure that users both know about, and, more importantly, observe the convention? And, what do you do if they don't? IIRC 5001 is used for telnet, but 5002 is rarely used for development. I suppose that some serious users could use that port by mutual agreement, accepting that some less serious players might try to join in as well. The client side ignore device seem to have more practical merit to me. Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Trying to fit everyone into a few pre-defined groups is not a very good idea in my opinion. Peoples wants, needs, and uses are to varied to be known ahead of time. It also doesn't address the need for an ignore chat / ignore model feature, as having a group doesn't not mean people will behave appropriate for that group..purposefully or ignorantly. With that in mind, I would first implement the ignore chat / ignore model functionality. On the pilots list next to each client should be two buttons, one for ignoring chat, and one for ignoring the model as well. A group system would require more thought and effort I think...and should be done properly if at all. Ideally I think one should be at least be able to create, join, and leave a group at runtime. Groups could be removed automatically when there are no more users in it. Maybe mp should evolve to be more like an IRC server/client...with similar featuresbut obviously requires a lot of work and changes. just my 2 pennies cheers! --Jacob -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Seperate ports are gonna be a problem with firewalls. Is there a way to create a group using the callsign? eg my_group:callsign ? just a thought. Pete Jacob Burbach wrote: Trying to fit everyone into a few pre-defined groups is not a very good idea in my opinion. Peoples wants, needs, and uses are to varied to be known ahead of time. It also doesn't address the need for an ignore chat / ignore model feature, as having a group doesn't not mean people will behave appropriate for that group..purposefully or ignorantly. With that in mind, I would first implement the ignore chat / ignore model functionality. On the pilots list next to each client should be two buttons, one for ignoring chat, and one for ignoring the model as well. A group system would require more thought and effort I think...and should be done properly if at all. Ideally I think one should be at least be able to create, join, and leave a group at runtime. Groups could be removed automatically when there are no more users in it. Maybe mp should evolve to be more like an IRC server/client...with similar featuresbut obviously requires a lot of work and changes. just my 2 pennies cheers! --Jacob -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Ignoring MP pilots (was: Re: Daily FG .deb)
On Sat, 14 Nov 2009, Erik Hofman wrote: You could compare it to an IRC channel where users can get ignored, kicked and even banned. Not that I'm propagating a kicking or banning facility but making them invisible for others (may be even upon request of the user) may provide a nice way for beginners to get used to such an environment without the risk of annoying others. The ignore option in MP-chat is entirely local. You select that you don't want the messages from some particular callsign being displayed on your screen or sent to festival. Adding a similar option for the 3d model should be easy but has to be done in C++ code. Perhaps by adding a /ai/models/multiplayer/controls/show-model property (or similar) to each multiplayer entry that defaults to true (show) but can be set to false to hide the model of that pilot. Access to these properties could e.g. be via the pilot list as for MP-chat ignore. I'm not entirely sure it is a good idea to add this, though. OTOH if I really do not want to see or hear pilot X, then why not give me the option to ignore him (as I otherwise probably would have done it mentally anyway otherwise). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots (was: Re: Daily FG .deb)
On 14 Nov 2009, at 11:08, Anders Gidenstam wrote: Access to these properties could e.g. be via the pilot list as for MP-chat ignore. I'm not entirely sure it is a good idea to add this, though. OTOH if I really do not want to see or hear pilot X, then why not give me the option to ignore him (as I otherwise probably would have done it mentally anyway otherwise). Sounds pretty straightforward to do. it's a client-side ignore, so there is no potential for abuse (which a server-side ignore potentially could be). James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots (was: Re: Daily FG .deb)
Perhaps by adding a /ai/models/multiplayer/controls/show-model property (or similar) to each multiplayer entry that defaults to true (show) but can be set to false to hide the model of that pilot. Access to these properties could e.g. be via the pilot list as for MP-chat ignore. I'm not entirely sure it is a good idea to add this, though. OTOH if I really do not want to see or hear pilot X, then why not give me the option to ignore him (as I otherwise probably would have done it mentally anyway otherwise). Without having thought about the technical implementation, the concept of having groups comes to my mind. Probably some set of predefined groups, like - Beginner - Adheres to/provides ATC - Combat/Fighter on a mission - Airliner and/or locally defined groups. The user can select what groups he belongs to and only gets the MP traffic from other members of these groups. If the MP-server knows about these groups and it's members, it is able to distribute it's data to a limited set of users. This should save some traffic and might help with a growing community of MP-pilots. Immediately the idea of using a directory server with LDAP access pops up in my head. And, unfortunately, that this does not sound like a trivial task :-( Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots (was: Re: Daily FG .deb)
On Sat, 2009-11-14 at 13:02 +0100, Torsten Dreyer wrote: Yes, I also thought it sounded like groups, but I was thinking that the client would send a list of group-name strings that a user wanted to be part of when it sends the pilot call-sign and aircraft type information. This would also allow the creation of ad-hoc groups, just by entering a group name. It may also need a boolean if the client wants to only receiving information for the named group, or all MP data. S. Without having thought about the technical implementation, the concept of having groups comes to my mind. Probably some set of predefined groups, like - Beginner - Adheres to/provides ATC - Combat/Fighter on a mission - Airliner and/or locally defined groups. The user can select what groups he belongs to and only gets the MP traffic from other members of these groups. If the MP-server knows about these groups and it's members, it is able to distribute it's data to a limited set of users. This should save some traffic and might help with a growing community of MP-pilots. Immediately the idea of using a directory server with LDAP access pops up in my head. And, unfortunately, that this does not sound like a trivial task :-( Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots (was: Re: Daily FG .deb)
Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom On Sat, Nov 14, 2009 at 4:02 AM, Torsten Dreyer tors...@t3r.de wrote: Perhaps by adding a /ai/models/multiplayer/controls/show-model property (or similar) to each multiplayer entry that defaults to true (show) but can be set to false to hide the model of that pilot. Access to these properties could e.g. be via the pilot list as for MP-chat ignore. I'm not entirely sure it is a good idea to add this, though. OTOH if I really do not want to see or hear pilot X, then why not give me the option to ignore him (as I otherwise probably would have done it mentally anyway otherwise). Without having thought about the technical implementation, the concept of having groups comes to my mind. Probably some set of predefined groups, like - Beginner - Adheres to/provides ATC - Combat/Fighter on a mission - Airliner and/or locally defined groups. The user can select what groups he belongs to and only gets the MP traffic from other members of these groups. If the MP-server knows about these groups and it's members, it is able to distribute it's data to a limited set of users. This should save some traffic and might help with a growing community of MP-pilots. Immediately the idea of using a directory server with LDAP access pops up in my head. And, unfortunately, that this does not sound like a trivial task :-( Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
On 14 Nov 2009, at 21:35, Jon Stockill wrote: I would suggest that this is a bad idea - ever increasing port requirements are simply going to annoy the people running the servers. It's really not the right way to solve the problem. Indeed, this is a geek-appeal solution, not a good-user-experience solution. James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Pete Morgan wrote: Tom P wrote: Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom I like this idea a lot :-) I would suggest that this is a bad idea - ever increasing port requirements are simply going to annoy the people running the servers. It's really not the right way to solve the problem. Jon -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Tom P wrote: Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom I like this idea a lot :-) pete -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Pete Morgan Tom P wrote: Hi Torsten That's an interesting concept, I was thinking about groups as well. But instead of writing extra code on top of the current client and server, could we use different ports on the server? Let me explain: if I understand correctly, the server already allows connection to port 5002 for testing., What if we extend the concept to multiple ports and maybe assign a name to the port to make things clear. As you said, some of the predefined groups could be: - Beginner = port 5000 - Adheres to/provides ATC = port 5001 - Combat/Fighter on a mission = port 5002 - Airliner = port 5003 (I'd group Adheres to/provides ATC and Airliner together for now). Obviously the server will need to do a bit more work, but at least the demultiplexing between groups is done by the TCP/IP stack, which is quite optimal. The only drawback is that groups are *really* separate, it would not be easy to see traffic from other groups. Just an idea, Tom I like this idea a lot :-) Nice theory - in practice how do you ensure that users both know about, and, more importantly, observe the convention? And, what do you do if they don't? IIRC 5001 is used for telnet, but 5002 is rarely used for development. I suppose that some serious users could use that port by mutual agreement, accepting that some less serious players might try to join in as well. The client side ignore device seem to have more practical merit to me. Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
