Sorry, I didn't mean to imply that the sub age checking is fiddly... that looked fine to me. I was referencing the actual linking code itself -- I really dislike seeing ptNetLinkingMgr being used anywhere in python. We can do whatever is necessary, but it needs to be moved engine-side for PtKickClient to not be exploitable--the receiving client will need to validate that the sender is the owner of the age before it kicks itself. I think an appropriate test would be to only allow kicks if the parent/super age owners folder only contains one player (and I see this is what you're doing in your subage case). Since the Neighborhood has multiple owners, that should take care of your point under "edit 3."
I can handle local status chat messages from the engine code as well . Basically, all the python that would be left would be the KI command processing, calling PtKickClient, and revoking age invitations.
Kick command proposal
Re: Kick command proposal
Sounds good to me! I'll take care of the remaining Python code then. So calling PtKickClient could be done like this? PtKickClient(pid,msg)
Or should we drop the custom message and just make it a general message?
Or should we drop the custom message and just make it a general message?
Re: Kick command proposal
I was thinking that msg could be an optional argument. The kicked player's client can use a default message if the kicking player does not specify one.
As far as full function documentation goes...
I'll try to have the engine code done sometime this week!
As far as full function documentation goes...
Code: Select all
PtKickClient(client, msg=None)
Return value: Boolean describing if the kick was performed
Params: client (player ID or client key), msg (kick message sent to the remote client)
Re: Kick command proposal
The community at large should probably be informed that this implementation would be available so that we can get a sense of the reaction.
Perfect speed is being there.
Re: Kick command proposal
Easier to ask for forgiveness than ask for permission in this case. I'd avoid mentioning it at all in more public (read: volatile) venues.JWPlatt wrote:The community at large should probably be informed that this implementation would be available so that we can get a sense of the reaction.
Re: Kick command proposal
It'll get into those venues anyway in time. I'll just have to try to fight the fires as they arise
As far as any /kick implementation goes, I don't see this as being all that contentious. There's perhaps a bigger question about whether a /kick is really what's needed, but that's been thrashed to death in other threads. However I raise it simply because we got an indication from Cyan that the enhanced /ignore was something that appealed to them: I can't be sure, but I'm inclined to suspect that they weren't quite so enamoured of /kick. But if it were something that was present in the codebase but could enabled/disabled on a shard specific basis (either in the Python or switch in the client build) then it would allow those shards that don't want the feature to simply not activate it. Of course there's always the possibility that someone cooks up their own client that ignores the /kick (if I've understood the mechanics correctly) but those kinds of abuse are always going to be difficult to mitigate against.
Speaking personally, something inside me isn't sure that coupling revoking invites with /kick is the right thing to do; I'm not sure why though . In any case it seems to me to be unlikely that a "kickee" is going to have many age invites from the "kicker" so it's probably a moot point.
As far as any /kick implementation goes, I don't see this as being all that contentious. There's perhaps a bigger question about whether a /kick is really what's needed, but that's been thrashed to death in other threads. However I raise it simply because we got an indication from Cyan that the enhanced /ignore was something that appealed to them: I can't be sure, but I'm inclined to suspect that they weren't quite so enamoured of /kick. But if it were something that was present in the codebase but could enabled/disabled on a shard specific basis (either in the Python or switch in the client build) then it would allow those shards that don't want the feature to simply not activate it. Of course there's always the possibility that someone cooks up their own client that ignores the /kick (if I've understood the mechanics correctly) but those kinds of abuse are always going to be difficult to mitigate against.
Speaking personally, something inside me isn't sure that coupling revoking invites with /kick is the right thing to do; I'm not sure why though . In any case it seems to me to be unlikely that a "kickee" is going to have many age invites from the "kicker" so it's probably a moot point.
Mac_Fife
OpenUru.org wiki wrangler
OpenUru.org wiki wrangler
Re: Kick command proposal
I'd like an informed community. It's a matter of trust. It has been controversial, so it's not a little feature or fix we can just slip in that everyone will like.
Yes, it's not clear that D'Lanor has accepted the decoupling, using, for example, my suggestion of /uninvite. On the other hand, a beginner who doesn't know the system so well and is being harassed, would probably appreciate some automation. So maybe I'm on the fence here. Perhaps the automated uninvite should be very specific to the age they are both in at the time, and anything more should use the explicit command.
Yes, it's not clear that D'Lanor has accepted the decoupling, using, for example, my suggestion of /uninvite. On the other hand, a beginner who doesn't know the system so well and is being harassed, would probably appreciate some automation. So maybe I'm on the fence here. Perhaps the automated uninvite should be very specific to the age they are both in at the time, and anything more should use the explicit command.
Perfect speed is being there.
Re: Kick command proposal
Do you guys really come in to the city where this is an issue to you? I visit frequently and I see no reason to kick, stab, boot, yell, smash, chew, hit, bite, gnaw, burn, or kill when I'm on..then again, I'm obviously not around for all that..
Re: Kick command proposal
As D'Lanor notes, "You cannot kick players from public ages or city book ages (child ages)."
Perfect speed is being there.
Re: Kick command proposal
Perhaps splitting the /kick and /revoke commands would be preferable? It's equally counter-intuitive to need to /kick someone when they're not in an age you can do so from in order to revoke their invites. For an extra reminder, the successful kick command could reply with "<blah> has been kicked. Remember to use /revoke <ki> to revoke their invites to your ages if desired." etc.
Edited to add:
Still, it's important we have the discussion here and work through the implementation and presentation before sending it to Cyan.
Not a problem for me, but then I basically never play with strangers in MMOs, and I certainly don't invite random people to my private locations.charura wrote:Do you guys really come in to the city where this is an issue to you? I visit frequently and I see no reason to kick, stab, boot, yell, smash, chew, hit, bite, gnaw, burn, or kill when I'm on..then again, I'm obviously not around for all that..
Edited to add:
I agree, and it's important to remember this even when it's inconvenient. Fortunately, this feature is being discussed here, not developed behind closed doors and then thrust onto MOULa without public consideration. If we asked for a review on the part of everyone on the MOULa forum, we'd never accomplish anything as everyone has a different goal, some mutually exclusive and most of them ill-informed. There's a happy medium between completely closed and entirely open. It's also been discussed heavily already in more general terms ad nauseam over there, so I think D'Lanor and the rest of us here have a good idea of what is requested and can balance that with what is rational (as many of the rants on the subject there become quite emotional).JWPlatt wrote:I'd like an informed community. It's a matter of trust. It has been controversial, so it's not a little feature or fix we can just slip in that everyone will like.
Still, it's important we have the discussion here and work through the implementation and presentation before sending it to Cyan.
Last edited by Deledrius on Tue Jun 12, 2012 5:18 pm, edited 3 times in total.