1  2  3  4  5  6  |   Order by default

Dec 15, 1998, 1:10am

The need to separate state_changes by a timed lapse of 1-5 seconds
should be in the documentation. It came up earlier in connection with
bot movements (MY_X, MY_Y, MY_Z, MY_YAW); now it comes up again in
connection with bot gestures (MY_GESTURE). The example given would be
appropriate, since it also shows that there are (still undocumented) two
state_changes needed in certain cases, such as gestures. New programmers
are reluctant to read through over 1000 newsgroup messages looking for
solutions.

[View Quote] > Part 1.1 Type: Plain Text (text/plain)
> Encoding: quoted-printable

Dec 15, 1998, 2:29am

Doing AW_MY_GESTURE apparently involves requesting the special gesture and then
requesting the default gesture, with a pause of a few seconds between them. In a
multibot program it may be easier to post a flag in the CHAT event handler, and to do
both the special gesture and the default gesture in the main program loop (with the
few second pause between them). The order in which the bot instances are notified of
the CHAT event is somewhat unpredictable. Putting everything in the main loop
simplifies your interpretation of the timer signals. (I tried out this arrangement,
and it seems to work well; it also gives you more control over your bot's action
sequence.) Admittedly, with one bot, it may be simpler to request the special gesture
in the CHAT event handler, and request the default gesture, after a timed pause, in
the main program loop. But I notice you are also interested in the general case.

