LadyCailin

Perhaps "obnoxious" is too strong a word. But if non-english genchat is not intelligible for 90% of the players, I think it's fair to tell folks (nicely) to move that to a specific clanchat that was designed specifically for that purpose, and to keep it out of genchat as a general rule. We welcome international players, but we still require that players at minimum be able to read English, as that's what the server rules, etc, are written in, and if there is a problem, what language they will be communicated with by staff, so I think it's also fair to keep genchat English only, while still being respectful of people's native language by providing built-in avenues for them to use that language primarily. I work for an international company in Norway, and I'm required to use English, not Norwegian, and while I am not a native Norwegian, as far as I'm aware, none of the Norwegians feel slighted by the fact that anyone in a meeting can ask that the meeting be conducted in English. This isn't a slight against Norwegian, it's a pragmatic acknowledgement that the least common denominator language spoken by people in the company is English. Same principal applies here.

Also, just to entertain this argument further, I just chunked several lines of short (english) genchat in google translate, with detect language on, and it's bonkers how much english slang it detects as some language or another, so I just think that this isn't workable, cost aside. Here's some examples: Genchat: "*bongidy*" - Malagasy "block" Genchat: "yey" - Somali "wolf" Genchat: "nais" - Filipino "want" My favorite when it does detect English, but it autocorrects some stuff (this might be different behavior in the API, dunno): Genchat: "but they wont frop" - English "but they wont drop" So, the only workable way to do this then is to always print out both the original and translated, if we end up detecting non-english, which would just make actual non-English in genchat even more obnoxious. Anyways, there's just lots of problems here with solution #1, and none that I can think of with solution #2, so I would rather focus on that, try that out, and then go from there.

Translation and language detection are the same price, and count towards the same quota. Further, the network latency, even if the server's processing is instantaneous (which is close enough for our purposes, for both translation and detection) is by far the larger issue. Rate limits could be put in place, sure, so once we hit a monthly budget we turn the function off, but then we have to say "sorry, no more german in genchat for the rest of the month" or "no more swedish for the rest of the day" which is.. not sustainable.

For idea #1, it is worth noting this is not free. All translation services that are used at scale and have an API cost money, and we would need to send ALL chat to them, just to determine if it needs translation in the first place. Since the "cost" argument is mostly quantifiable though, I went and did a quick analysis of chat since the start of the rev (October 7) plus the last 7 days, to make up one month. Over that month, there were about 3.5 million characters that would need translating. Google has a monthly 500k char free tier, so we would need to pay for 3 million characters, which is $60 a month. Bing translate (Azure) has a 2 million free tier, and is $10 per million after that, so would be $15 a month. These prices aren't totally off the charts. Having said that, I think the user base that would actually benefit from this would outweigh the cost. Secondly, this could open us up to an expensive DDOS, which is more risk that I think we should take on. Thirdly, translation is not always that great, particularly for slang and other ever-evolving cultural phenomenon. There are additional arguments to be made here besides the cost, in regards to the practicalities (why should only mods get this feed? It would double chat for staff anyways, or alternatively we could replace the chat with the English, but then that introduces chat lag for everyone, even those writing English.) But I will leave those arguments for others to make. I think the bottom line probably is that - if we want moderation in genchat, we can only allow chat in languages that the moderation body understands, which is only English. We do not have such requirements in clanchat, given that these channels are explicitly opt-in, and so we can allow any language there. I think #2 is a completely workable solution with basically no downsides, however, and would support "official" creation of language channels for popular languages, which are advertised somehow and available for anyone to join. Moderation would be on an adhoc, by-request basis, as it is with any other clanchat or private messages today.

I see that the ban was in 2016, but I'd say you've served your time. Unbanned. Please read the rules at spawn before jumping in to playing again, and of course don't grief anymore.

I see no reason at all not to enable /hat for creative. I know of no issues that that can cause at this time, there are several servers that do that all the time, and I've never heard of anyone having issues. As to the command blocks, I'm still 100% against them, but I'm working on and have mostly added a redstone_changed event in CH, which can be used to detect redstone events and then run any CH script we want. This would work like EasySigns in that admins must configure it, but once configured, the full power of CH would be available, including the existing EasySign triggers. There is no real need for command blocks, if you think about the final end goal, and the goal can be reached in a much safer and straightforward way via other methods than command blocks, hence my objections to them.

