MustardJeep wrote:
Quote:
I suggested the /kick function from Hood or private ages.
rocketdog SERIOUSLY?

Do you have any idea how insanely abused that is EVERYWHERE it's implemented, and how quickly Griefers abuse that system? And if you have grifers in your private Ages seriously just burn the age and get a new one, problem solved.
Care to provide some examples of how /kick was implemented in those systems, and how it was abused? Constructive conversation is always preferable to unsubstantiated crap.
MustardJeep wrote:
Now on to a general reply/rant:
I've tried my best to ignore this thread because of the fact that soooo many people are taking it sooo seriously but I think I have to respond now.
Ignoring the source of the proposed "upgrade" to the ignore code I have to question some obvious holes in the logic of the cloak of invisibility. The "Ghost Avatar" is a existing problem in Uru; I saw one so to speak just last night meaning it's not a dead issue. How this applies to "/ignore" should be obvious to everyone. You can ignore someone, a group of your twenty best friends can ignore that someone, heek your favorite Group/Guild/Sewing Circle/IRC Buddy List/Russian Gulag can all gang up and ignore this person with the ultimate "/ignore" of invisibility and your still guaranteed to have at least one person present asking over open chat about person X's odd behavior. People are very used to one person not being visually present but footsteps being heard, voice chat being heard, cones and other kickables being kicked providing proof many in this thread have said they never want to see.
The logical counter of course is that the skills of the person upgrading "/ignore" would patch over all these little tell tale leftovers making a seamless excision of the offending player. So the Question I have to ask is now that they are "gone" how do you help the people still being bothered by them if they are having problems with the KI, don't say anything expressing their distress over the KI, and you can't see player X who is being the pain in the first place? It's the whole interlocking Rube Goldberg operation their invisible, your invisible, both of you are invisible if one "/ignore" can consign someone to a single player sandbox on a server your opening a can of worms............
Some things can never be excised (the state of the physics world must be kept in sync between all clients, for example). On the other half of your paragraph here: If someone isn't saying anything, it's really nobody's responsibility to step in and do anything for them. Yes, we should help people with griefers when they ask, but if they're not asking we shouldn't assume they want or need help. What you may view as griefing they may not see as a problem, or may even be normal interaction for those people.
MustardJeep wrote:
Just be honest a lot of the discussion has revolved around granting players Customer Service Mode from MO:UL.
I'm not sure where you got this idea.
MustardJeep wrote:
Now for two little things I am pretty sure none of you have considered.
1. Custom Builds : If you go for some overly complicated ignore/ban list the easy solution is to compile a client immune to the restrictions.
This is a possibility only for certain things. Everything Hoikas implemented happens on the ignorer's client, so it can't be circumvented. For a /kick, there may be a way to circumvent it client side. See further down about people that have that level of technical skill, though.
MustardJeep wrote:
2. GPL License : No matter what you do as a form of protection you have to publish the source code for it, because yes griefers will sue. After all the GPL was written by a grifer and the ultimate act of griefing the system would have to be legally taking you for everything your worth.
There are two halves to this. Both of them are wrong. Your first point here seems to imply that security through obscurity is a good thing. It is not. The details of a truly secure system can be revealed without any impact to actual security. The second... I don't even know what you mean by saying those sorts of things about the GPL. It's a very effective license for what it's designed for.
MustardJeep wrote:
Simple is better.
patients always wins out eventually.
and
You all need to get over the fear of community moderation one goofball promoted to reseng can do more good then all the people that want that power or are afraid of that power when they don't have it.
Generally agreed.
MustardJeep wrote:
Call it a Devil's Advocacy Rant.
I do I really really do understand the thoughts and concerns behind upgrading the "/ignore" feature. I've never had any issue of harassment directed at me as a boy or a girl Avie but I have a feeling that is more a matter of my play hours then anything else.

I have seen countless "stream of conciseness" typists that find it absurdly pleasing to message spam over the chat channels. The ignore command really could be improved a bit I don't argue.
In my book (Harassment = Bad) even in somewhere as kid friendly as MOULa just so I am clear.
Simple solutions however are always stronger solutions, at least they always have been in my life. I suggested a while ago making "/ignore" act on the primary account instead of the disposable "sub-accounts" that are created and destroyed with each avatar. I would also happily sign my name to a petition that reactivates even a single Cyan employee checking the report log for "/harass" once a week for a half hour. (Yes even as a additional expense to cavern operating costs.)
Tying anything to account is pointless in a F2P game like Uru - it's painfully easy to make a new account. I would like to see more CSR support from Cyan, but I'm not sure how much good it would actually do with how easy it is to re-register.
MustardJeep wrote:
I'll admit I haven't looked at Hokias's addition yet but I have been looking at the source code of Uru for some time now. I'm sure it does what he says but I question altering that ancient piece of software even with "minor" changes. Especially since Cyan doesn't ban players to my knowledge and new accounts are simply verified by e-mail.
The uru code might be old, but it's not all that awful, in the grand scheme of things. It's quite easy to make modifications like this.
MustardJeep wrote:
I've been in other games and other worlds, but the one I love is Uru.
So say we all!
MustardJeep wrote:
I would rather see time, money, and energy spent by Cyan doing the things that assure a stronger game. (Better security on the Vault, 100% rewrite on the KI, updated glue code on the Python, Updated version of Python, making the book share "yeesha hologram statue" rather then "book slammed in face", and the "to do" list goes on.....)
These are the sorts of fixes that are going to come from the community. They're all great feature requests, and some have already been implemented, though not yet merged back to Cyan.
MustardJeep wrote:
P.S.
Quote:
You have no idea what the kick function is about or how and when and who could use it. Don't you think we know not to put this function in a place where a griefer could use it against us?
rocketdog
A Kick function can only be a kick function, I can not imagine you or anyone else developing something with that name that doesn't behave in the common vernacular. The "Kick function" removes a player from a game level, most often this feature is paired with a ban of variable time length to prevent that person from simply returning.
Well yeah, a kick is a kick. But not anybody will be able to kick just anybody else, at least using /kick. To be entirely honest, anybody with custom code could "kick" somebody from any age already if they wanted to. Adding /kick as an own-age moderation tool adds no new potential for griefing.
MustardJeep wrote:
Quote:
<snip>Don't you think we know not to put this function in a place where a griefer could use it against us?
Who is us?
Who do you trust?
Who decides who gets admin privileges and who doesn't?
I care very deeply about people that want such very powerful and abused commands added especially when they can only be used by "us".
Everybody gets priviliges to control their owned age instances. Seems pretty simple. And keep in mind that anyone that has the skills to modify these commands has the ability to add similar commands themselves... and see what I said above in regards to that.
Also, as a general point, you seem to be under the working assumption that the commands as presented are abusable. That may well be the case, but I'd like to see some sort of use case analysis that shows how before we all just jump on board with what you say about that.