1  ...  8  9  10  11  12  13  ...  28  |   Order by default

Apr 11, 2001, 7:37pm

I didn't mean you, Moria, with the namecalling bit. LOL :oP

Grims


[View Quote]

Apr 12, 2001, 2:57pm

No it isn't.

[View Quote]

Apr 14, 2001, 11:58am

This ALWAYS the case. The only attributes that are populated as part of the
AW_EVENT_CHAT message are AW_AVATAR_NAME, AW_CHAT_MESSAGE, AW_CHAT_TYPE and
AW_CHAT_SESSION. There's no "for some reason" about it ... as documented on
http://www.activeworlds.com/sdk/AW_EVENT_CHAT.htm.

If you want to do anything beyond the basic coverage of the AW events you
have to remember all the settings from the AW_EVENT_AVATAR_CHANGE messages.
I don't have time right now to knock up a sample application for you
unfortunately, but basically you need to do manage a session table ...
something like this:

On an AW_EVENT AVATAR_ADD, you take all the attributes supplied by the SDK
and create a new entry in some form of list. How you implement this list is
vvery much dependant on your programming style, preferences and how you want
to use the list afterwards ... it could be a (large) fixed array (not
recommended), a dynamic array, a collection, a linked list, etc. The
important thing is that you store the avatar's location information against
its session number. Personally, I always use a class called CAWAvatar that
holds the avatar's information and the owning citizen information once its
resolved from the AW_CALLBACK_CITIZEN_ATTRIBUTES ... but it can be simple
Session Number plus the X, Y, Z and Yaw coordinates if you want.

On an AW_EVENT_AVATAR_CHANGE, you need to look up the session number in your
list and adjust the location information held against it (X, Y, Z and Yaw).

On an AW_EVENT_AVATAR_DELETE, you can throw the entry relating to that
session away.

When you get your AW_EVENT_CHAT message, you can lookup the avatar's
location from the list to establish where the avatar really is ... NOT the
leftovers of the previous event that updated the avatar's X, Y, Z and Yaw
attributes in the SDK stores.

As far as getting the bot to go in front of the avatar, you need to apply
some simple maths. Simply adding 100 to the coordinates will always put the
bot at 100 further north and 100 further west. You need to use circle
formula to get it 1m away from the avatar in the directionthe avatar is
LOOKING.

0 Yaw is looking North, 900 is looking West, so to find the X offset, you do
the radius of the circle (the distance away fromt he avatar ... 100 in this
case) and multiply it by Sine(Yaw/10). For the Z offset, you use Cosine
instead. Therefore:

botPosX = avatarPosX + (JOIN_DISTANCE * Sin(avatarPosYaw/10)
botPosZ = avatarPosX + (JOIN_DISTANCE * Cos(avatarPosYaw/10)

To make the bot "look at" the avatar ... you simply reverse the avatar's Yaw
with simething like ((avatarPosYaw + 180) Mod 360).

"The Derek" ... you amaze me ... I have only just removed you from my filter
list (which you originally earned membership of because I was tired of your
continual crap responses) and you immediately demonstrate the same old
inability to read the documentation and insistance on making uninformed
assumptions instead of finding things out. Back on the list for you.

Hope this helps TrekkerX. As I said, I'm a bit puched for time right now so
I can't make up a sample application for you. After Easter is over, if
you're still stuck, let me know and I'll put something together for you
quickly to demonstrate how to handle session tables. This post is using the
event names in the actual SDK as documented (for C) but the names in the
AwSdkOcx2 and 3 are close enough for you to make the connection.

Grims




[View Quote]

Apr 14, 2001, 12:11pm

Sorry ... typing is crap today ... formulas should read as follows:

botPosX = avatarPosX + (JOIN_DISTANCE * Sin(avatarPosYaw/10))
botPosZ = avatarPosZ + (JOIN_DISTANCE * Cos(avatarPosYaw/10))

Just a quick note ... it might be crap maths in this machine, but I use
Visual Studio 6 with Service Pack and COS(90) ... I think ... is never
calculated correctly, so watch for that. I seem to remember from my school
days that Cos(x) = 1/Sin(x) so you can use that if you get this problem.

Grims/


[View Quote]

Apr 14, 2001, 1:09pm

Hmmm yeah ... 1/Sin(x) doesn't work does it :o( ... Thanks.

BTW TrekkerX ... don't forget to convertdecrees to Radians before using the
VB Cos/Sin functions.

Grims


[View Quote]

Apr 14, 2001, 12:04pm

Your only issue is that the bot won't get notifications of anything outside
its hearing radius. The hearing radius of the bot is dictated by the rights
of its owner and, to my knowledge, there is nothing you can do about it. To
my mind, you need to position a number of bots around the world to get total
coverage and get them talking to each other, either behind the scenes in the
bot code itself or by whispering between them (which is again dependant on
the hearing radius of the bot).

It would be nice if a bot owned by a cit with ED could get enter/exit
messages covering the whole world generated by the world server, but alas,
not yet.

Grims



[View Quote]

Apr 19, 2001, 8:55pm

A 21MB Winchester Disk ... now we're talking !!

[View Quote]

Apr 19, 2001, 8:53pm

Hey ... if you ask him nicely, I'm sure Andras would host a newsgroup for
you lot called "My dick's bigger than yours". Then you can keep this crap up
all day long without boring other people !!

Waddya reckon??



[View Quote]

Apr 24, 2006, 12:19pm

Just a quick question ... I've been trying to think my way around this, but
I keep coming to the same conclusion and I'd just like to check with those
that may know or have an opinion what their views are.

I've been playing with multi-threading and the SDK in .NET (C#), having
different functions of a single bot operating in their own threads as well
as running multiple bot instances in their own threads (i.e. within the same
process). Object sychronisation between threads is a breeze in .NET, however
I need to make a base framework thread-safe in a way that doesn't require
the applications that are built upon it to care about the threading.
Unfortunately, it strikes me that there's no *simple* way to make the SDK
thread safe in this way.

An example of the problem could be where there are two threads running
within a single bot process, both of which are interacting with the objects
in the world. I can neither predict nor guarantee the function of an
application thread when two separate threads are setting the same SDK
attributes (AW_OBJECT_NUMBER, AW_OBJECT_X, AW_OBJECT_Y, AW_OBJECT_Z, etc.)
and making calls to the SDK. Using the threading and synchronisation
capabilities of .NET, I can ensure that a single thread "owns" the SDK at
any point in time, however this would involve introducing (what I would
consider to be) needless overheads on all calls to the SDK, including the
attribute getter/setter methods and I want the applications themselves
(built on the framework) to be developed the same regardless of threading.

The only way I could see to guarantee the integrity of the thread processes
was to rework the interface the the SDK using an alternative method of
making the calls from code, building a complete "command" that is then
executed through the framework against the SDK methods. This would give me
an opportunity to perform the whole lock/process/unlock within the new
mechanism and each call subsequent call would wait for the lock to be
released. I had hoped to keep to the AW SDK documentation as closely as
possible (to avoid the need to redocument everything as well as keeping a
common frame of reference for developers), and this method doesn't really
achieve that to the extent I intended.

Does anyone have any ideas for alternative approaches? Basically, I don't
want to force a developer to make calls to "grab and release" the SDK
methods around their processes as this is unnecessary complexity, leaves the
door wide open for irritating and hard-to-find bugs as well as stiffling the
extention of objects through polymorphism. I also don't want to be loading
and managing more than one instance of the SDK (assuming loading instances
of ummanaged code is even possible!). If need be, I'll opt for the new
calling method but I'd prefer to find a (better) alternative.

I hope this made sense!!

I have been out of the AW frame for some time now, and I don't recognise a
fair few of the names that post in the newsgroups these days, so I don't
really know who's knowledgable in what areas. I've also been away from the
SDK for the same period, so please forgive me if I'm a bit out of touch with
where AW is at the moment.

BTW ... what's the deal with AW_UNIVERSE_RENEWAL_CHARGE? Does this attribute
exist (as described in the SDK documentation for
AW_EVENT_UNIVERSE_ATTRIBUTES) or not (as indicated by its absence from
aw.h)?

Many thanks,

Grims.

Apr 25, 2006, 7:56am

Thanks Andras,

I'll sort out the rest of the grunt work inside and just keep in view the
threading option for now. Hopefully a release of the SDK with thread support
will come along before my interest starts to wane and its implemented in a
way that doesn't need too much rework in the framework.

Cheers,

Grims.

[View Quote] > To make the answer short - the AW SDK 3.6 (up to the latest build) does
> not support multi threading and it is not multi threading safe.
>
> Wait for the 4.x release :)

Jun 3, 2006, 8:19pm

So - and without any documentation its hard to tell anything really - can
build 60 of the SDK can now handle multiple threads interacting with it
(referring back to my example of two independent threads performing similar
tasks and getting themselves confused by overwriting eachother's attribute
settings and/or switching instances when running concurrently)?

There's nothing that jumps out from the aw.h, just an instance-level event
subscriber, which I would imagine most people that run multiple bots in the
same program have implemented themselves anyway on top of the old method
(although I'm not saying its not good to have this where it belongs, in the
SDK!).

Thanks

Grims

[View Quote]

May 20, 2006, 5:34am

1) What programming language do you program bots in?

In the past, C, C++ and VB. Now I've consolidated onto C#.

2) What do you prefer to program in (in case they aren't they same answer)?

C# - no contest.

3) Why do you prefer to program bots in the language of your choice? List
pros and cons please!

