Case sensitivity

[o11c]

As of the next restart, certain strings will be treated case sensitively, so that "Foo" is not the same as "foo". Previously, case sensitivity existed sporadically, allowing the creation of inconsistent states.

There is one exception: character names are case insensitive, since they are public-facing and it would be too confusing otherwise. Particularly, this makes scamming difficult (although of course you have watch out for l/I/1 and O/0 if your font does not distinguish them), and allows GMs to use the @ban and @block commands exactly as they did before.

It also affects the @item and @spawn commands, but those are not "critical" like @ban and @block.

The only thing that players are likely to notice is the account name. If you registered with the account name "Frost", previously you could log in with the account name "frost" - but only until someone created an account named "frost" or "FROST", at which point you would suddenly start getting errors.
I know that people have previously complained about losing access to their account because of this, so it is best to always make it fail if they type the name wrong.

[Frost]

I first heard of this a few hours ago, and expressed concern that case sensitivity will interfere with normal workflow for GMs, as it has for people on the testing server.

Before we make changes on the main server, I'd like to hear:

1) Reasons for the change to @item and @spawn commands, and if there are other GM commands affected.

2) What GMs and playtesters think about this proposed change, as well as any questions they have.


edit: the change to login name was explained to me on IRC. Basically, right now you can use any case when you make your account, and the server doesn't care whether you type it the same way when you login. It confused me at first, but now I get it.

Now:
account "Frost", I type "frost" and it works
(someone then creates a "frost" account)
Result: I type "frost" as always, and suddenly it's the "wrong password." I panic and burn dinner.

Proposed:
account "Frost", I type "frost" and it fails.
(someone creates a "frost" account)
Result: Still fails. I'm not wondering why my account broke, or was I hacked. Dinner is saved.

[Narus]

As of the next restart, certain strings will be treated case sensitively...

First I think you should ask before you commit this kind of things.

It also affects the @item and @spawn commands, but those are not "critical" like @ban and @block.

I don´t see why you should change that, I understand how case sensitive names affects accounts but I really think you should not change the commands, as you said is not critical but I think it´s more comfortable for us not to have to deal with caps during spawn parties if players want fast spawns...

So please don´t touch the GM commands.

[prsm]

O11c, not sure what this gains us......
can you explain different please?

[o11c]

It is not a change made for the purpose of benfitting you; it is for the health of the server.

My process was this:

• Notice that case sensitivity was applied inconsistently.
• Force all comparisons to case sensitive. This greatly simplified much of the codebase, although I don't claim to have made all of the simplifications yet.
• Check that the current settings really did not allow character names to differ in case, and that there were no zombie characters.
• Add a bunch of special logic to make character names ignore case. I was going to say "like they used to", but they really didn't - the case-insensitive logic was used in just a few cases like character creation (fortunately) and @ban

[Frost]

It is not a change made for the purpose of benfitting you; it is for the health of the server.

Your list is about the source code. The server works pretty well already. Can you quantify how the resulting server will be more "healthy"?

Incidentally, I consider GM usability to be one aspect of "the server."
I think player experience is also important, which is why I had asked about the login changes.

[o11c]

I count thing like "not crashing on exit, losing player data" and "not allowing the database to enter an inconsistent state" as important parts of the server health, as well as "making code that is not prone to causing either of the previous at a later date due to seemingly unrelated changes".

[Frost]

I count thing like "not crashing on exit, losing player data" and "not allowing the database to enter an inconsistent state" as important parts of the server health, as well as "making code that is not prone to causing either of the previous at a later date due to seemingly unrelated changes".

You're saying that making GM commands case-sensitive is necessary to avoid certain crash situations, and also to avoid some data loss?

Can you give an example of such a failure scenario?

[o11c]

I am, indeed, saying that the same API that can make or break a crash is directly related to the parsing of GM commands.

You want to know how to have more bugs? Reimplement code in several different places.

The new code is shorter overall, even *including* hundreds of lines of dedicated testing.

[Chicka-Maria]