[View Quote] > People seem to have more success if there is an explicit loop around aw_wait, and
> the 'while aw_wait' loop includes the AW_MY_GESTURE instead of the CHAT event
> handler. A global flag can be set in the CHAT event handler, and the loop can
> respond to the flag with the GESTURE. At least this worked better for us with
> AVATAR_CHANGE events and aw_say responses. (As if the "context" for the response
> to the event wasn't the event itself.)
>
[View Quote]

Dec 15, 1998, 5:05pm

Also the documentation for aw_state_change might mention that if you leave
out an attribute for AW_MY, the server gives you a default. If you leave
them all out on your first aw_state_change, your bot will be a Tourist
located at GZ doing nothing special (all zeroes).

[View Quote] > The need to separate state_changes by a timed lapse of 1-5 seconds
> should be in the documentation. It came up earlier in connection with
> bot movements (MY_X, MY_Y, MY_Z, MY_YAW); now it comes up again in
> connection with bot gestures (MY_GESTURE). The example given would be
> appropriate, since it also shows that there are (still undocumented) two
> state_changes needed in certain cases, such as gestures. New programmers
> are reluctant to read through over 1000 newsgroup messages looking for
> solutions.
>
[View Quote]

Dec 15, 1998, 10:34pm

Thanks, Roland. I hope that all your clear and helpful remarks from this thread
will soon make their way into the documentation!

[View Quote] > This isn't quite correct. Every time you call aw_state_change(), as with
> all API methods that use attributes, the values of all attributes are sent
> to the server regardless of whether your code sets them or not. If you have
> never set an attribute, its value will be zero for integers, false for
> booleans, and empty for strings (note this doesn't apply to attributes that
> are set automatically by the SDK in response to events and requests.) If
> you have set it before, it will continue to retain that value until you set
> it again.
>
> This is why it is okay to only set AW_MY_GESTURE and call aw_state_change(),
> without setting all other AW_MY_ attributes as well, assuming you have
> already called aw_state_change() before to locate your avatar in the world
> somewhere. The SDK will simply send again all the same values for AW_MY_X,
> AW_MY_Y, etc. as before. Note that this is different from the concept of
> the server assigning default values for unspecified attributes.
>
> -Roland
>
[View Quote]

Dec 18, 1999, 7:00pm

I've added two new construction bots to the website at
http://www.canopus.org/construction/construction.html. The first is a
LostFound Bot that will scan all the Census Districts of a world looking
for property you have lost track of. If it finds a District with objects
belonging to you in it, it will record the coords of a sample object of
yours in that District. The second bot is a VisualFinder Bot. It will
assist you by stating the model and exact location of objects which you
right-click.
I've also updated the program for Designer Artifacts, and put updated
Delphi source code for the AWAPI & the SDK encapsulation on a new
webpage at http://www.canopus.org/delphi/delphi.html.

Dec 16, 1998, 10:48pm

Gee, I wasn't making a point. Just thought that it would be easy to copy
paragraphs from this thread into the aw_state_change doc or the AW_MY_GESTURE
doc.

[View Quote] > So, ummm, what exactly is your point, Canopus? That the documentation is
> incomplete? Thanks, but I already knew that. Like the SDK itself, and Active
> Worlds in general, the documentation is a work in progress, and it will
> improve with time
>
> -Roland
>
[View Quote]

Dec 17, 1998, 7:40pm

Thanks for all the updates in the documents, Roland. I just went through the
methods, attributes, and events and downloaded over a dozen ones that sounded
new to me, including aw_state_change. (Hmmm, maybe it was there for weeks
already.)

[View Quote] > Sorry. It's just that I thought he was giving *me* a hard time about the
> docs...I'm a bit over-extended here trying to keep everything going at once
> and sometimes I can get defensive.
>
> -Roland
>
[View Quote]

Dec 16, 1998, 2:12am

This is a multi-part message in MIME format.
--------------666C325B562452EF2495B2D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is the Delphi (Object Pascal) version of Build 11 of the AWAPI.
If you're new to the SDK, go back to the 10/1/98 Delphi thread, where
there are general instructions for using the Delphi AWAPI.

--------------666C325B562452EF2495B2D4
Content-Type: application/x-zip-compressed; name="Build11AWAPI.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Build11AWAPI.zip"

UEsDBBQAAAAIAAmfjyW89/U0cQwAACtCAAALAAAAYWtBV0FQSS5wYXPFGmtv48bxuwH/h4W/
nGy4bhMgXyIEKCXRNnMSqZDU+VG0AiWtbeYo0SEp+5xD/ntnl699i5LvWgW4kDM779nZ2aG/
Rp+tG2vqXEyj/K/jo+Oj7SYuUAXsE8DXsxFOnp9i1PMWv+NlgWDlMkpO0QovkyiLijjd5Cja
rFC8fk6zAiXxIouyt+Mj9JBmqHjCyFoW8QtGN2mWrHIEjM+oqHhT4OwhWmIqN8c5kKCbeLNK
X/NzNMF5Hj1ieAre8lkRJ/A0TKIc1lG9liC2QNbNfGLdzq0w9J3BLLTnY9u9Cq/RL+jHn37q
M6sGM2c8AvAPP1Dq46Pe2d++5Y/obvhFqID/MhSjBdrCE0Zg7W6ue/zOTolVxdszJuY2DgGT
e0Q3gI29K8edu9bEPucgUysIbjx/xEO9G9f2hYW+88kZ21e2hqTFu7PJQE+tUAFw1vCOB1rT
6dgZWqHjuTzCnljO+Bz1zjZpgSBxVmjxRhMtGH0kbqBLZ67zyfYDez7wvZvA9ucTx3Ums8m5
Du/bY9sKbC1+YIeWhAQnjEda1iU2CC0/lHC+feUEoU/Ng5ffZo5vN/4cOqFzb7uCHxso478a
Jkakhpe+EoChMyE75TKUuGgjXK9wJhPnqtKasJHk3U4dA5p1Yg0bW0FYRlZa7QHCmTiNnqVD
WftLSOiEYwE0sIYfR7435aFXvjdzRzzMG/xqD0OwOLxWInz70rcDAUfrydx3rq4F5WxIBtsN
5yMPPO8qV7ghSTcZEUztoWONK7mBaklt1ZxJFgFz5du2q8ENxjPBTUPLh5B8BIWG1tQaOGMn
vONXgO1QS4ahDY/WyJkFPHo6G8AuJbobuQjLFKYNfbvNG9gzEyF0196EpOWVGGcaCH6jCHHl
M7lEjpzAGoztUqo9n/ljwWrQxb3iYTf2eEiUAPUCSQ+7zBVFuClC55ehPR6rcrw0S0dljcfe
DbUsvPZnKtzl+E7Sv8SEUOemni/Isz5ZUKaCOaRsMLRdW0VZOTQABkNRXU+drzTeWjNKLEc2
uZvfMs93zPM9C7dumLfwbmozr1eQPjO/gZSmgdpBwBwlFZStJRXoVni/E97vRXyrSwVh9alA
gk7DaysUNaIwIbdoetxyb/fcWwAnh+0OeYIAqmcNqILGb5AKeCu83wnv9yK+tbSCTLyRPRZg
IzsY+s6UPbcrjDVUAD1p+zIIUUMCE7XiOpUmRznXVtByU0n1BTzo381ha0/HdsiHiI0k1C/b
DYT2pYJJDVEFn0HnEIhA33KvJA7cQV0DQacJHBcSmC2VEiP1CVyj6WnLtSR0L46hGZEPVgqF
xaFQ9Smcs81Wub0EjmY+18RRKFHPGo3gcAkkeGtBjYJqPfRctzyNraBFXEK3wqlNAT6co1OH
cRyFBrY7ahOFAckMBDsoTNCWwqo6SkC9MxQVRRYvtgXO0QIn6SuKMowUPSoqe/Uyyzw3tKT9
WUN51zdr2f6vgtGwiMCJ11YcUvahcZvMQ08CXfreRF5n34YSMGCc2gBZMb96wh2DAqqGjoNx
GlPILfd2x73d87i2EJV9NOk8hpxcDs45l8VMwFPXKsSdbckEQgq065mTrQGS2Mna3DtTCTa9
9lzxztQgB7MAGsogUBv3CRLYk4lAy9m4PVPZG/Lx0WmfvSnan0i3qrovVpjy/ALTz1VwqJJM
MeNQcDIw5bRE0eNpYDO9PgMvq7QCYbuCcFKbeUh9wohqNmeSrEtzFWuMD/gFVe9jxDrupaeC
txWLx5KKQ2uHYBCz4QVUvc14KNkGbHwpFGKLuOAOoXEjzT8T1Rok3LhqKL2cSNDmJsSmVcup
OlpkT0lLNBzqC5+BQ71Ew4Ge4RK0jAU5rSSUFIgGw7q2AdYHPKWTsPWtWGZWb0k2VjVSDlfd
cgRswGiraDmtVAIY+J41GlqMYQR6c+1AT+3LjNn04phXCO/ycuy0XX8DdlVQF67lVh0QSVbV
2ouSKLg8z2DnfXShaztXoMp7ohJDZkS0fnHynhwy4fsFTVM6T+wTSvhNW8x/qscaZd3YL3hT
TLN0Cdhn+B9ebTPcoodRkiyi5WdxRS9bop+RA2IeccZU0QAvizQL8B85rLayLHr71z8uLn48
R+Tff6P0oabp/+8Hj+S3RhgV6AmlaPWdxo4P282SDIJBWPQ6j8kMubfYxsmK8Vfz1EdLMjsG
ZzSepWQQvTVqkTzPZYajAqNeOdBdpeso3gDz6fApAoZ08MwIiGFRtFli9DO4p06FUySpgL6S
luwhBcEQJfLcUD5HWbRGcY5O/rlIix9OUJoBr5NNnJz8pVZunuE8TV6g1etFqxW85CBwGGWr
eBMlh+soClvhvMjSN7R7ZSMBltZ7YMfSeY4hdK1qqIvvQH+996jzJI8l6SPEb7cJrxFJpXWc
JHGOIfarnMmoLh4A6oia0Z4t3ehKT4i0ffQSJVu8lxIQrnjzqNajyl8ToUaRciPU2lA+rC4Q
EzXTRZomB/mEEL7HKegr/aiEXtJ4Ra5LZN9UhRb1mCMTLU9PhUr7F6F20wL/TLMMf3kmu4to
dsJwOfn7CcPmhGQfvXgVrzFk5BPO8IWUh58bDZalUTX5KX1lTwLWEmH7V6tK73Cm9Etze2f1
mlPE23ZKtz9TFS7wBTWyEfFMD7YV3C7JFbJx2XoL4X+KXjBqSthJjaRnguDDEySWOrK6LHA1
3cNG3qmfOeMEL/VbfUR3lYZ1yQJMTmPqN/EuEkEmkIU0A3i1KqIqFQXCMnjNKa+PHOXShE0S
30TvKdqsEpLXpTr7Bq0iV8SMRuqkwvcgSvogVYvImSlHiTFE7ZJ+owTnGk2UBOaksaqP3lfy
FbetXNFLVETZflUZf4Gi3qFuRm+10Oh1XX4OVpU63dHxFOfPRO+8rBXzmOlG+h34aksonHFw
2i/BoY+4gx3LuIj/xJt5Ox6aL97mm2jdtDP0ubtlGobb9YKGqcSqI6K1qeG5Wu1h0t4+WOEE
0zbOpOQOHhv8pUv61MvhrHiJ023egSSBg2KT445OaFa3Y7/D4lkz6uzNmqDx5nukdnRnvVzp
Tt0WJLUCKPMuAlL65yUdfV8t7uyxan3lsN3r/9jiDKrPFyip5G7HEvypgOUYCOpevr0OdohC
BlU5XXfphKkvmS3f2fbtJn7BGZeo3Ymr4tlZQUz/RmgPpSgBKc/dAl/6fv6Qpev5EsPZ2KP/
musIuXSjNS6e0pU4ml9uswzOt+SNnGRxEi0ScosRJvVCYUk3RVRl6mGFrGLwrmJY8aCbq1e9
5RxdwzUiIwlmDHHa4cxfwbGu6vQTvHksnkiZYXQ13mIIp+53GEZCK2C3ugW48hGunCBo0yWN
fof+7DDHE0q46T8nbwr6PqKYOdd6M2jt8fsc5TlsoFVX/eP1OgZ7O9WyDD9CkkBr0GV3bVbz
hzjpVhmqtbU3zKYzm/H4KF4/J3gN+47++WAJEwzsNkOCuyBYtokS9MF6vVglyQd6DIKfP1RM
PvSNcyYNA0TpycoP8tb7PqMokyKlSJ0q32nwpNPogyxY1kw/pTKxrahkdoZR1q4UKAn1LPcZ
edWiCHNJeZahLE438TK5g9LIrPYcipm1JsxUzuk2OGu1F71fekTN+l1jJIO/KtayzM4jOLOv
SjY69jqruk7qTJa1EmTpnSd65p1C2KiZf69w1bxlqQeM5cyRq8dUelHfZL5lLJmMIFmNQ+ZZ
ZpMpR42gbzUpMtnbCFLosHnvQMkomHBXCFVPnYycvqhqo24utVTfu3eUlEhx2plHV6iD7E5F
pRKjqmfGAZe5jrDEio7l/cMw4ybTsu+syl5jtAN0ofwN2iivwWaXM7R6xgeGkyfXs9/nMruj
VnMc9RI1g6tu5hBiPWvDzLAb+5qBog80zhjN3BlaA+P9x5HGHlRiqxd9YIrx5Hr2e407zTnG
s9SLPCjHWGI964NzTGSgOD9Mc1cz85ZUZmuc0JrZtqRatgcmD0etZa4d/HZirsuS7zYlNm1I
KlTWRTtINvEqiXQJ1GVebN5mGj6ywL1m1GaZelaKRkc73TZ5raLSuU03Au+y8SitwT07puVm
EUouKqfsPWLf0eMKDInI//NIfkcH0rJT9AgHTO+7idM2PN941m9sWhlZsibv+Spgkkr4qqXt
MVRp1WhN3rO21hJlXXZ9YDDvPI5aZt79a4Q5kQgfNff3f7Ewua2VIEvf9WXD7DiOWmZu+gxi
ZtxQKk5S/fcSM8+aUFVS9d9VzDwbSgPTPT/AmI82jmdZqQF2cXz0X1BLAQIyCxQAAAAIAAmf
jyW89/U0cQwAACtCAAALAAAAAAAAAAEAIAC2gQAAAABha0FXQVBJLnBhc1BLBQYAAAAAAQAB
ADkAAACaDAAAAAA=
--------------666C325B562452EF2495B2D4--

Jan 27, 1999, 10:00pm

I'm working on an object-oriented platform for Delphi programmers, one that will
use avatar, chat, citizen, and other objects and will hide a lot of aw details
inside object methods. From reading this thread, and also the thread below about
citizen lookup confusion, I have come to believe that it is dangerous to use
synchronous calls (aw_citizen_attributes_by_name, aw_object_add, aw_query,
aw_enter, etc.) in programs that also contain event handlers and asynchronous
callbacks. The danger occurs because the synchronous calls do an implicit
aw_wait, and during that aw_wait, any event handler or asynchronous callback
might be called. This is what the documentation on Events warns us about, namely
that "events can be triggered at any time the SDK is active...except for those
methods that are documented to 'return immediately'."

The methods that are documented to "return immediately" are the ones that can
and do have callbacks installed (the ones that can be dangerous when
synchronous, but are tamed when divided into an earlier part and an asynchronous
part). My question is, are there other methods that "return immediately"?
Specifically, will events and asynchronous callbacks occur during the course of
methods like aw_state_change, aw_say, aw_session, and aw_whisper?

[View Quote] > Roland,
>
> i trying to implent user-level security into my bot, so i had it ask for the
> citizen number of a avatar in response to a request. it used
> aw_citizen_by_name().
>
> the problem is that aw_citizen_by_name does an internal aw_wait() while
> waiting for the server, which in turn calls my callback functions for any
> events, and that causes other code in my bot to get executed, and changing
> state inside... e.g. the state about the person talking to the bot...
>
> after that inner request is served, and my callback function returns, it
> returns back to the callback function, which returns into aw_wait(), which
> finaly returns the aw_citizen_by_name() call. in that function i do have the
> information requested, but i am unaware that in the meantime a lot of other
> eventhandling and state changing took place....
>
> my point is here, that we need callback functions for ALL aw.dll functions
> which might block on an aw_wait() call. and it would be nice to be able to
> disable event dispatching for the period of a function call.
>
> the current way is similar to windows message dispatching. code invoked in
> response to a windows message which opens a messagebox invokes internal
> message dispatching again, and might be re-called while still in the
> function.. message-based preemptive tasking, that is :)
>
> for now i am going to disable userlevel auth, but i think i have to redo my
> complete event and callback dispatching.. i have to store everything on a
> FIFO list and work on that from the top level aw_wait() loop only.. which
> disables all benefit gained by a callback mechanism...
>
> Walter
>
> Walter

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

