Thread

aw_query (Sdk)

aw_query // Sdk

1  |  

lucio

Nov 6, 1998, 6:01pm
A couple of questions to whoever can help:

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 ?

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 ?

Thanks for for your help.

Lucio & Emanuele

lucio

Nov 6, 1998, 7:30pm
On the same issue, and just to clarify question 1), how would I query
objects at say 15s 12e ?

Thanks.

LP

canopus

Nov 7, 1998, 1:54am
First try reading the document called "Property" (which is all about Queries)
and then study Sample Program 2 (there are 5 lines that use Cell or Sector
coords derived from a specific AW location, 1N 1W in the program).

[View Quote] > A couple of questions to whoever can help:
>
> 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 ?
>
> 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 ?
>
> Thanks for for your help.
>
> Lucio & Emanuele

roland vilett

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

canopus

Nov 7, 1998, 2:15pm
In Sample Program 2, the Query is used to find a midispk object which has been
placed at 1N 1W on Beta world (this shows up in the CellX, CellZ in the first line
of handle_cell_object). These coords place it in SectorX=0, SectorZ=0 (this shows
up in the lines making calls to aw_query near the end of main and in the middle of
handle_query). SectorX=0, SectorZ=0 define the center Sector of a 9-Sector Zone,
ranging from X= -1 to +1 and Z= -1 to +1 (this shows up in the sanity-check line
in handle_cell_begin). You and the server communicate about the Zone with
reference to an array of 9 Sector-status containers, which is passed back and
forth during communications (Querying a Zone can take many communications). The
array is indexed from 0 to 2 in two dimensions, so you have to convert your 9
SectorX and 9 SectorZ coords to the corresponding array indexes: subtract your
center SectorX and SectorZ from 1, and then add the difference to the current
SectorX and SectorZ array indexes (this shows up in the last line of
handle_cell_begin: 1,1 minus 0,0 = 1,1, so you add 1 to SectorX and 1 to SectorZ
when indexing the array).
When I tested out the Delphi version of Sample Program 2, I placed a midispk at
Beta 1S 78W. So the line in my CellObject handler tests Cell_X = 78 and Cell_Z =
-1. That's in a Zone whose center Sector is at SectorX=10, SectorZ=0. So I did
aw_query(10, 0, SEQUENCE) at the end of the main procedure and in the ReQuery
handler. And the sanity-check in the CellBegin handler tests whether SectorX<9,
SectorX>11, SectorZ<-1, SectorZ>1. The line at the end of CellBegin updating the
SEQUENCE array adds the appropriate differences to the array indexes:
SEQUENCE[SectorZ + 1, SectorX - 9] finds the Sector-status container in the array
which is ready to be updated.

[View Quote] > First try reading the document called "Property" (which is all about Queries)
> and then study Sample Program 2 (there are 5 lines that use Cell or Sector
> coords derived from a specific AW location, 1N 1W in the program).
>
[View Quote]

roland vilett

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

lucio

Nov 9, 1998, 1:42pm
Thanks to both.

I had looked at the Property section of the Docs but was confused on the
specific aw_query parameters I asked about. One reason I got confused is
because I thought the ZONE was always referenced with respect to the
position of the bot... thinking back I don't know how I got that idea.

My objective is to build a bot that will keep the world synchronized with an
SQL database. I am the builder of "Virtualy", a world entirely covered with
a modular surface. The fact that the entire surface is covered with objects
makes it impossible to use the traditional registry-based building control.
To overcome this I have developed an SQL database structure (for the moment
in MS-Access) which is periodically fed by a propdump. I have a set of
queries and SQL scripts that allow me to monitor and do "bulk" maintenance
on the world (For example: assign all objects in an area to a citizen so he
can modify the ground and remove trees).

The current problem is that changes made to the world by other citizens
between the propdump and propload phases are lost. I believe an on-line SDK
bot would eliminate this problem. I also think such a sync process should be
fairly straight forward and similar to what the browser normaly does with
the local cell.dat cache.

My next step would be to build a reverse process that builds in the world
from new records in the SQL database. This would eliminate the need for
builder bot scripts (used in the beginning to create Virtualy) or the merge
and propload which I currently use.

In practice what I am aming at is an ODBC interface to the World Database
:)))

Comments on this idea ?

Lucio

canopus

Nov 9, 1998, 3:11pm
It sounds reasonable to me. I've programmed a surveyor bot that reads the entire
contents of a Zone (each object with its 10 attributes) into a textfile that
anyone can edit; and a builder bot that builds from a textfile of that type. My
original idea was to use a database, since databases are an integral part of the
Delphi system (including SQL, Access, Paradox, etc.), and I reduced it to
textfiles only to make the bots accessible to everybody. There are two
world-builders that I know of who are working on SDK mappers for their worlds,
one working in Delphi.

The bots can only query one Zone at a time, and live input mode is good only for
that Zone. Will you have your bot move around from Zone to Zone to detect new
construction?

By the way, Virtualy is a beautiful place. All the trouble you took to build
with so many landscape objects was worth it.

[View Quote] > Thanks to both.
>
> I had looked at the Property section of the Docs but was confused on the
> specific aw_query parameters I asked about. One reason I got confused is
> because I thought the ZONE was always referenced with respect to the
> position of the bot... thinking back I don't know how I got that idea.
>
> My objective is to build a bot that will keep the world synchronized with an
> SQL database. I am the builder of "Virtualy", a world entirely covered with
> a modular surface. The fact that the entire surface is covered with objects
> makes it impossible to use the traditional registry-based building control.
> To overcome this I have developed an SQL database structure (for the moment
> in MS-Access) which is periodically fed by a propdump. I have a set of
> queries and SQL scripts that allow me to monitor and do "bulk" maintenance
> on the world (For example: assign all objects in an area to a citizen so he
> can modify the ground and remove trees).
>
> The current problem is that changes made to the world by other citizens
> between the propdump and propload phases are lost. I believe an on-line SDK
> bot would eliminate this problem. I also think such a sync process should be
> fairly straight forward and similar to what the browser normaly does with
> the local cell.dat cache.
>
> My next step would be to build a reverse process that builds in the world
> from new records in the SQL database. This would eliminate the need for
> builder bot scripts (used in the beginning to create Virtualy) or the merge
> and propload which I currently use.
>
> In practice what I am aming at is an ODBC interface to the World Database
> :)))
>
> Comments on this idea ?
>
> Lucio

lucio

Nov 9, 1998, 3:14pm
>The bots can only query one Zone at a time, and live input mode is good
only for
>that Zone. Will you have your bot move around from Zone to Zone to detect
new
>construction?


Yes :) The bot would constantly move between zones and refresh the DB both
ways, with the world being primary in case of conflict.

>
>By the way, Virtualy is a beautiful place. All the trouble you took to
build
>with so many landscape objects was worth it.

Thanks :) But the are relatively few objects in Virtualy as the idea was to
mazimise object re-use. I will be teaching the technique at AWUniv at 21:00
VRT this coming saturday .

LP

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn