grimble // User Search

grimble // User Search

1  ...  9  10  11  12  13  14  ...  28  |  

SDK Developers : Pissed Off

Jun 18, 2006, 7:09am
I think a more considered, less sarcastic response would have been more
appropriate here.

People have bought citizenships and world licenses based on what
Activeworlds and the SDK did before the forced upgrade ... and the
combination of the changes brought in with 4.1 has clearly moved the
goalposts for many. Now even the design of existing SDK applications needs
to be readdressed because of changes in the platform.

Bearing in mind the level of communication and documentation from AWI
relating to 4.1, I think this type of complaint is only to be expected.
Clearly very few people knew what was coming and the impact it would have on
existing projects or new projects.

Grims

[View Quote]

SDK Developers : Pissed Off

Jun 18, 2006, 7:06pm
No, I don't think we do agree. My reply was to Cryonic's post. I think HIS
reply should have been more considered and less sarcastic, and I think
complaints such as Strike's are only to be expected.

Whilst I believe that we now have to deal with what we've been dealt and try
to move forward from the position we find ourselves in, I also find it
inconceivable how the heck we got to this position in the first place. If
I'd had a vested interest other than a citizenship before the upgrade,
expecting 3.6 + the new 4.1 features, I'd have the right 'ump now as well,
especially with the operational changes in and lack of any documentation for
the SDK.

I don't necessarily condone broadcasting complaints, but its astonishing
that Cryonics should respond in that manner and, to me, its out of line.

[View Quote]

SDK Developers : Pissed Off

Jun 20, 2006, 11:38am
"potential or possible" = "I wonder what's the best way to do it"
"very difficult, if not impossible" = a challenge!

[View Quote] > "presently existing in fact and not merely potential or possible"

On a more constructive note ...

Jun 18, 2006, 12:06pm
I've been playing recently with a concept that the SDK seems to lend itself
to quite nicely, and with the current state of the SDK and the difficulties
involved in using it at the moment, I thought now might be a good time for
some healthy discussion on the subject.

Based on my previous experience of the people that used the SDK and the way
this newsgroup worked (it used to be more of a "how do I do this?" and "why
doesn't my bot do what its supposed to?" forum with code snippets flying
around and, sometimes, even active discussions on specific topics), it
struck me that we would all be better served by something based on sharable,
re-usable components.

If you look for a basic OO abstraction of the SDK, you'll probably come up
with a set of virtual methods in some form of base class to handle SDK
events, which is great for laying down a template for developing bots. This
still targets a single set of code per event, though.

I've spent the last couple of weeks going through several iterations of
prototype for a very simple framework that doesn't attempt to abstract the
SDK, but rather puts in place a foundation for "plug-ins" - reusable
components that can be connected to a base "bot" class, sharable in either
code or binary form. The framework deals with enabling plugins to subscribe
to SDK events and callbacks and their delivery to appropriate components
when they arrive. Additional base class methods open up the plugins (and the
base "bot" class in the framework) to the SDK methods whilst still
protecting the operation of the framework.

This "plug-in" framework enables all manner of components to be created
ranging from the simple (for example, a plug-in for handling the bot's
avatar in the world, logging chat messages, etc.) to the more complex
(Demeter, game controllers, property managers, etc.). Plug-ins can use their
own plug-ins within them and they can be extensible, enabling people to
build on top of existing functionality by subclassing the plug-in.

The prototype isn't ready for public consumption - I'm hoping to have plenty
of examples and documentation before I throw the code up to be shot at - and
it only exists in .NET 2.0 at the moment (the concept was inspired in the
first place by delegates, although the idea of using delegates in the
implementation was discarded after the first prototype).

Most SDK applications spend 95% of the time doing nothing and often multiple
bot instances are running simultaneously, picking up the same events and
callbacks.