Dec 31, 1998, 2:36am

I just tried the OBJECT_RESULT callback, using an old program that tested
whether a visible bot in one zone of Beta could build in another zone of Beta
(it could), plus tried to find out which OBJECT_ATTRIBUTES were valid in the
context of OBJECT_RESULT (the same ones as for object_add, it appears). This
time I also collected the value returned in the rc parameter: it was an integer
all right (4364880). This is not a recognized reason code, but it's not 0
either, even though the object was built at the correct spot.

So I rewrote the program slightly, having the bot try to build an object at a
spot where there already was an object not belonging to the bot's owner
(presumably illegal); this time the value returned in the rc parameter was also
an integer, but a new one (4364876). This is also not a recognizable reason
code, though admittedly it's not 0.

What happens when your C programs inspect the rc parameter value in a callback?
Never any problems? This isn't a parameter that is passed by reference, is it?
What could be causing this strange problem? Usually there's no problem with the
rc returned by an aw_int function.

On 12/1, XelaG reported a problem with the rc value in callback parameters. At
that time, I tried it out and had a similar problem. Then, I tried some other rc
values which are not stated in the documentation to actually be reason codes.
One of them, the rc value of the aw_query function, behaved in the same strange
way, as I reported. Since Sample 2 specifically avoided getting the rc on
aw_query (and the query callback), I was led to believe that undocumented rc
must also be unreliable rc. But if this is just a problem with the Delphi
connection to certain sdk functions, I'd be grateful to hear that this is not a
problem in the C or C++ programs that are getting rc during callbacks or during
aw_query.

