Kitserver Pes 13 Download

[Crisoforo Schuhmacher]

Kitserver2010 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, whereeach 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.

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, comparedto the previous versions of Kitserver. So, first new thing: you have a more traditional installernow, well it's just a self-extractable archive with some logos :) Run it, and it will ask youwhere 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 controlover 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.

This was previously called setup.exe, but Windows thinks that anyapplication 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 attachmentof kitserver to the game EXE files.

Now select the game executable (it should actually already be preselected). You canalso 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 troubleshootingcrashes: you can always temporarily detach Kitserver from the game to verify that the gameruns fine without it. And then re-attach the Kitserver later).You can also install/remove Kitserveronly 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 thekitserver 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 theconfig.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.

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, orthere 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 geta 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 themanager.exe program and attach the kitserver to the new EXE. Assuming, of course, that Kitserversupports the new EXE, that's all there is to it. Now you can again start the game from Kitserver2010folder.

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:

Kitserver uses a file called config.txt as its main configuration file. A lot of things are specified there, including which modulesto 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 ita different name on purpose: so that those who upgrade their kitserver installation don't accidently overwrite their existing config.txt). If you aren'tupgrading 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). Otherwiseyou 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.

The main configuration file for kitserver - config.txt - is located in thekitserver 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:

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.

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.

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 riskingtotally destroying the content that you already have. Putting a new patch intoa 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, andthen delete the AFS-root folder. Multiple patches is no longer a management nightmare :). (See more info on AFS-roots in the sections below)

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).

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.

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:

Similarly with balls, if you are replacing ball BINs, you probably want toadjust 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:

It is worth noting that each afs-root folder can have its own songs.txtand 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 ownafs-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.

3a8082e126