ACScript compatibility

• ac.Version returns a string of the form "SkunkWorks x.yy.zzzz" instead of just "x.yy.zzzz" as ACScript does. This is by design, so your script can tell if it's running under SkunkWorks rather than ACScript.
• Like skapi.MouseMove, ac.MouseMove doesn't work under Win9X unless you're logged in. Stealth scripts that duck-and-cover by logging out when other players appear may not work properly under Win9X for this reason. (Such scripts should work without modification under Win2K/XP however.) See skapi.MouseMove for workaround ideas.
• I couldn't figure out what the difference is between ac.MouseMove and ac.MouseMoveAbs, so I've treated them as synonymous. If somebody knows otherwise, please let me know.
• There are a few names in the ACScript API—specifically ac.Debug, ac.Print, and obj.Type—that can't be defined in VB because they're reserved words in the VB language. The way I get around this is to read in your script, scan it for references to these methods and properties, rename them to ac.Debug_, ac.Print_, and obj.Type_ (with trailing underscores), and then pass the modified script to the scripting engine. In nearly all cases this works transparently and you'll never notice the difference. The only time this might be of concern to you is if you use eval( ) to load and execute script code dynamically at runtime. In that case my script loader won't see the references, and they won't get renamed. If you don't know what I'm talking about here, then you probably aren't doing it and won't have a problem.
• There are a few situations in which WaitEvent mode 1 (ciWaitModeOne) can actually fire more than one event before returning. For instance, the Remove Multiple Enchantments message can fire OnSpellExpire multiple times (once for each enchantment removed) before returning from WaitEvent. The Create Object message can in some cases fire both OnObjectCreate and OnAddToPack before returning.
• The behavior of the OnCombatMode event is somewhat different than in ACScript. As you may know, there is no specific Combat Mode message from the server; instead it's encoded as part of a generalized Animation message. Frankly I couldn't figure out what rule ACScript uses to decide when to fire OnCombatMode as opposed to OnAnimationSelf, but in fact it fires OnCombatMode a lot even in situations where your combat mode status hasn't changed. The rule I adopted to is to fire OnCombatMode only when your combat mode status actually changes, and use OnAnimationSelf for everything else. So you'll see a lot fewer OnCombatMode events when running under SkunkWorks, but hopefully you'll still get all the ones you really need.
• A longstanding strange behavior in ACScript is that entering a portal triggers OnStartPortalSelf followed immediately by OnEndPortalSelf. Exiting a portal triggers OnEndPortalSelf again, so that you actually see two End events for each Start. This seems like a bug to me, so I haven't bothered to emulate it. In SkunkWorks the OnStartPortalSelf and OnEndPortalSelf events are properly paired, with the End event coming (as you'd expect) when you actually exit the portal.
• There was a certain amount of guesswork involved in deciphering the differences between OnTell, OnTellMelee, OnTellServer, and OnTellMisc. I may not be classifying tells precisely the way ACScript does. If you see any discrepancies here, let me know and I'll try to correct them.
• The following ACScript command line options are not supported:

−L	SkunkWorks figures out which scripting language to use from the filename extensions (.js or .vbs).
−E	To disable all event handlers, use skapi.RemoveHandler(evidNil, null).
−S	Width and Height are read from your AC registry settings and cannot be overridden.
−P	Keyboard and mouse functions are always enabled.

Most scripts will not be affected in any meaningful way by these discrepancies. My suggestion is to try yours without modification and see what happens. If something breaks that used to work under ACScript, let me know.