KitServer 5.2 is an add-on program for Pro Evolution Soccer 5, Winning Eleven 9, and Winning Eleven 9 Liveware Evolution. It is a loader and manager for various modules. Kitserver Module 5.2.0 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. The Ballserver Module 5.2.0 (see section 3) does similar things to Kitserver, it offers the possibility of chosing a ball from the external database. Of course it is possible to store more than the eight standard balls. Furthermore the LOD Mixer Module 5.2.0 enables more detailed graphics and controlling of match aspects in Leagues and Cups (see section 4).
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)
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.)
So we start with the GDB, as the most dramatic 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 201, 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: <team-num>,"<folder name>" # 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 organization.
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 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.)
Reserved PNG file name | Reserved BMP file name | Meaning |
---|---|---|
all.png | all.bmp | all-in-one kit |
shirt.png | shirt.bmp | shirt |
shorts.png | shorts.bmp | shorts |
socks.png | socks.bmp | socks |
font.png | font.bmp | 256x64 image with font for displaying player names on the back of the shirt |
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 shirt or shorts in it (either as part of all-in-one kit, or as separate image) should have a config.txt file in it. Most of the attributes apply to the shirt, except for "shorts.number.location", which applies to shorts. That's why you would still need a config.txt in a folder, which doesn't have a shirt image, but has shorts.
Here's the summary table of all the supported attributes:
Attribute name | Meaning | Format | Example |
---|---|---|---|
model | identifier for 3D-model of the shirt | decimal integer | |
collar | Presense of collar | yes/no | |
numbers | Filename (with path, relative to kit folder) of the image that contains numbers texture: 256x128 4bit/8bit paletted image | string in double quotes | |
shorts.num-pal.X | Filename (with path, relative to kit folder) of the image that contains numbers palette: a 4bit/8bit paletted image. This is the palette that will be used for the shorts from kit folder "X", if such shorts are used with the current shirt. | string in double quotes | |
shorts.number.location | Where on the shorts the number should be placed. ("off" means the number will not be displayed at all.) | left|right|both|off | |
name.location | Where on the shirt the name of the player should be placed. This is useful for teams like Boca Juniors, who have player names printed at the bottom of the shirt. ("off" means the name will not be displayed at all.) | top|bottom|off | |
logo.location | Where on the shirt the sponsor logo should be placed. (This attribute is probably not gonna be very useful with kitserver, since if the team has the logo on the back of the shirt, it will probably be painted as part of the kit texture itself, by kitmaker) | top|bottom|off | |
name.shape | Indicates whether the name should be curved or straight. The values have the same meaning as in Edit Mode: type1 - straight, type2 - slightly curved, type3 - curved. | type1|type2|type3 | |
radar.color | This attributes specifies the color you see on the ingame radar. It also influences the kit that is selected by default after selecting teams, as PES5 uses it as an indicator whether two kits have similar colors and would be too confusing together. Be careful: This is also the main color of standard mini-kits (not 2.5D)! | color, written in hexadecimal format RRGGBB (red,green,blue) |
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 should 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.number.location = left shorts.num-pal.pa = "..\..\adidas_white.png" shorts.num-pal.pb = "..\..\adidas_black.png"
What this means in plain English is the following:
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.
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 through all available parts, and not just 1st and 2nd choices. (You'll notice that it doesn't matter if you press left arrow or right arrow - the kitserver always cycles the kits in the same order. This is currently a limitation of kitserver. In the future i will try to make it so that you can move between the kits in both directions.) 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.
It is also possible to set goalkeepers kits. There are now 2 modes of kit selection: "Player mode" and "Goalkeepers mode". You can switch between them by pressing [Tab] key. For goalkeeper, choose the kits the same way as you did for the players. As with player kits, you can mix the parts, if you go into the "Change Setup" mode. (Remember that the same shared palette rule - as with player kits - still aplies.)
For people who experimented with adding/changing kits in PES5, probably the most annoying feature of this version of the game - is the shared palette requirement. What it means is that both 1st and 2nd choice player kits for each team, must share the same 256-color palette in order for the mixing of the kits to work correctly. While the concept of kit mixing is a welcome step taken by Konami, the shared palette thing has proved to be a non-trivial obstacle.
The way the game logic works, the shared palette requirement is pretty much unavoidable, if you want to be able to mix parts from different kits. Kitserver, however, gives you the possiblity to use both shared palette kits and non-shared palette kits. For each team you can use the former or the later ones, or even have a mixture of both types of the kits! During the strip selection, the kitserver will automatically recognize the conflicts of palettes and will only allow the mixing of the parts that share the same palette.
As mentioned earlier, this gives you the opportunity to organize your kits in several different ways. Let's consider them in more detail, using the sample GDB examples:
1 | All player kits for given team share the same palette. You download the kits - 1st, 2nd, extras, and then you need to convert them to use a single shared palette. This is easy, if you have the right tool. Unfortunately, there seems to be no free software tools for that, although there are commercial ones. (You can use GIMP or Photoshop, but they don't handle the transparency correctly for paletted PNG files.). Another problem is that once you have more than 4-5 kits, it will be difficult to convert them to a shared palette without loss in quality. Especially, if the kits use many different colors. Rememeber, the shared palette is only 256 colors total. In the sample GDB, the examples of this approach are Newcastle, Man Utd, Real Madrid, and France. The advantage of shared palette is, of course, the fact that you can freely mix all the parts of all kits without restrictions. |
2 | Every kit has its own palette. This is the simplest way to organize the kits. You just download them and put into the right folders in GDB, and they are ready to be used - no modification needed. However, if you try to mix the parts during Strip Selection, you'll see that kitserver is switching the kits entirely - effectively it cycles through all of the kits, but doesn't allow mixing of the parts. This is similar to how extra kits worked for PES3 and PES4. Of course, you can still do what kitmakers did then: create all the combinations as separate kits - this way you'll get the same result as if you mixed the parts. (Actually, kitmakers are often still doing these extra combination themselves, so we're lucky here as we don't need to do any extra work - all the kits are often available for download! :-) Since kitserver allows for extra kits, this becomes possible, even though you'll need to have many more kits (compared to shared palette approach) to have all the combinations you want. In the sample GDB, the example of this solution is Tottenham. |
3 | A combination of #1 and #2.
Yes, you can use both shared and non-shared palette kits for the same team. Again,
the kitserver will allow "acceptable" mixing - when all parts in the mix use the same
palette, but will block the "illegal" mixing. In the sample GDB, see Germany as the example of this approach. |
Ballserver uses the same GDB folder as the other modules like Kitserver. The subfolder is named balls. You'll notice that there is a file inside called map.txt (like in Kitserver) to configure the balls. The format is quite simple: one line is one ball, and there are three attributes. The first one is the name displayed in the ingame selection, followed by the name of the 3D model file and the texture file. Look at the example:
# This is the configuration file for Ballserver # Format: "<name displayed in game>","<model file>","<texture file>" # Example: "adidas Finale Capitano Grey","ariel_mdl.bin","adidas_finale_capitano_grey.bmp" # Texture paths are relative to GDB\balls\, model paths to GDB\balls\mdl\ # adidas "adidas Finale Capitano Grey","ariel_mdl.bin","adidas_finale_capitano_grey.bmp" "adidas Teamgeist Blue","gwidon_mdl.bin","adidas_teamgeist_blue.png" # Nike # Puma # This comment makes sure you have pressed the enter key after the last ballPlease don't forget the quotes, they are important! If your map.txt looks like this (and you have those files, of course), you can choose between adidas Finale Capitano Grey and adidas Teamgeist Blue in game later. The texture files have to be stored inside the "GDB\balls" folder and the models in "GDB\balls\mdl".
When downloading balls, you will recognize that quite a lot of balls share one 3D model. In this case, you need each model file only once. In general, models are independent from the texture size, so a model delivered with a 256x256 texture should work with a 512x512 texture as well. If you're unsure, just try it with different models.
Start the game just as usual. When you come to kit selection, you will see a new text under the mini-kits saying
"Ball: game choice" by default. In this case, you will recognize no change when playing as the ball you selected in
the options will be used. Now comes the new feature: press B on your keyboard to select the next ball (or V
to cycle back). The text will change into "Ball: <name configured in map.txt>" and if everything is
well-configured, you will play with that ball. To choose a random ball, press R and to reset the ball to game choice
press C.
KitServer now includes another tool - LOD Mixer - as an integrated module. It allows to do some tweaks to the graphical engine of the game, such as Level-Of-Detail table adjustment, enable the crowd on all cameras, choose weather/stadium/etc. for League/Cup/ML games.
Run lodcfg.exe to configure the LOD Mixer settings. Here's the screenshot of how that looks (very similar to older standalone version of LOD Mixer 1.6):
Typically, you wouldn't need to modify that, unless you're running into problems, or want to manually enable/disable individual modules. For example, if you wish to use ballserver and lodmixer, but don't really want the kitserver module, you can do that by modifying the kload.cfg file. Here's how the default config looks:
# Loader configuration file gdb.dir = ".\" DLL.num = 6 DLL.0 = "kitserver\zlib1.dll" DLL.1 = "kitserver\libpng13.dll" DLL.2 = "kitserver\kserv.dll" DLL.3 = "kitserver\bserv.dll" DLL.4 = "kitserver\fserv.dll" DLL.5 = "kitserver\lodmixer.dll" # DirectX options dx.force-SW-TnL = 0 dx.emulate-HW-TnL = 0
The top two DLLs - zlib1.dll and libpng13.dll are needed for PNG image support. Do not remove those. The bottom 4 are independent modules, which you can enable or disable at will. For example, to disable kitserver module (kserv.dll), just comment it out with a "#" symbol at the beginning of the line:
DLL.num = 6 DLL.0 = "kitserver\zlib1.dll" DLL.1 = "kitserver\libpng13.dll" #DLL.2 = "kitserver\kserv.dll" DLL.3 = "kitserver\bserv.dll" DLL.4 = "kitserver\fserv.dll" DLL.5 = "kitserver\lodmixer.dll"
The dx.force-SW-TnL and dx.emulate-HW-TnL options provide functionality similar to
what 3DAnalyzer does with its "Force SW TnL" and "Emulate HW TnL Caps" settings. If your game
crashes (because of an old graphics card, or some other compatibility issue), and you cannot run
the game with 3DAnalyzer, try these two options - they might be all you need to get the game
working again.
To enable, just change the values from 0 to 1.
Programming: juce (KitServer, LOD Mixer, some BallServer algorithms), Robbie (BallServer, Faceserver)
Testing: biker_jim_uk, ntalex
Kits: Spark, kel, qiankun.
Balls: DAMned.
Ball models: Ariel, Gwidon.
Face: Chris79.
Kits, balls and ball models 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.
Documentation: TriAn (Russian text), juce (English text + Russian text mods/additions),
Robbie (German text, English BallServer and Faceserver manual)
Kitserver and Ballserver use 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/