[View Quote] > Roland,
>
> this is what i'd say too, so maybee we can help Xelag out here somewhere...
>
> xelag, did you try the OBJECT callback yet ?
>
> i am sure we can find a way to tell delphi to correctly supplying a function
> receiving a
> simple integer...
>
> Walter
>
> Roland Vilett schrieb in Nachricht <368a96d2.0 at homer>...

Dec 31, 1998, 3:57am

We're using the cdecl calling convention. We began using the stdcall convention, but
that definitely was not right (see 10/1 thread). We still have the options of the
register, pascal, and safecall conventions, which have not been tried. I don't know
of an aw function parameter passed from Delphi that has had problems under the cdecl
convention for parameter passing.

[View Quote] > I just tried the OBJECT_RESULT callback, using an old program that tested
> whether a visible bot in one zone of Beta could build in another zone of Beta
> (it could), plus tried to find out which OBJECT_ATTRIBUTES were valid in the
> context of OBJECT_RESULT (the same ones as for object_add, it appears). This
> time I also collected the value returned in the rc parameter: it was an integer
> all right (4364880). This is not a recognized reason code, but it's not 0
> either, even though the object was built at the correct spot.
>
> So I rewrote the program slightly, having the bot try to build an object at a
> spot where there already was an object not belonging to the bot's owner
> (presumably illegal); this time the value returned in the rc parameter was also
> an integer, but a new one (4364876). This is also not a recognizable reason
> code, though admittedly it's not 0.
>
> What happens when your C programs inspect the rc parameter value in a callback?
> Never any problems? This isn't a parameter that is passed by reference, is it?
> What could be causing this strange problem? Usually there's no problem with the
> rc returned by an aw_int function.
>
> On 12/1, XelaG reported a problem with the rc value in callback parameters. At
> that time, I tried it out and had a similar problem. Then, I tried some other rc
> values which are not stated in the documentation to actually be reason codes.
> One of them, the rc value of the aw_query function, behaved in the same strange
> way, as I reported. Since Sample 2 specifically avoided getting the rc on
> aw_query (and the query callback), I was led to believe that undocumented rc
> must also be unreliable rc. But if this is just a problem with the Delphi
> connection to certain sdk functions, I'd be grateful to hear that this is not a
> problem in the C or C++ programs that are getting rc during callbacks or during
> aw_query.
>
[View Quote]

Jan 21, 2000, 5:08am

I have added a BackUpBot to the Bots available for download at
http://www.canopus.org/construction/construction.html. The BackUpBot can
be used to record all of your buildings in a World. The Bot saves its
building data into a file of the same type used by the CensusBot & the
LostFoundBot (a *.css file), & it can be viewed in the CensusViewer. The
file content can be edited & turned into a Survey, Blueprint, or
Demolition file, so that the BackUp could be used when restoring,
copying, destroying, or moving any of your building sites. If you want
to know more, the BackUpBot helpfile is also on the website.

Dec 31, 1998, 2:53pm

Thanks, Walter. That significantly narrows down the problem: we ordinarily have
no trouble using the cdecl calling-convention when we are calling an aw function
with parameters, but we do have trouble when aw calls one of our functions with
parameters (i.e. callbacks). The return value from an aw function does not cause
trouble (except possibly when a callback is installed). I wonder what
calling-convention the aw side is using, and how we should deal with it (in the
callback case).


[View Quote] > Canopus schrieb in Nachricht <368AFF51.D43EAC47 at ix.netcom.com>...
> callback?
> it?
> the
>
> This is what i do in my C++ bot Daniel. I have it build, and i have a
> callback which reads out the error loud (using aw_say()). So any value not
> equal to 0 gets detected immediately, and so far all rc values passed to my
> callback_object(int rc); have been correct, accurate and documented.
>
> I rather think that the integer you read in your code is not the return code
> at all, but some other memory spot instead. You supply a delphi function to
> a dll, which calls it as if it where a c function, right ? Yes, you use c
> calling convention, but there is obviously still a difference.
>
> I guess it would help if the rc code was additionally available as
> aw_int(AW_RETURN_CODE) ?
>
> At
> other rc
> codes.
> strange
> rc
> not a
> during
>
> aw_query has never reported any error for me. Actually i wouldn't really
> know how. My Query Callback function has never got an error code in rc.
> Query is allowed for anybody everywhere so that wouldn't work, right ?
>
> Walter

Dec 31, 1998, 6:32pm