The reason for the (longer than I'd planned) post, was to see if anyone
wanted to discuss ...

(a) whether this has been tried/implemented before with any success/failure
stories,
(b) the whole "plug-ins" concept and preferences on implementation,
(c) possible target platforms,
(d) whether you think anyone would use it,
(e) anything else.

This is nothing ground breaking, just a concept that seems to work quite
nicely. It may even bridge the gap to "native" SDK development for those
that haven't tried it before. There's a chronic lack of people involved in
SDK development, which is sad.

Any comments welcome, Grims.

On a more constructive note ...

Jun 19, 2006, 6:43am
Before I say this, I want to make sure that its not read as an argument for
..NET.

JerMe makes an important point here, and one that needs to be followed for
this to satisfy the initials goals of (a) bridging that gap to make the SDK
more accesible and hopefully bringing more people into SDK development, (b)
encouraging working functional component code to be shared based on a common
framework (with an obvious code conversion required to change plaform) and
(c) give us all something new to talk about.

I'm working in C# at the moment because its the best language for me to
rattle out prototype code and I can concentrate on what the framework's
doing rather than getting my head all stuffed up with another language's
syntax. With the skills avilable in this group, there shouldn't be any
reason that its not ultimately available on ANY platform. Having said that,
I don't know the bounds and capabilities of pure ANSI C++, and I've rarely
used Delphi other than out of curiosity. This is where the members of this
newsgroup come in.

I need to fully prove this to myself, knock out some meaningful examples of
plug-ins to demonstrate it, document them and the framework itself and write
up the prototyping findings (why it does what it does the way it does). This
should give the rest of the group enough ammunition to shoot the idea and/or
it implementation (not me personally please!) into little biddy pieces as
they wish, make more contributions regarding the interface and start to
shape it from ALL our experience, whilst at the same time coming up with
conversions of the code if there's a demand for a specific platform. I won't
be able to do the other platforms justice and being kicked for my efforts in
that respect would detract from building on the framework.

Yes, it needs to be ANSI C++, but it also needs to be .NET (providing the
framework for VB.NET, C# and the latest Delphi's), maybe an MFC-specific
version and perhaps others. I'm hoping this will be driven by everyone here
rather than one individual.

The important thing is that they all work the same way with the same
interface and predictable results. Plugin events need to be fired in the
same order, the same syntax (outside of language syntax) used across
platforms, nothing added to specific platforms that can't be implemented on
other platforms realistically. The only potential barrier I see to this at
the moment is different coding standards for each language, but I'm hoping
this can be wrapped up within each framework impacting the interface. We
would have to define a set of sub-standard (bad phrase I know!) for the
interface that retains reference to the SDK documentation but doesn't
necessarily comply with, for example, recognised language naming
conventions. There's also an issue where a plugin subscribes to a callback,
which may prove something of a headache when it comes to the idea of
self-contained functionality (i.e. a callback subscription in one plugin
makes calls to that respective method asynchronous in all plugins for that
instance). This may need to be addressed via development guidelines or
mandatory plug-in documentation. Who knows? This is a good example of where
everyone can contribute to try to resolve it.

Thanks for bringing this up.

[View Quote]

On a more constructive note ...

Jun 19, 2006, 8:17am
DM,

Thanks for the offer, I've been to the site a few times and have already
considered approaching you when the time was right. Its just an idea at the
moment, and "community" involvement will likely fade away (as ever) over
time. There has to be something a little more concrete to discuss first
(i.e. an initial spec/design as a bear minimum) so that comments and
opinions can be shared, which means me sticking my head out of the trenches.
To do that, I need to have a few things sorted in my own head so that I can
provide a basis for the discussions and be able to adequately articulate my
own position.

Btw, everyone is in a niche of the SDK development "community" right now ...
there's not enough people involved in it anymore for there to be a
"mainstream".

Keep up the good work, Grims.

[View Quote]

On a more constructive note ...

Jun 19, 2006, 8:23am
3.6 features are the only thing I can do on the SDK at the moment without
wasting a lot of time experimenting with features that I know absolutely
nothing about (no documentation for build 60 and the new attributes ya see).
This was the main reason for raising this now (the underlying concepts of
using the SDK haven't really changed much with 4.1), since sadly I can't do
anything with the new toys at present.

Grims.

[View Quote]

On a more constructive note ...

Jun 19, 2006, 7:54pm
TBH, platform isn't really my focus at the moment. I think the important
thing at this stage is identifying solution(s) for the "challenges" I've yet
to solve satisfactorily.

The main problem I have at the moment is routing callbacks to the correct
target. Events have the same problem to an extent, but callbacks are more of
a challenge. It all revolves around different plugins doing the same sort of
thing at the same time - who gets what events and what callbacks without
screwing up the other one. I'm working through this to a degree, but I
assume there must be dependencies within the SDK for ordering of callbacks.

By way of example, in a test application I issued 10 async aw_cell_next()
calls without checking in with the server between them (they all used the
same AW_CELL_ITERATOR value with AW_CELL_COMBINE set to true). These seemed
to come back in order (CELL_BEGIN, n x CELL_OBJECT, CELL_END events followed
by a CELL_RESULT callback - each block intact and sequential with the exact
same results). I know aw_query and aw_query_5x5 prevent more than one query
at a time on a single instance, but does anyone know the rules within the
SDK for methods that don't hold that restriction? Are there any rules? A new
attribute would be useful, which we can set before an async call and it
comes back in the callback (and the events it causes), but we've not got it.
The whole handling of the query events and callbacks is an issue at the
moment.

Any ideas welcome!

[View Quote]

On a more constructive note ...

Jun 19, 2006, 7:57pm
You're probably thinking about managed C++ code in .NET 2.0 (i.e effectively
C++.NET), for which I would expect your comments to hold true.

Grims.

[View Quote]

Prob

Jun 18, 2006, 7:24pm
Assuming you're using .Net 2.0, use the UnmanagedFunctionPointerAttribute
modifier in the delegate prototype. In your code ...

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void d1(int rc);

The problem is that .NET, by default, wants to deal with __stdcall methods
in the DLL, but the methods are exported as __cdecl. The marshalling can
handle the difference on simple method calls (i.e. managed code to unmanaged
code) but the callback comes from the native code in the DLL (unmanaged
code) and so the marshalling doesn't come into play. The above will adapt
the definition of the delegate to fix the exception.

If you're using .Net 1.1, you're pretty much out of luck unless you want
some nasty code in your project (creating an assemply on the fly as part of
the call), or you want to do what I did and wrap up the SDK static link
library in your own Win32 dll that exposes __stdcall methods. Unfortunately,
there's no aw_static.lib available for build 60 right now and intermediating
aw.dll is really a bit messy. Best not to be on .NET 1.1.

Grims

[View Quote]

18 Seconds

Jun 21, 2006, 1:53pm
I don't *think* this is my code ... so I'll ask the question, although it
may seem a bit cryptic.

Does 18 seconds mean anything to anyone? Sometimes (I can't explain when
exactly) aw_wait sits there doing nothing for almost exactly 18 seconds -
always within a few of tenths of a second - after the handler for the last
message has completed processing and it doesn't return back to my main bot
loop.

I put some extra console messages in to work out where it was stopping, and
the problem went away. I take some of them back out, the problem returns! It
can happen on synchronous or asynchronous calls and its DEFINITELY stuck in
aw_wait (I've got markers either side of aw_wait now, so I KNOW its in
pausing there).

Any ideas/comments welcome. My initial assumption was that it was my code
causing the lack of activity, but I'm certain that its not now (not directly
anyway). Its probably worth saying that this has coincided with moving to
build 61. I'll pop it back onto build 60 later and see if it makes any
difference.

Thanks, Grims

18 Seconds

Jun 22, 2006, 5:36am
Build 60 demonstrates the same problem.

The process is showing no activity while its paused and I can still get the
problem after forcing garbage collection (its in .NET 2.0) after each
event/callback. Maybe its an interop issue, but I can't trace it.

I assume this isn't anything anyone's seen before. Perhaps its related to
two other things ...

(a) It takes 2 for aw_init to do its stuff (is this the unpacking?) - I
thought this used to be almost instantaneous.
(b) aw_enter times out about one in five times.

Oh well ... Grims.


[View Quote]

I DESPERATELY NEED YOUR HELP!

Apr 20, 2001, 6:06am
I think that, for some people here, that decision has alread been made!


[View Quote]

18 Seconds

Jun 22, 2006, 7:17am
OK, so it WAS my fault, kinda, although its annoying.

I had a version of the framework that supported kicking off event handlers
in their own background thread but I hit this exact problem then (the magic
number is actually more like 20 seconds, which is how long the SDK seemed to
wait when it hit a conflict) and I had to impement resource locking around
use of the SDK to stop it.

In the interests of keeping it simple, I took all the tread support (and
therefore the locking) out of the code, but this now means that I can't have
a background aw_wait loop thread for the same reasons. I guess I'm looking
at either not having the aw_wait loop in the framework or implementing user
exits in the loop for the bot application to do the things it needs to (like
log in) with the loop running.

Anyway, pointless thread sorry,

Grims

[View Quote]

Missing Bots

Jul 27, 2006, 8:44am
I'm hitting this now. The instance isn't being informed of bots already in
the area when it enters. Other instances (that arrive subsequently) are
reported OK though.


[View Quote]

Installed Events

Jul 13, 2006, 1:15pm
I'll keep this brief - probably my ignorance.

Should I expect ALL events get sent to the SDK session (and update the
associated attributes in the SDK) from the server regardless of whether an
event handler has been installed for a given event?

I assumed that only the requested events were sent - which doesn't appear to
be the case. I guess that most sessions are browsers and interested in all
events, so they're always delivered, but it seems an awful waste of
bandwidth - at both ends. I think I was expecting the server(s) to be a
little more intelligent and take some of the brunt.

Grims.

Installed Events

Jul 18, 2006, 3:53pm
Can anyone confirm this for me please (i.e. whether this is as expected or
if its doing something it shouldn't at the moment).

It may seem like just a matter of semantics and therefore a trivial thing to
bot development, but I've got a working "plugin" framework and there's a
part of it that's dedicated to ensuring that events are not unnecessarily
subscribed (in an attempt avoid unnecessary traffic). If all events are
delivered regardless, I may as well use this fact and just filter the events
within the framework.

Thanks, Grims.

[View Quote]

Debugging

Jul 14, 2006, 7:24am
SDK Build 62 appears to have this restriction removed (no 2 second exec time
on aw_init, stepping through code seems to work fine).

Assuming this wasn't an oversight (in which case it would have come to light
eventually anyway, so don't slap me for pointing it out should they put it
back in for Build 63+), its certainly good to have our development tools
back, and I for one am grateful for that decision!

I've just got to get my hands out of the CTRL-F5 habit now (but I think I'll
wait a while, to see if there's a restricted Build 63 on the way).

Grims.

[View Quote]

SDK 62 Console bot Application Error when closed

Jul 18, 2006, 1:42pm
Can you elaborate on why this is necessary please? In its role of
"terminating" the Activeworlds SDK, its fair to assume that this should shut
up shop gracefully.

Is this a long-term thing or just a stop-gap until build 63? Has the purpose
of aw_term changed now?

Thanks, Grims

[View Quote]

SDK 62 Console bot Application Error when closed

Aug 17, 2006, 7:19am
Hi Mauz,

Is there any chance you could ask the enigmatic Mr Steve to post his
comments in Andras's AW.Bots_And_SDK newsgroup (assuming its not possible to
do so here)? That way we can actively discuss this. I use C# and haven't
experienced a problem with aw_term, so it would be interesting to nail down
the root cause.

