ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
citizen lookup confusion (Sdk)
citizen lookup confusion // Sdkwalter knupeDec 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 roland vilettDec 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] decastro@cable.a2000.nl (xelag)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] decastro@cable.a2000.nl (xelag)Dec 29, 1998, 6:54am
In (i), I DO set aw_instance_set() before sending the request to the
server. XelaG. roland vilettDec 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] walter knupeDec 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] decastro@cable.a2000.nl (xelag)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] canopusJan 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 walter knupeJan 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] canopusJan 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 walter knupeJan 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)? > canopusJan 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] walter knupeJan 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 |