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:

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: