1  2  3  4  5  6  |   Order by default

Oct 16, 1998, 12:03am

Sounds like you need to get a lawyer and get your stuff back from the FBI.
If you really didn't do anything and they came and took all of your computer
equipment you should have an easy case.

-Roland

[View Quote]

Oct 16, 1998, 5:10pm

Yeah changing object ownership is a bit of a mess. Because of the way an
object change is handled in the world server, if there is a registry in
effect in that world, the object winds up encroaching with itself and the
change is rejected. So it cannot be done in worlds with a registry. If
there is no registry however, you should be able to change the owner of the
object, but only if the the bot instance has Eminent Domain in the world.

It's theoretically possible to fix the registry problem but the solution
would complicate the object_change operation significantly so it hasn't been
addressed yet...

AW_OBJECT_OWNER is not used by aw_object_add(). Sorry if the docs are not
clear on this (I'm still working on updating and extending them.) All
objects are automatically added under the ownership of the citizen doing the
adding.

In short, most of the time it is simply not possible to build as another
person unless you know their privilege password. And I think that most of
the time, this is arguably a good thing :)

-Roland

[View Quote]

Oct 17, 1998, 4:03am

Yes two different bots running in the same application can have completely
different owners. It's all in the attributes you set before calling
aw_login() for each instance.

-Roland

[View Quote]

Oct 19, 1998, 4:17pm

The bot limit is applied universe-wide, per citizen number. It's not
applied per-instance, per-application, or per-world.

In other words, the limit is on the total number of bots owned by a
particular citizen running anywhere in the universe. Thus if you have
access to multiple citizenships you can, for example, write a single
application that runs lots and lots of bots, under a variety of accounts.

The bot limit for individual citizenships can be raised by the universe
administrator (i.e. COF).
I don't think it's been decided yet whether or not and under which
circumstances requests for bot limit increases will be fulfilled. This part
isn't my decision. If you have requests, or just strong feelings on the
matter, please direct them to cof at activeworlds.com.

-Roland

[View Quote]

Oct 19, 1998, 2:19am

That's correct. 2.1 worlds know what an SDK application is, so they know
not to count them against the user limit. 2.0 servers don't know about the
distinction between users and bots, so they count bots as users.

If you're running Hambot without the SDK option, then it appears to the
server as either a normal tourist or a normal citizen, so hambot bots get
counted as users, even in 2.1 worlds. At some point it will no longer be
possible to run Hambot in non-SDK mode, so this issue is only temporary.

-Roland


[View Quote]

Oct 19, 1998, 4:33am

Actually no. Most of the worlds run by COF are still running 2.0 worlds.
We are currently testing the 2.1 server with a about a dozen worlds, but the
vast majority are still 2.0.

Also SDK bots will work in 2.0 worlds. The SDK has code that detects
whether a world is a 2.0 or 2.1 server, and changes protocols appropriately.
I think only one the one function aw_whisper() will not work in 2.0 worlds.

-Roland

[View Quote]

Oct 21, 1998, 5:24pm

The 2.1 server and browser are still under development at COF, so there
isn't any documentation available on them yet. The 2.1 server is close to
being completed, so there are about a dozen worlds or so currently running
it as a test. However there is still quite a bit of work left to do on the
2.1 browser so it won't be available for a while yet.

For obscure reasons, under certain circumstances a world's user count can
appear to temporarily exceed its maximum. In this case I don't think it had
anything to do with the bot per se since the world was presumably a 2.0
world.

-Roland

[View Quote]

Oct 20, 1998, 6:20pm

Hi,

Build 7 of the SDK is now available. Please upgrade at your earliest
convenience.

As requested, all "char *" declarations have been changed to "const char *"
for easier compatibility with C++. Also a bug has been fixed which
sometimes caused synchronous API calls, such as the call to
aw_object_change() in the second sample application, to stall and never
return

-Roland

Oct 23, 1998, 1:38am

Please do not crosspost your posts to so many newsgroups. At least, please
don't crosspost to the SDK newsgroup when your post is not related to the
SDK. Thanks!

-Roland

ps. if you are going to reply to this thread, please be sure to check the
"Newsgroups:" field of your post and remove "sdk" before posting your reply.

[View Quote]

Nov 11, 1998, 3:01am

