1  ...  4  5  6  7  8  9  ...  28  |   Order by default

Jun 2, 2002, 7:36pm

MrGrimm always stuck to common method - a condensed and capitalised version
of the attribute names, which in the aw.h file are AW_OBJECT_TILT and
AW_OBJECT_ROLL, so AwObjectTilt and AwObjectRoll are certainly a good bet.


[View Quote]

Jun 2, 2002, 7:58pm

The tricky one is going to be AW_CONSOLE_MESSAGE ... since
aw_console_message is also a method (for which he uses the same paradigm).

[View Quote]

Jun 3, 2002, 2:47pm

I don't know if this is related by aw_world_ejection_delete prototype is
different to previous builds if the aw.h file is anything to go by. Build 22
had an IP Address argument, but this is now the method has no arguments and
the IP address is populated with aw_int_set ... i.e.

aw_int_set(AW_EJECTION_ADDRESS, inet_addr(<IP Address>));

If you're adding to a previous version of your code, this may well be your
problem. Not very considerate really.

Grims.

[View Quote]

Jun 4, 2002, 4:37pm

A few people seem to have successfully implemented terrain functions in
bots, so I have a feeling I'm missing something, BUT ...

Does anyone find that the first aw_terrain_set call after an
aw_terrain_delete_all doesn't work?

Grims

Jun 4, 2002, 5:35pm

Geesh! This is getting to me now!

aw_data can return a maximum of 255 bytes of data according to the help
files (which must be true as the length value is only 1 byte). Yet aw_data
is used to retrieve 128 shorts for a line of page terrain heights (256
bytes) ... has anyone tried this or is my brain just mush from trying to get
my head around this?


[View Quote]

Jun 4, 2002, 6:17pm

Sorry, my mistake. I should have put this as a separate thread. This is on
aw_terrain_query in the AW_EVENT_TERRAIN_DATA event handler. Thanks for the
pointer on the first part though.

Grims

[View Quote]

Jun 6, 2002, 10:32am

For info, this was just an issue with the world server version.

Grims

[View Quote]

Jun 5, 2002, 6:27am

Actually, MrGrimm has it available from his web-site at
http://www.grimmsoft.com/aw/sdk/ without terrain support. Besides, not all
sdk functions required an aw_state_change before you could use them prior ro
build 24.

[View Quote]

Jun 9, 2002, 8:37am

if you're definitely using the same citnum privs for the bot as has placed
the other objects there then I can't see what the problem can be. Wrong cit
is the usual problem with this as aw adds the replacement object before
deleting the old one.

[View Quote]

Jun 15, 2002, 5:06pm

The documented propdump format doesn't include the object number which means
you'd have to rescan anyway. Without the object number you can't handle the
object delete or select events or issue any object change, delete, click or
select calls.

Unfortunately, unless all objects in the cell are dumped to the file, the
sequence not implied by the contents. I would recommend a custom format
prefered by the programmer. Just my opinion - it really depends what the bot
is responsible for in the world. There's only a need to dump the objects you
care about, and a structured format (I don't recommend this unless you've
already got suitable gerator/parser code or componant, but I create all my
files in XML now) in my experience is best rather than a flat one.

Grims.

[View Quote]

Feb 22, 2001, 12:44am

Wow ... two massive extremes, but I think you're both a bit off.

I would take a couple of weeks just to plan it properly and design how it is
going to hang together if you are going to approach it properly. You have to
prove to yourself that you've got the right idea and that it can do
everything you hope it will before you go ahead.

You've got to bear in mind that Xelag has developed the Xelagot over time,
learning from his experiences. Too many people think all this stuff is real
easy and that you can just plough into these things, but I'm sure that Xelag
wen't through a number iterations of his bots before it reached the stage it
is now.

You are talking about potentially defining a new scripting language to suit
bots, and then writing the parser that has to validate EVERYTHING. And that
is without the implementation of the new script into actual function. Then
there's testing and documentation before you can even release it to the
public (unless you want to look a bit silly) for them to find the
"glitches".

Even if you've got all day, every day to work on it ... you're still talking
a number of long weeks to achieve this ... like I said ... IF you are going
to do it properly.

Grims

[View Quote]

Jun 29, 2002, 1:38pm

With the introduction of the Tilt and Roll attributes in v3.3, some SDK
applications (including publicly released bots) may produce unexpected
results. This only applies (I believe) under the following circumstances ...

(a) the application picks up object click, object add or cell object (i.e.
handles 3x3, 5x5 and/or cell
next queries) events.

(b) the application uses object change, add or load SDK methods.