will this make the usernames case sensitive? so if we don't remember the proper uppercase letters of our usernames we cant use them?

trying to understand better <_<

[melkior]

I understand why the account names (usernames) have been made case sensitive, and honestly, I support the reasoning behind that. But I wouldn't be surprised if a lot of our players simply don't remember how they registered their accounts. There could be some problems with that, so maybe implementing a web interface to retrieve that account name by entering the account e-mail and password might be a good idea. I think that could make the change smoother.

As for the @ commands... I haven't looked at the server code in a really long time. I doubt I'd even understand most of it at this point. I trust o11c's expertise when he says that there is a problem with the current case sensitivity and how inconsistent it is.

Looking at the GM logs, most of the @spawn commands had been issues with lowercase monster names. That's why I think fixing this should've been done in a way that allows for the GMs and testers to use the commands like they've always used them.

Consistency is great, as is keeping the code base simpler, but I don't think it should be forced when it suddenly changes the user experience. @ commands are tools. They help the GMs do their work, and they help testers experiment on the test server. Tools should be simple and easy to grasp, and I don't think this is a step in the right direction.

[Jaxad0127]

will this make the usernames case sensitive? so if we don't remember the proper uppercase letters of our usernames we cant use them?

trying to understand better <_<

Would you rather that happen now, or later when some registers an account whose name matches yours but with a different case?

[Frost]

I am, indeed, saying that the same API that can make or break a crash is directly related to the parsing of GM commands.

"The same API" is very broad. Any bad code "can make or break a crash" so that's not informative.

I was going to suggest that we remove the case-strictness and try to trigger the problem that it fixes. Of course, first someone has to know what it fixes.

If you can't tie the case change any closer than the nearest town, and can't think of a failure situation that would be fixed by forcing case sensitivity on users, then it sounds like you don't know either.

The server is pretty stable right now. Unless someone can identify the risk of leaving the current GM commands alone, I can't think of a reason to incur the cost of changing them.

About the usernames...I think Melkior makes a good point. A lot of people will get locked out, and may have no idea about the "proper case" of their accounts.
Before we make that change (which I happen to agree is necessary), I suggest we:
1) Tell as many users as possible that this is planned (and include Spanish, German, and Portuguese/Brasilian speakers in particular).
2) Have some automated method for people to get "unlocked."
3) Tell people again just before we actually make the change.

[AnonDuck]

Always consult the users before making usability changes haha.. I understand it's a mess but I'm sure a case-insensitive comparison can be used for certain things like @commands somehow.

[o11c]

I am, indeed, saying that the same API that can make or break a crash is directly related to the parsing of GM commands.

"The same API" is very broad. Any bad code "can make or break a crash" so that's not informative.

Well, the previous ad-hoc API was full of vulnerabilities of one degree or another. The new API is good code.

I was going to suggest that we remove the case-strictness and try to trigger the problem that it fixes. Of course, first someone has to know what it fixes.

I did not *add* the requirement that it be case-sensitive, I *removed* the ability to be case-insensitive. Case-sensitive is *always* the default.

And frankly, at this point, I don't care about analyzing the complete effect of individual vulnerabilities or their ad-hoc patches - there are far, far too many, including some that are remote-exploitable - when I can just fix them properly.

About the usernames...I think Melkior makes a good point. A lot of people will get locked out, and may have no idea about the "proper case" of their accounts.
Before we make that change (which I happen to agree is necessary), I suggest we:
1) Tell as many users as possible that this is planned (and include Spanish, German, and Portuguese/Brasilian speakers in particular).
2) Have some automated method for people to get "unlocked."
3) Tell people again just before we actually make the change.

Of course.

Always consult the users before making usability changes haha.. I understand it's a mess but I'm sure a case-insensitive comparison can be used for certain things like @commands somehow.

@commands are not user-facing. GMs and testers are expected to know better.

It *would* be possible to do a heuristic like "always capitalize the first letter", but while that would work for "arrow", it would not work for "ironarrow", and I think it's better to not introduce an inconsistency.