There's a lot of bot specific settings you can use to aid you in how you want the bot to run, this dialog will provide you with many things to tinker with to get your's running right.

Auto start will initiate the connection in 10 seconds after the program loads, this can be over-ridden when the program opens with the Connect button, which displays Abort # where # is the number of seconds till client launch. The Abort will also appear with a count down whenever the bot disconnects and it's set up to Auto connect if disconnected, which is the next check element. Auto connect will also, initially, start at 10 seconds, should that connection be refused or it cannot make a successful login, it will bump that time by 10 seconds, so the next instance will be 20. This continues to bump by 10 seconds up to a maximum of 70 seconds, generally, with the wonderful uptime we enjoy with the server, that should rarely happen.

Depending on how you want to run your bot, you can have the system automatically step into stand alone mode after connecting, The time out on that event is also 10 seconds. Later on I might set it up where you can abort that as well to permit you to start the bot and upload a dream. Might also set up where you can have to bot upload the dream via the client as well, need to figure out the exacts on how to make that happen. There's already a lot going on behind the scenes as is.

Keep the connection if the client closes is an alternate means of stepping into standalone, instead of dismissing the bot once connected, you use the client for what ever reason you need to have the client active, like uploading a dream, or moving the bot to a specific position, then close the client, the bot will remain connected. Which is a something to bear in mind, I've done it, so will you, that is, close the client, then not remember that the bot is still connected, so you hit the close button on the bot, thinking it will go away. Whoops. Well, it did go away, just not as expected.

Save the connection log is like the normal client's log, except that it saves everything that the bot "prints" to the receive buffer. So error messages, botscript generated messages, internal processing messages, they all are saved to the file. You also have the option to have it all saved as a "daily" log, which is something of a misnomer because either log is kept till the bot reconnects for any reason, the main difference is that the daily log option will only generate one log per alt per day, without this being checked, you get logs which are to the minute that the bot made the connection. And finally, if you so desire, you can suppress the creation of a log from the client.

I should point out that the bot does do it's best to restore the settings after launching, however, if for any reason the bot crashes before doing so, it will leave your settings mucked up, do remember to fix them if that happens. To help make your life a bit easier with that, the bot saves your settings in the same folder as "backup-settings.ini" for you. The restore attempt will happen 5 seconds into the connection on successful login. Also, something to note is that the settings is still "dirty" if you use pick mode and close the client's alt picker, pressing disconnect will reset the bot and restore the settings. I think I also got the overall system to where this will work transparently as well, if there is a backup present, the program will use that file as the settings when it does the restore event.

Specifically, as of right now, these are the settings the bot modifies when when generating a connection:

• UseProxyOrFirewall = Yes
• ProxyHost = localhost (Unless you're using IP addressing)
• ProxyPort = 6750 (Unless you got multiple clients checked)
• SessionCloseCheck = No (To suppress the message box about "Furcadia not closing gracefully")
• LogFileType = 3 (If you set the suppress client log option)

Use the Who Is timer and Use the furre manifest are a combo setting. To explain all this properly you must understand that the protocol underwent a change and the player list is no longer sent, usually, so the bot generates this internally like the client. When you do a who, the bot will insert that list into the results "locally", if you got the client running, you get the client's player list, the two should contain the same names, if in different order. If you have the Who Is timer set, every N seconds the bot will who the dream, the sole purpose for this is to use the old Who Is detection system. Otherwise you can just leave this unchecked and use the Furre Manifest triggers to find out who's entered and left the dream. However, doing the Who will not execute the Who Is Detection unless that is enabled on the menu. That's been fixed from SK, it was broken there and would run regardless of the menu status. Bad programmer.

Now for some quirks, if you have this panel's Use Furre Manifest checked, instead of the trigger functions being called when someone enters or exits the dream, the Who Is Detection system is called, with the name and the action, so the only things which are valid under that scenario is when someone comes to the map and when someone goes off the map. If you have both checked, then you get both Who Is Detection running, and the trigger event running the same commands as well.

If you have the Who is timer disabled, but are using the Furre Manifest, then two more actions are taken into consideration. If you have the Who Is Detection enabled on the menu, then the Manifest and Removal will run the Who Is Detection. If, however, you have the Who Is Detection disabled, then you will have them do both, that is, it will run the Who Is Detection first, then process the triggers for any matching events. Then just to make matters more interesting, currently, if the Who Is Detection is enabled, then any time the bot see's a "who", it will run the Who Is Detection if the Who Is Detection is enabled!

Did I confuse you with that?

Note, the Furre Manifest trigger name is "Someone appears in the dream" and the Furre Removal trigger is "Someone exits the dream", ok?