Normalmente, a versão mais atualizada desta documentação, e as traduções para outros idiomas, estão disponiveis aqui: https://kitserver.mapote.com. A Documentação para as versões anteriores do Kitserver 5-8 e 2010 também pode ser acessada lá.
Kitserver 11 é um programa de computador adicional para Pro Evolution Soccer 2011 (e DEMO do Pro Evolution Soccer 2011). É um carregador e um gerenciador para os vários módulos, onde cada módulo é relacionado (normalmente) a um arquivo DLL contendo uma
nova funcionalidade especifica à edição e funcionamento do jogo. Originalmente o Kitserver foi desenvolvido para disponibilizar kits para o Pro Evolution Soccer 3, e um tanto de novas funções foram adicionadas ao seu leque de opções com o passar
dos anos.
Abaixo está um sumário das funcionalidades presentes na versão atual. Siga o link da coluna à direita para ver mais detalhes sobre um módulo em especial
Se você é novato no uso do Kitserver, por favor leia antes as instruções de instalação.
AFS2FS 11.0.0 | afs2fs.dll | Gerencie arquivo AFS (.img) do jogo usando arquivos e pastas externas: torna muito mais fácil e rápido instalar e remover patches, sem necessidade de modificar arquivos *.img originais. |
---|---|---|
Kserv 11.0.1.0 | kserv.dll | Organiza seus kits na pasta GDB, e determina para cada time os seus kits corretos. |
LOD Mixer 11.0.0 | lodmixer.dll | Configuração do Nivel de Detalhes Gráficos (LOD) para jogadores e arbitros. |
Speeder module 11.0.0 | speeder.dll | Aumente ou diminua a velocidade real do jogo. |
Sides module 11.0.0 | sides.dll | Permite escolha livre do time que P1/P2 pode controlar nas partidas. |
Com o XP e Vista, e agora o Windows 7 tendo maior enfase nas permissões de modificar arquivos e pastas, em diferentes niveis de privilégios de usuarios (UAC), a rotina de instalação do Kitserver foi mudada. Se você é um usuario experiente das versões anteriores do Kitserver, por favor leia isto atentamente pois irá te salvar bastante aborrecimento desnecessário.
Em muitos casos, seguindo só estes 3 passos explicados na mensagem da janela do descompactador de arquivos bastará para a instalação. Se for o seu caso, ótimo, siga adiante e desfrute do jogo com as customizações que o Kitserver permite utilizar :)
Você pode deixar no diretório padrão, ou pode personalizar o caminho como quiser. O importante a se considerar é que você tenha total permissão de escrita/leitura na pasta de destino (seu diretório HOME é um exemplo. Outras opções: "Meus Documentos" ou "Desktop"). Isso vai garantir que você não caia em nenhuma "armadilha" de virtualização de pastas, tipica do Windows Vista, e não pedirá privilégios de administrador para rodar o jogo com o Kitserver.
Agora vá na pasta que extraiu os arquivos do kitserver. Você verá nela uma pasta chamada Kitserver11. Abra aquela pasta, você verá algo como isto:
O próximo passo é ter certeza que existe um arquivo chamado
config.txt
Se você está instalando o kitserver 11 pela primeira vez,
provavelmente não tem um arquivo config.txt. Neste caso, execute a
ferramenta de configuração, um programa chamado config.exe, aperte o
botão [Save] e será criado o arquivo config.txt para você.
Se, no entanto, você está fazendo upgrade a partir de uma versão anterior do kitserver, você já tem um arquivo config.txt, que provavelmente gostará de atualizar ao invés de começar do zero. (Por exemplo, se você fez muitas configurações detalhadas do LOD pro jogo ficar mais bonito ou mais rapido, e não quer perde-las). Se este é o seu caso, então é preciso fazer o seguinte:
dll = kserv.dll
Agora você tem o arquivo config.txt, e estamos prontos para rodar o jogo junto do Kitserver. Para fazê-lo, nós iremos usar um novo utilitário, adicionado no Kitserver11 - chamado krun.exe. Apenas clique em krun.exe e deverá rodar o jogo. (Ele lê o registro do Windows e descobre automaticamente o caminho do executavel do jogo)
A partir do Kitserver 11.0.0, uma nova ferramenta foi introduzida: krun.exe - Carregador do Jogo com Kitserver. Esta é a ferramenta que você irá usar para rodar o jogo sob controle do Kitserver.
Por padrão, o krun irá consultar o registro do Windows, para saber em que pasta o game está instalado e tentará executar um executavel naquela pasta, chamado PES2011.exe. No cenário mais comum, isto é o que você deseja fazer :)
Porém, pode ser o caso de você ter uma organização de arquivos mais complexa. Talvez hajam varios EXEs instalados na mesma pasta, baseados em patches de diversos Foruns de edição. Então suponhamos que ao invés do PES2011.exe você queira rodar este executavel: C:\myPesPatch\PES2011_patched.exe.
Isto tambem é possivel com a ferramenta krun: você precisa criar um arquivo de configuração para ele, contendo o caminho completo do exe. Criamos um arquivo texto chamado krun-config.txt, pondo esta linha nele:
C:\myPesPatch\PES2011_patched.exe
E está feito. Agora quando você executar o krun.exe, ao invés de ler o registro do Windows, ele irá executar o EXE determinado no arquivo krun-config.txt
Isto pode ser uma dica valiosa e muito útil para criadores de patches: você pode renomear krun.exe para outro nome, e ainda assim ele ao ser executado poderá encontrar o seu arquivo correspondente de configuração da pasta do executavel.
Por exemplo, se ele está nomeado MeuPatch.exe. Então você precisa nomear o seu arquivo de configuração do executavel: MeuPatch-config.txt.
Você poderá sempre rodar o jogo sem o Kitserver.
Rode-o da maneira normal - pelo Menu Iniciar ou atalho no Desktop.
Se você não usar o programa krun, o kitserver não será
carregado na memória junto do jogo.
Isto é util para solucionar bugs de fechamento repentino do jogo, por exemplo. Se não funciona como esperado a primeira coisa a se fazer é tentar isolar a causa. Assim você pode saber rapidamente se está relacionado ao Kitserver ou é outro problema isolado do jogo.
Quem tem usado o kitserver por alguns anos notará que este modo é um tanto diferente do procedimento até então usual: o Kitserver não é conectado (attach) mais ao EXE do jogo, ao invés disso o jogo roda como um processo-filho do utilitario krun, que carrega do módulos do kitserver junto do jogo. O novo jeito de funcionar pode parecer nada familiar, mas resolve muitos problemas de segurança que dificultavam a rotina de conectar um EXE nas ultimas versões do Windows. O Kitserver não precisa mais modificar o executavel do Jogo (o que é sempre detectado como atividade suspeita por programas anti-virus), sendo feito tudo no próprio tempo de execução do jogo.
Desinstalar é muito fácil: apague a pasta Kitserver11, quando não quiser usá-lo mais. O Kitserver não modifica nada nas pastas de sistema, nem na pasta do jogo, assim a remoção é bem simples.
O Kitserver usa um arquivo chamado config.txt como o seu arquivo principal de configurações. Varias opções são definidas nele, incluindo quais módulos serão habilitados, a configuração de cada módulo, etc. Aqui está um exemplo de um arquivo config.txt:
[afs2fs] img.dir = "c:\mypesfiles\root1" [kload] dll = afsio.dll dll = afs2fs.dll dll = speeder.dll dll = sides.dll dll = kserv.dll
Cada módulo pode ter a sua própria seção de configuração que inicia com [nome-do-modulo], e normalmente tem uma ou mais opções detalhadas. Agora, normalmente você não precisa modificar manualmente o arquivo config.txt, exceto quando precisa mudar o comportamento de um modulo em especial (DLL), ou desligar/ligar uma DLL.
Para desligar um determinado módulo - apenas adicione um comentário com o simbolo '#' no inicio da linha na seção [kload]. (Ou você pode apagar aquela linha inteira.)
A ordem das DLLs é importante. Particularmente: afsio.dll tem que ser carregada antes que afs2fs.dll. Apenas em raras situações você pode tentar re-ordenar estas DLLs.
Antigamente conhecida como lodcfg.exe (costumava ser a GUI - interface grafica - do LOD mixer, mas agora tem varias outras opções), este simples programa permite modificar varias opções do Config.txt com interface intuitiva. É uma ferramenta auxiliar, e tudo que você configura nela pode ser escrito diretamente no config.txt por meio de um editor de texto. Na verdade, algumas coisas você pode fazer somente manualmente - como adicionar e remover módulos (DLLs). Mas para coisas simples - como mudar resolução, ou escolher angulo de camera - é mais rapido e facil no config.exe, ajuste rapidamente as opções e clique em [Save], e pronto.
Este módulo permite organizar seus arquivos BIN em pastas externas, ao invés de inseri-los em arquivos AFS(*.img), o que pode ser demorado e frustante, além de precisar de muito espaço extra no disco rigido.
Muitas pessoas sugeriram durante os ultimos anos soluções parecidas, mas finalmente foi Str@teG quem planejou este conceito de distribuir BINs em pastas, e eventualmente eu decidi implantá-lo no kitserver. Então agora está presente neste módulo - afs2fs.dll. Por experiencia pessoal, sei que as pessoas são resistentes à idéia de instalar grandes patches que necessitam regenerar o arquivo AFS, não porque seja um processo complicado ou algo do tipo, mas porque é demorado e precisa de muito espaço livre no HDD. Com o afs2fs, isso agora é muito fácil: você só põe a BIN na pasta relacionada e está feito. E, claro, não há limite de tamanho por arquivo - os bins podem ser do tamanho que for preciso!
O módulo também é prático, quando você quer usar outro patch sem apagar aquele que você já usa. Você só precisa pôr o novo patch em uma pasta-raiz AFS em um caminho diferente e adicionar uma linha no arquivo config.txt para fazê-lo funcionar. Remover também é fácil: apague a linha "img.dir" correspondente à pasta no config.txt, e então apague a pasta-raiz AFS. Gerenciar varios patches não é mais um pesadelo :) (veja mais info em 'Localização da pasta "img"' nas seções seguintes)
Comece escolhendo onde um caminho onde ficarão os arquivos. Por exemplo, usaremos c:\mypesfiles\root1. Esta será a sua 'pasta-raiz AFS'. Dentro daquela pasta, crie uma pasta chamada img. (É essencial que você tenha esta pasta chamada "img", porque o jogo reconhece apenas nomes especificos). Então, dentro de img, crie as pastas, conforme a sua necessidade, com os nomes - dt00.img, dt01.img, dt0b.img, e assim por diante. Lá serão postos os arquivos BIN.
É importante nomear as pastas corretamente: uma pasta tem que ter exatamente o mesmo nome que o arquivo AFS (pasta 'img' do jogo) correspondente. Por exemplo, se você nomear uma pasta dt00, ao invés de dt00.img, não irá funcionar direito.
Minha pasta img ficou assim:
Em geral, você pode nomear os arquivos como quiser, mas é preciso seguir a seguinte regra: deve haver um numero do BIN no nome de todo arquivo, precedido por um sublinhado ('_'). Além disso, os nomes dos arquivos NÃO PODEM ser mais compridos que 63 caracteres.
Exemplos de nomes corretos:
unknown_317.bin
goalnet_41.bin
ball_9.bin
unknow_9 (extensão .bin é opcional)
music_11.adx (um arquivo poderá ter extensão diferente: .adx é tipicamente usado para musicas, chants e arquivos sons)
Exemplos de nomes errados:
unnamed10.bin - sem simbolo de sublinhado (underscore) antes do numero do BIN.
face.bin - sem numero do BIN.
Por padrão, o módulo AFS2FS não irá procurar automaticamente nenhum caminho da pasta-raiz AFS (pasta img). Sendo assim você precisa determinar a localização desta: Na seção [afs2fs] de config.txt, você pode determinar a localização desta, em qualquer lugar de seu disco rigido. Você também pode ter várias pastas-mães AFS, o que é util se você tem varios patches e não quer perder o rastro de onde vieram diferentes BINs editados (sendo possivel então deletar um deles em separado facilmente apagando a pasta-raiz correspondente).
Aqui está um exemplo de 3 diferentes pastas-raíz numa seção [afs2fs] do config.txt:
[afs2fs] img.dir = "c:\mypesfiles\root1" img.dir = "patch-RPL" img.dir = "afs-root3"
A ordem destas pastas é determinante quando existem "colisões". Por exemplo, se você tem um arquivo dt0b.img/ball_9.bin na segunda pasta (patch-RPL), e dt0b.img/superball_9.bin na terceira pasta (afs-root3). Mesmo que os arquivos tenham nomes diferentes, eles substituirão o mesmo BIN - nº9 do arquivo dt0b.img, e assim teremos uma "colisão". A regra é simples: a ultima pasta-mãe listada é a usada no jogo. O que significa que nesta situação, o arquivo dt0b.img/superball_9.bin será usado, já que a pasta é a ultima da lista na seção[afs2fs]
IMPORTANTE de se lembrar: A pasta-mãe AFS é a pasta que contém uma pasta "img", não confunda com a pasta "img". Em outras palavras, se o caminho completo for c:\mypesfiles\root1\img", então o endereço no config.txt deve ser: img.dir = "c:\mypesfiles\root1"
Quando substituir musicas com o AFS2FS, tambem é possivel mudar o titulo da musica e o autor, usando um arquivo de mapa songs.txt que deve ser colocado na pasta-raíz AFS.
Aqui está um exemplo de um arquivo songs.txt:
# Song names map # Format: <binId>, "<title>", "<artist>" # Note that double quotes are required. 44, "I'm mad about you", "Sting" 45, "Вне зоны доступа", "Город 312"
IMPORTANTE: como todos os outros arquivos texto map e config, a codificação precisa estar em Utf-8 or Unicode, especialmente se você usa caracteres não-latinos - como no exemplo acima. (codificação (ANSI está OK caso você use só caracteres Latin-1.)
Do mesmo jeito com as bolas, se você substituir as BINs, provavelmente vai querer mudar os seus nomes. Um modo simples de fazer isto é usar um mapa nomeado balls.txt que deve ser colocado na pasta-mãe AFS:
# 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, "Мячик плохонький"
Não custa lembrar que cada pasta-raíz AFS pode ter os seus próprios songs.txt e balls.txt. Desde que tenham os arquivos de musicas e bolas correspondentes, tem sentido relaciona-las a nomes desta maneira. Caso tenha varias pastas-mães (por exemplo varios patches, e cada um deles com uma pasta-raíz), então os "conflitos" serão resolvidos da mesma maneira do que com os BINs (veja detalhes acima). Em outras palavras, se uma pasta-raíz tem um nome para a musica 11, e outra pasta-raíz tem outro nome para a musica 11, a pasta-raíz que estiver listada por ultimo (no config.txt) definirá o nome da musica/bola mostrado no jogo.
Aqui está uma imagem para deixar claro onde os arquivos songs.txt e balls.txt devem ficar. No exemplo, "root1" é minha pasta-raíz:
O módulo Kserv é responsavel pela utilização de kits colocados na pasta GDB ("Game content DataBase") durante o jogo. A caracteristica principal dele é oferecer uniformes para qualquer time do jogo, desbloqueando o limite de slots de kits do arquivo dt0c.img planejado origalmente só para prover kits de times licenciados.
Kserv foi historicamente o primeiro módulo do programa Kitserver, feito para PES3. Foi dele que surgiu o nome Kitserver. Depois, como novas funcionalidades foram introduzidas como novos módulos, para evitar confusão, resolvemos mudar o nome do módulo responsavel por kits para kserv, enquanto o nome Kitserver descreve o programa principal
A pasta GDB contém uma subpasta chamada uni, onde são armazenados os kits (uniformes). O arquivo mais importante dentro da pasta uni é chamado map.txt. Este arquivo diz ao kitserver onde encontrar os kits para um time em particular. Como você sabe, cada time tem uma única ID - um número inteiro de 0 to 370. Para cada time na GDB, você deve especificar no map.txt onde estão os kits deste time. Aqui está um exemplo:
# This config maps team number into folder name # Format: <team-num>,"<folder name>" # Example: 23,"Russia" 23,"National\Russia" 7, "National\England" 88, "EPL\Arsenal"
Por favor note que a pasta GDB de exemplo (disponivel com o kitserver) é só um dos modos de organizar os times e pastas. Ele usa o nome de pasta "EPL" para todos os times da liga inglesa, "National" - para todas as seleções nacionais, e daí por diante. Você poderia simplesmente usar uma lista unica de pastas dentro da pasta uni, sem estes grupos extras. Nesse caso, apenas modifique o arquivo map.txt para refletir as suas mudanças, e crie a estrutura de pastas que preferir. Esta é a principal vantagem de se usar um map.txt - a flexibilidade na organização de kits.
Você pode ver no map.txt abaixo que para encontrar um uniforme para o time #88, o kitserver precisa ir para a pasta GDB\uni\EPL\Arsenal. Esta pasta irá conter todos os kits disponiveis para o time #88. Dentro dele, você precisa criar um pasta para cada kit. Deste jeito: Para jogadores de linha, o nome da pasta do 1º Kit tem que ser pa e a pasta para o 2º kit pb. Kits adicionais podem ter qualquer nome começando pela letra "p". Eu achei prático usar prefixo para todos os kits adicionais como px-. Por exemplo, px-vermelhobranco. Para os goleiros, o 1º Kit tem que estar na pasta gae o 2º kit na pasta gb. Kits adicionais para goleiros podem ter qualquer nome começando pela letra "g".
Agora vamos mexer dentro de uma das pastas de kits. Pegando pa como exemplo. Veja a tabela abaixo para a explicação de cada arquivo:
Nome do arquivo | Significa | Formato |
---|---|---|
Imagem do Kit | 1024x512 8-bit paletizada em formato PNG. | |
Imagem da Fonte: usado em nomes nas costas da camisa | imagem 256x64 8-bit ou 4-bit paletizada em formato PNG. | |
Imagem dos Numeros: usada para numeros nas costas e frente da camisa e do shorts | imagem 512x256 8-bit ou 4-bit paletizada em formato PNG. | |
config.txt | Arquivo de configuração das propriedades do Kit (veja a próxima seção para mais detalhes) | arquivo texto (codificado em UTF-8) |
NOTA IMPORTANTE PARA KITMAKERS:
kits em BMP não são mais suportados, por favor use somente o formato PNG.
Este é o arquivo de configuração das propriedades do Kit. Como antes, é só um arquivo texto simples - você pode usar o Bloco de Notas ou qualquer outro editor de texto para vê-lo e edita-lo. Para cada pasta de kit, você deve fazer um arquivo config.txt dentro dela. Aqui está um exemplo de config.txt para a pasta pa:
# 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.left.pos.long = 1 sleeve.patch.left.pos.short = 1 sleeve.patch.right.pos.long = 1 sleeve.patch.right.pos.short = 1
Aqui está um resumo de todas as propriedades disponiveis:
Nome do atributo | Significa | Formato | Exemplo |
---|---|---|---|
collar | Tipo de colar (note que tipos diferentes de modelo 3D terão valores diferentes de colar) | 1/2/3/4 | |
description | Qualquer informação sobre o kit. Este texto será exibido na tela de escolha de uniformes. É util quando os kits parecem identicos, mas você quer saber qual deles está selecionado. | qualquer texto entre aspas | |
front.number.show | Determina se o numero frontal deve aparecer na camisa: 1-visivel, 0-esconder.(Isto só é aplicavel para seleções nacionais.) | 0|1 | |
front.number.size | Tamanho do numero na parte de frente da camisa. | numero decimal. Valores validos: de 1 a 30 | |
front.number.x | Posição Horizontal do numero na parte de frente da camisa. | numero decimal. Valores validos: 0(esquerda)-30(direita) | |
front.number.y | Posição Vertical do numero na parte de frente da camisa. | numero decimal. Valores validos: 0(embaixo)-30(topo) | |
main.color ( radar.color ) |
Este atributo determina a cor principal do kit. Tambem é usado como a cor dos jogadores dos times no radar durante a partida. Tambem influencia na escolha automatica dos uniformes antes da partida. (O antigo nome "radar.color" tambem é suportado para compatibilidade.) | cor, escrita em formato hexadecimal RRGGBB (red,green,blue) | |
model | identificador para o modelo 3D da camisa | numero inteiro | |
name.show | Determina se o nome do jogador deve ser mostrado na camisa: 1-visivel, 0-oculto. | 0|1 | |
name.shape | Indica se o nome deve ser convexo ou reto. Os valores são os mesmos do EDIT MODE: tipo1 - reto, tipo2 - levemente curvo, tipo3 - convexo, tipo4 - bastante convexo. | type1|type2|type3|type4 | |
name.size | Tamanho do nome do jogador na camisa. | numero decimal. Valores validos: de 1 a 35 | |
name.y | Posição Vertical do nome do jogador na camisa. | numero decimal. Valores validos: 0(embaixo)-30(topo) | |
number.size | Tamanho do numero nas costas. | numero decimal. Valores validos: de 1 a 35 | |
number.y | Posição Vertical do numero nas costas. | numero decimal. Valores validos: 0(embaixo)-30(topo) | |
shorts.color | Este atributo especifica a cor do shorts do jogador de linha/goleiro. A cor do shorts é usada pelo jogo para determinar a cor correta dos acessórios como coxeira e outros acessórios nos jogadores que usam isto configurados na mesma cor do shorts. | cor, escrita em formato hexadecimal RRGGBB (red,green,blue) | |
shorts.number.location | Lugar no shorts onde o numero deve ficar. ("off" significa que o numero não será exibido.) | left|right|off | |
shorts.number.size | Tamanho do numero no shorts. | numero decimal. Valores validos: de 1 a 35 | |
shorts.number.x | Posição Horizontal do numero nos shorts. | numero decimal. Valores validos: 0(esquerda)-30(direita) | |
shorts.number.y | Posição Vertical do numero nos shorts. | numero decimal. Valores validos: 0(embaixo)-30(topo) | |
sleeve.patch | Tipo de logotipo na manga da camisa. Os tipos de logos nas mangas estão armazenados em dt0c.img/unknown_5879.bin. A primeira (0) geralmente está em branco. | numero decimal. Valores validos: de 0 a 19 | |
sleeve.patch.pos.long | Posição do logo na manga comprida. | numero decimal. Valores validos: de 0 a 7 | |
sleeve.patch.pos.short | Posição do logo na manga curta. | numero decimal. Valores validos: de 0 a 7 |
Por padrão, o uso do atributo "description" está ligado, mas se você quiser pode desabilita-lo. Para fazer isso, edite o seu arquivo config.txt, e adicione a seguinte opção na seção [kserv]:
[kserv] use.description = 0
Nas suas ultimas atualizações DLC, a KONAMI incluiu novos modelos que usam texturas diferentes de kits - uma em especial em que duas texturas diferentes aparecem no mesmo uniforme: um justo junto ao corpo e outro normal.
Apenas certos modelos suportam estas texturas, e a partir do DLC 2.00, são estas:35,36,37,38,39,40 e 41. O módulo Kserv 11.0.0.0 em diante suporta isto sem nenhuma configuração adicional. No entanto se outro DLC for lançado e mais modelos como estes forem lançados, agora é possível especificar isto na seção [kserver] do arquivo config.txt. Você precisa listar todos eles dessa maneira:
[kserv] ... techfit.model = 35 techfit.model = 36 techfit.model = 37 techfit.model = 38 techfit.model = 39 techfit.model = 40 techfit.model = 41 ...
Outro modelo 3D especial é o Puma Tight-fit, modelo 24. Permite a você fazer com que qualquer kit se torne justo rente ao corpo (bons exemplos disso são os de Seleções Africanas)
A partir do DLC 2.0, apenas o modelo 24 é deste jeito e o módulo Kserver 11.0.0.0 suporta ele sem configuração adicional. Caso mais modelos como este sejam adicionados em atualizações da Konami, é possivel adiciona-los tambem no arquivo config.txt na seção [kserv]. Você precisará listar todos eles, desse jeito:
[kserv] ... tight.model = 24 ...
LOD-Mixer é o módulo que permite um ajuste fino em alguns aspectos dos gráficos da engine do PES2011.
Estas opções podem ser configuradas manualmente no arquivo principal de configuração do Kitserver (kitserver/config.txt), mas você pode tambem usar a Ferramenta de configuração
(config.exe).
Algoritmos de LOD (Level-Of-Detail, nivel de detalhes) são usados em motores gráficos para melhorar tanto a qualidade da imagem quanto a velocidade de renderização, quando exibidos objetos de varias distancias a partir do ponto do observador. A idéia basica é que quando há um objeto muito proximo do observador um modelo muito detalhado seja usado. E, quando está distante, outro modelo menos detalhado é usado. É muito mais rapido renderizar um objeto com poucos poligonos e que está distante, até porque por ser pequeno apresentaria defeitos visuais na correção de arestas (anti-alising). Na teoria, pelo menos, é assim que deveria funcionar.
PES 2011 tem 4 modos diferentes de renderizar um jogador. A opção usada em cada momento depende de varias circunstancias. o quão longe o jogador está da câmera, se é o jogador com a bola (controlado por uma pessoa), se é replay ou uma jogada acontecendo, e por ai vai. Aqui vai uma figura que mostra a diferença visual entre os niveis de detalhe (LOD):
Note que as etiquetas S1, S2, S3, que são postas entre as quatro renderizações. Você pode tomá-las como transições de uma renderização para outra. (Por exemplo, S1 controla quando a engine do jogo alterna de um jogador em detalhes completos para o mesmo jogador um pouco menos detalhado.) Esse é o significado de S1,S2,S3 na interface da Ferramenta de configuração.
Infelizmente, a engine PES sempre sofreu de um conservadorismo nos baixos niveis de detalhes (LOD), e a troca de modelos complexos para normais acontece muito rápido, e isso resulta em varios artefatos visuais. No PES4-PES6, os exemplos são: jogadores carecas, e detalhes inviveis nos kits. No PES2008-PES2011, os jogadores e juizes ficam com faces genéricas a todo momento, quando se distanciam da camera.
Então, se você tem um ótimo PC e uma placa de Video com boa capacidade, você pode pensar em "turbinar" os detalhes do jogo pelo LOD para fazer estes modelos pesados aparecerem mais frequentemente, mesmo quando os jogadores estão longes da câmera (a qualidade das animações parece ser afetada por isto, também). Para faze-lo,mova as barras para a direita.
Além disso, no raciocinio inverso, se sua maquina está rodando mal o jogo num frame rate insatisfatório, você pode tentar mover a barra do LOD para o outro lado - fazendo a engine carregar mais vezes os modelos com poucos poligonos. Isso pode aumentar a fluência das animações, ao custo da qualidade da imagem. Para isso,mova as barras para a esquerda.
Configurar o LOD Mixer bem leva tempo e se tem melhores resultados na base do erro-e-acerto. (Se algo exato, seria feito sem opções na verdade!) Eu gostaria de mencionar uma serie de observações que devem ajuda-lo a ajustar os melhores valores de detalhes.
Mito nº1: se eu mover todas as barras para direita eu sempre terei a melhor imagem.
Isso simplesmente não é verdade. Você terá a mais detalhada e trabalhosa renderização, sim, mas não necessariamente a melhor imagem. Objetos detalhados vistos de longe ficam piores que outros menos detalhados, por causa do efeito de anti-alising (correção de arestas).
Mito nº2: minha GPU (placa de video) é realmente boa, pode rodar qualquer coisa no talo.
Isso não é verdade, tambem. A geração atual de jogos se tornou bastante sofistiscada e faminta por recursos de processamento. GPU e CPU trabalham pesado para processar renderização, fisica, Lógica da inteligencia artificial. 60 FPS é a tipica fluencia de animações que um jogo deve apresentar, para termos uma jogabilidade aceitavel. Isso significa que a renderização de uma cena inteira deve caber em 1/60 e ainda haver tempo pra outras tarefas na fila. (A Física do jogo, em particular, roda na mesma velocidade, assim a imagem não sofrerá interferencia.) Para ter certeza que o tempo de renderização não trará problemas na medida que são processados, o Nivel de Detalhes é usado como uma técnica de otimização. Movendo todos os sliders para a direita, você está na verdade dizendo à sua placa de video: "renderize todos os objetos na tela com os maximos detalhes possiveis. E se você fritar enquanto faz isso, eu não ligo!". OK, então, não é um exemplo engraçado, mas você deve ter entendido o recado.
Agora, voltando para o nosso jogo, como foi dito antes, em muitos casos, você só precisa mover uma barra ou duas para ter o efeito desejado, mantendo o frame rate atual. Vamos pegar alguns exemplos:
Estes são exemplos básicos. Você poderá notar alguns outros artefatos que gostaria de corrigir. A idéia é: experimente os seus valores de LOD, não configure a esmo tudo no maximo - na maioria dos sistemas irá causar lentidão e queda de frame-rate, porque a sua Placa de Video (e CPU) irá ter muito mais trabalho para executar. Em muitos casos ajustando apenas uma ou duas barras terá o efeito que você deseja, sem influir nos frame-rate (quadros por segundo).
Nem todos estão satisfeitos com o tempo de reação dos jogadores em campo. O que tem que ser considerado é que não é facil simular isso pensando em como acontece num jogo real. Muitos fatores estão em jogo, e alguns deles dependem de hardware. Pessoalmente acho que a Konami fez um ótimo serviço na velocidade do jogo, mas muitos colegas acham que o jogo está muito rápido.
Varias maneiras de desacelerar o gameplay já existiam, e nem todas são perfeitas, mas todos foram criados pra um propósito em especial. O módulo speeder existe basicamente pra desacelerar o relógio, truque pra deixar o jogo mais lento. Esta não é uma solução ideal, mas se for só um pequeno ajuste, ainda pode parecer real sem forçar a barra, e ao mesmo tempo melhorar a experiencia do jogador. Não a considere como uma bala de prata, no entanto. Pode melhorar a sua diversão mas tem alguns efeitos colaterais :) (Um deles, por exemplo: uma partida de 10 minutos com velocidade 0.9 irá durar, na verdade, 11.1 minutos.)
É possivel diminuir e aumentar a velocidade de jogo. O valor 1.0 não muda a velocidade (padrão). Menor que 1.0 - diminuirá a velocidade, maior que 1.0 - aumentará a velocidade. Não é recomendado usar valores menores que 0.7, porque a musica/narração quebrarão no meio. Valores maiores que 2.5 tambem não são suportados. É toscamente rapido em 2.5!.
Usando a Ferramenta de configuração para ajustar a velocidade de Jogo:
Como alternativa, você pode configurar a velocidade do jogo direto no arquivo config.txt, usando a opção count.factor setting:
[speeder] count.factor = 0.95
Este módulo permite mudar livremente o lado do jogador (HOME ou AWAY) em partidas não-amistosas. Bem útil se você gosta de jogar campeonatos com seus amigos, e quer que eles joguem como seus oponentes, ao invés de jogar junto contra a CPU.
Por padrão no jogo, a escolha livre de lado está desabilitada. Para habilita-la, clique na caixa de seleção Free sides selection na Ferramenta de configuração, e aperte o botão [Save].
Ou, como sempre, você pode editar o arquivo config.txt, seção "sides", e definir free.select para 1, como mostrado abaixo:
[sides] free.select = 1
Programação: juce, Robbie e Stelios
Beta-testing: membros e visitantes dos foruns Evo-Web e PesWe.com.
Pasta GDB: Kits do Arsenal por mstar
Kitserver 11 logo: por Ariel
A licença do Kitserver é baseado no BSD e pode ser lida aqui: license.txt
Claudio Pires (aglioeolio) - Pesbrasil.org