Btw ... the aw.dll I'm using is timestamped 12th July 2006 (14:42), but I
will experiment with the 4th August version to see if it solves my other two
issues with Build 62 (no AW_AVATAR_ADD for bot sessions and
AW_EVENT_WORLD_ATTRIBUTES/AW_CALLBACK_ENTER sequencing).

We could really do with an "Announcements" newsgroup or something so that we
can tell when new versions are uploaded (be it correctly numbered or not)
with a change log.

Thanks, Grims.

[View Quote]

AW_CALLBACK_ENTER

Jul 21, 2006, 9:06am
I think there's something wrong with the ordering of the callback/event
handler invokes in the SDK for (at least) aw_enter (BUILD 62).

Following an asynchronous aw_enter method call, first the SDK reports an
AW_CALLBACK_ENTER callback, then an AW_EVENT_WORLD_ATTRIBUTES event. This is
arguably OK (though inconsistent with similar methods), except that the
world attributes are populated for the CALLBACK and NOT set for the event -
with obvious concequences.

This can be recreated by changing one of the world attributes (say,
aw_string_set(AW_WORLD_NAME, "RUBBISH")) in the AW_CALLBACK_ENTER callback
handler. The value of AW_WORLD_NAME will still be "RUBBISH" in the
AW_EVENT_WORLD_ATTRIBUTES event handler, as shown below.