> MtGox Oh hell no. As far as other exchanges, as long as you *immediately* convert the bitcoins into fiat, AND can transfer the USD into a FDIC insured account within a reasonable time, I see no problem with that. Without doing those two things, you're opening yourself up to market losses, and foreign, unregulated institutional failures, which is obviously very bad. Having said that, those two conditions are the only things to worry about, if you can satisfy those conditions, I would absolutely condone that. I've never looked into the merchant/receiver side of coinbase, but they are a trusted and well known company. https://coinbase.com/clients I would look into that first, and if for whatever reason that doesn't work out, I can research other means.

Now hang on just a second. You were very explicit about the date being June 20, 1 month. There's a point to study bans... that you can't appeal before the date. Abusing this system makes the whole thing pointless, and merely an inconvenience to the admins. Why were you so adamant about the ban, but now you aren't?

It's srsly hard, I had to go to collage to lern how to make minecraft mdos. yah. hard.

https://nerd.nu/forum/index.php?/topic/836-server-crests/ ^^^

That's not the concern. If our system is breached, the attacker could already get IP addresses from other places. The purpose is to prevent accidental reading of IPs during database maintenance. Anyways, we can use a salt as well (and sha256 while we're at it).

Multiple admins will be able to comment on a post, so I think that addresses your point? I have made changes to the feature list to address your other concerns.

One thing that I have wanted to implement for a while is an anonymous suggestion box, as a direct line to the admins. I think this would be a good way for players that have issues with the community to feel safer about speaking out about their concerns with staff, while not fearing any sort of retribution. To this end, I think an anonymous suggestion box would go a very long way. Here is the list of features I propose, along with some basic technical details about their implementation. Feel free to discuss the feature set, suggest technical changes, or otherwise voice your opinion. The suggestion box will be anonymous. There will be some features in place to prevent abuse (via spam), but otherwise will be unrestricted.When you want to make a submission, you will enter your username. A token will be sent to you in game. This will not be associated with the actual post in any way, but will simply be a way to keep non-community members from making a submission. (A captcha will also probably be in place as well.) The token will be valid for a limited time (24 hours or so). You can optionally provide an email address, and responses will be emailed to you. While we will have to link your email address to your post, you can use a throwaway email account if you wish, and regardless, the email will be base64 encoded and put in the database (to prevent accidental viewing by techs), with the promise that we will not purposefully look up your email address in the database. If you still don't trust that promise, you can use a throwaway account. Places like mailinator.com provide these types of services for free. Regardless of whether or not you provide an email, a "read receipt token" will be provided, which is a unique token that you can use to re-access the post and read replies. For accountability, all reads of the post will be publicly logged; when someone accesses the post with the read receipt or an admin views the post, it will log this information with the post. An "edit token" will also be provided, and should be kept private. This will allow you to respond to the posts directly. To prevent abuse and sharing of this token, the IP of the computer using this edit token will be one way hashed (md5) and stored. Only a limited number of IP addresses will be allowed to use this token. The source code for all this will be publicly available, and there will be a link to show the source code directly in the browser, so that the source is always viewable real time. Only admins (server, head and techs) will have access to the posts. When there are unhandled posts, admins will be notified in game when they sign in. This would be implemented as a web feature in php, and would not be server specific. At admins discretion, posts can be made publicly available, for instance, to quell concerns about incidents not being handled. No data can be edited or deleted by a single admin. Only amendments may be made. However, if 3 different admins vote to delete a post or comment, t The number of unhandled posts will be publicly available information. Handled posts will be opened to the public after 24 hours of non-activity on the post. If the OP wishes to keep the post private permanently, they may check a box to keep it private by default, though admins will still reserve the right to publish any and all posts. Once posts are revealed, they will be publicly available to view by the community, including admin replies and records. As this system can be easily abused by people that wish to ruin nice things, I'm open to suggestions on how we can prevent abuse without sacrificing the anonymous nature of it.

I'm assuming that no one has any objections in general at this point, so I guess we can go ahead and move forward with this. I figure keeping the contest open for a week should be sufficient, then we can set up a poll on the forum or something. The rules dumbo laid out are fine with me, though I would add one more point that we have the right to modify the design of the crest for design/layout purposes, but the theme of the winning crest will be used (or something like that).