Greetings,

It's been a while. I try not to bug developers knowing their time is very valuable, so without wasting too much, I do take the opportunity of posting to thank them, since it is rare, but worthy.

Thank you Cameron for the continued availability of the forums, and thank you Greg for maintaining Skunkworks. Thank you very much.


I would like to add the ability of my multi-toon (they login and logout as needed for portals) buff / portal program to remember the number of players connected at most recent login/logoff. I've read a bunch of stuff on the subject over the course of months, know the packet message type to look for, but can't find a corresponding Skunkworks event to use. I've read the source for population filter and it makes use of the decal.adapter which, when I try to add to VS 2003/vb.net as a reference, get an invalid assembly message. Is this because I'm behind a rev (to VS 2005)?

I thought, and briefly tried, adding references to Decal, using ServerDispatch, messing with other stuff that I think at this point a Decal developer would probably cringe if he/she saw what I was doing. Last thing I want to do is code incorrectly, around precautions many smarter people have taken to prevent me from doing something like this. Second to last thing I wanted to do was post the question.

Is there a way to extract this value in Skunkworks only? I dont have any filters checked aside from Skunkworks, don't use a GUI, don't initialize a plugin, nothing fancy. I would be grateful for any help.

Thanks!

OnRawServerMessage is the generic catch-all event for cases where there isn't a more specific SkunkWorks event. You'll have to do the message decoding yourself, as described in the SkunkWorks docs.

Questions about how to code for Decal should be posted in the Decal development forum.

Thank you for your prompt reply.

I'm very sorry, I should have mentioned that. I would have happily used that, using the bitmasks recommended in your documentation as you suggest, but for the life of me, I cannot find the OnRawServerMessage event in the VS environment. I looked in Object Browser, I tried by auto-fill in, it eludes me, and at this point would be more than willing to concede I am missing something simple.

I'm confused. What does VS have to do with it? When you said "nothing fancy" I assumed you're writing a typical SkunkWorks script in one of the supported scripting languages (e.g. VBScript or JScript), and that all the VS talk had to do with some experiment you'd done with Decal plugins.

In any case I'm not surprised the event doesn't show up in the VS object browser, since it's called using late-binding COM calls (i.e. the method name is looked up at runtime rather than compile time) as is usual for scripting languages.

Maybe if you went into more detail about what kind of program you're writing (SkunkWorks script, SkunkWorks COM DLL, Decal plugin, or what have you) and what language you're coding in, I might be able to give more specific advice.

Absolutely and sorry for the confusion.

I've never written what I thought was any script, don't know how to use "JScript" and would be inadvertently coding VBScript if that turns out to be the case. I fire up Visual Studio 2003 which installed when I installed Visual Basic.net.

I created a new blank solution, new project, created a main form to enter MySQL credentials, and use the VB.Net connector to query a MySQL server for character info (which toon to login for which portal requested).

The startup option is a Sub Main, and I use Explicit and Strict on.

I declare a skapi variable As New SkunkWorks.SkapiCls and the skev as WithEvents skev As SkunkWorks.SkevCls = skapi.skev.

I call skapi.WaitEvent(0) when no handlers are in action in a default outer loop.

The end result is a compiled .exe I created a shortcut to on my desktop that, once provided MySQL credentials will bring up the AC launcher, fill in details, wait for the skapi.plig to change, then loop thru skapi.rgszChar(i) to fill a combo-box with char names.

I use Mouse commands to log characters in at the launcher screen. I use OnLogon, OnEnd3D, and OnEndPortalSelf to control character state.

When I run the program on different machine, I copy the entire working directory and just create another shortcut to the .exe located in the /bin subdirectory. I'm not sure what else to call it other than a program since the by-product is an executable.

In game, the Decal bar is empty, there is no interface to interact with the program. Any changes require a logout, client shutdown, and recompile. Debugging requires setting breakpoints, alt-tabbing, and hoping I return before the Skunkworks event queue fills.

The late-binding explains to me the lack of the event in Object Browser. I wish I could say I knew more about coding for COM, creating DLL's, or making a real Decal app with a GUI, but I don't. I feel the approach would be called a simple one by more competent developers.