Good suggestion, Roland; the thought had crossed my mind. Unfortunately, unless
my programming was at fault, the dereferenced rc value was not a reason code (if
I loved working with pointers, I wouldn't be programming in Delphi!). XelaG
reports that he also tried out dereferencing the rc value, but no luck. So it
must be in the calling conventions somewhere?

[View Quote] > The values 4364880 and 4364876 look very suspiciously like typical Windows
> memory address pointers. I think this problem must be a simple one of
> simply passing an address back at one point instead of a value.
>
> Just for kicks, have you tried dereferencing the value that comes back in rc
> as an int pointer?
> In other words, what is the value of *(int *)rc? The luckiest possible
> situation is that you are simply receiving the address of the rc parameter
> instead of the value.
>
> -Roland
>
[View Quote]

Dec 31, 1998, 11:50pm

Thanks, Netropolis! I just tested it on ObjectResult, and for a legal
build, rc=0, while for an illegal build, rc=300. I consulted a lot of C
and Pascal books today, and nobody mentioned this solution! I will
incorporate it in the Delphi AWAPI for Build 12.

[View Quote] > Declare ur callback procedure as:
>
> procedure CitizenByName(retcode: Integer); cdecl;
>
> I just tested it, it returns the correct citizen number and rc.
>
> HTH,
>
> -Netro
>
[View Quote]

Jan 1, 1999, 1:02am

This is a multi-part message in MIME format.
--------------5466877A935C7CA5AFB2C6ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is the Build 12 version of the AWAPI written in Object Pascal
for Delphi. Besides the recent update to the API, this version corrects
a problem with the calling convention for callback procedures. If you
are coming to the SDK for the first time, you should read the
instructions for using the AWAPI that appeared in the NG thread for
10/1/98. And a Delphi Unit containing the Reason Codes was made
available by XelaG in the NG thread for 12/2/98.

--------------5466877A935C7CA5AFB2C6ED
Content-Type: application/x-zip-compressed; name="Build12AWAPI.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Build12AWAPI.zip"

UEsDBBQAAAAIANySnyXmmRt3hAwAAKZCAAALAAAAYWtBV0FQSS5wYXPFGmtv48bxuwH/h4W/
nGy4bhMgX2IEKCXRMnMSqZDUyXbRCpS0tpmjRIek7XMO+e+dXb72LUq+axXgQs7svGdnZ4f+
Gn225tbUuZhG+V/HR8dHz9u4QBXwkgC+ng1x8vQYo563/B2vCgQrV1FyitZ4lURZVMTpNkfR
do3izVOaFSiJl1mUvR0fofs0Q8UjRtaqiF8wmqdZss4RMD6jouJtgbP7aIWp3BznQILm8Xad
vubnaILzPHrA8BS85bMiTuBpkEQ5rKN6rUBsgaz5YmLdLKww9J3+LLQXY9sdhdfoF/TjTz9d
Mqv6M2c8BPAPP1Lq46Pe2d++5Y/obvhFqID/MhSjJXqGJ4zA2t1c9/idnRKrircnTMxtHAIm
94huABt7I8dduNbEPucgUysI5p4/5KHe3LV9YaHvfHLG9sjWkLR4dzbp66kVKgDOGtzyQGs6
HTsDK3Q8l0fYE8sZn6Pe2TYtECTOGi3faKIFw4/EDXTpzHU+2X5gL/q+Nw9sfzFxXGcym5zr
8L49tq3A1uL7dmhJSHDCeKhlXWKD0PJDCefbIycIfWoevPw2c3x7KAsnaSu4U81icG35I1l7
33btuTUW0AMndO5sV2DcQJn41DAx4jW8jIUADJ0J2YlXocRFm0H1CmcycUaVSYSNJO9m6hjQ
bJBq2NgKwjJzpNUeIJyJ0+hZBoy1v4SETjgWQH1r8HHoe1MeOvK9mTvkYV7/V3sQgsXhtRLh
21e+HQi4MvC+M7oWlLMh2Ww3XAw98LyrXOGGJJ1lRDC1Bw7kQik3UC2prVowyShgRr5tuxpc
fzwT3DSwfAjJR1BoYE2tvjN2wlt+BdgOtWoQ2vBoDZ1ZwKOnsz5UAaK7kYuwTGHawLfbvIE9
ORFCd+1NSFqOxDgrdqAQVz6TS+TQCaz+2C6l2ouZPxasBl3cEQ+b2+MBUQLUCyQ97DJXFOGm
CJ1fBvZ4rMrx0iwdlTUee3NqWXjtz1S4q/GtpH+JCaGOTj1fkGd9sqAMBgtI2WAANUlFWTk0
AAYDUV1Pna803lozSixHNrld3DDPt8zzHQu35sxbeDu1mdcRpM/MbyClaaB2EDBHVQVla0kF
uhHeb4X3OxHf6lJBWH0qkKATlPtQ1IjChNyi6XHDvd1xbwGcTLY74AkCqJ41oAoav0Eq4I3w
fiu834n41tIKMvGG9liADe1g4DtTti+oMNZAAfSk7csgRA0JTNSK64SaHOVcW0HLTSXVF/Cg
f7uArT0d2yEfIjaSUL9sNxDaowomNVwVfAadSSACfcsdSRy4g7oGgk4TOC4kMFsqJUbqE7hG
09OWa3noXhxDpyIfrBQKi0Oh6lM4Z5utcnsJHM58rkmkUKKeNRzC4RJI8NaCGgXVeuC5bnka
W0GLuIJuhVObAnw4R6cO4zgKDWx32CYKA5IZCHZQmKAthVV1lIB6ZygqiixePhc4R0ucpK8o
yjBS9MCovAuUWea5oSXtzxrKu75Zy/Z/FYyGRQROvLbikLIPjdtkEXoS6Mr3JvI6+yaUgAHj
1AbIivnVE+4wFFA1dByM05hCbri3W+7tjse1hahssknnMeDkcnDOuSxmAp66ViFubUsmEFKg
Xc+cbA2QxE7W5s6ZSrDpteeKd7IG2Z8F0FAGgdq4T5DAnkwEWs7G7ZnK3sCPj04v2Zuo/Yl0
q6r7aIUpzy8w/VwFhyrJFDMOBScDU05LFD2e+jbT6zPwskorELYrCCe1mYfUJ4yoZnMmybo0
d7DG+IBfUPU+RqzjXnkqeFuxeCypOLR2CAYxG15A1duMh5JtwMaXQiG2iAvuABo30vwzUa1B
wo2rhtLLiQRtbkJsWrWcqqNF9pS0RMOhvvAZONRLNBzoGS5By1iQ00pCSYFoMKxrG2B9wFM6
CVvfimVm9ZZkY1Uj5XDVLUfABoy2ipbTSiWAvu9Zw4HFGEag82sHempfZsymF8e8QnhXV2On
7fobsKuCunAtt+qASLKq1l6URMHleQY776MLXdu5AlXeE5UYMoOi9YuT9+iQCeIvaJrSeeUl
oYTftMX8p3qsUdbcfsHbYpqlK8A+wf/w+jnDl2hFRqbtqkGUJMto9Vlc2MtW6GfkgLQHnJ22
ZJVKAV4VaRbgP3IgsrIsevvXPy4ufjxH5N9/o/S+Jr383485yW+DMCrQI0rR+jsNOe+ftysy
dgZh0esiJhPr3vI5TtaM25qn1n+NgykZxHKDWiTPc5XhqMCoV46P1+kmirfAfDp4jIAhHXMz
AmJYFG1XGP0M7qkT4xRJKqCvpEG7T0EwRIk8N5RPURZtUJyjk38u0+KHE5RmwOtkGycnf6mV
W2Q4T5MXaPx60XoNLzkIHETZOt5GyeE6isLWOC+y9A3tXtlIgKX1jtixdJFjCF2rGuriO9Bf
7z3qPMljSfoA8dttwmtEUmkTJ0mcY4j9OmcyqosHgDqiZrQnTTe60hMi7SV6iZJnvJcSEK54
+6DWo8pfE6FGkXIj1NpQPqwuEBM102WaJgf5hBC+xynoK/2EhV7SeE0uT2TfVPUW9ZgDFK1O
T4WC+xehdtMC/0yzDH95IruLaHbCcDn5+wnD5oRkH72GFa8xZOQjzvCFlIefGw1WpVE1+Sl9
ZQ8E1hJh+1erSu9wplyW5vbO6jWniLftlG5/pipc4AtqZCPiiR5za7hrkgtl47LNM4T/MXrB
qClhJzWSngnqQ+sEiRWPEJV1ria/38ob9jNno+Csy1Yt0WulfV2SAZMjmrpPvKBEkBBkIU0E
Xq2KqMpIgbCMYXP06wNIuTTRk8Q3QXyMtuuEpHepzr6xq8gVoaMBO6nwXUJVLSUHqBwrxhy1
Yy4bVTgHaWIlMCc9V30Ov5IPyG0Zi16iIsr2K9H4C1T4DkU0equFRq+b8ku0qu7pzpHHOH8i
eudl4VjETGty2YGvtp7CgQdH/woc+oA72LGKi/hPvF20k6PF8m2xjTZNb0Ofu1umYfi8WdIw
lVh1RLQ2NTzX6z1M2tsHa5xg2tOZlNzBY4u/dEmfejkcHC9x+px3IEng1NjmuKMTmtXtRPCw
eNaMOnuzJmi8+R6pHd1ZL1e6U7cFSa0AyryLgJT+ZUtH31eLO3usWl85bPf6P55xBtXnC5RU
ctFjCf5UwHIMBHVj394NO0Qhg6qcbrq0xdSXzJbvbPvzNn7BGZeo3Ymr4tlZQUz/PGkPpSgB
Kc/dAl/6fnGfpZvFCsPZ2KP/musIuYGjDS4e07U4tV89Zxmcb8kbOcniJFom5EojDPGFwpJu
i6jK1MMKWcXgXcWw4kE3V696yzm6hmtE5hPMTOK0w5m/hmNd1fYnePtQPJIyw+hqvNIQTt0v
NIyEVsBudQtw5QPcP0HQtksa/Q5d2mGOJ5Rw7X9K3hT0l4hiFlwfzqC1x+9TlOewgdZd9Y83
mxjs7VTLMvwASQKtQZfdtV0v7uOkW2Wo1tbeMJvObMbjo3jzlOAN7Dv6l4slTDCw20AJLoZg
2TZK0Afr9WKdJB/oMQh+/lAx+XBpHDppGCBKT1Z+kLfe95lLmRQpRepU+U5TKJ1GH2TBsmb6
kZWJbUUlszPMtXalQEmoZ7nP/KsWRZhLyrMMZXG68ZfJHZRGZrXnhMysNWGmck63KVqrvej9
0iNq1u+aKRn8VbGWZXaex5l9VbLRsddZ1XVsZ7KslSBL7zzeM+8UwkbN/HuFq+YtSz1gRmeO
XD2s0ov6JlMuY8lkBMlqHDLVMptMOWoEfatJkcneRpBCh+17B0pGwYS7Qqh66mTk9EVVG3Vz
qZX63r2jpESK0848ukIdZHcqKpUYVT0zDrjMdYQlVnQs7x+GGTeZln1nVfYaox2gC+Vv0EZ5
DTa7nKHVMz4wnDy5nv0+l9kdtZrjqJeoGVx1M4cQ61kbZobd2NcMFH2gccZo5s7QGhjvP440
9qASW73oA1OMJ9ez32vcac4xnqVe5EE5xhLrWR+cYyIDxflhmruambekMlvjhNbMtiXVsj0w
eThqLXPt4LcTc12WfLcpsWlDUqGyLtpBsolXSaRLoC7zYvM20/CRBe41ozbL1LNSNDra6bbJ
axWVzm26EXiXjUdpDe7ZMS03i1ByUTll7xH7jh5XYEhE/p9H8js6kJadokc4YHrfTZy24fnG
s35j08rIkjV5z1cBk1TCVy1tj6FKq0Zr8p61tZYo67LrA4N553HUMvPuXyPMiUT4qLm//4uF
yW2tBFn6ri8bZsdx1DJz02cQM+OGUnGS6r+XmHnWhKqSqv+uYubZUBqY7vkBxny0cTzLSg2w
i+Oj/wJQSwECMgsUAAAACADckp8l5pkbd4QMAACmQgAACwAAAAAAAAABACAAtoEAAAAAYWtB
V0FQSS5wYXNQSwUGAAAAAAEAAQA5AAAArQwAAAAA
--------------5466877A935C7CA5AFB2C6ED--

Jan 4, 1999, 7:06pm

The documents state that an object is uniquely identified by its Object
Number, Object X, and Object Z attributes. But during an
EVENT_OBJECT_DELETE, the only available attributes are Object Session,
Object Number, Cell X, Cell Z, and Cell Sequence. Will Object Number,
Cell X, and Cell Z also be sufficient to uniquely identify an object?

Jan 6, 1999, 4:27pm

In the context of OBJECT_RESULT you can get the same attributes you would
in an OBJECT_ADD or OBJECT_DELETE event. There is no need to specify the
OWNER when building, unless you have eminent domain rights, because the
OWNER will always be the bot's owner anyway. (See the thread on Changing
the Owner. What is important in object_change is the unique combination of

OLD_NUMBER, OLD_X, and OLD_Z, the object's current NUMBER, X, and Z. See
the above thread on Object Delete Event.) OBJECT_SESSION is redundant when

