case sensitivity on help pages about bzflag

[JMakey]

The few commands I tested are case insensitive in their names (/lagstats, /LAGSTATS, and /lagSTATS all work the same), so I assume this refer to the handling of specific help topics. For example, /help rules is different from /help RULES.

It would be trivial to use TextUtils::compare_nocase() to make help topics be case insensitive. I'd like to get input about the impact on server configurations before deciding whether to make such a change.

[allejo]

I'd be in favor of having them be case insensitive. I personally don't have any help topics that are different due to case. Is there a use case for having /help rules be different from /help Rules?

[macsforme]

Case-insensitive help file names sound fine to me, as long as both ends of it (the help file initialization and the command parser) handle it the same way.

[blast007]

@macsforme This may be what you meant, but just to be clear, the issue is about the help message name, not the help message filename. The -helpmsg command line option specifies a filename (example: ../help/rules.txt) and a name (example: rules). The name is used to access the help message via the /help command, which is what is being compared case sensitively.

Fixing this should only require a minor change to src/bzfs/commands.cxx, making the comparison in sendHelpTopic use the TextUtils method that @JMakey mentioned. There should not be a need to modify the TextChunkerManager for this.