And I am totally opposed to this thread continuing any longer in the SDK
newsgroup :)

-Roland

[View Quote]

Oct 24, 1998, 2:17pm

The trick with getting avatars to "walk" is that you have to kind of
second-guess the lifeforms avatar animation engine's decision about how to
animate an avatar based on how far it has moved in a given amount of time.
This is an elusive algorithm that even I don't grasp (I didn't write it).

The bottom line is, it's based on how far your avatar moved in a given
amount of time. One thing to keep in mind is that you don't have to update
your avatar's bots position more than once per second (note to self, add
this to the SDK docs); position updates more frequent than that will just be
ignored by the server. A "typical" walking rate is about 1.3 meters per
second...so if you space your position updates out so that they are 1 second
and 1-2 meters apart, you should see the avatar appear to "walk" (assuming
it has a walking animation sequence available of course).

-Roland

[View Quote]

Oct 24, 1998, 2:11pm

One problem I can see right away is that your first call to aw_say() won't
work because aw_create() changes the default instance (i.e. the bot that
subsequent commands apply to) to the instance you just created. You need to
either move the call to aw_say() above aw_create() or use more calls to
aw_instance_set() to switch back and forth between the two bots.

Also you did not call aw_state_change() before your second call to aw_say(),
so it won't work either. You have to announce your position in the world at
least once by calling aw_state_change() before you can say anything.

Beyond that, if you are still having problems I would suggest more liberal
checking of return values (especially from calls to aw_enter() which can
fail for lots of different reasons) with appropriate bail outs/diagnostic
messages so you can quickly identify problems when you run the program.

-Roland

[View Quote]

Oct 26, 1998, 5:48pm

Yes the plan has always been to first release an API to the basic
client/server protocol as it currently exists, since that implementation can
be completed in the least amount of time and it is the minimal
implementation required to provide full bot functionality.

In the future, after the initial release and as the SDK matures, "higher
level" APIs will be added to encapsulate some of the more complex SDK
operations, such as avatar movement, property, etc.

-Roland

[View Quote]

Nov 1, 1998, 7:19pm

I just wanted to toss in here something to watch out for. I've probably
mentioned this before, but if you write code that moves entire buildings you
have to be prepared to encounter area-full areas if you are moving large
numbers of objects in sub-cell increments. The reason for this is that if
you have a building that has been built more or less at or close to the cell
data limit for that world, it is quite likely that if you move the building
so that it no longer contains the same N/S orientation or no longer falls in
the same position relative to the cell gridlines, the building's objects
will fall into a different arrangement of cells in their new location,
causing a re-distribution of object data amongst the cells. As a result,
you will probably wind up with one or two objects that can no longer be
placed because the cell data limit has been exceeded in the new arrangement.

The only way to avoid this problem is to avoid building right up to the cell
data limit before moving a building, or to only move buildings in distances
of whole cell increments so that the objects retain the identical cell data
distribution at their new location.

-Roland

[View Quote]

Oct 24, 1998, 7:00pm

RC_NOT_INITIALIZED means you didn't call aw_init() first.

-Roland

[View Quote]

Oct 26, 1998, 9:39pm

This topic was discussed just a few days ago in this newsgroup. You should
read over some of the posts from last week to get the details.

In a nutshell, no, you cannot. At least, not in worlds with a registry
(i.e. most public building worlds, where encroachment is being enforced).
In a world without a registry, in theory you could build as another by
adding an object and then immediately changing the owner number of the
object after it was added. To do this your bot instance would have to have
the Eminent Domain right in that world.

-Roland

[View Quote]

Oct 26, 1998, 9:43pm

Hi,

I'm sorry but I don't understand what you mean by "the API should also have
the world server functions". What functions do you mean? Please explain in
more detail.

The API as it is currently implemented provides access to the entire world
server protocol and the majority of the universe server protocol. Adding
new functionality to the API is not just a matter of extending the API, it
also involves adding new functionality to the world servers as well and thus
is a substantial project.

-Roland

[View Quote]

Nov 4, 1998, 6:58pm

>Roland, is there anything I'm leaving out or have
>screwed up? If not, is there a convenient way we could put hooks
>in for this?


