Its valid for a user mention to be sent and parsed when a nickname
mention is expected. As such we should filter both from the message
contents to avoid message processing issues.
There where various oddities and bugs here, namely:
- Guild kept its initial `presences` list even though this is basically
useless, and was never kept up-to-date
- State did not properly use all the fields of presence_update, and was
creating some annoying recursive oddities w/ user and presence binding
* First pass at voice sending
* more voice
* Refactor playables a bit, general fixes n stuff
* Cleanup
* Voice encryption, dep version bump, etc fixes
* Remove debugging, don't open a pipe for stderr
* Refactor playables
This is still a very lose concept, need to think about what the actual
differences between encoders and playables are. Also some rough edges in
general with the frame/sample calculations.
However, this still feels miles ahead of the previous iteration.
* Properly reset state when resuming from a pause
* rework playables/encoding/etc a bit
* Add a proxy, allow for more pipin'
* Cleanup, etc
* Fix resuming from a pause lerping music timestamp
* Fix some incorrect bounds checks, add MemoryBufferedPlayable
GUILD_UPDATES are cool and special and of course they are partial.
Although this is logical, our type/models autoinitialize some fields by
default (which is actually fairly sane). However when this happens, we
smash these new blank mappings over the previously updated state.
Instead we should just ignore fields that don't come in GUILD_UPDATEs,
and save our state.
Andrei
Andrei Zbikowski