the bot is building, since the builder bot's session is the session doing
the building; but during an OBJECT_ADD or OBJECT_DELETE event, it tells
you which avatar-session has done the building event. (If you handle
OBJECT_ADD and OBJECT_DELETE events, you will see your bot's building
events as well as everyone else's in the Zone.)

A bot can build anywhere in the world it has entered. A visible bot can
have an avatar in one Zone and build in another Zone far away in the same
world. (See the thread under Build 12 Available.) But it can only be
uptodate (Query supplemented with OBJECT_ADD and OBJECT_DELETE live
updates) in one Zone. My experience corresponds to Walter's conclusion,
that multiple bots can build in separate Zones and can be uptodate in
separate Zones. A builder bot can begin building at an arbitrary location
in its world without Querying to see what was already there: then
OBJECT_NUMBER is its only evidence whether the building activity
succeeded.


[View Quote] > I have a few questions about building objects.
>
> 1. I've installed AW_CALLBACK_OBJECT_RESULT, the callback for the
> methods aw_object_add, aw_object_change and aw_object_delete, but I'm
> not sure which attributes apply. The documentation mentions somewhere
> only aw_int(AW_OBJECT_NUMBER).
>
> 2. In aw_object_change, aw_int_set(AW_OBJECT_OWNER, Owner) should be
> specified acording to the docs, but that's not the case in the other 2
> methods. Is that correct?
>
> 3. Does one have to call aw_instance_set(Instance) before setting
> attributes in these 3 methods?
>
> 4. What is the function of AW_OBJECT_SESSION? Is this attribute also
> used here, or in the callback?
>
> 5. I assume that aw_instance applies everywhere in querying and
> building events and callbacks: am I correct?
>
> XelaG.

Jan 6, 1999, 6:49pm

A visible bot can also query a zone that is far away from the zone its avatar
is in. Try doing Sample 2 with a visible bot avatar located far from its
midispk. In effect, the API has two independent systems, one for avatars/chat,
and one for property.

[View Quote] > In the context of OBJECT_RESULT you can get the same attributes you would
> in an OBJECT_ADD or OBJECT_DELETE event. There is no need to specify the
> OWNER when building, unless you have eminent domain rights, because the
> OWNER will always be the bot's owner anyway. (See the thread on Changing
> the Owner. What is important in object_change is the unique combination of
>
> OLD_NUMBER, OLD_X, and OLD_Z, the object's current NUMBER, X, and Z. See
> the above thread on Object Delete Event.) OBJECT_SESSION is redundant when
>
> the bot is building, since the builder bot's session is the session doing
> the building; but during an OBJECT_ADD or OBJECT_DELETE event, it tells
> you which avatar-session has done the building event. (If you handle
> OBJECT_ADD and OBJECT_DELETE events, you will see your bot's building
> events as well as everyone else's in the Zone.)
>
> A bot can build anywhere in the world it has entered. A visible bot can
> have an avatar in one Zone and build in another Zone far away in the same
> world. (See the thread under Build 12 Available.) But it can only be
> uptodate (Query supplemented with OBJECT_ADD and OBJECT_DELETE live
> updates) in one Zone. My experience corresponds to Walter's conclusion,
> that multiple bots can build in separate Zones and can be uptodate in
> separate Zones. A builder bot can begin building at an arbitrary location
> in its world without Querying to see what was already there: then
> OBJECT_NUMBER is its only evidence whether the building activity
> succeeded.
>
[View Quote]

Jan 7, 1999, 4:17am

Then was I just lucky when I added an object and had the OBJECT_RESULT callback
handler get me MODEL, X, Y, Z, YAW, ACTION, & DESCRIPTION, as well as NUMBER?
(It got seemingly correct values.) Since there is only this one callback for
adding, changing (=deleting, then adding), and deleting, and NUMBER is the only
one that is defined in the context of the callback, is that because it's the
only attribute that is true after both adding and deleting? (And if you want to
get more information after an aw_object_add or aw_object_change, you shouldn't
use an OBJECT_RESULT callback, because it has to work even after an
aw_object_delete)?

[View Quote] > Since some of the other responses to this question might be a little
> confusing, I'll try to give my own answers as concisely as possible.
>
>
> That is the only attribute that is defined during AW_CALLBACK_OBJECT_RESULT.
> If you have multiple building requests outstanding, you use the object
> number to match up the result with the request that you issued.
>
>
> That is correct. In aw_object_add, the owner is always the owner of the bot
> who is building, and aw_object_delete does not care who owns the object,
> only whether or not your bot is allowed to delete it, which the server can
> determine for itself. :)
>
> I think someone said that you only need to set AW_OBJECT_OWNER if you want
> to change owner. This isn't quite correct - the new owner number is always
> sent to the server as part of the aw_object_change, so you must always set
> this attribute, even if the owner is you. Otherwise you might wind up
> sending a garbage value to the server for the new owner number.
>
>
> As with any other method, this depends on what you have done since the last
> time you called aw_instance_set(). If you have called aw_wait() or any
> synchronous API methods and this is a multi-instance application, then yes
> you must call aw_instance_set() first.
>
>
> AW_OBJECT_SESSION indicates which avatar around you is doing the building
> during a live add or a live delete. It is only used during those two
> events. It corresponds to the AW_AVATAR_SESSION attribute given in
> AVATAR_ADD events. Its primary purpose is to distinguish live building
> events that you caused from live building events caused by other people
> (although there are other interesting potential uses for it.) In other
> worlds, if aw_int (AW_OBJECT_SESSION) equals aw_session(), then this
> building event was triggered by your bot.
>
> Note that it is possible that this session number will not correspond to any
> avatar that you have received an AVATAR_ADD for. For example, if the
> building were being done by another bot that has not announced its location
> by calling aw_state_change().
>
>
> Yes,
>
> -Roland

