* Rewrite SendMessage() functions to account for new rate-limits
* Refactor new message splitting logic into SteamChatMessage.cs
This makes it ready for unit tests
* Change the concept into UTF8-oriented logic
* Misc
* Add fix for another unit test
* Update
* Fix failing test
I SPENT HOURS ON THIS
* Misc
* Misc
* Add additional unit tests ensuring this works as designed
* Misc
* Misc
* Add one more unit test
* Rework the logic to account for new findings
* Misc
* Add unit test verifying exception on too long prefix
* Address first @Abrynos concern
Because we can
* Throw also on too long prefix in regards to newlines
* Correct wrong bytesRead calculation
This worked previously only because we actually never had enough of room for escaped chars anyway and skipped over (2 + 2 missing bytes was smaller than 5 required to make a line)
* Add unit test verifying if calculation was done properly
* Address @Ryzhehvost concern
* Handle empty newlines in the message properly
* Misc
No reason to even calculate utf8 bytes for empty lines
* Misc
* Add unit test verifying the reserved escape message bytes count
* Correct calculation of lines by taking into account \r
* Update ArchiSteamFarm/Steam/Bot.cs
Co-authored-by: Sebastian Göls <6608231+Abrynos@users.noreply.github.com>
* @Abrynos next time check if it compiles without warnings
* Update SteamChatMessage.cs
* Apply @Abrynos idea in a different way
* Rewrite bot part to remove unnecessary delegate
* Add @Ryzhehvost test
* Add debug output
* Extend @Ryzhehvost test for prefix
* Misc
* Misc refactor
* Misc
* Misc
* Add logic for limited accounts, correct for unlimited
Thanks @Ryzhehvost
* Misc
Co-authored-by: Sebastian Göls <6608231+Abrynos@users.noreply.github.com>
In very unlikely situation where something other than our executable would reference our code, version and module of SharedInfo should refer to ASF code, not that executable.
Normally this should not matter and it does not, but https://github.com/JustArchiNET/ASF-ui/pull/1409#issuecomment-855873098 highlighted a potential enhancement idea in which the caller requests ASF to save the same content as currently exists. Since write operation could emit unnecessary event which forces ASF to start/stop/restart bot/process, I believe that it's justified to add a read operation in front of it to ensure that the file actually needs to be written over.