This reworks how emotes are cached in relation to their physical
location on disk. Functionally, they should be the same from the user
perspective but it sets up some stuff that will make it easier to add
emotes from various sources.
Added a few more stats to keep track of:
- Max users in chat
- Stream start
Also added a `/stats` command to list the user count (current and max),
as well as uptime (sever and stream, separately).
Resolves#85
This is for #32.
This adds a starting framework for loading, caching, and executing
templates on the server and the client. Currently only the server uses
this functionality.
Change the function signature for commands to return a string as well as
an error. Currently, errors are handled no differently than normal
response messages.
Also removed the redundant `/setpin` command.
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
All emotes are set to have a height of 28px. This fixes the
auto-scroll on message when the message has emotes, but it also forces
all emotes to be 28px high.
So far only PIN and Open modes are implemented. It uses a session
cookie to store the validity of the pin/password.
The "Enter pin" page has some unreadable messages on it right now, but
it kinda works.
The processing of ChatData was changed so ChatData has a DataInterface object, which will be converted to a
ChatDataJSON that will have the DataInterface field converted to a json.RawMessage field. This change allows
greater customizability in the chat messages, since the Data field can still be read and modified.
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
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
Zorchenhimer
joeyak