Thread

Bots Disappearing (Bots)

Bots Disappearing // Bots

1  |  

ctc one

Oct 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

xelag

Oct 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 one

Oct 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]

chandler56

Oct 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]

xelag

Oct 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]

grimble

Oct 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]

xelag

Oct 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]

grimble

Oct 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]

grimble

Oct 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]

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn