1  |   Order by index

Mar 27, 2004, 11:20am

I think its is very important for the SDK (considering 3.5 SDK should be
along soon) to have some form of method for indicating its connection
state... There is the enumeration for some kinds of connection, but its
only available to the world server?

Its important for bots to know where they are...

My ideas:

Have AW_CALLBACK_ENTER trigger when reconnecting from a dissconection

have AW_EVENT_UNIVERSE_DISCONNECT implimented someway

get rid of bloody session 444 as a normal session...

- MR

Mar 27, 2004, 2:29pm

[View Quote] > I think its is very important for the SDK (considering 3.5 SDK should be
> along soon) to have some form of method for indicating its connection
> state... There is the enumeration for some kinds of connection, but its
> only available to the world server?
>
> Its important for bots to know where they are...
>
> My ideas:
>
> Have AW_CALLBACK_ENTER trigger when reconnecting from a dissconection
>
> have AW_EVENT_UNIVERSE_DISCONNECT implimented someway
>
> get rid of bloody session 444 as a normal session...
>
> - MR
>
>

When you reconnect to the world, you'll receive an AW_EVENT_WORLD_ATTRIBUTES event. Just add your handler to use it.
The same is valid for the reconnection to the uniserver except use the AW_EVENT_UNIVERSE_ATTRIBUTES event

--
Andras
"It's MY computer" (tm Steve Gibson)

Mar 27, 2004, 3:41pm

On 27 Mar 2004 08:20:51 -0500, "strike rapier"
[View Quote] >I think its is very important for the SDK (considering 3.5 SDK should be
>along soon) to have some form of method for indicating its connection
>state... There is the enumeration for some kinds of connection, but its
>only available to the world server?
>
>Its important for bots to know where they are...
>
>My ideas:
>
>Have AW_CALLBACK_ENTER trigger when reconnecting from a dissconection
>
>have AW_EVENT_UNIVERSE_DISCONNECT implimented someway
>
>get rid of bloody session 444 as a normal session...
>
>- MR
>


Besides what Andras said, I would like to add that a session turns to
reason 439 when there is a universe disconnect. It would be better to
have a separate event though, like when the world disconnects:
AW_EVENT_UNIVERSE_DISCONNECT would be great to have!

Alex

Mar 27, 2004, 9:12pm

[View Quote] I understand what Andras is saying, and I couldent agree more about the
universe dissconect... my problem is when I recieve world dissconect I don't
know if im kicked out of the world or the universe by the dissconection...
if I have to wait for a universe attributes event to update my status
displays thats useless... because by the time I have recieved them its
already too late to update the displays... because im connected again.

- MR

Mar 27, 2004, 11:11pm

On 27 Mar 2004 18:12:52 -0500, "strike rapier"
[View Quote] >I understand what Andras is saying, and I couldent agree more about the
>universe dissconect... my problem is when I recieve world dissconect I don't
>know if im kicked out of the world or the universe by the dissconection...
>if I have to wait for a universe attributes event to update my status
>displays thats useless... because by the time I have recieved them its
>already too late to update the displays... because im connected again.
>
>- MR

Yes you know... a world disconnect message is a world disconnect, not
a universe disconnect. The only way you can track universe
disconnects at the moment is to check the bot's session number. I do
that in every event, and especially after I call aw_wait. Never
assume a world disconnect is a universe disconnect, just test them
separately. It works 100% fime in my bot.

Alex

Mar 27, 2004, 11:12pm

fime=fine

[View Quote] >On 27 Mar 2004 18:12:52 -0500, "strike rapier"
[View Quote]

Mar 27, 2004, 11:19pm

Unless your session number is you know what... although I guess that is just
for aw_session... hmmm

- MR

[View Quote]

Mar 28, 2004, 12:29am

Well in practice, I have not had problems with overlapping session and
reason numbers. My bot will post in red that the session is
doubtfull if it is within the range of reason numbers, but that won't
really affect it. A few reason numbers in the session will though, my
choice, those related to disconnects:

471 RC_CONNECTION_LOST
429 RC_UNABLE_TO_CONNECT
439 RC_NO_CONNECTION

Apparently, only 439 as session number should indicate that the uni
has disconnected (Will somewhere in the beta ng said that), but
because my code was already written, I left it at this. Whenever any
of these numbers appears as session numbers, I unlog the bot, destroy
the instance, and start anew. This has always worked for me.

Alex

On 27 Mar 2004 20:19:49 -0500, "strike rapier"
[View Quote] >Unless your session number is you know what... although I guess that is just
>for aw_session... hmmm
>
>- MR
>
[View Quote]

1  |   Order by index