Kitserver 2010 Manual

Manual For Kitserver to use in PES 2010

Version history: history.txt

October 15, 2009 – Kitserver 9.0.0 – “First-Blin-Komom” release

1. Introduction

Add-on program for Pro Evolution Soccer 2010 (and Pro Evolution Soccer 2010 DEMO) is an Kitserver 2010. It is a loader and manager for various modules.
Below is a quick summary of the available features.To get more details about a particular module follow the link in the left column.

AFS2FS 9.0.0	afs2fs.dll	Manage AFS (.img) game content using files and folders: much easier and quicker to install/remove patches, without the need modify *.img files

2. Installation / Removal

As with previous version of Kitserver, you have to unpack the archive to your PES installation folder. It should look like this:

Then go to kitserver folder and run the setup.exe. Select the game executable (it should already be preselected) and click “Install”. What this does is it “attaches” the kitserver to the game: now whenever you start the game, the Kitserver DLLs will be loaded into memory. If you decide that you don’t want to use Kitserver any longer, run setup.exe again and click “Remove”, and it will detach the kitserver from the game EXE.

2.1. Advanced usage of setup.exe

The kitserver setup.exe program can also be run without GUI – in a so-called batch or command-line mode. This can be useful, if kitserver is part of a bigger patch, which contains an installer, and typically the last step of the installer is to attach kitserver to the game EXE file. This can be accomplished by running the setup like this:

setup –install –gfile={game-exe} –sfile={settings-exe}
setup –remove –gfile={game-exe} –sfile={settings-exe}

Example:

setup –install –gfile=..\pes2010.exe –sfile=..\settings.exe

3. Usage and configuration

3.1. Main configuration file: config.txt

In the kitserver folder, there is the program’s main configuration file – config.txt. This is where you would need to make changes to enable/disable individual modules (DLLs), and/or configure module settings.

Here’s how my config.txt looks like:

[afs2fs]
debug = 1
img.dir = "c:\mypesfiles\root1"

[kload]
dll = afsio.dll
dll = afs2fs.dll

Each module can have its own configuration section, which starts with [module-name], and typically has one or more options following it. Now, normally you wouldn’t need to modify config.txt file, except for the cases, when you need to modify the behaviour of a particular module (DLL), or enable/disable such DLL.

To disable a particular module – just comment out the corresponding line in the [kload] section by putting a ‘#’ symbol at the beginning. (Or you can delete that line altogether.)

The order of the DLLs is important. In particular: zlib1.dll, libpng13.dll, afsio.dll must be loaded in that order before kserv.dll; afs2fs.dll after kserv.dll. Only in very rare situations you should try re-arranging the DLLs.

Top

5. AFS2FS Module (afs2fs.dll)

This module allows to organize your BIN-files into folders on disk, instead of inserting them into AFS(*.img) files, which is sometimes a pain, and may require a lot of extra disk space.

Several people over the last few years had suggested similar solutions, but ultimately it was Str@teG who kept talking about this idea of organizing BINs into folders, and eventually i decided to just go ahead and do it. So now this is realized in the this module – afs2fs.dll. From personal experience, i know that people are sometimes reluctant to install big patches that require an AFS-rebuild, not because it’s particularly difficult or anything, but because it can be time-consuming and disk-space-hungry. With afs2fs, this is now very easy: you just put the BIN into correct folder and that’s it. And, of course, there are no size constraints – the bins can be as large as needed!

The module is also handy, when you want to try a patch without risking totally destroying the content that you already have. Putting a new patch into a separate AFS-root and modifying config.txt is all you need to get it going. Removal as easy too: delete the correspoding “img.dir” line in config.txt, and then delete the AFS-root folder. Multiple patches is no longer a management nightmare . (See more info on AFS-roots in the sections below)

5.1. How to set up the folders

Start by choosing a location where you would be putting your files. For example, let’s take c:\mypesfiles\root1. This will be your so-called AFS-root. Inside that folder, create a folder called img. (This is very important that you have the folder named “img”, since the game relies on particular names). Then, inside img, create folders, as needed, named – dt00.img, dt01.img, dt0b.img, and so for. That’s where you’re going to be putting the BIN-files.

It’s important to name the folders correctly: a folder must have exactly the same name as the corresponding AFS-file. For instance, if you call a folder dt00, instead of dt00.img, things will not work.

This is how my folder looks:

5.2. How to name the files

In general, you can name the files whichever way you want, but you must follow one rule: there must be a BIN number in the name, and it must be preceded by an underscore character (‘_’). Also, the filenames CANNOT be longer than 63 characters.

Examples of correctly named files:

unknown_317.bin
goalnet_41.bin
ball_9.bin
unknow_9 (.bin extension is optional)
music_11.adx (a file can have a different extension: .adx is typically used for music and sound files)

Examples of incorrectly named files:

unnamed10.bin – no underscore symbol before the BIN number.
face.bin – no BIN number.

5.3. AFS roots

By default, the AFS2FS module will not search any “special” default paths. Instead you must specify your AFS roots explicitly: In [afs2fs] section of config.txt, you can speficy the location of your root, which can be anywhere on your hard disk. You can also have multiple roots, which is very useful if you have several patches, and you don’t want to lose track of which BINs came from which patches (so that you can easily uninstall a patch by just deleting its root folder).

Here is an example with 3 different roots are configured:

[afs2fs]
img.dir = "c:\mypesfiles\root1"
img.dir = "patch-RPL"
img.dir = "afs-root3"

The order of the roots is significant, when it comes to resolving “collisions”. Say, you have a dt0b.img/ball_9.bin in the second root (patch-RPL), and dt0b.img/superball_9.bin in the third root (afs-root3). Even though the files are actually named differently, they intend to replace the same BIN – #9 from dt0b.img, and therefore we have a “collision”. The rule is simple: the lower root in the list wins. Which means that in this situation, the dt0b.img/superball_9.bin file will be used, since its root is listed last in the [afs2fs] section.

Remember this is IMPORTANT: The root is the folder that contains “img”, not the “img” folder itself. In other words, if the full pathname is c:\mypesfiles\root1\img”, then in the config.txt you should have: img.dir = “c:\mypesfiles\root1″

Credits

Programming: juce and Robbie

“read more”

And here is the rest of it