Jan 7, 1999, 3:55pm

It's hard to see how to match up multiple building requests using only object
number. Suppose you have done two object_adds, two object_changes, and one
object_delete. The object_adds don't already have an object number, and the
object_changes have an old object number, but the server will give them a new
object number after the change is successful. (For object_delete, the old object
number could be returned and recognized.) When using OBJECT_RESULT, should you
use aw_int_set (AW_OBJECT_NUMBER, aw_random) to suggest an object number to the
server? (is it an offer the server cannot refuse)?

[View Quote] > Since some of the other responses to this question might be a little
> confusing, I'll try to give my own answers as concisely as possible.
>
>
> That is the only attribute that is defined during AW_CALLBACK_OBJECT_RESULT.
> If you have multiple building requests outstanding, you use the object
> number to match up the result with the request that you issued.
>
>
> That is correct. In aw_object_add, the owner is always the owner of the bot
> who is building, and aw_object_delete does not care who owns the object,
> only whether or not your bot is allowed to delete it, which the server can
> determine for itself. :)
>
> I think someone said that you only need to set AW_OBJECT_OWNER if you want
> to change owner. This isn't quite correct - the new owner number is always
> sent to the server as part of the aw_object_change, so you must always set
> this attribute, even if the owner is you. Otherwise you might wind up
> sending a garbage value to the server for the new owner number.
>
>
> As with any other method, this depends on what you have done since the last
> time you called aw_instance_set(). If you have called aw_wait() or any
> synchronous API methods and this is a multi-instance application, then yes
> you must call aw_instance_set() first.
>
>
> AW_OBJECT_SESSION indicates which avatar around you is doing the building
> during a live add or a live delete. It is only used during those two
> events. It corresponds to the AW_AVATAR_SESSION attribute given in
> AVATAR_ADD events. Its primary purpose is to distinguish live building
> events that you caused from live building events caused by other people
> (although there are other interesting potential uses for it.) In other
> worlds, if aw_int (AW_OBJECT_SESSION) equals aw_session(), then this
> building event was triggered by your bot.
>
> Note that it is possible that this session number will not correspond to any
> avatar that you have received an AVATAR_ADD for. For example, if the
> building were being done by another bot that has not announced its location
> by calling aw_state_change().
>
>
> Yes,
>
> -Roland

Jan 7, 1999, 4:02pm

aw_object_add (like aw_object_change and aw_object_delete) returns an integer,
which may be a reason code, in which case you might be able to eliminate some
errors. And maybe the server issues its object numbers in exactly the same order
as you issued your building requests, in which case you'd want to keep a queue
of outstanding build requests. All in all, using callbacks seems to be more
expensive than using synchronous calls.

