Jessecar96/SteamBot — pull request #426 by thesandvichisaliar (2013-08-09 00:05:10+00:00)
Title: Adds "exec" command and other BotManager tweaks.

Allows commands to be given directly to bots via the BotManager console using "exec X Y", where X = the username or index of the bot and Y = your custom command to execute. This command is handled in the UserHandler's `OnBotCommand`.

Other changes include:
* Threaded the BotManager commands and slightly changing the way accounts are authorized while `UseSeparateProcesses = true`.

* Extended functionality of the "start", "stop", and "auth" commands to allow usernames as well as indexes. (Makes authorization much easier since the username is given in the email).

* Also fixed the `Console.Title` cycling through bot usernames while in Separate Processes mode.

Details:

Basically this is to eliminate the need of having an account logged into Steam to send commands via messaging. This won't really help those who run SteamBot on a separate machine like a server where accessing the console is more difficult than a message through Steam.

While in separate processes mode, the `Thread.Sleep(1000);` loop to keep the thread alive is changed to watch for input. The 'exec' command is written to the process' stdin, like the auth code, though now they are prefixed with "auth " or "exec " respectively to allow distinction. In `Bot.cs` the authorization process is now the same whether using separate processes or not.

I decided to thread the commands because in the event of a command taking a significant amount of time, you would be prevented from executing any other actions. Most importantly, you wouldn't be able to stop the bot without manually closing the window or killing the process. Having multiple threads running on the same bot is not recommended though there shouldn't be much issue if the actions do not interfere. If for some reason the bot is stopped and a thread is still running, the bot will throw an `ObjectDisposedException` when it tries to write to the log. This could be prevented by not disposing the log when the bot is stopped, but then you wouldn't be able to access the log to check for errors.

If some form of #394 was implemented, than this could change, but since the log is inaccessible I have the errors write to console, as ugly as it is.

`OnBotCommand` is virtual so no changes are required if you do not wish to use the feature.

Any suggestions/tweaks/fixes would be appreciated.