The Pro's for me personally are numerous (hey, its .NET!) - its a language
I've grown very comfortable with since VS2003Pro landed on my doormat two
years ago. I'm still working on .NET 1.1 for numerous reasons (no "killer"
need for .NET 2.0 being a key one at present) but the compatibility between
1.1 and 2.0 is good enough to make this not an issue. At the time it
represented a C++ derivative with the CLR (C++.NET didn't exist in 1.1). Now
I can do more, quicker in C# without digging into docs than I can in C++.

The Pro's for other people? A free quality development environment, quick to
learn, the CLR and a common platform for application, web, service, etc.
development and its easy to develop and share your own components.

Cons? Deployment to Windows platforms only. That's all I've got on Cons (not
that it bothers me!).

Grims.

May 22, 2006, 10:11am

Until yesterday, I was blissfully unaware of a number of issues I had with
using the SDK under .NET (C#). Some VERY shy exceptions keeping themselves
out of sight (System.Timers.Timer! GRRR!) meant I was missing some real
problems with interfacing with the SDK. I think this list is going to grow,
so I'll start with the three I've attached below.

This is using .NET 1.1 (but the same happens in 2.0) and SDK Build 41. If
anyone has experienced these before and/or has any constructive comments,
I'd be grateful.

Many thanks,

Grims.

**********
*** C# Callback Delegate
**********
I have SDK callbacks being installed though the use of a delegate, as
follows:

public delegate void SDKCallbackHandler(int ReturnCode);

This works great until the end of the delegate processing, when the
application kicks out a null reference exception from within aw_wait(). It
would seem not to be a GC'd delegate - .NET has a specific exception for
GC'd delegates and all the delegate instances are static and within context.
I get no such problems with the event delegates.

**********
*** AW_CALLBACK_LOGIN/aw_login Return Code
**********
Possibly related to the delegate issue above (only because its a callback),
but when I install the AW_CALLBACK_LOGIN callback, aw_login() returns a 439
(No Connection). If I don't install the callback, it logs in fine.


**********
*** aw_cell_next Return Code
**********
This one is annoying. As I've done before in other languages, I have a query
facility for a single cell using the aw_cell_next with a forced value for
AW_CELL_ITERATOR. Generally this works fine, with the AW_EVENT_CELL_BEGIN,
AW_EVENT_CELL_OBJECT and AW_EVENT_CELL_END events all being delivered and
setting the attributes that would be expected. However, the return code for
the aw_cell_next call is always 74 (No Such Cell). Its not my calculation
for AW_CELL_ITERATOR, because I've tried setting it to zero (as per docs)
and the same happens - the events are fired but it returns 74 and
AW_CELL_ITERATOR is not incremented.

May 22, 2006, 4:38pm

Thanks Andras. Yes it was in AW, but the value of AW_CELL_COMBINE doesn't
appear to make a difference - I get a 74 in either case. This isn't a major
issue if its an AW only thing. I would assume that there won't be another
world like AW with this complication, so for now I can work around it until
I run it somewhere else.

Thanks for the info.

Grims.

[View Quote]

May 23, 2006, 6:41am

I hope this doesn't turn into a thread of me talking to myself, but I've
found ONE solution that seems to solve the null reference exception. Having
said that, its far from elegant (actually its a mess!) and I don't really
want to use it, but it does confirm the problem - calling convention
(although if that's the case then I'm surprised no-one else has hit it
unless other .NET users are going through COM).

Back in the days when I was using VB6, I created a new aw.dll from
aw_static.lib and used this directly from VB6 without going through COM. I
think that would probably be the best way to address this as well (its a
shame I don't have the code anymore!). Its nothing difficult, just an amount
of effort to put a prototype together. Once I've confirmed it works, if
there's a demand for it from others then I'll redo it a little more neatly
and tout it about.

Again, any comments welcome.

Grims.


[View Quote]

May 24, 2006, 6:12am

The new DLL worked great - it can be called directly (and safely) from .NET
with appropriate prototypes. It may be a while before I get a chance to
finish it and tart it up (or it may not), but I'll probably wait until the
final 4.1 SDK is available so that it can support that release before I
publish it.

Grims

[View Quote] > Back in the days when I was using VB6, I created a new aw.dll from
> aw_static.lib and used this directly from VB6 without going through COM.

May 24, 2006, 6:15am

This one is is still a problem for me. Does anyone else suffer from this on
Build 41 (on any platform)?

Grims

[View Quote]

May 25, 2006, 5:54am

Last post on this. .NET 2.0 handles the calling convention issue with
callbacks by using an attribute on the delegate, so there's no need to worry
about this afterall (unless you're like me and use .NET 1.1).

Jun 13, 2006, 1:42pm

Is there any more information on this (i.e. does anyone know if it is at
least planned to be looked at)? I assume that build 60 is not the final SDK
release for 4.1 - there's no static link library available at present.

I have a similar (related?) problem when running multiple threads in an
application within the Visual Studio IDE (.NET 2.0). In debug, when
initiating a new thread (totally unrelated to any SDK activity) after making
a call to the SDK in the parent thread, the application dies with a
StackOverflowException (the same as if I try to step past the aw_init in
debug mode). If the child threads are started before the first SDK call in
the parent thread, then everything works fine. The child thread could be
anything, even an empty method.

The SDK call doesn't have to be aw_init, it could be any SDK call and I
can't tell at this point where the StackOverflowException is being raised
from. I may know a bit later - at the moment I'm assuming its raised within
the SDK as the IDE doesn't catch it.

Grims

[View Quote]

Jun 14, 2006, 7:03am

Thanks for the info Ima and Dr - although this really should be publicised.
I don't mind the need for an NDA, but I think it would all sound much less
paranoid and over-zealous if a simple distinction was made between a freely
downloadable runtime-only license and a development license requiring a more
formal agreement including an NDA.

Having said that, there's all manner of scope for inadvertant distribution
of the "debuggable" SDK. I wonder if we'd have to put similar anti-debugging
restrictions in any DLLs we create that incorporate the SDK if we have the
static link library from AWI.

As for the debugger, until now, as long as I don't try to step through the
code after making a call to the SDK, I could run the app from within Visual
Studio in debug (i.e. F5). Now, though, crashes when initiating new threads
within the application mean I've got to CTRL-F5 it instead - hardly a big
deal I know, but perhaps a flaw in AWI's plan?

When you think about it, its a shame that just as the SDK supports something
new and exciting with all these additional 4.1 features, the SDK becomes
less accessible. Personally, I don't see what AWI are trying to achieve with
this, but that's their perogative.


[View Quote]

Jun 4, 2006, 8:37pm

Wouldn't the Working Directory setting in the shortcut solve that problem in
this case?

[View Quote]

Jun 7, 2006, 7:20am

Can anyone shed any light on how to use these methods properly please? For
example, I assume that ...

** aw_event_set works as before, setting a global event handler for all
instances (?)
** aw_instance_event_set sets the event handler for the current instance
(identified with aw_instance_set)
** aw_event returns the event handler based on the the current instance
(identified with aw_instance_set - Instance = zero for global handler?)

Assuming that the above is true (please correct me if not), if both the
global and instance event handlers are installed, are they both called? ...
and if so, in what order?

I could experiment with this, but playing with the SDK at the moment is more
of a chore than any fun with the current release, so any info would be
appreciated.

Thanks, Grims

Jun 14, 2006, 10:31am

I should know this already, but is aw_wait instance-specific or does it
receive events/callbacks for all instances? I'm going to run into more
really irritating issues with multi-threading if its not global.

Thanks, Grims

Jun 14, 2006, 11:01pm

After another coffee, it became obvious that it didn't make the blindest bit
of difference to me after all!

Still, thanks for the info.

[View Quote]

Jun 14, 2006, 11:11pm

This may have been the case before, but I don't remember it at all.

I'm getting two AW_EVENT_WORLD_ATTRIBUTE events when I enter the world
("AW") ... one from the aw_enter call and one from the next aw_wait.

Is this to be expected?

Jun 15, 2006, 1:00pm

Nope ... sorry, second event arrives immediately after the first (from
within aw_enter when its all done sequentially). "Luck" made it look like
aw_wait was joining in.

Same attributes, but there's definitely two calls to the event handler.


[View Quote]

Jun 18, 2006, 10:46am

How many people are still using this, isn't it a COM component?

[View Quote]

Jun 18, 2006, 12:19pm

Read the words ... "How many people are still using this?".

I was going to elaborate on alternatives for anyone using it beyond VB6.0
but sod it - reactions like that say it all really. I guess you can just
wait to see if it makes the light of day.

[View Quote]

Jun 18, 2006, 1:14pm

No, I'm not having that ... don't you dare try and divert blame onto AW for
your petulence.

At the risk of being contentious, its 2006 and VB6 (released in 1998!) is
two generations behind the latest version of the language and anyone using
it needs to consider how they move forward (making the transition to VB.NET
or to another development language). If people are using .NET 1.1, there's
very few reasons not to move to .NET 2.0 and if they're using .NET 2.0
already, there's no reason to be using a COM component to interface with the
SDK.

Happy waiting ...

[View Quote]

Jun 18, 2006, 2:15pm

..NET is only INTEROPERABLE with COM and there's a whole assembly dedicated
to it supporting it. Its just an unnecessary middleman in this case. The SDK
interface can now be [Dllimport]ed directly into a .NET 2.0 assembly by
specifying the correct marshalling attributes.


[View Quote]

1  ...  8  9  10  11  12  13  ...  28  |   Order by default