1  |   Order by index

Dec 28, 1998, 3:14pm

Roland,

i got into some trouble when trying to look up citizen by name in
multi-instance applications.

I called citizen_attributes_by_name() without having callbacks installed.

Whenever i asked for a nonvalid name, such as a bots name, the answer is
correct, BUT

whenever i ask for a valid name, i get a response which is not neccessarily
related to my request... i get a different aw_string(AW_AVATAR_NAME) and the
aw_int(AW_CITIZEN_NUMBER) corresponds to the returned name, not to the name
i asked for.

i also found out that the current instance returned by aw_instance() seems
to be random. its a valid one, but not the one that was set before the
inquiry. that might be related to the fact that i have no callbacks
installed, and while the lookup waits for the server response it might
trigger other events which might cause my code to change the instance. this
is therefore just a side observation. and for the bot instance, even when
the answer is correct corresponding to the request, the bot instance is
usually not the one which issued the inquiry. I am not sure if the
citizen_lookup is in any way related to bot instances, if not this
observation is pointless.

my current workaround is to repeat the inquiry until the requested one gets
satisfied. that means that sometimes i have up to 8
citizen_attributes_by_name() calls before getting the right answer.

as far as i know XelaG ran into the same problem, and he was using
callbacks. he is currently using the same workaround as i am.

Could you comment on this ? What am i doing wrong, or could this be a
aw.dll "feature" ? :)

Walter

Dec 28, 1998, 7:21pm

It is possible that there is a bug in aw_citizen_attributes_by_name() in the
multi-instance case. I've tested it extensively under the single-instance
case but not multi-instance. I'll take a closer look at that.

As for what you said about aw_instance(), yes, in a multi-instance
application once you've called a synchronous API method (i.e. one without a
callback installed) the current instance can change at random, depending on
what events are triggered for the other instances while the SDK is waiting
for a response to your current call. That is one of the reasons why the
aw_instance() and aw_instance_set() calls are provided, so at any time you
can determine which instance is current, and change it to the one you want.

-Roland

[View Quote]

Dec 29, 1998, 6:46am

When using the callback in multi instance cases, aw_instance() was not
giving the right instance number, as far as I could see. I should
re-test it to be sure, but my workaround in this case is to:

1. ignore rc which does not work for me and Canopus (see earlier
postings) in any case.

2. ignore aw_instance()

To do this, I proceed as follows:

(i) I only send one aw_citizen_attributes_by_name() or _by_number()
request at a time, and wait for the callback before sending a new
request. I keep track of the bot instance (not using aw_instance())
and the contents and purpose of the request.

(ii) when the callback returns, I check my request with the contents
of AW_CITIZEN_NUMBER and AW_CITIZEN_NAME. I they are related, I know
(hopefully) the answer is correct. Otherwise, I got an error (rc
function substitute).

(iii) if the purpose was to determine the citizen number of a
citizen-like name that has a known session number (or citizen name in
the case of the login number), I know the person in question must be a
citizen and i should not have received an error back. If i didnt get
the required information, i iterate the call untill I get it right.

XelaG.

On Mon, 28 Dec 1998 13:21:48 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >It is possible that there is a bug in aw_citizen_attributes_by_name() in the
>multi-instance case. I've tested it extensively under the single-instance
>case but not multi-instance. I'll take a closer look at that.
>
>As for what you said about aw_instance(), yes, in a multi-instance
>application once you've called a synchronous API method (i.e. one without a
>callback installed) the current instance can change at random, depending on
>what events are triggered for the other instances while the SDK is waiting
>for a response to your current call. That is one of the reasons why the
>aw_instance() and aw_instance_set() calls are provided, so at any time you
>can determine which instance is current, and change it to the one you want.
>
>-Roland
>
[View Quote]

Dec 29, 1998, 6:54am

In (i), I DO set aw_instance_set() before sending the request to the
server.

XelaG.

Dec 29, 1998, 5:42pm

