This command launches a goroutine that does the actual downloading of
the emotes so the client doesn't hang until the process is finished.
subscribers.json needs to be manually downloaded and added next to the
main executable for now. Eventually, it will download and cache this
file (for 24 hours, at a minimum).
Issue #10 should not be considered finished yet. This needs to be
tested a bit more with multiple channels. Ideally, some that exist and
some that don't to verify that it fails gracefully (ie, adds the emotes
it was able to download).
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.
joeyak