KitServer 5.1 Manual

1. Introduction

Kitserver 5.1 is an add-on program for Pro Evolution Soccer 5. It provides the alternative way of managing players and goalkeeper kits outside of the game's AFS file: you organize the PNG or BMP kit images into an external database, which is basically a collection of folders and files that follows few simple rules. You are not restricted to just 1st and 2nd kit for each team - you can have as many as you like.

2. Quick summary of the features

3. Installation

As usual: copy the entire kitserver folder into your game folder, so that the directory structure looks like this:

Go to kitserver folder and run setup.exe. The "PES5.exe" in the drop-down list should be pre-selected, so just press "Install" button. The kitserver should show a message box saying that the installation was successful. (If you get an error message, make sure that you not currently running the game, and that the PES5.exe file is not marked as read-only)

4. Removal

Go to kitserver folder and run setup.exe. The "PES5.exe" in the drop-down list should be pre-selected. (Select it, if not so). Press "Remove" button. The kitserver should show a message box saying that the uninstallation was successful. You can now delete the whole kitserver folder, if you want. (Or you can leave it there - it won't do any harm, and you'll be able to quickly re-enable kitserver later, if you run setup again and press "Install" button.)

5. GDB organization

So we start with the GDB, as the most drammatic change of way kitserver works (compared to version 5.0). The GDB contains a folder named uni, which is responsible for storing the team kits (uniforms). The single most important file inside uni is called map.txt. This file tells kitserver where to find the kits for particular team. As you know, each team has a unique id - a integer number from 0 to 203, i think (+ some extra all-star teams). So for every team in the GDB, you must specify in the map.txt, where the kits are for this team. Here is an example:

# This config maps team number into folder name
# Format: ,""
# Example: 21,"Russia"

8,"National\France"
9,"National\Germany"
65,"EPL\Aston_Villa"
75,"EPL\Man Utd"
77,"EPL\Newcastle"
80,"EPL\Tottenham"
170,"La Liga\Real Madrid"

Please note that the sample GDB (provided with kitserver) is just one possible way of organizing the teams and folders. It uses "EPL" folder to group all english teams, "National" - to group all national teams, and so for. You may find that you just prefer a flat list of folders - without these extra groups. In that case, just modify the map.txt file accordingly, and create the structure of folders that you prefer. That's the main advantage of having map.txt - the flexibility of kit organizaiton.

You can see from map.txt above that in order to find a kit for team #8, the kitserver needs to go to the folder GDB\uni\National\France. This folder will contain all of the kits that are available to team #8. Inside it, you must create an individual folder for each kit. Like this: For players, 1st kit must have a folder name pa, 2nd - pb. Extra kits can have any folder names that start with letter "p". I found it useful to prefix all extra kits with px-. For example, px-blue. For the goalkeepers, 1st kit must be in the folder ga, 2nd - in the gb. Extra kits (though not implemented yet) can have any folder names that start with letter "g".

Now let's move on inside one of the kit folders. Take pa, for example. This is how you folder will look, if you have a so-called "all-in-one" kit, meaning that it's not split into separate parts: shirt, shorts, and socks. Kitserver can succesfully work with split kits and all-in-one kits, as it would automatically split the all-in-one kit at runtime. The only time when split kit is really required, is when the splitting rules are nonstandard: like the Juventus goalkeeper kit with two differently colored socks. Also you may want to use split kits, when you don't have all the parts. For example, see Newcastle's px-away2 folder: it doesn't have the all.png, but instead contains shorts.png and socks.png. Notice that there is no shirt.png in there, which is totally fine: the kitserver will just use the shorts and socks, and take a shirt from a different folder.

So, to summarize:
Having the all.png is equivalent to having these three: shirt.png, shorts.png, and socks.png. (Generally, you shouldn't have all four of them, or all.png and say shirt.png - this will quickly become confusing.)

5.1. config.txt

This is the attribute configuration file (in previous Kitservers it was called "attrib.cfg"). As before, it is just a plain text file - you can use Notepad or any other text editor to view or modify it. For each folder that has a shirt in it (either as part of all-in-one kit, or as separate image) should have a config.txt file in it. A "shirtless" kit doesn't need a config.txt, as it will be ignored, because the attribute configuration is tied to a particular shirt.

Here's the summary table of all the supported attributes:

For examples of shorts.num-pal.X usage - study the sample GDB: it contains many different examples. Initially this may look too complicated; however, after a bit of time, it will become clear why this kind of organization was needed: In order to be able to freely mix the parts of the kits, you need to be able to specify what sort of numbers and palettes shold be used on shorts in many different situations. For example, consider the config.txt from Germany "pa" folder:

model = 37
collar = no

numbers = "..\..\adidas_black.png"

shorts.num-pal.pa = "..\..\adidas_white.png"
shorts.num-pal.pb = "..\..\adidas_black.png"

What this means in plain English is this:
For the shirt use Adidas numbers (black). When this shirt is used with "pa" shorts, then apply palette file "adidas_white.png", which effectively renders white numbers on the shorts. When this shirt is used with "pb" shorts, then apply palette file "adidas_black.png", which results in black numbers being drawn on the shorts.

6. Strip Selection and 2.5D kits

In order to provide a visual reference for currently selected GDB kits (including extra kits), these so-called "2.5D" kits are overlayed on top of the KONAMIs mini-kits. The name originated from the fact that these are 2Dkits, but they are built with the real textures that are used in the match. Here's a screenshot: (When the team doesn't have the kits in GDB, the original KONAMI mini-kits will still be visible.)

You can switch between 1st/2nd kits as before - using your keyboard or gamepad - whatever you have configured. In order to get to the extra kits, press "O" button - to enter "Change Setup" mode. The little yellow arrows will now move the individual parts of the kit, signalling that you can start mixing individual parts. This is all standard game functionality - you don't need to press any special hotkeys to activate that.

Now comes the Kitserver new feature: by switching to different shirt(shorts,socks) you will now be cycling though all available parts, and not just 1st and 2nd choices. Exactly which combinations of kit parts are allowed is determined by whether your kits use shared palettes or not. Kitserver will automatically detect different pallettes and will block combinations where more than one palette is used, because otherwise you'll get messed-up kits when the match starts.

The sample GDB has several examples of how you can organize your kits:

7. Credits

Programming: juce
Testing: biker_jim_uk, ntalex
Kits: Spark, kel, qiankun. All from here: http://www.wevolution.org
Fonts, numbers: original authors unknown. Images taken from this site: http://www.socsci.umn.edu/~jkoepp/pes5/ and from the game itself.

Kitserver uses the following open source software:
pngdib by Jason Summers http://entropymine.com/jason/pngdib/
libpng by Guy Eric Schalnat, Andreas Dilger, Glenn Randers-Pehrson, and others http://libpng.org/pub/png/libpng.html
zlib by Jean-loup Gailly and Mark Adler, and others http://www.zlib.net/