ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
Xelagots: new approach to disconects implemented (Bots)
Xelagots: new approach to disconects implemented // BotsxelagMar 27, 2001, 4:14am
For Xelagot users:
The latest version fixes the Announce Text bug introduced a week ago. For programmers: It also has a brand new way of dealing with disconnections. Up to this version, the bot relied on the SDK to handle disconnections. Very often, the blocking action of the Winsock code used by the SDK would freeze the bot and user interface during a disconnection. Now, I use the following method: 1. If the session number of the bot (aw_session), which I monitor at every 'heartbeat' and in every event handler and callback, changes to one of these: RC_CONNECTION_LOST RC_UNABLE_TO_CONNECT RC_NO_CONNECTION I issue and aw_destroy to log off the bot, and try periodically to create a new instance and log the bot back in until this succeeds. 2. But, if the bot gets a world error event indicating a disconnection, without its session number changing to an error code as above, I issue a aw_exit and then periodically an aw_enter. So the bot still stays in the Universe in this case. The codes I use here are the ones given in the event world_disconnect for rc: RC_CONNECTION_LOST // 471 RC_UNABLE_TO_CONNECT // 429 RC_NO_CONNECTION // 439 RC_NO_SUCH_WORLD // 27 RC_WORLD_NOT_RUNNING // 489 (admin closed world) These same error codes are tested in the aw_enter callback: any other error code will stop the bot from carrying on trying to enter the world, these five will trigger a timer (60 seconds later) to issue a new aw_enter. Note that blocking still occurs: aw_login and aw_enter block. The callbacks for both of these, as far as I could establish, are synchronous instead of asynchronous: the function returns only after the callback has triggered. But this blocking is less, usually, than the one happening during disconnections if one leaves the SDK go it's way. A few weeks ago, Roland advised me to use a similar method to the one I have now adopted: at any sign that something has gone wrong, destroy the instance and try to log back in. I am using a slightly milder approach :) XelaG |