[View Quote] > What if I have 10 outstanding add object building requests, of which 5 fail.
> Since the object number is created on the server, and applied only on
> success, what chance do i have to match
> my building requests with the error replies ? lets say i get 5 different
> failure reasons, which object caused which failure ?
>
> Walter
>
> Roland Vilett schrieb in Nachricht <369436b2.0 at homer>...
> AW_CALLBACK_OBJECT_RESULT.

Jan 8, 1999, 12:37am

Since aw_object_add and aw_object_change can order most object attributes and
immediately gather OBJECT_NUMBER afterwards, I take it that the result from the
aw_object_add and aw_object_change is a valid indicator of success/failure in
the synchronous case, but in the asynchronous, callback case, you must wait for
OBJECT_RESULT to deliver the verdict (in the rc parameter value)?

[View Quote] > No this isn't correct, sorry for the confusion on this topic. You can
> always use AW_OBJECT_NUMBER to uniquely identify which build request is
> which. See my other post in this thread.
>
> Also, within a single world the AW_CALLBACK_OBJECT_RESULT callbacks always
> occur in the same order that that the building requests were issued.
>
> -Roland
>
[View Quote]

Jan 25, 1999, 10:24pm

Suppose you call aw_object_change in the asynchronous case: the SDK has created
and stored a new number in the attribute AW_OBJECT_NUMBER, and you can save this
new object number to identify which object you are hearing about during
AW_OBJECT_RESULT. If the value of the rc parameter in AW_OBJECT_RESULT indicates
a failure (due to encroachment, area full, trying to change owner, etc.), will
the object that failed to change still retain this new object number, and when
we try to change this object or delete it later on, can we use this new object
number as the object's AW_OBJECT_OLD_NUMBER? (Or does the object revert to its
old number, from before the build operation failed)?

[View Quote] > Did I forget to document this as well? Damn.
>
> The object number is not created on the server, it is created by the SDK for
> you and stored in the attribute AW_OBJECT_NUMBER. Immediately after calling
> aw_object_add() or aw_object_change() (even in the asynchronous case)
> AW_OBJECT_NUMBER holds the newly assigned object number. You can remember
> its value at that point to match up the later results with the requests.
>
> -Roland
>
[View Quote]

Jan 27, 1999, 8:57pm

Don't know if it's relevant or not, but in linking Borland Delphi (Object
Pascal) to the aw.dll, there was a choice of five calling conventions (register,
pascal, cdecl, stdcall, and safecall). At first, stdcall was used, but it didn't
work; then cdecl (the regular c calling convention) was used, and it has
continued to work fine.

[View Quote] > I am surprised that Borland handles dll exported function names this way,
> because usually the leading
> underscore in dll exportet names (and in linker-level non-c++ function names
> as well) is the calling convention.
>
> Functions that use regular c calling convention have a leading underscore,
> functions that use PASCAL calling convention have no leading underscore...
> therefore a function prototype having the wrong calling convention declared
> would lead to a linker unresolved external error instead of a program crash.
>
> DLL exported function have by convention a PASCAL calling convention and
> therefore no leading underscore. under rare conditions, such as variable arg
> functions (wsprintf(const char *, ...) is such a function) must have c
> calling convention, and are exportet using a leading underscore.
>
> just FYI
>
> Walter aka Faber
>
> ps: calling conventions define the order of arguments on the stack
> and the side (caller/callee) reponsible for cleaning up the stack
> after argument usage / removal
>
> Tony McGrath schrieb in Nachricht <36af3b8c.0 at homer>...
> means

Feb 5, 2000, 3:43pm

The magsbot is the answer to all those people who ask, "where can I get a
cheap, full-featured compiler so I can write my own bot programs?" Better:
the magsbot is free! Yet it provides the support that we expect from major
programming languages, such as built-in lists, file access, timers, DLL
connectivity, even user-programmable buttons. Plus the magsbot makes the
major bot functions (chat, avatar-awareness, surveying, building) available
in the same scriptlike programming language. The latest version makes it
easier for non-programmers to begin programming by studying explicit
bot-programming examples. So users can invent all sorts of new bots--if they
have the imagination to think of any--just by programming a magsbot.


[View Quote] > Hi,
>
> Welllll, I must say I'm a little disappointed in the lack of reaction to
> Magsbot. I've only gotten feedback from a few people. I'd really
> appreciate any comments, either positive or negative, about it.
>
> What do you want in a bot? It can probably be done with Magsbot, and
> I'll try to write the scripts (buttons or behavior table) for it, if so.
> Or add it to the basic bot, if not. :)
>
> -Magine
>
> Get Magsbot at http://www.pipeline.com/~magine
>
> * Now includes example user-defined buttons for Follow avatar, Record
> and Playback avatar movements, Bookmarks, Log objects by click and and
> Rebuild from log, Recite text file thru chat; and behavior table with
> daily greeting and visitor log, respond to questions, play midis, ask
> trivia questions, much more. Magsbot has it's own extensive "Bot Basic"
> control language, and you can change behavior while the program is
> running without having to reload a script.

Feb 5, 2000, 4:27pm

The AW Newsletter promises a lot of good new things will be happening
when AW 3.0 appears. Nothing specific is mentioned, but in the area of
Bots, there could be a number of additions to the Bot SDK. There will
always be unexpected uses of the old Bot SDK, but some of the expected
bots (mentioned in the SDK documentation itself) have never appeared.
These are the bots that wander about at random, moving in response to
the scene that they happen to be in. (Bots that follow a prepared path,
or obey explicit chat commands to come here or go there, have
owner-selected moves.) Randomly-wandering bot avatars should be as
realistic as other avatars, & should therefore avoid obstacles, like
trees and walls, or should fall from a tower but stop when they hit a
roof or an automobile.

The principal reason why these bots haven't been accomplished is that
the old AW 2.0 SDK didn't support collision detection. Every world has a
collection of data about its objects; one segment of this data is the
segment containing the object bounding boxes (the yellow lines appearing
around an object when you select it with a right-mouse-click are the
lines of the object's bounding box). There may be secrets hidden away in
the object data, but the object bounding boxes can hardly be considered
to be proprietary information. On AlphaWorld, you can print out the
object bounding boxes from an online file; but on most other worlds, you
can't get at them. (If you were very patient, you could create all the
world's objects one by one & count your keystrokes across all the sides
of all the objects; and then repeat this process for all the other
worlds.)

So the best single addition to the SDK would be access to the bounding
box data for the current world, either all at once (like Querying
property) or on demand (by submitting the model name of the object).
Then we could have realistic bots that wander about the way that citizen
and tourist avatars do now, without someone shouting at them "Bot! Go to
333S 444E 5.4A."

1  2  3  4  5  6  |   Order by default