Setup and configuration

Before installing SkunkWorks, please review the requirements to make sure you have everything you need. If you haven't yet installed Decal or updated your scripting engine, do it now.

To install SkunkWorks, first stop Decal if it's running by right-clicking the Decal Agent icon in the system tray (in the lower right corner by the clock) and choosing Exit. Then run the SkunkWorks.msi installation package by double-clicking on it, or by right-clicking and choosing Install. Reboot if you are asked to do so.

When setup has finished, run the SkunkWorks console from Start 4 Programs 4 SkunkWorks 4 Console. The first time you run it, you may be asked if you want to regenerate message crackers.

Regenerating message crackers

SkunkWorks uses Decal's Messages.xml for message decoding, but not in the way you might think. The usual use of Messages.xml is to interpret it at runtime, as the messages arrive, looking up the message type and walking the XML tree of field definitions to extract the desired data. My concern was that this might not perform well enough for the volume of decoding required for a full-featured macro platform. ACScript veterans will recall the problems many users had with slow message processing, especially under Win9X. I wanted to avoid a repetition of those problems in SkunkWorks if at all possible.

So what I've done instead is to develop a scheme in which Messages.xml is translated at compile time into VB message-cracking functions with efficiency approaching that of hand-written code. This helps to insulate SkunkWorks from protocol changes while still retaining the high performance of hand-coded crackers. The downside is that if the protocol does change, message crackers must be regenerated and Skapi.dll must be rebuilt.

This is one of the reasons for distributing the SkunkWorks source. With the source and a VB compiler, you're all set: you can regenerate crackers and rebuild Skapi.dll yourself in case of a protocol change. Instructions for doing so follow. If you don't have VB installed, these instructions don't apply to you, and you can skip ahead to What happens on patch day? if you like.

Each time you start the SkunkWorks console, it checks your version of Messages.xml against the version it was compiled with. If your version is newer (and you have VB installed), it asks if you want to regenerate message crackers using the newer Messages.xml. (If this starts to annoy you, you can disable the version check using the "Don't ask again" checkbox on the dialog.)

If you choose No (or if you've disabled the version check), you can always regenerate crackers later using the Regen Crackers command from the Configure menu.

If you choose Yes, here's what happens:

SkunkWorks uses a transform called GenCrackers.xsl to merge Messages.xml with a set of cracker definitions called MessageCrackers.xml. While this is going on you'll see a lot of VB source code flash by on screen, just to let you know that something is happening. It then writes the result to a file called MessageCrackers.bas in the SkunkWorks\Source folder, overwriting the previous contents of that file. (So if you're tinkering with the message cracking logic for any reason, make your changes to MessageCrackers.xml, not MessageCrackers.bas, if you want them to stick.)
You'll then see a message box telling you that crackers have been regenerated and SkunkWorks is about to exit. Click OK to continue.
If you have SkunkWorks.vbp open in Visual Basic, close it. This is so that the copy of MessageCrackers.bas loaded into VB's memory gets refreshed. If you forget to do this, VB won't notice that the crackers have changed and you'll keep getting prompted to regenerate.
Open SkunkWorks.vbp in Visual Basic and choose Make Skapi.dll... from VB's File menu to recompile the regenerated crackers.
Restart SkunkWorks from the Windows Start Menu or, if you want to debug, by clicking the 4 button on the VB toolbar.

What happens on patch day?

Like many third-party AC tools, SkunkWorks is vulnerable to breakage by the monthly patch. The most likely problem is changes to memory locations that Decal and/or SkunkWorks depend on. Symptoms of this sort of breakage include inability to select items using skapi.SelectAco or ac.SetPreviousSelectedObject, failure to track the mouse on Win9X, and so forth. SkunkWorks uses Decal's Memlocs.xml for these functions, so the best solution is to wait for a new version of this file to be released (this usually happens fairly quickly) and download it using Decal's automatic update feature.

A more serious but less likely sort of failure happens when AC's communications protocol changes in such a way that SkunkWorks can no longer make sense of one or more packet types. Symptoms of this sort of failure include events not firing when they're supposed to, or passing nonsensical parameter values to event handlers in your script. In severe cases, character and inventory information may be confused as well.

SkunkWorks gets its protocol information from Decal's Messages.xml, so downloading a new version of this file is the first step in solving protocol problems. Two things you need to be aware of, though:

Because protocol changes can be subtle, it may take the Decal community a few days to figure out what changed and issue a new version of Messages.xml.
Because SkunkWorks reads Messages.xml at compile time, not at runtime, fixing protocol problems entails rebuilding Skapi.dll. If you have a Visual Basic compiler installed, you can do this yourself as described in Regenerating message crackers as soon as the new Messages.xml becomes available. If not, you'll have to wait a bit longer for someone else (like me) to post a rebuilt executable.