aw_enter
CALLBACK >> AW_CALLBACK_ENTER [RC = 0 RC_SUCCESS]

... etc. etc. etc.


[NOTE: AW_WORLD_NAME set to "RUBBISH" in callback handler]

EVENT >> "AW_EVENT_WORLD_ATTRIBUTES"

I assume from this that the AW_CALLBACK_ENTER callback is simply being
triggered from the SDK, on receipt of the AW_EVENT_WORLD_ATTRIBUTES event
.... but, incorrectly, before the event handler is invoked.

Rather than email directly to AW at the moment, can someone verify whether
this has already been raised in the BETA newsgroup please? I'd expect not
after three versions of the 4.1 SDK having been "released" to date.

Grims.

I DESPERATELY NEED YOUR HELP!

Apr 20, 2001, 6:11am
The speed/type of the connection isn't the issue here ... its the fact that
hosting servers on your connection uses up more of the ISP's available
bandwidth. They've forecast the average home users bandwidth requirements
and priced the at Home package accordingly. You pay more ... for at Work ...
because its a different segment of users ... with higher bandwidth
requirements.

Its their business ... let them run it and charge what they want. If people
don't like that, then they can go elsewhere. Geesh! its only the way the
world works afterall and has done for centuries!

[View Quote]

Wouldn't it be cool if...