I'm not sure - you're asking specifically about the JNI, correct? The JNI
was not developed by COF and I have yet to try it out myself. The author of
the JNI posts here regularly, hopefully he will be able to answer your
question.

-Roland

Nov 1, 1998, 7:11pm

I am not familiar with the details of 6.0 but this error implies that your
application project is set up to be a Windows application, so the linker is
looking for your WinMain() and not finding it. Much as all normal C
programs must have a main() function, all Windows applications must have a
WinMain() function.

However, you can get around this requirement by creating a "console
application" project, which functions as a normal C program, requiring a
main() instead of a WinMain(). When you use the New Project wizard under
Visual C++, you have a choice of a variety of different project types to
create. I'm not sure but your error suggests that you probably picked
"Win32 application" (that's how it appears under 5.0). Instead you should
create a project of type "Win32 Console Application" if you don't want to
mess around with creating a WinMain() function. Of course, console
applications will limit you to "DOS box" stdin/stdout functionality only.
If you want to create a full fledged Windows app with windows and menus etc.
then you will have to bite the bullet and learn how to write a WinMain()
function, among other things.

I don't know how these various project types correspond to linker options at
the low level. My advice would be to start over by creating a new Console
Application project from scratch and moving over your source files.

-Roland


[View Quote]

Nov 7, 1998, 7:04am

>1) aw_query requires the int x_sector and int z_sector parameters. Are
these
>real AW coordinates (i.e. 32N, 5W) or are they the reference to the sector
>in the zone ?


As Canopus suggests, a good idea would be to read the page on "Property" in
the SDK docs. It at least attempts to make some sense out of the confusion
that is property in Active Worlds. :) The second sample application is
also worth looking at, although unforunately it is maybe a little bit too
much of a simple case and doesn't illustrate the full complexity of querying
property at any arbitrary point in a world (it only deals with the zone
centered around 0N 0W.)

But in short, aw_query() takes the coordinates of the central sector of the
zone you are querying. The SDK provides a utility to function
aw_sector_from_cell() to help you convert cell coordinates to sector
coordinates. For example, to initiate a query at 32N 5W as you suggested,
you could write code like this:

#define CELL_X 5 /* 5W */
#define CELL_Z 32 /* 23N */

int sequence[3][3];

aw_query (aw_sector_from_cell (CELL_X), aw_sector_from_cell (CELL_Z),
sequence);

>2) I have noticed that aw_object_number occasionaly returns some large and
>sometime negative number. The following is part of a dump of values
>retrieved from Virtualy which has about 65,000 objects.
>
>57837,286443,905945912,-9500,2500,9000,900,v5012.rwx,,
>57838,286443,905945912,-10000,2600,9000,1800,v5231.rwx,,
>1622163995,188537,909781012,-9200,3000,9100,0,col10m02.rwx,,
>926433427,188537,909781016,-9200,3000,9350,0,col10m02.rwx,,
>2043787557,188537,909781038,-9200,2050,9350,0,col10m02.rwx,,
>
>The first number is the aw_object_number which makes sense in the first two
>lines. Is this normal ? What do the negative numbers mean ?


Object numbers are usually randomly generated 32-bit numbers. They will
appear to be negative if the 32nd bit is 1 and you print them out as signed
integers. Conceptually, they aren't really positive or negative, think of
them as a random sequence of bits that serve to uniquely identify an object
within a cell.

There is one exception to this, however: when a world has been built up via
a propload, the object numbers are assigned sequentially starting at one.
So the 57837 and 57838 are presumably objects that have been there since the
last propload, and the larger numbers are from objects that were placed
"live" (i.e. while the world was running, from either the AW browser or an
SDK app).

>Thanks for for your help.
>
>Lucio & Emanuele
>
>

Nov 7, 1998, 5:08pm

Sorry, a typo in my last post. This line:

#define CELL_Z 32 /* 23N */


should read

#define CELL_Z 32 /* 32N */

a small detail but property is confusing enough already, I didn't want to
make it any worse :)

-Roland

Nov 10, 1998, 10:01pm

Are you calling aw_wait() at all? You must call aw_wait() in order to
receive any events. Also, aw_wait() periodically sends heartbeats to the
servers so they know your bot is still alive. I assume the reason your bots
are vanishing is that you are not calling aw_wait(), so after about a minute
the world server gives up on your bots and disconnects them.

