1  |   Order by index

Dec 29, 1998, 9:13pm

Hi,

Build 12 of the SDK is now available. Please upgrade at your earliest
convenience. You may download it from the usual place:

http://objects.activeworlds.com/downloads/sdk.zip

Build 12 introduces 3 new universe attributes in aw.h:
AW_UNIVERSE_BUILD_NUMBER, AW_UNIVERSE_REGISTRATION_CHARGE, and
AW_UNIVERSE_RENEWAL_CHARGE. These attributes are for use by the 2.1 browser
(they aren't of much use for an SDK application.)

A problem has been fixed that occurred when the calls
aw_citizen_attributes_by_name() and aw_citizen_attributes_by_number() failed
if the citizen name or number didn't exist: the queried name or number was
not being sent back to the SDK in the failure case so it wasn't possible to
correlate the query with the response in the AW_CALLBACK_CITIZEN_ATTRIBUTES
if there were multiple calls outstanding. Now the name or number is being
correctly sent back even if they don't exist.

-Roland

Dec 30, 1998, 1:09am

On Tue, 29 Dec 1998 15:13:17 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >Hi,
>
>Build 12 of the SDK is now available. Please upgrade at your earliest
>convenience. You may download it from the usual place:
>
>http://objects.activeworlds.com/downloads/sdk.zip
>
>Build 12 introduces 3 new universe attributes in aw.h:
>AW_UNIVERSE_BUILD_NUMBER, AW_UNIVERSE_REGISTRATION_CHARGE, and
>AW_UNIVERSE_RENEWAL_CHARGE. These attributes are for use by the 2.1 browser
>(they aren't of much use for an SDK application.)
>
>A problem has been fixed that occurred when the calls
>aw_citizen_attributes_by_name() and aw_citizen_attributes_by_number() failed
>if the citizen name or number didn't exist: the queried name or number was
>not being sent back to the SDK in the failure case so it wasn't possible to
>correlate the query with the response in the AW_CALLBACK_CITIZEN_ATTRIBUTES
>if there were multiple calls outstanding. Now the name or number is being
>correctly sent back even if they don't exist.
>
>-Roland
>
Hehe, Roland, this invalidates my workaround for Delphi problems with
the rc parameter of the callback :-(

Am I correct in my observation for build 12?

if you send an invalid citizen name, you get back the same invalid
name (new situation, allows identification) and a citizen number = 0
(new situation, COF won't like it :-).

if you send an invalid citizen number, you get the same invalid
citizen number (new situation, allows identification) but the name
remains unchanged from the previous call (old situation).

If the name were set to say, "", I could then identify it as an error
message, bypassing the rc problem.

Thanks for your efforts, sorry if I sometimes sound irritated and
unreasonable, I'm working nights on these bots, they're great.

XelaG.

Dec 30, 1998, 7:12pm

>Am I correct in my observation for build 12?
>
>if you send an invalid citizen name, you get back the same invalid
>name (new situation, allows identification) and a citizen number = 0
>(new situation, COF won't like it :-).


Yes, this is correct. Not sure why you would say that COF won't like it, I
deliberately implemented it this way :)

>if you send an invalid citizen number, you get the same invalid
>citizen number (new situation, allows identification) but the name
>remains unchanged from the previous call (old situation).


Yes, also correct.

>If the name were set to say, "", I could then identify it as an error
>message, bypassing the rc problem.


Well...technically, the value of AW_CITIZEN_NAME is undefined in the
lookup_by_number failure case. In practice, yes, it is simply unmodified
from its previous call, but I would hesitate to suggest writing code that
depends on this behavior. Instead I would try to focus on why the rc
problem exists - I assume this is a problem with callbacks in your
particular implementation of an interface to the SDK, not with the SDK
itself, correct?

-Roland

Dec 31, 1998, 12:56am

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>...
>Well...technically, the value of AW_CITIZEN_NAME is undefined in the
>lookup_by_number failure case. In practice, yes, it is simply unmodified
>from its previous call, but I would hesitate to suggest writing code that
>depends on this behavior. Instead I would try to focus on why the rc
>problem exists - I assume this is a problem with callbacks in your
>particular implementation of an interface to the SDK, not with the SDK
>itself, correct?
>
>-Roland

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:16am

On Wed, 30 Dec 1998 13:12:18 -0800, "Roland Vilett" <roland at lmi.net>
[View Quote] >
>Well...technically, the value of AW_CITIZEN_NAME is undefined in the
>lookup_by_number failure case. In practice, yes, it is simply unmodified
>from its previous call, but I would hesitate to suggest writing code that
>depends on this behavior. Instead I would try to focus on why the rc
>problem exists - I assume this is a problem with callbacks in your
>particular implementation of an interface to the SDK, not with the SDK
>itself, correct?

Roland: this is what I still don't know. I haven't tried other
callbacks yet, and am gratefully basing my implementation of the code
on Canopus' SDK Delphi work. His posting in this thread and my talks
to Walter lead me to tentatively conclude that we are dealing here
with an as yet unresolved Delphi problem, not an SDK one. But, I still
haven't heard from a C or C++ programmer whether they have the same
problem with rc in the citizen attributes callback.

Until we resolve this problem, I am forced to bypass rc in callbacks
and use rather awkward methods.

XelaG.

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]

Dec 31, 1998, 11:54am

Canopus schrieb in Nachricht <368AFF51.D43EAC47 at ix.netcom.com>...
>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.

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

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

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, 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, 4:08pm

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

Just for kicks, have you actually been working on the next AW build and will you actually release anytime this century?

[View Quote] > Just for kicks, have you tried dereferencing the value that comes back in rc
> as an int pointer?

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

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]

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:40am

Netropolis, this made my year. Oid mortales !

XelaG.

On Thu, 31 Dec 1998 17:42:52 -0300, Netropolis
[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]

1  |   Order by index