Wait, you are saying that aw_instance() is not correct during callbacks?
That doesn't make any sense. We are running bots right now that depend on
this functionality and they are working fine.

Or are you saying that it doesn't work during just this one callback? I
looked specifically at the code for the AW_CALLBACK_CITIZEN_ATTRIBUTES case,
it is correctly setting the current instance before triggering the callback,
just as with all other callbacks. I can't see how or why this callback
would behave any differently than the others...

If someone could provide some C code that demonstrates this problem, that
would help me a lot...thanks!

-Roland

[View Quote]

Dec 29, 1998, 10:21pm

What i said was that i did this from a c++ code which has its own instance
around in m_instance:

aw_instance_set(m_instance);
if (aw_citizen_attributes_by_name("Faber") == 0)
{
void **new_instance = aw_instance();

// and right here, in a multi-instance-application, the new_instance
// was quite often not m_instance anymore, but some other instance
// from my application... i could not see a pattern which instance it
returned.

// important for this although is, that i have no callback for the
// aw_citizen_attributes_by_name
// which means it could have triggered other handler-functions (e.g.
handle_avatar_add())
// for other instance, and in that case i do a lot of aw_instance_set()
myself
// which would all occur before the programm returns to this point here

}


I have not testes build 12 yet, but tonight my workaround noted NO retries
when looking up people by name, as if the bug would have been corrected in
the server..

i am about to d/l build 12 and recheck...

Walter


Roland Vilett schrieb in Nachricht <3689303c.0 at homer>...
>Wait, you are saying that aw_instance() is not correct during callbacks?
>That doesn't make any sense. We are running bots right now that depend on
>this functionality and they are working fine.
>
>Or are you saying that it doesn't work during just this one callback? I
>looked specifically at the code for the AW_CALLBACK_CITIZEN_ATTRIBUTES
case,
>it is correctly setting the current instance before triggering the
callback,
>just as with all other callbacks. I can't see how or why this callback
>would behave any differently than the others...
>
>If someone could provide some C code that demonstrates this problem, that
>would help me a lot...thanks!
>
>-Roland
>
[View Quote]

Dec 30, 1998, 12:41am

On Tue, 29 Dec 1998 11:42:11 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >Wait, you are saying that aw_instance() is not correct during callbacks?
>That doesn't make any sense. We are running bots right now that depend on
>this functionality and they are working fine.

I didn't imply this at all, we're following Faber's thread. It was a
specific probrem with citizen attributes.

>
>Or are you saying that it doesn't work during just this one callback?

The aw_instance() problem was my mistake. I've been checking all
afternoon at aw_games, and my error was that I had been asking for
aw_instance also in cases when I was not using the callback. A useless
query, you could rightly say. My appologies for the confusion.

>I looked specifically at the code for the AW_CALLBACK_CITIZEN_ATTRIBUTES case,
>it is correctly setting the current instance before triggering the callback,
>just as with all other callbacks. I can't see how or why this callback
>would behave any differently than the others...

>If someone could provide some C code that demonstrates this problem, that
>would help me a lot...thanks!
>
>-Roland

The mystery of the failed callbacks remains. That was the original
thread. Faber and I, separately, have been tracking, how many times we
must ask the server to-day (afternoon and night in Europe) until we
get the correct answer for an existing citize. Faber does not use
callbacks for this, I switch from one mode to the other. He had no
errors, I had very few. A big contrast with yesterday, when many if
not most queries for citizen numbers of existing citizens had to be
repeated. We were both using build 11, both days.

It could be that there sometimes is a server error, and that the dll
has nothing to do with this error, it just may report what it gets.

XelaG.

>
[View Quote]

Jan 11, 1999, 5:42pm

I have found a similar problem when using only 1 bot. In a teller bot
program which makes synchronous calls to aw_citizen_attributes_by_name, followed
by a request for aw_int(AW_CITIZEN_NUMBER), at several points, the number
returned is not always the one for the citizen named in the synchronous call.

