- Move mutex into Settings struct
- Replace sync.Mutex with a sync.RWMutex
- Move adding approved emotes into a Settings method
- Save settings after adding emotes
- Wrap saving in a lock
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
Temp connections were removed to reduce some complexity. Now a
connection is a full client, even before joining chat. A name is
required to be set to join chat and receive messages.
This change also removes the need for UUIDs on connections and clients.
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 reverts commit 13d74faf01, reversing
changes made to ec0c6752bc.
These changes completely broke the RTMP stream. Reverting until I
figure out why.
This should fix#65, although it may be expanded in the future.
Default settings for limits can be changed or disabled in the settings.
Default values:
- Chat: 1 second
- Duplicate chat: 30 seconds
- /nick: 5 minutes
- /auth: 5 seconds
- /color: 1 minute
Creation of the chat Client object has been moved from ChatRoom.Join()
to NewClient(). This function also handles setting the initial name.
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
Use an RW Mutex for chatConnection and use some goroutines when sending
data to clients in Broadcast(). This should prevent blocking on
unresponsive clients.
The UsernameMaxLength and MinLength constants were removed because common.IsValidUsername checks that.
Changed queue sizes to 1000 because if 25 people are joined and 4 say a message at the same time
it results in 100 messages.
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.
ChatRoom.delClient() wasn't updated to use UUID's instead of names.
The calling functions were passing in a name instead of a suid, so
attempting to delete the client silently failed.
Fixes#52
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
Wrapping the connection with a mutex prevents the "concurrent write to
websocket connection" panic. The new functions are ReadData() and
WriteData so as to not collide with ReadJSON() and WriteJSON().
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
The broadcast code would lock up eventually after a lot of messages.
It was rewritten to simplify and make it a bit more robust. Chat
should no longer seize up for individual chatters or the entire room
after a lot of messages.
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
Alex Dunn
Zorchenhimer
joeyak