General Suggestion - Allowing communications commands to be case insensitive - Denied

[Jess1224]

What are you suggesting?

I am suggesting to make the communications commands, such as /ci, /mtf, /site, and other such commands to be case insensitive, meaning that the commands would work if /MTF is typed, /mtf is typed, or /mTF is typed, etc..

How would this change better the server?

This would make typos less annoying for users, and mean that in high pressure situations users can get comms messages out without having to worry about typing the command absolutely perfect. This is obviously a quality of life change, but it allows accidental capital letters to stop being detrimental to a comms message.

Are there any disadvantages of making this change to the server?

I would say there is no disadvantage, as the programming required to do this is subsequent to one line of coding, or could even be done in line depending on how the comms programming is done. This would not put any extra stress on the server, especially as almost every other command, such as ULX commands, already are case insensitive, and the string function .lower() being run will not cause the server any stress. The only disadvantage I could possibly see is that time is having to be spent programming this in, however as it is such a trivial task I imagine this wouldn't take too long, especially as I have knowledge of what has to be done and almost anyone could do it.

Who would this change mostly benefit?

More or less everyone, definitely anyone playing on a class with access to communications. D-Class or SCP mains may not see any benefits from this suggestion as they have no access to comms, however as the majority of active players on the server use comms on a daily basis, I feel this is a universal change that would benefit everyone.

[Nydekore]

-Support for just one reason

Many job codes start with the branch they belong to, i.e. "research_high_command"

There are chat commands you can to do access these jobs which is simply /(job code here)

But because of comms, if I were to do /research_high_command it would think that I was trying to access research comms because the command I did started with "/research"

The only way to get around that is to capitalize the job codes name as the comms don't pick up on that.

It's a small thing but there have been times where the f4 menu has broken and I've had to use those commands, this would disrupt that alternative option.

[Jess1224]

1 minute ago, Nydekore said:

-Support for just one reason

Many job codes start with the branch they belong to, i.e. "research_high_command"

There are chat commands you can to do access these jobs which is simply /(job code here)

But because of comms, if I were to do /research_high_command it would think that I was trying to access research comms because the command I did started with "/research"

The only way to get around that is to capitalize the job codes name as the comms don't pick up on that.

It's a small thing but there have been times where the f4 menu has broken and I've had to use those commands, this would disrupt that alternative option.

 

After testing this, it is seemingly an issue, however this could also be avoided by changing the method that the command is looked for. Instead of using the .StartWith() string function to detect the command, the command could be split into two by the first space, as most commands are. This means that /sitekjdgndsojg would no longer send a comms message, and your message would HAVE to be /site kdsnfjg. Whilst this is still quite simple to add, this does add some complication to the issue, as it means the comms system would need a bit more rewriting than currently so.

[The Real Slim Nova]

4 hours ago, Nydekore said:

-Support for just one reason

Many job codes start with the branch they belong to, i.e. "research_high_command"

There are chat commands you can to do access these jobs which is simply /(job code here)

But because of comms, if I were to do /research_high_command it would think that I was trying to access research comms because the command I did started with "/research"

The only way to get around that is to capitalize the job codes name as the comms don't pick up on that.

It's a small thing but there have been times where the f4 menu has broken and I've had to use those commands, this would disrupt that alternative option.

 

[Sixx]

On 3/7/2022 at 5:12 PM, JessicaP1224 said:

 

After testing this, it is seemingly an issue, however this could also be avoided by changing the method that the command is looked for. Instead of using the .StartWith() string function to detect the command, the command could be split into two by the first space, as most commands are. This means that /sitekjdgndsojg would no longer send a comms message, and your message would HAVE to be /site kdsnfjg. Whilst this is still quite simple to add, this does add some complication to the issue, as it means the comms system would need a bit more rewriting than currently so.

+Support

Makes sense 

[Ein]

+Support

More of a Q.O.L. thing, but this makes sense. Makes communicating in a more panicky situation without binds just that little bit easier.

Explanation of how to get around the previously stated problems also reinforces this.

[Craig Crustacean]

43 minutes ago, Ein said:

+Support

More of a Q.O.L. thing, but this makes sense. Makes communicating in a more panicky situation without binds just that little bit easier.

Explanation of how to get around the previously stated problems also reinforces this.

 

[Coltable]

Denied. The SCP-RP SMT has decided against adding this suggestion for performance reasons, the benefit to the server, or another unstated reason.