Supposedly a synchronous call "blocks", and the CITIZEN_NUMBER should be the
one for the citizen named in aw_citizen_attributes_by_name. However, I get
reliable responses only when the teller bot is not distracted by avatars
arriving or chatting during the "block" period. (The bot tracks arriving and
departing avatars and it also tracks chat events.) This may be because the bot
maintains a list of all avatars and records all their attributes when they
arrive, including their citizen_number, which requires that EVENT_AVATAR_ADD
include its own "blocking" call to aw_citizen_attributes_by_name. (The calls to
aw_citizen_attributes_by_name during the chat events are needed to find out the
number of a citizen not necessarily present, the one that the client avatar is
transferring money to.)

XelaG reports that callbacks for aw_citizen_attributes_by_name are more
reliable than synchronous calls. I wonder if this is because the callback allows
you to do your own "blocking" by requesting aw_int(AW_CITIZEN_NAME) inside the
callback handler?

In this thread, it is reported that the problem can be serious one day and
almost undetectable the next. It would be easy to test whether the problem comes
and goes in parallel with the presence or absence of other avatars (if adding an
avatar includes calling aw_citizen_attributes_by_name or
aw_citizen_attributes_by_number). On days shen the only other avatar in the bank
with the teller bot is my own avatar, there have been no problems (so far!), but
on days when other avatars are arriving and chatting, reliability problems
occur.

Thanks to Walter Knupe and XelaG for detecting this problem, and also for
suggesting the workaround.



[View Quote] > Roland,
>
> i got into some trouble when trying to look up citizen by name in
> multi-instance applications.
>
> I called citizen_attributes_by_name() without having callbacks installed.
>
> Whenever i asked for a nonvalid name, such as a bots name, the answer is
> correct, BUT
>
> whenever i ask for a valid name, i get a response which is not neccessarily
> related to my request... i get a different aw_string(AW_AVATAR_NAME) and the
> aw_int(AW_CITIZEN_NUMBER) corresponds to the returned name, not to the name
> i asked for.
>
> i also found out that the current instance returned by aw_instance() seems
> to be random. its a valid one, but not the one that was set before the
> inquiry. that might be related to the fact that i have no callbacks
> installed, and while the lookup waits for the server response it might
> trigger other events which might cause my code to change the instance. this
> is therefore just a side observation. and for the bot instance, even when
> the answer is correct corresponding to the request, the bot instance is
> usually not the one which issued the inquiry. I am not sure if the
> citizen_lookup is in any way related to bot instances, if not this
> observation is pointless.
>
> my current workaround is to repeat the inquiry until the requested one gets
> satisfied. that means that sometimes i have up to 8
> citizen_attributes_by_name() calls before getting the right answer.
>
> as far as i know XelaG ran into the same problem, and he was using
> callbacks. he is currently using the same workaround as i am.
>
> Could you comment on this ? What am i doing wrong, or could this be a
> aw.dll "feature" ? :)
>
> Walter

Jan 11, 1999, 6:15pm

If you have a synchronous aw_citizen_attributes_by_name and handle
avatar_add events, take care of the following:

Say your bot arrives in an area where there are more than one people
already, e.g. 2 or 3.. your bot then gets all avatar_events directly... so
you receive the first avata_add...

you work on the info you got by calling sync aw_citizen_attributes_by_name .
that call blocks until you get the answer.. it blocks means it does internal
aw_wait() AND dispatches events. so while you are sitting there in your
avatar_add() event function waiting or aw_citizen_attributes_by_name to
return, your avatar_add() function gets called a second time, this time with
the information of the second avatar. everytime i called
aw_citizen_attributes_by_name INSIDE my last call to it, it immediately
returned with an error.
but even if you DON't call aw_citizen_attributes_by_name inside that second
evend, the event arriving alone did change the aw_int(AW_CITIZEN_NUMBER)
already...

result... use sync or async, but not both at the same time :)

Walter aka Faber



