Board ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
grimble // User Search
grimble // User SearchSDK Developers : Pissed OffJun 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 OffJun 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 OffJun 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] ProbJun 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 SecondsJun 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 SecondsJun 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
18 SecondsJun 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 BotsJul 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 EventsJul 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 EventsJul 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] DebuggingJul 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 closedJul 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 closedAug 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_ENTERJul 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
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 ProgrammersApr 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 CodeApr 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] |