Configuração e limitações

Esta página fecha a seção com o que você precisa configurar dos dois lados e onde o desenho encontra suas paredes. Os exemplos de config usam placeholders de propósito — os valores reais da bancada (IPs, chaves, credenciais) nunca vão para um repositório, e os seus também não devem ir.

Segredos nunca vão para o repositório

Tudo que aparece abaixo como SEU_SERVIDOR_IP, <...> ou valor fictício é exemplo. O IP público real, as credenciais de banco do config.lua, chaves privadas, senhas de backup e dumps de player nunca são versionados nem publicados. A chave privada de assinatura JWS mora só no Agent, entregue a ele por arquivo/variável de ambiente fora do controle de versão — nunca no config.lua do OpenTibia. Trate qualquer segredo em texto no repositório como incidente, não como configuração.

Configuração do client

O client precisa saber a qual servidor conectar. Isso vai no init.lua, na lista de servidores. Use o seu IP público no lugar do placeholder.

-- init.lua (client) — VALORES DE EXEMPLO
Servers = {
  MeuServidor = "SEU_SERVIDOR_IP:7171:854"   -- ip : loginPort : protocolVersion
}

-- Deixe o updater vazio para nao travar o login.
Services = {
  updater = ""
}

O formato de cada entrada é ip:loginPort:protocolVersion. Aqui, 7171 é a porta de login e 854 é a versão de protocolo (client 8.54). O Services.updater fica vazio de propósito: um updater apontando para lugar nenhum trava a tela de login.

Configuração do servidor

Do lado do servidor, o config.lua do TFS controla IP e portas. O ponto que mais causa dor de cabeça é o ip: ele precisa ser o IP público.

-- config.lua (servidor TFS) — VALORES DE EXEMPLO, NAO OS REAIS
ip = "SEU_SERVIDOR_IP"     -- IP PUBLICO. O TFS devolve este valor ao client no login.
loginPort = 7171
gamePort  = 7172

-- ... credenciais de banco, etc. ficam aqui e NAO vao para o repositorio ...
sqlHost = "127.0.0.1"
sqlUser = "<seu-usuario>"
sqlPass = "<sua-senha>"
sqlDatabase = "<seu-banco>"

IP público obrigatório dos dois lados

O TFS devolve o valor de ip ao client no login para o client saber onde conectar o mundo. Se você puser aqui o IP privado da máquina, o sintoma é característico: a lista de personagens aparece, mas entrar no mundo falha — o login (porta 7171) resolveu, mas o game (porta 7172) foi mandado para um endereço que o client não alcança. Use o IP público no config.lua do servidor e no init.lua do client.

O endereço e a chave da Lootfy NÃO ficam no config.lua

O config.lua do OpenTibia não conhece a Lootfy. A URL base da plataforma, a API key e a chave privada de assinatura são configuração do Agent (LOOTFY_BASE_URL, LOOTFY_SERVICE_API_KEY, LOOTFY_JWS_PRIVATE_KEY_FILE…), não do servidor de jogo. Essa separação é o que mantém a chave privada longe do Lua e do banco do parceiro.

Bancada vs entregável

Vale ter clareza sobre o que, do case, você de fato leva para o seu servidor e o que fica na bancada como referência:

O que é entregável

• O módulo de client game_lootfy — a pasta que você solta em modules/. Sanitizado, portável, instala sem recompilar.
• O patch de engine doLootfyDeliver — os quatro arquivos-fonte C++ que você aplica e recompila (ou o equivalente, se a sua engine é outra).
• A forma do Lua de servidor — como o opcode.lua valida contra o cid e delega ao Agent. Referência de desenho, adaptada ao seu servidor.

O que é só bancada

• O servidor OpenTibia da bancada em si — com IPs reais, credenciais de produção, dumps de player e histórico com dívida de segurança. Nunca é publicado.
• O binário pré-compilado da engine — específico da toolchain e arquitetura da bancada.
• Qualquer arquivo de config com valor real (config.lua preenchido, bench.staging.json, chaves .pem). Fora do portal, fora do repositório.

As limitações reais

Estas não são pendências que serão resolvidas — são restrições do ambiente OpenTibia antigo, e cada uma explica uma decisão do desenho.

1. O client 8.54 não seta header HTTP customizado. A chamada HTTP dele não aceita headers, e a assinatura viaja no header X-Lootfy-Signature. Consequência: o client não pode carregar o envelope assinado, então o servidor assina e envia (o ramo B). É a razão de o Agent e o opcode 221 existirem nesse desenho.

2. O binário da engine é x86-64 / Debian, sem build Windows. A bancada roda um binário pré-compilado para Linux x86-64. Não há build Windows pronto; rodar em Windows exigiria portar a toolchain.

3. Recompilar o TFS 0.3 é um projeto à parte. Aplicar o patch de entrega exige compilar a engine com a toolchain antiga (container debian:bullseye-slim, autotools, bibliotecas -dev). Se você não compila a sua engine hoje, reserve tempo para esse passo — ele é independente do resto da integração.

4. IP público obrigatório dos dois lados. Como visto acima, tanto o config.lua do servidor quanto o init.lua do client precisam do IP público, ou o jogador não entra no mundo.

Se a sua engine é outra

Todas essas limitações são do OpenTibia 8.54 / TFS 0.3 da bancada. Um parceiro com um client moderno que saiba setar header pode usar o ramo A e dispensar parte do vaivém pelo servidor; um parceiro com outra engine implementa o equivalente de doLootfyDeliver com os próprios bindings. O que não muda, em nenhum caso, é o contrato: o servidor assina, o client transporta, a plataforma verifica, e nenhum dinheiro do jogo se move na entrega.

Guia de Integração (genérico) O contrato de integração para qualquer engine — endpoints, assinatura JWS e a ordem recomendada de implementação.