OK, I get the picture now. What you've written is what's called "a standalone COM app to run with SkunkWorks" in the COM API section of the SkunkWorks docs. While this does work (obviously) and is a supported use of SkunkWorks, it's probably the least common and least recommended way to use SkunkWorks, mainly for the reasons you've cited: no in-game miniconsole, no Stop button, and you have to log out and recompile every time you make a change.

If you want to continue down that path, you can. In order to receive late-binding events, you'll need to define a COM class with a public method called OnRawServerMessage, and pass an instance of that class to skapi.AddHandler per the SkunkWorks docs. I don't recall the precise steps needed to define a COM class in VB 2003; refer to your VB documentation for that. (In VB 2005, there's a checkbox under Assembly Info to "Make assembly COM-visible".)

However once you've figured out how to do that, you may find it easier to wrap your entire program in a COM class that you can instantiate and call from script. Then you don't need a separate executable that you start before logging in; you can start and stop it from the SkunkWorks console (or in-game miniconsole) the same way you'd start any SkunkWorks script. See the COM API section of the docs for more info on this option.

If you're not clear on what I mean by script, I mean simply a text file written in (for example) JScript or VBScript that can be executed directly, without compilation, by the Windows script interpreter. This is the same interpreter that's called from IE to execute script found in web pages. But you don't need to create a web page to write script. Windows can execute script files directly from a command prompt, and the SkunkWorks console can execute script written to the SkunkWorks API (that's what the console is for). The Libraries folder of your SkunkWorks installation contains a number of sample scripts in both VBScript and JScript. Coding in script is by far the most common way to use SkunkWorks, because you don't need any programming tools other than a text editor, and you can stop, edit, and restart a script from the in-game miniconsole without having to log out or recompile. Links to the Windows Script documentation can be found in the Links section of the SkunkWorks docs.

And just FYI, writing a Decal plugin is a whole different kettle of fish. Decal plugins are DLLs that satisfy a specific interface and execute within the ACClient process. They're not standalone executables like the one you're writing. So adding Decal references to your EXE project won't magically give you access to Decal events and APIs, since the suppliers of those APIs won't be present in your process.

Least common and least recommended sounds par for the course for me. I like breakpoints? It's not so bad a procedure once you get used to it, logging in and out.

Option Strict Off it is then, crash course in late binding and reflection. So much to learn.

The only advantage I can think of for ease of starting and stopping would be if I ran multiple scripts or changed them frequently.. I think. This one is designed to run for days and the debug and development cycle, even tho it might sound odd, just seems like it would be easier out of game. I'm not sure I'd be able to attain the level of debug I'm used to if I go the route of putting the whole thing (15 or so separate classes, 216kb .exe) in a COM class. I'm still working up to text editor or mini-console code. I actually do like the auto-fill, indent, highlight, etc. of Visual Studio.

> Links to the Windows Script documentation can be found in the Links section of the SkunkWorks docs.

I do sincerely appreciate your effort to not only offer crystal clear advice but include relevant documentation all along the way. I will have to familiarize myself with the script interpreter. I'm always opting compilation for performance, but really can't speak to the performance of the methods you mention as I've not used them.

I think we'll leave the fish in the kettle for now, adding and subsequently removing a reference to the swfilter was enough of a reminder for me to do one thing at a time.

Got what I was after, am off to put it in production code, can't thank ya enough. Do take care sir.

As far as debugging goes, you can attach a VS debugger to a script-hosting process (such as SWConsole) and set breakpoints in the script code.

Even with the COM DLL method, it should be possible to attach a debugger to SWConsole and set breakpoints in your compiled DLL code.

Regarding performance, obviously compiled code will be faster than interpreted code. But I've found script performance to be more than adequate for most character automation tasks (shopping, crafting, salvaging, navigation, etc). I don't do combat macroing so I can't speak to that. But for building a large, complex automation system (tens of thousands of lines of code), I find that the convenience of script trumps the performance advantages of compiled code and really speeds development time.

But if you're happy with the way you're doing it, don't let me talk you out of it.