Canopus schrieb in Nachricht <369A5436.62EBF456 at ix.netcom.com>...
> I have found a similar problem when using only 1 bot. In a teller bot
>program which makes synchronous calls to aw_citizen_attributes_by_name,
followed
>by a request for aw_int(AW_CITIZEN_NUMBER), at several points, the number
>returned is not always the one for the citizen named in the synchronous
call.
>
> Supposedly a synchronous call "blocks", and the CITIZEN_NUMBER should
be the
>one for the citizen named in aw_citizen_attributes_by_name. However, I get
>reliable responses only when the teller bot is not distracted by avatars
>arriving or chatting during the "block" period. (The bot tracks arriving
and
>departing avatars and it also tracks chat events.) This may be because the
bot
>maintains a list of all avatars and records all their attributes when they
>arrive, including their citizen_number, which requires that
EVENT_AVATAR_ADD
>include its own "blocking" call to aw_citizen_attributes_by_name. (The
calls to
>aw_citizen_attributes_by_name during the chat events are needed to find out
the
>number of a citizen not necessarily present, the one that the client avatar
is
>transferring money to.)
>
> XelaG reports that callbacks for aw_citizen_attributes_by_name are more
>reliable than synchronous calls. I wonder if this is because the callback
allows
>you to do your own "blocking" by requesting aw_int(AW_CITIZEN_NAME) inside
the
>callback handler?
>
> In this thread, it is reported that the problem can be serious one day
and
>almost undetectable the next. It would be easy to test whether the problem
comes
>and goes in parallel with the presence or absence of other avatars (if
adding an
>avatar includes calling aw_citizen_attributes_by_name or
>aw_citizen_attributes_by_number). On days shen the only other avatar in the
bank
>with the teller bot is my own avatar, there have been no problems (so
far!), but
>on days when other avatars are arriving and chatting, reliability problems
>occur.
>
> Thanks to Walter Knupe and XelaG for detecting this problem, and also
for
>suggesting the workaround.
>
>
>
[View Quote]

Jan 12, 1999, 5:04am

Meaning I would be wise to set a callback handler for
aw_citizen_attributes_by_name, and pose the Citizen Number question there (async
during a regime of asyncs)?

[View Quote] > If you have a synchronous aw_citizen_attributes_by_name and handle
> avatar_add events, take care of the following:
>
> Say your bot arrives in an area where there are more than one people
> already, e.g. 2 or 3.. your bot then gets all avatar_events directly... so
> you receive the first avata_add...
>
> you work on the info you got by calling sync aw_citizen_attributes_by_name .
> that call blocks until you get the answer.. it blocks means it does internal
> aw_wait() AND dispatches events. so while you are sitting there in your
> avatar_add() event function waiting or aw_citizen_attributes_by_name to
> return, your avatar_add() function gets called a second time, this time with
> the information of the second avatar. everytime i called
> aw_citizen_attributes_by_name INSIDE my last call to it, it immediately
> returned with an error.
> but even if you DON't call aw_citizen_attributes_by_name inside that second
> evend, the event arriving alone did change the aw_int(AW_CITIZEN_NUMBER)
> already...
>
> result... use sync or async, but not both at the same time :)
>
> Walter aka Faber
>
> Canopus schrieb in Nachricht <369A5436.62EBF456 at ix.netcom.com>...
> followed
> call.
> be the
> and
> bot
> EVENT_AVATAR_ADD
> calls to
> the
> is
> allows
> the
> and
> comes
> adding an
> bank
> far!), but
> for
> neccessarily
> the
> name
> seems
> this
> gets

Jan 12, 1999, 4:21pm

I think my email to you whould answer this question ( and maybe open up alot
of other questions, who knows :)

Walter

Canopus schrieb in Nachricht <369AF418.1285DFE9 at ix.netcom.com>...
>Meaning I would be wise to set a callback handler for
>aw_citizen_attributes_by_name, and pose the Citizen Number question there
(async
>during a regime of asyncs)?
>