(c) the application code was written for a previous build of the SDK (i.e.
one that doesn't support the Tilt and Roll object attributes) but where the
version of the SDK has been "upgraded" to build 24 without changing the code
to handle the setting of the tilt and roll attributes.

(d) 3-axis rotation is enabled in the world (or more to the point, there are
objects in the world where 3d-axis rotation has been applied)

For those that can't see the problem at first, I'll try to explain. As
you're aware, all relevant attributes need to be set to the desired values
when making a call to the SDK since the values are retained within the SDK
throught its "life". So if the last object event (perhaps from a query
event) raised on build 24 included non-zero Tilt or Roll values, these will
be used in a subsequent aw_object_change call if they are not reset by the
code.

If the application was written for (and works perfectly well with) build 23,
but the version of the SDK has been changed to build 24 without readdressing
any object add, change or load calls, you may find that the Tilt and Roll of
the new object will not be what you expect.

As an example, an application that maintains a billboard, changing the
picture on an object at regular intervals may end up creating the object on
its side or skewed at a funny angle. I really depends on how the object tilt
and roll attributes have been "left" by the last event. Pre-build 24
applications will only be setting the Yaw of the object for its orientation
and not the Tilt and Roll.

I've reworded this a few times trying to get it to make sense, and I'm not
sure I have managed it. If your application doesn't use the object change,
add or load SDK methods then its not an issue. Unless the developer didn't
read the help pages properly, this only applies to applications that
PRE-DATED build 24 and the version of the SDK used has been changed TO build
24.

For VBer's benefit, build 24 is either AwSdkOcx5.ocx or the recent COM
wrapper from MrGrimm (they're both based on build 24).

If you're in the habit of keeping the version of the SDK up to date in your
applications you my want to check this in your code.

Grimble.

Jun 29, 2002, 2:31pm

Me too, chubrub. Still, who needs backwards compatibility, eh?

GrImble

[View Quote]

Feb 26, 2001, 1:49pm

lanezeri ... time to stop using VB. A simple app with a form in C/C++
doesn't use anywhere near the amount of space VB does. Having said that,
you're right .. if you're using VB, you ain't going to get the setup on a
3.5" diskette.

Grims


[View Quote]

Feb 26, 2001, 2:13pm

There's a java wrapper to the SDK that claims to allow bots to run as
servlets ... can't get much more "server based/thin-client" than that(!).
Never got around to trying it out though ...

Has anyone had any success with it?

http://www.insead.fr/CALT/Project/AWJavaBots/

Grims.


[View Quote]

Jul 2, 2002, 11:16am

That's not quite the same problem. From what I've read in the newsgroups,
the build 24 release of Preston isn't availabe yet, so the SDK build that
the current version is based on doesn't even know about the Tilt or Roll
attributes and so they will be defaulted to zero by the world server. I
imagine the same would be true of a v3.2 bowser in a world with 3-axis
rotation where the Tilt and Roll isn't seen in the older version.

When the 3.3 compatible version of Preston is released (although I guess it
may wait until 3.4 now as the new version is following on so soon), all
should be well.

Grims

[View Quote]

Feb 26, 2001, 5:23pm

Umm... you do like to go out on limbs, don't you lanezeri?


> I use VB because I don't have the time to waste making 500 lines of code..
just to log the bot in.

Have a look at the sample bot programs on the SDK web-site (written in C)
and reconsider this statement. You'll notice a marked similarity to the
interface to the AwSdkOcx2 control (except those quickstart/quickstop calls
for the sake of 12 lines which you would only need to write once anyway in a
function).


> 2) C++ is for games not applications, AW was made in C++ it is a game..
> applications are made mostly in VB unless they are huge like AOL.

Wow ... Nice one. OK, this is the limb I was talking about. I won't go into
detail, but you probably couldn't be more wrong if you tried. Exactly how
many serious pieces of software do you know of that are written in VB? What
a bizarre statement to make! ... amusing, but bizarre. C and C++ have been
the languages of choice for professional and casual software developers for
YEARS.


Grims.

Jul 1, 2002, 7:20am

Did you look at the help files before asking? Obviously not.

http://www.grimmsoft.com/help/index.php?parent=1&item=24&expand=2

or

http://www.activeworlds.com/sdk/aw_enter.htm




[View Quote]

Jul 2, 2002, 11:05am

Unless you're using a fixed font (e.g. courier new) in the RT box, you
really want to be working out the width of the text in pixels rather than
the number if characters ("WWWWW" is much wider that "IIIII").

You can do this using the TextWidth property of either the form of an
invisible picture box (with the same font settings as the RT Box).

You can find it in the VB local help or (sorry if the link gets split in the
post) at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vb98/html/v
bmthtextwidth.asp

Grims

[View Quote]

Jul 2, 2002, 11:09am

For a chat window, maybe the SelHangingIndent property would be more
suitable (also indents wrapped lines of a "paragraph").

Grims

[View Quote]

Feb 26, 2001, 6:50pm

LOL ... Whatever. I disagree, anyhow.

BTW, I don't have a problem with VB ... as you well know, I use VB!! I'm a
little confused where you got that idea from.

.... And who the heck do you think you are talking to "bud"??? Damned kids!

Grims


[View Quote]

Jul 2, 2002, 1:33pm

Hmmm ... tried it (and a standard 3x3) and I can't get it to behave either
but then its been a long time since I've actually had to write query code
(usually strip it from a library which I don't have for the COM wrapper).

What are you using to populate the sequence number? I tried (with variations
of) ...

cellX = mAWSDK.aw_int(AW_CELL_X)
cellZ = mAWSDK.aw_int(AW_CELL_Z)
cellSequence = mAWSDK.aw_int(AW_CELL_SEQUENCE)

sectorX = mAWSDK.aw_sector_from_cell(cellX) - QUERY_SECTOR_X + 2
sectorZ = mAWSDK.aw_sector_from_cell(cellZ) - QUERY_SECTOR_Z + 2
mAWSDK.aw_seq_5x5(sectorX, sectorZ) = cellSequence

where QUERY_SECTOR_X and QUERY_SECTOR_Z are the centre sectors for the
query, so the centre sector is in element 2. Maybe I'm missing something ...

Not a very helpful post really I guess, sorry.

Grims


Grims

[View Quote]

Jul 2, 2002, 8:45pm

It used to be that way around with the OCX too, but now we don't have the 2D
array, the COM object does. The arguments are explicity named now, but I did
try the "wrong" way around and a number of variations with no luck. No
documentation to speak of at the moment, sadly for people to work it out.

Grims

[View Quote]

Jul 2, 2002, 8:49pm

This is for the COM wrapper not the AwSdkOcx5 control. There's no array in
the bot code anymore - its been taken out of the developers hands. The old
control used to work pretty much the same as going directly to the sdk (same
array orientation).

The sample code on MrGrimms site refers to the OCX control and not the COM
wrapper.

Grims

[View Quote]

Jul 2, 2002, 8:51pm

Does anyone read the documentation anymore? Not exactly hidden.

[View Quote]

Jul 2, 2002, 9:30pm

Does "Str(intX) = ..." compile ??? I think that's your problem from a quick
glance. Really surprised it compiles though. I wouldn't expect that to do
anything to the value of intX.

Str converts a numeric into a string, but the store for that string isn't
the same as the numeric. So, the value of intX isn't changing and remaining
at zero. Same for intZ further down. Just "intX = Left(teleport, X - 1)"
would work.

Have to say at this point that I didn't run the code ... short on time,
sorry.

Grims.


[View Quote]

Jul 2, 2002, 11:44pm

It should be ... I would have expected that the throw up an error when it
compiles the procedure (when it is about to execute it). Its always a good
idea to run it in the IDE using Ctrl-F5 (run with full compile) though ...
it mean you'll find all the syntax errors before it runs and not during the
execution (which will throw up an error. I didn't mean compile to an exe.

Grims

[View Quote]

Jul 3, 2002, 12:02am

OK, I just tried it out and there's several issues in there. Is it important
to try to parse (and have to validate) a "100N 53E" style location? You
would have a much simpler job if you had separate edit boxes for NS and EW
cooords. If you really want to progress with this, there are ways to do it,
obviously, but I imagine this isn't the most important part of the app when
there's an easier alternative available.

Grims



[View Quote]

Jul 3, 2002, 5:03am

Something is causing me huge problems recently to do with the delivery of
events when I REALLY don't want them.

When processing an event, you expect to have a clean thread where the code
will execute until you relinquish process control. Recently, however, I've
been hitting more and more problems where the SDK is firing off events to
the application simply because I made a call to the SDK from within an event
handler. I'm reasonably certain that this is a relatively new problem, since
I've done what I'm attempting now on several occasions before and its
nothing special. Maybe I just got away with it those times.

A specific example is when processing an AW_EVENT_AVATAR_ADD, I want to call
aw_citizen_attributes_by_number to retrieve some additional attributes on
the user. Unfortunately, this causes the avatar add event for another avatar
present to be raised mid-process, incrementing store counters and generally
making a mess of things. It also means that avatar change events are being
processed (and being ignored/reported by a - I thought - pointless sanity
check) before the code has finished handing that avatar's add event.

I could put an event queue into the app and just populate it from the event
handlers and process that queue event by event (which is the only workaround
I can see at the moment), but it seems an unnecessary uverhead when I'm
already supposed to be doing that by processing the SDK events themselves.

The events are definitely originating from within the
aw_citizen_attributes_by_number call (the first time my app gets involved
after the call is at the top of the handler for the next event).

Is anyone else experiencing this/solved it? ... 'cos its starting to drive
me nuts going round in circles like this.

Grims.

Jul 3, 2002, 10:12am

Thanks MilesTeg ...

I'd like to adjust your statement slightly to "install the RIGHT DARNED
CALLBACK to avoid this, dopey!" if that's ok.

Grims

[View Quote]

1  ...  4  5  6  7  8  9  ...  28  |   Order by default