Kitserver 2010 is an add-on program for Pro Evolution Soccer 2010 (and Pro Evolution Soccer 2010 DEMO). It is a loader and manager for various modules, where
each module is built as a (typically) independent DLL containing logic to
enhance the game in particular aspect. While originally the Kitserver was
developed to "serve" kits Pro Evolution Soccer 3, a lot more functionality
has been added over the years.
Below is a quick summary of the available features. Follow the link in the left column to get more details about a particular module.
If you are new to Kitserver, please make sure you read the installation instructions.
AFS2FS 9.2.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. |
---|---|---|
Kserv 9.2.0 | kserv.dll | Organize your kits into GDB, and assign each team its own kits. |
LOD Mixer 9.2.0 | lodmixer.dll | Custom resolution selection, manual/Automatic aspect ratio correction, LOD configuration, quality-check bypass |
Camera module 9.2.0 | camera.dll | Increase the camera viewing angle for Normal and Wide cameras, and enjoy new playing experience. |
Time module 9.2.0 | time.dll | Set match time to any number of minutes between 1 and 255. |
Speeder module 9.0.6 | speeder.dll | Increase or decrease gameplay speed. |
With XP and Vista, and now Windows 7 having more emphasis and enforcement of file ownership and different user rights, and promoting the use of "Standard User" accounts, i realized it was time to change the installation routine slightly, compared to the previous versions of Kitserver. So, first new thing: you have a more traditional installer now, well it's just a self-extractable archive with some logos :) Run it, and it will ask you where you want your kitserver files extracted:
You can leave the default directory specified in the installer, or you can put in your own. The important thing is that you unpack the files into a place where you have full control over the files (your HOME directory is one example of that.) This will ensure that you won't run into any File Virtualization surprises on Vista, and also that you will NOT need administrative privileges to run the game with Kitserver.
Now go to that directory that you installed your kitserver to. You will see there a folder named Kitserver2010. Open that folder, you should see something like this:
Now, copy the two executables from your game folder to the Kitserver2010 folder - pes2010.exe and settings.exe. (Depending on your Windows settings, you may see them as simply pes2010 and settings - with file extensions hidden. In fact, by default the file extensions of known file types are hidden, as you can see on the screenshot below). So, now it should look like this:
Almost there! A couple more steps and we'll have the game running with Kitserver.
Now open the kitserver folder and run the manager.exe program.
This was previously called setup.exe, but Windows thinks that any application named setup.exe wants administrative access, even though the kitserver's setup actually doesn't. Also, the name "setup" was always slightly misleading, so i decided to rename it to more neutral - manager - because it manages the attachment of kitserver to the game EXE files.
Now select the game executable (it should actually already be preselected). You can also select your settings.exe (if say you wish to by-pass the quality checks, for example. Otherwise, it is not necessary). Once you select the files, click "Attach" button. What this does is it "connects" the kitserver to the game: now whenever you start the game (using that particular game EXE), the Kitserver DLLs will be loaded into memory. If all went well, you should see a picture like this:
If you decide that you don't want to use Kitserver any longer, run manager.exe again and click "Detach", and it will disconnect the kitserver from the game EXE. (This is useful when troubleshooting crashes: you can always temporarily detach Kitserver from the game to verify that the game runs fine without it. And then re-attach the Kitserver later). You can also install/remove Kitserver only for one exe by setting the other one to "no action".
Now for one last step, before we can run the game with kitserver:
We need to make sure there exists a file called config.txt in the
kitserver folder. If you're upgrading your Kitserver, then you might already have it in there,
in which case the installation/upgrade is done. If not, then it's easy enough to create the
config.txt file: just run the Kitserver's configuration tool, click "Save",
and it will make the config.txt for you.
That's it. You're ready to launch the game.
REMEMBER: you need to start the game using the game EXE (pes2010.exe) in Kitserver2010 folder, because that is the one that has the kitserver attached to it.
For folks who had been using kitserver for some time, it is worth noting that it is still possible to install the kitserver the "old" way: in the game folder. Everything would still work fine, as long as you do everything as Administrator: run config.exe, run manager.exe, and you have to run the game as administrator too. I would honestly not recommend doing that, but instead adopt the new way. It is safer and you don't need to worry about administrative privileges, and you don't run into File Virtualization issues which can lead to nasty surprises, and many hours spent muttering things like: "why does my config.txt show correct setting, but in the game i don't see the effect? What is going on?!!..."
Uninstall is very easy: just delete the Kitserver2010 folder, and that's it.
Kitserver
doesn't write into system folders, or anything of that sort, so removal is very simple.
Also, it is worth reminding that you can always temporarily detach the kitserver from the game exe, and then re-attach it back, by using the manager program (as described in 2.1 section above). This is useful when suddenly you get game crashes, and you are not sure whether Kitserver is at fault, or there is some other reason.
From time to time, Konami releases patches to the game. There is already 1.01 and 1.02 patches, and there probably will be more released in the future. When you install these patches, you get a brand new game executable (pes2010.exe) among other things. It is important to realise that Konami patch doesn't now about your Kitserver installation, and therefore the game EXE in your Kitserver2010 folder will still be the old one.
So what you need to do is copy the new game EXE over to the Kitserver2010 folder, then run the manager.exe program and attach the kitserver to the new EXE. Assuming, of course, that Kitserver supports the new EXE, that's all there is to it. Now you can again start the game from Kitserver2010 folder.
The kitserver manager.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 manager like this:
manager --install --gfile={game-exe} --sfile={settings-exe}
manager --remove --gfile={game-exe} --sfile={settings-exe}
Example:
manager --install --gfile=..\pes2010.exe --sfile=..\settings.exe
Kitserver uses a file called config.txt as its main configuration file. A lot of things are specified there, including which modules to load, what settings those modules should use, and etc. Go to your kitserver folder and you should see a file called config-sample.txt. (I gave it a different name on purpose: so that those who upgrade their kitserver installation don't accidently overwrite their existing config.txt). If you aren't upgrading then the chances are that you don't have an existing config.txt, in which case just rename (or copy) the sample config into config.txt (or run configuration tool, click "Save" and it will do the same thing). Otherwise you may want to compare the sample config with yours and see if you need to make changes to your config: such as add new modules in the [kload] section, for example.
Remember: if you don't have config.txt in your kitserver folder, kitserver will not do much. But it will log the fact that it couldn't find the config.txt. So if you think kitserver doesn't work for you, check the pes2010.log file for error messages
The main configuration file for kitserver - config.txt - is located in the kitserver folder. If you don't have it there - re-read the end of Install section (2.1) above. Here is an example of what can be in config.txt:
[afs2fs] debug = 1 img.dir = "c:\mypesfiles\root1" [camera] angle = 30 [kload] dll = zlib1.dll dll = libpng13.dll dll = afsio.dll dll = kserv.dll dll = afs2fs.dll dll = lodmixer.dll dll = camera.dll dll = time.dll dll = speeder.dll gdb.dir = "."
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.
Formerly known as lodcfg.exe (it used to be the GUI tool for LOD mixer only, but now it covers other configuration options as well), this simple GUI program allows to modify some configuration settings in config.txt. It's a helper tool and all that it does, you can also do manually, by editing config.txt in your favourite text editor. In fact, some things you can only do manually - like adding and removing modules (DLLs). But for simple things - like changing resolution, or choosing camera angle - it's faster and easier to just launch config.exe, quickly adjust things, then click [Save] button, and you're done.
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)
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 img folder looks:
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.
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.
IMPORTANT thing to remember: 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"
When replacing songs with AFS2FS, it is also possible to change the title of the song and the artist's name, by using a songs.txt map-file, which should be put into afs-root folder.
Here's an example of such songs.txt file:
# Song names map # Format: <binId>, "<title>", "<artist>" # Note that double quotes are required. 11, "??? ???? ???????", "????? 312" 12, "I'm mad about you", "Sting"
IMPORTANT: as with all other map-files and config files that Kitserver uses, the encoding of the file needs to be Utf-8 or Unicode, especially of you use non-latin symbols - like in the example above. (ANSI encoding is ok if you only use Latin-1 characters.)
Similarly with balls, if you are replacing ball BINs, you probably want to adjust their names too. One easy way to do that is to use a balls.txt map-file, which should be put into afs-root folder:
# Ball names map # Format: <ball-number>, "<name>" # Note that double quotes are required. # (Ball numbers go from 1 to 16) 8, "Nike-ball Blue" 9, "????? ??????????"
It is worth noting that each afs-root folder can have its own songs.txt and balls.txt. Since each afs-root may contain music files and ball files, it makes sense to tie the names to them this way. If you have multiple afs-roots(as when for example you have multiple patches, and each patch uses its own afs-root), then the "conflicts" are resolved the same way as they are with BINs (see above for details). In other words, if one afs-root has name for song 11, and another afs-root has a name for song 11, then whichever afs-root is specified lower in the list (in config.txt) - will win.
Here's a picture to clarify where songs.txt and balls.txt files should be placed. In this case "root1" is my afs-root:
Kserv module is responsible for serving kits from the GDB ("Game content DataBase") during the game. The main feature of it is that you are not limited to the slots that dt0c.img has for the kits, and you can assign a kit to any team.
Kserv was historically the first module implemented in the original Kitserver program, made for PES3. That's where the Kitserver name originated from. Later, as more functionality were introduced as new modules, to avoid confusion, we changed the name of the module that serves kits to kserv, while Kitserver name now refers to the entire program.
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 - an integer number from 0 to 340. For every team in the GDB, you must specify in the map.txt where the kits for this team are. Here is an example:
# This config maps team number into folder name # Format: <team-num>,"<folder name>" # Example: 23,"Russia" 23,"National\Russia" 10, "National\Germany" 7, "National\England"
(If you haven't updated your data using Konami downloadable update, then the team IDs can be found in uni_org.txt)
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 #23, the kitserver needs to go to the folder GDB\uni\National\Russia. This folder will contain all of the kits that are available to team #23. 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-redwhite. 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.
See the table below for explanation of each file:
Reserved file name | Meaning | Format |
---|---|---|
Kit texture | 1024x512 8-bit paletted image in PNG format. | |
Font texture: used for names on the back of the shirt | 256x64 8-bit or 4-bit paletted image in PNG format. | |
Numbers texture: used for numbers on the back and the front of the shirt, and also on shorts | 512x256 8-bit or 4-bit paletted image in PNG format. | |
config.txt | Kit attribute configuration file (see next section for more details) | text file (in UTF-8 encoding) |
IMPORTANT NOTE TO KITMAKERS:
BMP kits are no longer supported, please use PNG format instead.
A team can have more kits than just 1st (pa) and 2nd (pb). You can put additional kits to their own folders and then be able to choose them in the game. (As i mentioned before, the folders for extra kits must be named starting with letter p - for player kits, and letter g - for goalkeepers. For example: px-white, or gc-third.) To use an extra kit, you will need to press the "hotkeys" when the uniform selection screen is shown (see screenshot below):
Hot-key | Action |
---|---|
[1] | Change home team player kit |
[2] | Change away team player kit |
Please note that it is currently NOT possible to select goalkeeper kits, but this feature will be implemented in the future versions of kserv.dll. Extra kits will also be supported for goalkeepers.
This is the attribute configuration file. 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, you should have a config.txt file in it. Here is an example config.txt from pa folder:
# Attribute configuration file auto-generated by GDB Manager collar = 0 front.number.show = 1 front.number.size = 8 front.number.x = 26 front.number.y = 18 main.color = A70623 model = 45 name.shape = type3 name.show = 1 name.size = 28 name.y = 24 number.size = 22 number.y = 11 shorts.color = A70623 shorts.number.location = left shorts.number.size = 14 shorts.number.x = 14 shorts.number.y = 6 sleeve.patch = 1 sleeve.patch.pos.long = 1 sleeve.patch.pos.short = 1
The summary table of all the supported attributes:
Attribute name | Meaning | Format | Example |
---|---|---|---|
collar | Collar-type (note that different models will have different interpratations of the collar value) | 1/2/3/4 | |
description | Any notes about the kit. This text will be displayed on kit selection screen. Useful when there are several kits that look nearly identical, but you want to know which one is currently selected. | any text in double quotes | |
front.number.show | Specifies if front number should be shown on the shirt: 1-show, 0-hide.(This only applies to national teams.) | 0|1 | |
front.number.size | How big the front number on the shirt is. | decimal number. Range: 1-30 | |
front.number.x | Horizontal position of the front number on the shirt. | decimal number. Range: 0(left)-30(right) | |
front.number.y | Vertical position of the front number on the shirt. | decimal number. Range: 0(low)-30(high) | |
main.color ( radar.color ) |
This attribute specifies the main color of the shirt. It is also used as the color of the players on radar screen. It also influences the kit that is selected by default. (The old name "radar.color" is also supported for backwards compatibility) | color, written in hexadecimal format RRGGBB (red,green,blue) | |
model | identifier for 3D-model of the shirt | decimal integer | |
name.show | Specifies if player name should be shown on the shirt: 1-show, 0-hide. | 0|1 | |
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 - more curved, type4 - even more curved. | type1|type2|type3|type4 | |
name.size | Size of the player's name on the shirt. | decimal number. Range: 1-35 | |
name.y | Vertical position of the player's name. | decimal number. Range: 0(low)-30(high) | |
number.size | Size of the number on the back. | decimal number. Range: 1-35 | |
number.y | Vertical position of the number on the back. | decimal number. Range: 0(low)-30(high) | |
shorts.color | This attribute specifies the color of the player/gk shorts. The color of shorts is used by the game to determine correct color of the underpants for those players who wear them, and have them set to match the shorts color. | color, written in hexadecimal format RRGGBB (red,green,blue) | |
shorts.number.location | Where on the shorts the number should be placed. ("off" means the number will not be displayed at all.) | left|right|off | |
shorts.number.size | Size of the number on shorts. | decimal number. Range: 1-35 | |
shorts.number.x | Horizontal position of the number on shorts. | decimal number. Range: 0(left)-30(right) | |
shorts.number.y | Vertical position of the number on shorts. | decimal number. Range: 0(low)-30(high) | |
sleeve.patch | Index of the sleeve patch to use. Sleeve patches are stored in dt0c.img/unknown_5879.bin. First one (0) is typically blank. | decimal number. Range: 0-19 | |
sleeve.patch.pos.long | Position of the patch on long sleeve. | decimal number. Range: 0-7 | |
sleeve.patch.pos.short | Position of the patch on short sleeve. | decimal number. Range: 0-7 |
By default, the usage of "description" attribute is enabled, but if you want, you can disable it. To do that, edit the main configuration file, and add the following option to the [kserv] section:
[kserv] use.description = 0
LOD-Mixer is the module that allows to fine-tune some aspects of PES2010 graphics engine.
Currently the following features are implemented: screen resolution and aspect ratio correction. All of these can be configured manually in kitserver's main
configuration file (kitserver/config.txt), but you can also use Kitserver's configuration tool (config.exe).
Many LCD monitors are neither 4:3 nor 16:9. Often, a 16:10 ratio is used, or even 16:9.6. This results in the picture being distored: players either too fat or too skinny, and ball is not round. In this year version, Konami are again using the black bars (as they were in PES2009) to compensate for the case when aspect-ratio is different (LB checkbox). However, if you don't like the black bars, then run settings.exe, turn off the LB checkbox, and then use Kitserver's aspect-ratio correction feature instead:
With LOD Mixer, you can set the aspect ratio to whatever you want. Either let LOD Mixer calculate it automatically - at run-time, using the current screen width and height in pixels - or set the value manually. Automatic way would work quite accurately, assuming the pixel is square. Sometimes, however, you would want to set it manually. For example, i play on widescreen monitor, but using a 800x600 resolution, because my video card is not powerful enough. The automatic calculation would give 4:3, but since the view is stretched to fill the entire screen, we need to account for that. Setting aspect ratio to 1.6 (which is a natural AR for my laptop) does the trick.
You can set any screen resolution you want, if you play in a Windowed mode. Even crazy screens like 1234x487 will work, but you're likely to suffer from performance problems on such cases. Hidden fullscreen resolutions are fully unlocked now as well. However, only those that your video card really supports in full-screen mode, will work. If you accidently choose an unsupported fullscreen resolution, then PES should still be able to start in a window.
This feature may be useful to people who like to play a tournament - a league or cup together. PES 2010 doesn't allow human players to control both teams, unless both of their selected teams are playing against each other in the match. With this new feature, you can remove that limitation. Now, even if it is for example, P1 vs. COM game, or P2 vs. COM - you can freely select which team you control with each controller. So, you can both play on the same team, or you can let your friend control the opposition - to make things more interesting. You can also now choose a "Spectator" mode for in tournaments.
Another possiblity opened by this feature: in training mode, you can play for defence and/or goalkeeper. Very handy to train penalty saves!
LOD (Level-Of-Detail) algorithms are used in graphics engines to improve both the picture quality and the speed of rendering, when drawing objects at various distances from the viewer. The basic idea is that when the object is close to the camera, one (very detailed) model is used. When it is far - another, simpler model with less detail is used instead. It's much faster to render a low-poly model of the object, and it typically looks better, when drawn in small size, because it suffers less from aliasing. In theory, at least, that is how it is supposed to work.
Unfortunately, PES series had always suffered from an overly- conservative LOD configuration, where the switch to low-poly models would happen way too soon, and that would result in various visible artifacts. In PES4-PES6, examples were: balding players, and missing details on kits. In PES2008-PES2010, the players and referees appear to have blurred generic faces, once they move slightly away from the camera.
So, if you have a good PC and a powerful videocard with GPU cycles to spare, you may fancy tuning the LOD sligtly to make the game engine display more detailed models, even when they players are a bit away from the camera (Animation quality seems to be affected by this as well). To do that, move the sliders to the right.
Also, if on the contrary, your machine is stuggling to run the game at a smooth frame rate, you can try moving the LOD sliders in the opposite direction - thus making the engine switch to the low-poly models sooner than normal. This may improve the framerate, although at the expense of picture quality. To achieve that, move the sliders to the left.
The lodmixer module also supports 6 more LOD settings, which aren't shown as sliders in configuration tool. Those are LOD settings for so called "active player". This is the player that is controlled by human player during free kicks and corner kicks. "Active player" LODs are also used by the game during uniform selection screen and in Edit Mode.
Basically, i got lazy, and didn't feel like adding 6 more sliders to the configuration tool :) And also couldn't quite figure out where exactly to put them, without totally clobbering the UI. But you can still use them, by adding them manually to [lodmixer] section in config.txt. You probably not going to use all of them, but you might find this one handy: lod.active.player.fk.s1. I put this setting into the config-sample.txt, and set the value of it to 0.010 - this gives maximum detail for the player taking a free kick.
Here is the full list of "active player" LODs with their default values. Feel free to experiment with them, if you really want to:
lod.active.player.ck.s1 = 0.010 lod.active.player.ck.s2 = 0.010 lod.active.player.ck.s3 = 0.010 lod.active.player.fk.s1 = 100.0 lod.active.player.fk.s2 = 0.010 lod.active.player.fk.s3 = 0.010
Configuring LOD well takes time and is best done via trial-and-error method. (If it was easy, it would've been probably done right in the first place!) I'd like to mention a few considertations here that should help you with LOD configs.
Myth #1: if I move all sliders to the right, I will always have the best picture.
That is simply not true. You will get the most detailed and expensive rendering, yes, but
NOT NECESSARILY the one that looks the best. More-detailed objects at far distance
actually look worse than less-detailed ones, because of the aliasing effect.
Myth #2: my GPU (video card) is really good, surely it can handle anything thrown at it.
That is not true either. Current generation of games has become quite sofisticiated and
resource-hungry. GPU and CPU are working hard to process the rendering, physics, AI logic.
60 FPS is the typical minimum frame-rate at which a game needs to run, in order to provide
nice and smooth gameplay. That means the rendering of the entire scene must fit into 1/60th of
a second and still leave some time for other tasks to be done. (Physics, in particular is often
run at the same rate as rendering, so that the picture doesn't suffer from noise.) To make sure
rendering time doesn't escalate dramatically as more objects are rendered, LOD is often employed
as the optimization technique. By moving all sliders to the right, you are effectively
disabling the LOD algorithm and telling your GPU: "render all objects on the screen at the
most possible detail. And if you fry while doing that, i don't care!". Ok, so maybe it's not a funny example,
but you get the point.
Now, coming back to our game, as i said, in many cases, you only really need to adjust 1 slider or two to get the desired effect, and still keep the smooth frame-rate. Let's consider some examples:
These are just some examples. You might notice some other artifacts that you'd like to fix. The main thing is: experiment with your LOD configuration, don't just blindly set everything to maximum quality - on most systems that will result in stuttering and loss of frame-rate, because your GPU (and CPU also) gets a lot more work to do. In many cases, adjusting just one or two sliders gets the effect you want, without hurting the frame-rate.
For reasons known only to Konami product managers, for the third(!) year running, they took away the interface feature that allowed to adjust camera angle (it was in PES3-PES6, but it disappeared starting with PES2008). The underlying logic is still present in the game executable though, and this module allows you to take advantage of it. You can adjust the camera angle: standard values are 0 - 9, but you can actually set a bigger value, which will result in camera turning even more. For example, i like to play with angle value set to 30.
Choose any value from 0 to 2^32-1. Angles like 20, 40, 100 give quite a different perspective of play. More fun :)
Use Kitserver configuration tool (config.exe) or, you can also edit your config.txt file manually, like this:
[camera] angle = 30
This tiny module allows to stretch the length of the match to normal 90 minutes, if you want, but really you can choose any number of minutes between 1 and 255. Going beyond 90 will make the seconds flow slower than normal. Also, another extreme is setting the match time to 1 minute. This is a whole new experience too: you have to really treasure the ball - keep posession, or you risk not getting it back at all, before the final whistle! Also, if you get a scoring chance, better put it away, because chances are it'll be the only one you get.
To set the match time use match.time setting:
[time] match.time = 90
Not everyone is satisfied with the pace of the gameplay. It must be said that it is not an easy thing to get this aspect of simulating a football match correctly. Many factors are in play, and a lot depends on hardware. Personally, i think Konami did a decent job at that, but many folks find the gameplay too fast.
Several techniques of slowing the game down exist, and not one of them is perfect, but all work to some extent. The speeder module basically slows down the clock, sort of tricking the game into running slower. This is not an ideal solution either, but if a small adjustment is used, it can still look real, play well, and actually provide a smoother gameplay. Don't consider it a silver bullet though. It might work well for you, but it also may not deliver everything you had hoped for :) (One side-effect, for example, is that if you set your match time to 10 minutes, but you have the Game Speed set to 0.9, the actual match time will be approximately 11.1 minutes.)
It is possible to decrease the game speed and also to increase it. The configuration tool has the 'Game Speed' slider for easy adjustments. The value 1.0 gives the default unchanged speed. Less than 1.0 - slower gameplay, greater than 1.0 - faster gameplay. It is not advised to use values lower than 0.7, because the music/commentary starts to break up. Also values larger than 2.5 are not supported. It is already ridiculously fast with 2.5!.
Alternatively, you can set the game speed adjustment manually in config.txt, by using count.factor setting:
[speeder] count.factor = 0.95
Programming: juce and Robbie
Big thanks to: England and Energia - for help with 1.1 and 1.2 EXE support, PATe.Arminia - for help with kit attributes, Stelios and ninuzzu - for KitsRelink tool, which helped me greatly when i was working on kserv module, Ariel - for great-looking kitserver logo.
Beta-testing: members and guests of Evo-Web and PesWe.com forums.
Original idea for afs2fs modules: Str@teG
Many other ideas came from users of Evo-Web forums and PesWe.com forums
Special thanks go to: administrators of PesWe.com website and members of PesWe forums.
Kitserver license is BSD-style license that can be found here: license.txt