1  |   Order by index

Jan 6, 1999, 6:31am

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, 11:00am

I can only answer to 2 of your 5 points..

XelaG schrieb in Nachricht <36931a46.2188897 at news.activeworlds.com>...
>I have a few questions about building objects.
>
>3. Does one have to call aw_instance_set(Instance) before setting
>attributes in these 3 methods?
>
>5. I assume that aw_instance applies everywhere in querying and
>building events and callbacks: am I correct?

And those two even have a single answer: Querying and building takes place
in the world you are currently in, since you don't specify a world
separately. therefore it must be bound to a current bot instance and its
current worlds.

for that reason one would come to the conclusion that each bot can build
separately, as if each was controlled by its own program. this observation
probably applies to ALL sdk functions except for aw_init() and aw_exit().

Walter aka Faber

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 6, 1999, 7:18pm

Canopus schrieb in Nachricht <3693CC3C.DDE0C1DC at ix.netcom.com>...
>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.


So its the world those systems share, and thats all :)

Walter

Jan 6, 1999, 9:22pm

On Wed, 06 Jan 1999 12:49:00 -0800, Canopus <aek2 at ix.netcom.com>
[View Quote] >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.

Three in my experience: one for avatars, one for chat, one for
property. The bot perceives chat farther than avatars, says my Delph
at least....

XelaG.

Jan 7, 1999, 12:18am

well, according to daniel, the distance matches those from avatars
exactly :)

Walter

XelaG schrieb in Nachricht <3693ef7d.35009490 at news.activeworlds.com>...
>On Wed, 06 Jan 1999 12:49:00 -0800, Canopus <aek2 at ix.netcom.com>
[View Quote]

Jan 7, 1999, 2:05am

Mine's south american, telepathic.... LOL.

Try it out. I can see his reaction through the program's chatbox and
talk to him thought the program and the awb and, unless he had lost
his lists somewhere, the list dump didn't show me any more, I had been
'goodbyed', he could not perform 'join' or follow commands, but he did
execute a teleport when i told him to do so through the aw brouwser,
and was answering my questions on his screen, questions I was putting
to him through the browser, although I couldnt hear his answer through
it, only through the prog.... Maybe Roland has an explanation...

On Thu, 7 Jan 1999 03:18:24 +0100, "Walter Knupe" <wak at faber.ping.de>
[View Quote] >well, according to daniel, the distance matches those from avatars
>exactly :)

Jan 7, 1999, 2:11am

For that matter, a bot does not need to be "in" the world at all in order to
build, as the #2 sample program shows. A bot can manipulate property behind
the scenes without having an avatar physically in the world.

In other words, yes, avatars and chat are handled separately from property.

-Roland

[View Quote]

Jan 7, 1999, 2:24am

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.

>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).


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.

>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?


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.

>3. Does one have to call aw_instance_set(Instance) before setting
>attributes in these 3 methods?


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.

>4. What is the function of AW_OBJECT_SESSION? Is this attribute also
>used here, or in the callback?


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().

>5. I assume that aw_instance applies everywhere in querying and
>building events and callbacks: am I correct?


Yes,

-Roland

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, 1:58pm

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>...
>
>
>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.
>

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 7, 1999, 5:26pm

Maybe the safest way is to combine building activities and query,
which provides much more information.

XelaG.

On Thu, 07 Jan 1999 09:55:50 -0800, Canopus <aek2 at ix.netcom.com>
[View Quote] >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]

Jan 7, 1999, 10:44pm

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 7, 1999, 10:56pm

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 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 8, 1999, 2:50am

On Thu, 7 Jan 1999 16:44:46 -0800, "Roland Vilett" <roland at lmi.net>
[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

Does this mean that the object number itself is not sent to the server
at all and stored there? If this were so, the life-span of the object
number would be determined by the the programme session, and the
object number would be of no use as an ID number accross sessions.
Could you clarify this as well, Roland? Thanks.

XelaG.

Jan 8, 1999, 10:52am

I think I can answer this one myself: in AW_EVENT_CELL_OBJECT the
AW_OBJECT_NUMBER is received from the server (hopefully its not
re-invented by the sdk !), therefore....

XelaG.


On Fri, 08 Jan 1999 04:50:12 GMT, decastro at cable.a2000.nl (XelaG)
[View Quote] >On Thu, 7 Jan 1999 16:44:46 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote]

Jan 8, 1999, 7:15pm

Yes, that is correct. In the synchronous case, the return code of
add/change/delete indicates whether or not the the building operation
succeeded. Obviously, from a code complexity standpoint these operations
are far easier to deal with in synchronous mode. However, if you want to do
large numbers of building operations quickly, synchronous mode will
generally be too slow, hence the need for asynchronous mode.

In asynchronous mode, the return value will almost always be RC_SUCCESS,
unless there is some fundamental problem with the current state of the
session that is preventing the transmission of build requests to the server
(e.g. a network communication failure.)

In either case (synchronous or asynchronous) AW_OBJECT_NUMBER will be valid
immediately after the call returns.

-Roland

[View Quote]

Jan 8, 1999, 7:38pm

That's right :) The reason the SDK assigns the number is precisely so that
you can correlate the server response with the request (in asynchronous
mode). If the server assigned the number, then we would still have to
create some other kind of transaction number or something to match up
requests and replies. This way it kills two birds with one stone. :)

When developing the SDK I toyed with the idea of requiring the programmer to
assign the new object number manually before calling aw_object_add (e.g. by
calling aw_int_set (AW_OBJECT_NUMBER, aw_random()) but that seemed like it
would just create extra work and extra room for mistakes...

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

1  |   Order by index