From Worms Knowledge Base
|Latest version:||184.108.40.206 / 20 October 2012|
|Supported games:||W:A, WWP, W2|
|Supported W:A version:||All versions|
WormKitDS is a custom version of WormKit. Its main purpose is to make the usual way of loading WormKit modules (via external program) obsolete. Now WormKit.exe is not needed anymore, WA.exe will load modules itself!
- 1 General purpose
- 2 How does it work
- 3 WormKitDS FAQ
- 3.1 You say that this is a new WormKit, but why do I see something like "dsound.dll"?
- 3.2 Will it affect the stability of modules somehow?
- 3.3 Will this way work under Wine?
- 3.4 Will this way work under Steam version of W:A?
- 3.5 Will this allow me to watch replays, to do stuff with them or to use WebSnoop?
- 3.6 Can I temporarily disable WormKitDS?
- 3.7 Oh, and what if I run my old WormKit.exe while having a new WormKitDS?
- 3.8 When I run the game, a message "This module is no more needed..." pops up!
- 3.9 When I run the game, a message "Bad module: ..." pops up!
- 3.10 Now I got the intro screen again! How can I get rid of it?
- 3.11 Will this way work for WWP or Worms 2?
- 3.12 How can I delete WormKitDS?
- 3.13 The FkeyRearrange module shows me an error that it can't find its config file. I'm using The Wheat Snooper
- 4 See also
The general purpose of WormKitDS is to switch back to WA.exe while keeping to load WormKit modules. Why? Some programs are used to specific EXE files, so old WormKit, being a temporary process, didn't have its full power sometimes. Second, all replay and URL associations were belong to WA.exe, and not WormKit.exe, which caused troubles while working with replays of RubberWorm games, for example. So you don't need wkPathOverride anymore. And third, this will also allow you to run WormKit modules under the Steam version of W:A. Some modules will work on Wine as well, whereas the original WormKit.exe wouldn't work properly.
How does it work
Once all files are in place, start WA. It will then load the primarily required DLL files and WormKitDS. WormKitDS itself is a DLL file named "dsound.dll", which consists of a module loader and a loader of the original dsound.dll from system32 folder. By default, WA loads dsound.dll on the start, and if the file is placed in the WA's folder, then the priority will be given to it. After WA loads dsound.dll, the WormKit modules and the original system32's dsound.dll will be loaded too.
You say that this is a new WormKit, but why do I see something like "dsound.dll"?
To make WA loading modules itself, a DLL file which had the same name as one of the WA's required DLLs was needed. Usually this file is located in system32 folder, but here it's also used as a module loader.
Will it affect the stability of modules somehow?
Will this way work under Wine?
Partially. As it's known for now, modules (such as RubberWorm or Project X) which don't use Windows APIs, will work under Wine. But first you need to make some changes into winecfg to use a "native" dsound.dll instead of "integrated".
It is the madCHook library that has some incompatibilities with Wine, CyberShadow has started a rewrite of it to further support Wine, here is the current file and source code. Note that it's still unfinished and is written on Delphi, but any contribution to the project will be appreciated.
Also, as it was reported by Muzer, the latest versions of Wine seem to fully support the current madCHook, but this information isn't confirmed yet.
Will this way work under Steam version of W:A?
Yes, however the game-dependent modules have to be compatible with the game version it uses.
Will this allow me to watch replays, to do stuff with them or to use WebSnoop?
Yes, but you should use the installer, because it associates replays and URLs back to WA.exe (in case you messed the associations up).
Can I temporarily disable WormKitDS?
Yes, you need to run WA.exe with /nowk command-line parameter. You may also make a shortcut: edit your WA.exe shortcut to adjust /nowk to the end of path (after the last quotation mark), prefixing it with a space.
If you used the installer, then just navigate to WA's executable/shortcut, then hold Shift and right-click it; the option "Run WA without WormKit" will appear. To play a replay without WormKit, just right-click it and choose the corresponding option.
Oh, and what if I run my old WormKit.exe while having a new WormKitDS?
Nothing. The priority is given only to the one. The installer deletes WormKit.exe and edits registry back to WA.exe.
When I run the game, a message "This module is no more needed..." pops up!
Please delete wkPathOverride.
When I run the game, a message "Bad module: ..." pops up!
This message means that the current WormKit module is corrupted, has an unappropriate function in its code or doesn't seem to be a valid module. Consult the module developer.
Now I got the intro screen again! How can I get rid of it?
This may happen because the original WormKit forces disabling intro screens on start, and the feature "Skip Intro" of the Advanced Options hadn't been enabled. You can enable it there or import the tweak "SkipIntro_On.reg" from the /Tweaks/ folder of W:A. The installer cares about it automatically, so this may only concern people who chose to copy the files manually.
Will this way work for WWP or Worms 2?
Yes, the loader will work, but most of WormKit modules are written specifically to work with W:A code only. wkColorFix is an example of an universal module which works on every application.
How can I delete WormKitDS?
Removing dsound.dll from your WA folder is pretty enough.
The FkeyRearrange module shows me an error that it can't find its config file. I'm using The Wheat Snooper
When joining or hosting games, The Wheat Snooper doesn't care about changing the working directory to the WA's directory, it just uses its own. This can cause the modules not to find their configuration files, if there are some (this doesn't affect Kawoosh's modules). WormKitDS doesn't force using the WA's directory as a working directory, its main purpose is transparency and portability. Hopefully this issue will be fixed in the future The Wheat Snooper's releases.
The latest version of the installer fixes this problem as well. But it would be better if modules, that are connected to their configuration files, would search for them in the WA directory, and not the "current" directory. The same concerns The Wheat Snooper.