After setting up your bots, your program should spend the majority of its
time in a loop calling aw_wait(), as demonstrated in the sample programs.

-Roland

[View Quote]

Nov 11, 1998, 3:08am

If you are using callbacks for all your methods (i.e. asynchronous mode)
then your app must call aw_wait() periodically or the heartbeats won't get
sent and your bots will get disconnected, but in this case of course you
must call aw_wait() anyway or your callbacks won't get called either.

In synchronous mode, any of the methods that can have a callback installed
(e.g. aw_query(), aw_object_add(), etc.) will do an implicit aw_wait() and
thus heartbeats will get sent. However most of the common API methods don't
have callbacks and thus will not call aw_wait() when you call them.

It's only dawning on me now that this wasn't made clear in the SDK docs.
I'll remedy that oversight as soon as possible...

Calling aw_wait() with any negative time value means "wait infinitely". In
other words,

aw_wait (-1);

is equivalent to

for (;;)
aw_wait (1000);

-Roland

[View Quote]

Nov 12, 1998, 6:25pm

Oops. Sorry about that. I upgraded AlphaWorld to a 2.1 server last night,
and I forgot that 2.1 worlds disallow all bots by default.

I've now set AlphaWorld to allow all bots. Consider this an "experimental"
condition. The usual bot rules apply, including: 1) no bots at or near the
GZ area, and 2) no large-scale automated building (small SDK auto-building
projects of 100 objects or less will be tolerated for the time being as long
as no noticeable problems arise on the server side).

SDK apps have great potential for good, but also, unfortunately, for harm.
We will see how it goes with AlphaWorld allowing all bots. If there are too
many problems and/or abuses we may close it to bots in the future.

-Roland

ps. the aw_enter() problem should be fixed in build 8 of the SDK, just
posted now.

[View Quote]

Nov 12, 1998, 11:57pm

Actually, technically the ban only applies to the addition of new objects,
so your mover bot would be exempt.

Unfortunately, the way the ban is enforced is by tallying the daily number
of ADDs by citizen and then checking on anyone who registers above a certain
threshold, so if you did move 5680 objects from one place to somewhere else
it would show up as 5680 adds, assuming the move is implemented by deleting
all of the old objects in the old location and then adding them all again in
the new location. I guess you'd better drop me an email before doing it so
I know to watch out for it.

Sigh, I *really* need to get those building quotas implemented one of these
days...

-Roland

[View Quote]

Nov 17, 1998, 6:08pm

No, the no-GZ rule only applies to visible bots.

-Roland

[View Quote]

Nov 12, 1998, 6:15pm

Build 8 of the SDK is now available. Please upgrade at your earliest
convenience.

Build 8 fixes two problems:

1. aw_wait() had a small memory leak

2. aw_enter() should no longer hang when attempting to enter a world that
does not allow bots. It should now correctly return RC_NOT_WELCOME (467).

-Roland

Nov 12, 1998, 10:17pm

Sorry, a potential crash bug crept into aw_destroy() with build 8. Build 9
should fix the problem.

-Roland

Nov 14, 1998, 5:00pm

>You CAN run a background changer with the SDK using a collective program
>of relatively simple functions... The world server version does not affect
>the SDK other than the world user counts.

Actually that's not quite correct...2.1 world servers also have the ability
to lock-out SDK apps completely, or allow them in on a owner-by-owner basis.
2.0 world servers do not have this ability. Also 2.1 servers support the
aw_whisper() method, while 2.0 worlds do not.

Currently the only worlds running version 2.1 are those hosted by COF.

-Roland

Nov 21, 1998, 3:24am

I wouldn't worry about this clause too much. It is there to protect COF in
case someone tries to ship a supposedly finished product based on our beta
software. Presumably that clause will be removed once the SDK is released.

In the meantime, don't worry about exchanging source code or .exe's with
each other as you work on the SDK. As long as everyone understands that
this is beta software and it might be disabled, or fail, blah blah blah, at
any time, there shouldn't be any problem.

The one thing you should not do, however, is make an SDK-based application
and then give it to other people for their general use if they do not
understand that this is still beta software and so by using they are also
becoming unwilling beta testers.

-Roland


[View Quote]

1  2  3  4  5  6  |   Order by default