Apr 19, 2001, 4:47pm
Am I missing your point here? Where else are you going to change a
background apart from in a world (?) ... and therefore the need to run a
world.

Sorry if I'm being dense. LOL

Grims


[View Quote]

Wouldn't it be cool if...

Apr 19, 2001, 8:50pm
I don't think marcus quite understands (or understood rather) what can be
changed by who in a world, that's all.

At the end of the day marcus, if you want a different backdrop in a world,
override the image in a local path.

Grims


[View Quote]

Wouldn't it be cool if...

Apr 20, 2001, 5:43am
But AlphaWorld is the exception to every paradigm that AW really represents
(my view). A standard set of objects/avatars/textures for everyone to use in
a public world. It may have been the original, but its certainly not the
norm.

Paying your $80 still won't let you change the backdrop in AlphaWorld or any
other public building worlds. Its the right of the worldowner.

In order for AW to implement a "feature" where different areas have their
own backdrops, they would have to be able to define specific regios within
the world dynamically ... and for what? So that someone can change the
backdrop/lighting/etc. around their property without paying their dues.
That's what a world is ... and those attributes are what the worldowner has
control of. Public building only really exists to allow people to play and
chat at the same time. If you're serious about configuring the environent
that your property is in, get a whole world of you're own. You seems to want
the equivalent of the additional features you get the "Pro" version of
software while just paying to use the cheap shareware version.

If you want to do something ... and there's a cost involved, pay the price,
find an alternative or go without. Its a fact of life.

Grims


[View Quote]

Wouldn't it be cool if...

Apr 20, 2001, 9:08pm
LOL ... Dopey.

IT IS A PRODUCT ... NOT A PICK AND MIX !!!


[View Quote]

Wouldn't it be cool if...

Apr 21, 2001, 3:34am
GRRRR .... same old point every damned time.

AW does not exist in order to service AlphaWorld or the other public
building worlds. What proportion of AW's total $1.6 Million income last year
do you think came from $20 annual citizen ships of people who build only in
these worlds? If AW panders to the inane requests of the "customers" that
provide only a minority revenue stream, then they are being diverted from
the real driving forces of their business ... the facilities available to
and developed for those that are prepared to pay. What incentive would there
be for people to move to having their own private worlds if they are given
what they wanted in the public areas?

Also, where's the competitive advantage that AW would gain over anyone else
by pandering to the whims of citizens? Nowhere! There is no ..... Pah! Tell
you what, I'm just going to ignore the thread altogether.




[View Quote]

Attention VB Programmers

Apr 20, 2001, 6:03am
Perhaps if you read one of the gazillions of VB books out there you'd see
(a) why other people buy them and (b) what you can really do with VB. You
don't know how much you don't know ... and you're not going to find out
unless you listen to/read from people who DO know ... hence the existence of
reference/tutorial books.

If you just work it out on your own without the reference material, you're
gonna produce shit. Only a fool would believe otherwise. Its rediculous for
you to say that you don't need a "qualified" teacher on a subject ... be
that a person who knows the RIGHT answers (i.e. a tutor) or a book written
by such a person.




[View Quote]

Help with VB Code

Apr 19, 2001, 4:54pm
Dammit!! LOL


[View Quote]

Help with VB Code

Apr 19, 2001, 4:57pm
Sounds like you've got a global and a local variable/constant of the same
name.

Maybe you declared it as a constant as well in the declarations section of
the form/module??

Grims.


[View Quote]

1  ...  9  10  11  12  13  14  ...  28  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2025. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn