Hey John, John R. Dennison wrote: > On Fri, Mar 12, 2010 at 06:09:06PM -0500, cflrich wrote: > >> Well, in terms of any compliance, this should simply be a matter of an >> addition to the EULA of the client. It is no longer the case that >> > > I don't understand. I thought that the client was a standalone > app that would run alongside the netrek client? Is this not > the case? Does support have to be built into the netrek client > itself? > Ehhh, it is a standalone client, and it can run alongside the netrek. Support doesn't necessarily have to be built into the client, but we may want it to. I'm not sure yet, still thinking it through. I think it would be nicer if it were built in, but, that may be more work than its worth. The important thing is that whatever is implemented is more robust than just someone buying a vent server and handing out the info to everyone. This may be as simple as having the server detect which players are connected to which teams, and modifying the ACL to let them join the team voice. I would like it that if the player selects 'voice enabled' in his client, this happens automatically for him, ie, he doesn't have to swap out, manually connect, etc etc. Its something that still has to be looked at I guess. > Server admins should have the ability to squelch players as they > see fit. Their server, their bandwidth. > Absolutely, just like in text. > User <-> User squelching should be handled by the server as > ignores are currently handled, ":s" for example sent to the > offending player. I'd go so far as to say a new majority vote > to silence a player might be useful, also. > I agree here too. > Rich, are you going to want your darcs repo regenerated? > > Yeah, probably, if you don't mind. I'm not at the coding portion of this exercise yet, still trying to reason out exactly how this is going to function, which right now is reading up on mumble/murmur. Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100312/2e12c265/attachment.htm