Jan 12, 1999, 9:43pm

Thanks a lot, Walter, for the enlightening general remarks from yesterday, and the
helpful clarification today. :0) Until now I had the mistaken impression that the
implicit aw_wait that occurs in a synchronous call allowed only events relevant to
the call: e.g., that aw_query allowed only CELL_BEGIN, CELL_OBJECT, and CELL_END;
and so I thought a synchronous call to aw_citizen_attributes_by_name, with its
implicit aw_wait, would not allow any AVATAR_ADD, AVATAR_DELETE, or CHAT events to
occur during its implicit aw_wait. In fact, it looks like AVATAR_ADD occurs as soon
as aw_citizen_attributes_by_name "blocks", and AVATAR_ADD proceeds to scribble its
own number on the board where I expected the CITIZEN_NUMBER to be, in answer to
aw_citizen_attributes_by_name. Is this effect just limited to citizen_attributes? or
is it dangerous to use other synchronous calls (aw_query, aw_object_add, aw_enter)
that "block" and do an implicit aw_wait?

[View Quote] > Meaning I would be wise to set a callback handler for
> aw_citizen_attributes_by_name, and pose the Citizen Number question there (async
> during a regime of asyncs)?
>
[View Quote]

Jan 13, 1999, 5:06pm

[View Quote] >Thanks a lot, Walter, for the enlightening general remarks from yesterday,
and the
>helpful clarification today. :0) Until now I had the mistaken impression
that the
>implicit aw_wait that occurs in a synchronous call allowed only events
relevant to
>the call: e.g., that aw_query allowed only CELL_BEGIN, CELL_OBJECT, and
CELL_END;
>and so I thought a synchronous call to aw_citizen_attributes_by_name, with
its
>implicit aw_wait, would not allow any AVATAR_ADD, AVATAR_DELETE, or CHAT
events to
>occur during its implicit aw_wait. In fact, it looks like AVATAR_ADD occurs
as soon
>as aw_citizen_attributes_by_name "blocks", and AVATAR_ADD proceeds to
scribble its
>own number on the board where I expected the CITIZEN_NUMBER to be, in
answer to
>aw_citizen_attributes_by_name. Is this effect just limited to
citizen_attributes? or
>is it dangerous to use other synchronous calls (aw_query, aw_object_add,
aw_enter)
>that "block" and do an implicit aw_wait?

According to my experience, its dangerous for any synchronous call. I felt
like the world and universe could have gone down and up again after the
function returned.

But the information that you specifically requested in sync call and the
return code, both should still belong to your inquiry. I say should, because
i did have the case where any
aw_citizien_attributes_by_name() call returned completely valid, but
completely irrelevant information.... you would find it in some thread here,
but as a warning to you, this is what happened

i did, in sync manner, a aw_citizien_attributes_by_name("Faber"); in a
situation with say 10 other people around, say "Person1" to "person10";

so in 2 or 3 out of 10 calls like this i got after the call
aw_string(AW_CITIZEN_NAME) = "Person1";
aw_int(AW_CITIZEN_NUMBER) = <citno for person1>
or e.g.
aw_string(AW_CITIZEN_NAME) = "Person7";
aw_int(AW_CITIZEN_NUMBER) = <citno for person7>

which was perfectly valid, but not very interesting since not requested...
so i repeated the inquiry until i got
aw_string(AW_CITIZEN_NAME) = "Faber";
aw_int(AW_CITIZEN_NUMBER) = <citno for Faber>


the interesting point here is, that these reattempts, which i had displayed
on my screen, disappeared from one day to the next, that was 2 days before
the release of sdk build12.
since then, and therefore since using Build12, that did not reoccur, but
noone could explain why this odd behaviour disappeared in the first place.
this bug-disappearing is not connected to the upgrade from build 11 to 12.

so you might have run into an server or sdk bug, and the workaround for that
is to repeat your request and verify the returned name.


Walter aka Faber

1  |   Order by index