ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
Bots Disappearing (Bots)
Bots Disappearing // Botsctc oneOct 2, 2000, 11:09am
I've been using Grimm's VB Wrapper to build bots for my world.
Every so often the bot will disappear from the world. The Program will still be running, but the bot will no longer be in the world. Has anyone seen anything like this, or know what's happeneing, or what I should be looking for / doing in my program? ctc one xelagOct 2, 2000, 7:00pm
What probably happens is you fail to call aw_wait on time. If aw_wait is
not called within I think 60 seconds, the bot gets disconnected. You can call aw_wait(0) or its VB equivalent as often as you like: the AW browser calls it for each frame, my bots call it 2x a second. I time this with a windows timer (VB has them too), setting the timer at 500 milliseconds. In the timer event, I call aw_wait(0). XelaG [View Quote] ctc oneOct 3, 2000, 11:48am
Ok I've got that in my program. I'll just have to check to make sure it's
called enought. Thanks. [View Quote] chandler56Oct 7, 2000, 5:32pm
Try setting the timer to an interval of 1000 ms (or 1 second), and have this
in the timer procedure. You should enable & disable this timer as the bot disconnects & connects: SDK.AwWait(0) -- - Chandler56 "Use your free will to the ULTIMATE advantage: Assassinate the Government!" [View Quote] xelagOct 9, 2000, 6:13am
[View Quote]
I disagree, Chandler56. The timer should not, as a rule, be disconnected
when bots connect or disconnect (especially if you have a multi-bot program). aw_wait(0) takes care of the stuff: if there is a disconnection (waiting for server), calling aw_wait is the only way to re-establish the connection. If you have more than one bot logged in, you can't stop the timer anyway if one bot disconnects. There are two problems related to these disconnections which could justify stopping the timer: 1. aw_wait(0) blocks for 40 seconds at a time when the disconnection is due to a universe or isp disconnection (not if only the world goes down). This is caused by the winsock blocking connection, which the AW bot SDK uses: the AW browser does not use a blocking connection. This blocking will freeze your UI. This in general is not fatal, but does affect other bots which are not disconnected, it slows them down a lot. 2. some world servers on NT machines have problems with the AW SDK: this sems to be a winsock problem in Windows NT in some configurations, I have never experienced it myself (running world servers on NT4 and now Win 2000). Linux world servers don't have this problem. But the benefits of not stopping the timer are bigger than these disadvantages, in my opinion. It garantees that the bot can be left unattended, and the AW SDK does its job of reconnecting. A better solution than stopping the timer, if one really wants to handle oneself these disconnections, is to remove the bot from the universe (log it off), so as to allow other bots to function normally. To detect a disconnection there are 2 methods, using the AW SDK only. 1. you get a aw_world_disconnect, if the world disconnects (stops or is not reachable). You can simulate this by stopping the world server. 2. the bot's session number changes to 439 (NoConnection) without getting the world disconnect event: this is the serious case, when aw_wait(0) starts blocking. You can simulate this case by unplugging your modem. Reconnections are detected because the bot gets the world attributes: that means things have normalised. In cases of universe disconnects, the bot will get first the callback aw_login, then the event aw_universe_attributes, followed by callback aw_enter and the event aw_world_attributes. These callbacks, btw, are the result of an aw_login and aw_enter issued by the AW SDK, not by your bot program: as I said before, the AW SDK takes care of the situation. XelaG > > SDK.AwWait(0) > > -- > - Chandler56 > "Use your free will to the ULTIMATE advantage: Assassinate the Government!" [View Quote] grimbleOct 22, 2000, 7:03pm
I have the same problem and playing with it I think it is closely related to
my post this morning in the "sdk" NG (AWSDKOCX: Multiple Asynchronous Object Changes 22/10/2000 11:09). I call awWait(0) every 250 milliseconds, and the debug info proves it (or as close I can to proving it. No big gaps in the calls or anything..... but the bot disappears for a couple of seconds and then comes back up. It even gets the aw_avatar_add event because it welcomes me back !! No preceding aw_world_disconnect though. Grrrr..... very irritating !! Better learn C again I think, if I can't find out anymore. Gonna go play with aw_object_add and aw_object_delete to see what I can discover. If you managed to sort this, ctc one, I'd be very interest. Grimble. [View Quote] xelagOct 22, 2000, 7:40pm
[View Quote]
Well, I have had this as well in the past: for some reason, the aw.dll seems
to become unstable, as it were, and disconnects the bot for a second or two from the world (I haven't checked the session number to see if that changes too). This affected one of my bots last year, running a slide-show script for the Avvy awards (Avatars 1999): after like 10 slides, every new slide-change flashed the bot in and out of existance. They had to finish the slide-show manually. I say it is the sdk and not the world or universe server, because I tested the bot after it 'got sick', moved it to another universe and ran the slide show there... from the first slide, the bot kept disappearing. The bot was only changing objects, and it does that regularly and well... I never touched that script again! One thing that *will* cause this behaviour (and that was not the case in my slide-show script) is if you send strings which are too long (longer that AW_MAX_ATTRIBUTE_LENGTH = 255). Alex. > > Grrrr..... very irritating !! Better learn C again I think, if I can't > find out anymore. Gonna go play with aw_object_add and aw_object_delete to > see what I can discover. > > If you managed to sort this, ctc one, I'd be very interest. > > Grimble. > > [View Quote] grimbleOct 23, 2000, 5:07pm
Thanks Xelag. Not good news, but thanks anyway. :O)
I'm going to play with it to check the session id to see if I can detect when it happens in some way. I'll post a message if I find out anything useful. Grimble [View Quote] grimbleOct 27, 2000, 8:14am
OK, incase anyone is interested, I managed to solve the problem (or about
90% of it anyway) by restricting the number of unconfirmed updates at any one time to 5 (!!!) by implementing a simple update queue in the bot (irritatingly AFTER I had tried a number of much more complex ways of getting around it. I have a number of chat calls going out at the same time (which I haven't queued yet), so I don't know if they affect the number I can have outstanding. That's the next thing (because obviously the chat and the pics are a little out of sync right now by deferring the updates for a few moments). Maybe that will stop the remaining 10%. It still disconnects every so often (still seemingly unpredictably) and the session number DOESN'T change, but you DO get the AW_EVENT_WORLD_DISCONNECT when it happens and so I do an incremental aw_query when it reconnects (on AW_EVENT_WORLD_ATTRIBUTES). There's a little pause in the overall process (only about 5 seconds in all, since this is a very quiet area apart from the picture updates) but its much less temperamental now. Five is a horribly low number when I want to make 12 updates at a time, but I guess I can try two or three update bots, controlled by a 'master' process and see if I can get that to work faster. The performance isn't too bad but not as fast as I wanted. Just through I'd share the good/bad news. Cheers, Grimble. [View Quote] |