1  |   Order by index

Jun 10, 2006, 10:20pm

Has anyone figured out the new V4 object event data types

AW_OBJECT_ID
AW_OBJECT_SYNC
AW_OBJECT_TYPE
AW_OBJECT_DATA

AW_OBJECT_TYPE seems to be 0=Object 2=Zone 3=Emitter 4=Mover 5=Camera

I have tried to use aw_data(AW_OBJECT_DATA, &mylength); The integer
mylength variable takes on a value equal to the length integer in the
admin.exe propdump file, but the data part includes hex CC-CC-CC-CC
compared to the propdump data block that starts with "000000..." Is
the data encoded, like Radix or something?

Anyone have a code example how to grab this data for V4 object types
when object events occur?

Also, if you try to read AW_OBJECT_DATA for for the old type=0
standard RWX objects, it crashes. It must only be intended for new V4
types.

I notice several new integer fields in the admin.exe object propdump,
I assume these are for ID, SYNC, TYPE and the length of
AW_OBJECT_DATA. I'm not clear what they are for.

-cotarr

Jun 10, 2006, 11:25pm

Sorry, makes more sense now after some dinner,

Is this correct?

aw_data(AW_OBJECT_DATA, &mylength) seems to return a pointer to a
series of count=mylengh of 8 bit binary values. In the case of a zone,
the length returned is 51 bytes.

If I propdump a zone with admin.exe, then I see the "51" integer and a
hexadecimal ascii string of 51 bytes, which is exactly equal to what I
see in binary from the aw_data(AW_OBJECT_DATA....)

Next, if I look in aw.h at
typedef struct aw_object_data_zone
and then if I count up all the data type in the struct, i get:

5 float = 25 bytes
19 char = 19 bytes
5 short = 5 bytes
1 long = 2 bytes
Also equals 51 bytes.

So it would seem you could define a variable of type
aw_object_data_zone and just copy the binary. Is this how the object
events are intended to work?
-cotarr

[View Quote] >Has anyone figured out the new V4 object event data types
>
>AW_OBJECT_ID
>AW_OBJECT_SYNC
>AW_OBJECT_TYPE
>AW_OBJECT_DATA
>
>AW_OBJECT_TYPE seems to be 0=Object 2=Zone 3=Emitter 4=Mover 5=Camera
>
>I have tried to use aw_data(AW_OBJECT_DATA, &mylength); The integer
>mylength variable takes on a value equal to the length integer in the
>admin.exe propdump file, but the data part includes hex CC-CC-CC-CC
>compared to the propdump data block that starts with "000000..." Is
>the data encoded, like Radix or something?
>
>Anyone have a code example how to grab this data for V4 object types
>when object events occur?
>
>Also, if you try to read AW_OBJECT_DATA for for the old type=0
>standard RWX objects, it crashes. It must only be intended for new V4
>types.
>
>I notice several new integer fields in the admin.exe object propdump,
>I assume these are for ID, SYNC, TYPE and the length of
>AW_OBJECT_DATA. I'm not clear what they are for.
>
>-cotarr

Jun 11, 2006, 3:37am

[View Quote] AW_OBJECT_ID: This is a new identifier for objects that is unique across
the *entire* world, as opposed to AW_OBJECT_NUMBER only being unique in
*one cell*. An object change can be more easily detected by receiving
the same OBJECT_ID in an OBJECT_ADD event.

AW_OBJECT_DATA, as you have correctly observed, is only for V4 Objects.
It will not be saved with standard RWX/COB objects.

Jun 15, 2006, 12:00am

[View Quote] [View Quote]
Also the object ID doesn't change each time the object is moved or
changed in the AWB, the way the object number does, which is very nice.

As for AW_OBJECT_SYNC, you have to do aw_int_set(AW_OBJECT_SYNC,1)
before calling aw_object_click() if you want the effects to be seen
globally. I have no idea why. :D

You will notice that the various data structs are set up to have a
variable size block at the end for string data. In theory, you use the
aw_object_*_set functions to create the struct, but in practice, that
hasn't worked for me. I had to fill the struct manually to get it to
work...and even that hasn't worked for movers: when I created those, the
properties were scrambled up in the wrong fields. I wonder if the
struct defined for movers in aw.h isn't really what's being used
internally at present?

Jun 15, 2006, 7:49pm

Magine,

Thank you for the info on AW_OBJECT_SYNC.

As to the AW_OBJECT_DATA section, I have not tried to use the
predefined struct. Rather, I have just created a Hexadecimal text
string for each object type that exactly duplicate the Admin.Exe
propdump file format.

Although I can not alter the individual settings of an individual V4
object, I was successful with being able to interchange propdump files
from Admin.Exe for purpose of backup/move/copy/delete local areas of
objects. So far, all the V4 object I have tested were correctly
download and re-upload, using only the literal hexadecimal text string
and standard 4.1 prodpump format that I saw on mauz.info page. (thanks
Mauz). Later on I was going to try the struct formats, for each object
type, but i've not had time.

-cotarr

On 14 Jun 2006 22:00:26 -0400, "Magine" <magine at turtleflight.com>
[View Quote]

1  |   Order by index