COM interface

You don't have to use the SkunkWorks console to run your script. You don't even have to write your macro in script. SkunkWorks exposes a COM interface that you can access directly from any COM-capable programming environment such as Visual C++, Visual Basic, Delphi, etc. Any place you can host a COM object—even a Web page—you can use as a platform for building your macro.

Of course by bypassing the console you give up such prefabbed console amenities as the Stop button and the in-game miniconsole. You also lose the ability to use script libraries such as ACScriptLib or SkunkNav in your macro. If you want such features, you'll have to build them into your app yourself. On the plus side, you'll have the full power of industrial-strength programming tools at your disposal to do it with.

All of the SkunkWorks API services are accessed through the skapi object, which has the progid SkunkWorks.SkapiCls. So for instance in Visual Basic you would do something like this:

Dim skapi As SkunkWorks.SkapiCls
Set skapi = New SkunkWorks.SkapiCls

or alternatively:

Dim skapi As Object
Set skapi = CreateObject("SkunkWorks.SkapiCls")

the first example being preferable for performance reasons (early binding v. late binding).

When using the COM interface you have the option of receiving game events either by creating and registering event handlers using skapi.AddHandler, or by sinking COM-style events from skapi.skev. So for instance to receive the OnLogon event from skapi.skev (again using VB as an example) you would do:

Dim WithEvents skev As SkunkWorks.SkevCls
Set skev = skapi.skev

Private Sub skev_OnLogon(ByVal acoChar As SkunkWorks.AcoCls)
' Your code here.
End Sub

The details of instantiating COM objects and sinking events from them in other languages obviously depend on the language. I'm going to assume you know how to do it (or where to look it up) in the language you're using.

For best results you should start your app and instantiate the skapi before starting the game, or very soon after. You should also call skapi.WaitEvent frequently (preferably several times a second), starting from the moment you first instantiate the skapi, to keep the skapi's game state up to date and to keep the event queue from overflowing. The SkunkWorks filter will queue events for you up to a point, but if you let the queue overflow, you'll lose login and inventory information.

You'll also lose information if you stop your app and destroy your skapi in mid-game. No game state is stored in the filter; it's all in the skapi. So your skapi must remain continuously in existence while the game is running in order to have valid state. If you must stop and restart your app, e.g. for debugging purposes, be sure to log out of the game and back in again after restarting in order to refresh the game state.

Note also that if the filter finds no skapi running when the game starts, it will autolaunch the SkunkWorks console. Since in the current implementation no more than one skapi at a time can connect to the filter, this would prevent your app from connecting if you start it later.

You can disable this autolaunch feature by creating the following registry value:

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\SkunkWorks\Settings]
"Console"=""

To have the filter autolaunch your app in place of the default SkunkWorks console, do something like this instead:

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\SkunkWorks\Settings]
"Console"="\"C:\\MyDir\\MyApp.exe\" <args>"

with (obviously) the actual path and filename of your app, along with any command-line arguments it takes.

To restore the default autolaunch behavior, delete the Console registry value.

The foregoing assumes that you're building a standalone COM app to run with SkunkWorks. But that's not the only way to use the COM interface. You can also write SkunkWorks-aware ActiveX DLLs (COM components) that can be instantiated and used from within a SkunkWorks script. In that case, you do not want to instantiate your own skapi, because there will already be one in existence, and you can't create more than one. What you need in that case is a way to get a reference to that pre-existing skapi. You can do this by creating an instance of SkunkWorks.GetSkapiCls and using it to retrieve a reference to the skapi. In Visual Basic this looks like this:

The skapi object gives access to the native SkunkWorks API. The native API should provide everything you need, but if for some reason you prefer to use the ACScript API, you can do so as follows (again using Visual Basic as an example):

Dim ac As Object, Inventory As Object, Width As Long, Height As Long
Set ac = skapi.ac
Set Inventory = skapi.Inventory
Width = skapi.dxpRes
Height = skapi.dypRes

This sets up the familiar ac and Inventory objects as well as the Width and Height globals. (The SkunkWorks console does this for you automatically when starting a script.) References to ac.KeyEvent, Inventory.GetItem, and so forth now work as expected, with a few exceptions:

• Neither ac.RegisterHandler nor the automatic registration of ACMsg_* handlers will work in this mode. Since this is a pure COM interface, you need to package your event handlers up in a COM object, and register it explicitly using skapi.AddHandler.
• You should also be aware that for stupid technical reasons, I had to change a few names in the ACScript API. Specifically, ac.Print, ac.Debug, and obj.Type are now called ac.Print_, ac.Debug_, and obj.Type_ (with trailing underscores). The SkunkWorks console handles this translation transparently, but if you're bypassing the console to access the COM interface directly, you'll have to do the renames yourself.
• Finally, since you're running without a console, any output sent to ac.Print_ will land in the bit bucket. Use skapi.OutputSz(..., opmChatWnd) instead to direct output to the in-game chat window.

Note that all of these quirks can be avoided by simply ignoring the ACScript API and coding directly to the native SkunkWorks API in the first place.