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
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
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
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
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
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
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
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 -
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo