Functions added:
- LogErrorf()
- LogErrorln()
- LogChatf()
- LogChatln()
- LogInfof()
- LogInfoln()
- LogDebugf()
- LogDebugln()
- LogDevf()
- LogDevln()
New settings configure the logging: LogLevel and LogFile. LogLevel can
be set to one of: error, chat, info, or debug and will default to
error. LogFile is an optional file to write to. Providing a file will
not prevent output in the console.
LogDevf() and LogDevln() only compile when the "dev" flag passed to
build. This will cause Travis-CI to fail the build if it finds any
calls to either function.
Names can be passed to commands with @ prefixed to them.
When forcing a color change on another user the @ explicitly defines
the name, instead of simply being stripped off. This will allow the
a user named "red" to have their color changed: `/color @red blue`
A bunch of the color command code has changed with this to make things
less ambiguous and to add some other checks. `/color red #FF0000` and
`/color @red red` will change the color of the user "red" to the color
red while `/color red red`will return with an error. Note that the
color an name arguments can be in any order.
Resolves#64
Moved to common/utils.go:
- IsValidName() (function replaces direct calls to regexp.MatchString())
- RandomColor()
Moved to common/emotes.go:
- LoadEmotes()
Using this command will change the current user's nickname in chat.
It has an alias of /name.
An admin can force a name change by supplying the current name and a new
name. If a name has been changed by an admin, that user can no longer
change their name (similar to forced color change).
Resolves#42
Added a limit to how long the title can be when set from the /playing
command. The default value is 50 if it is not in the settings file or
if the value in the settings is below zero.
Resolves#43
Move the help html to a template and populate the lists dynamically.
This also splits out the base HTML stuff (eg, the <html> and <body>
tags) to a base template file.
These messages are only sent to mods and admins for certain events:
- User gains mod/admin privileges
- User attempts to gain mod/admin privileges unsuccessfully
- Mod/Admin uses the /sv command
- Mod/Admin uses the /playing command
- Mod unmods themselves
- Mod/Admin mods/unmods a user
- Mod/Admin uses the /reloademotes command
- Mod/Admin uses the /reloadplayer command
A separate message queue is used for these messages, and they are only
sent to clients that are either a mod or an admin. They are sent
with the same call to ChatRoom.Broadcast(), but after all the normal
messages are sent.
Resolves#3
Single-use moderator passwords can only be generated by an admin with
the /modpass command. To redeem the password and gain moderator
privileges, a user just needs to call /auth with the password.
The passwords are generated using the same function as the admin
password. Additionally, generating passwords now uses crypto/rand
instead of math/rand.
Resolves#15
This still needs a bunch of work, but this should be OK until the UI is
rewritten.
The command injects a <script> tag to open up a new window. Mod and
admin commands are only shown to mods and admins (no authentication
happens for this).
Resolves#8 for now.
Don't allow the user to randomize their color if it was previously
changed by an mod. And don't change to a random color if an incorrect
argument was given for the command.
