Andrade Systems
Em desenvolvimentoFiveM

wasteland_qg

Território e cofre · Lua

O cofre segue o quartel-general, não o clã: se o ponto muda de dono, o conteúdo continua ancorado ali.

Lua
1.082 linhas
Módulos
4

captura, cofre, rendimento e contratos de leitura

Autoridade
servidor

o cliente só dirige a experiência

Fonte verificada no repositório interno em 08/09/2026

O que faz

Em uso

A captura de um ponto é conduzida visualmente pelo cliente — barra, marcador, som — mas quem decide é o servidor: clã válido, tempo mínimo cumprido, cooldown do ponto e distância. A verificação de distância é o que impede a captura remota.

A posse vive numa tabela própria, e a fonte de verdade sobre o clã continua sendo o sistema de clãs, lido por junção. Clã que deixou de existir devolve o ponto como livre, sem precisar de rotina de limpeza.

O cofre reaproveita a interface de armazenamento compartilhada da base e guarda itens físicos em armazenamento persistente. O rendimento passivo só existe para clãs que pesquisaram a tecnologia correspondente, e deposita direto no cofre respeitando teto por item.

Evidência

Como o sistema aparece

Capturas da interface real, renderizada com payload de demonstração derivado dos contratos do resource — organizações, cargos, pessoas e identificadores são sintéticos. Onde não existe interface, entra visualização técnica, rotulada como tal.

  • Visualização técnica

    Captura, posse e cofre: onde cada decisão é tomada, e por que o cofre não acompanha o clã.

Por dentro da engenharia

Decisões de implementação

Um bloco por decisão de implementação. Abra o que interessa.

Cofre vinculado ao território

Problema

Se o conteúdo do cofre seguisse o clã, perder o território não teria custo: bastaria recapturar em outro lugar com o estoque intacto. E se seguisse o clã na tabela, uma disputa transformaria movimentação de item em migração de dados.

Solução

A chave do armazenamento é o ponto, não o clã. Quem controla o ponto acessa o que está lá dentro; quem perde o ponto perde o acesso ao que deixou.

Por que foi feito assim

Território que pode ser tomado precisa ter algo a perder, senão a disputa não significa nada. E ancorar no lugar torna a troca de dono uma mudança de permissão, não de dados.

Posse revalidada a cada operação

Problema

A interface do cofre fica aberta enquanto o jogador organiza itens. Nesse intervalo o ponto pode ter sido capturado por outro clã — e o descritor aberto continuaria autorizando movimentação.

Solução

Cada ação sobre o cofre revalida no servidor se o jogador ainda está no clã que ainda controla aquele ponto. O descritor da sessão aberta não é autoridade.

Por que foi feito assim

Autorização conferida uma vez, na abertura, é autorização válida para sempre. Em sistema onde a posse muda por disputa, isso é uma janela aberta.

Leitura cross-resource protegida

Problema

Este sistema lê as tabelas do sistema de clãs. Se aquele resource não tiver subido, a consulta estoura — e o erro aborta o handler que o cliente está esperando, deixando a chamada pendurada para sempre.

Solução

Toda leitura do vizinho é protegida. Falha vira ausência de dado, não exceção, e o handler responde mesmo assim.

Por que foi feito assim

Chamada bloqueante do cliente que nunca recebe resposta não gera erro visível: gera uma tela girando. É o pior modo de falha possível para quem está jogando.

Stack

O que foi usado

  • Servidor

    • Lua
    • FiveM
    • vRP
  • Dados

    • MySQL 8.0
    • Armazenamento persistente por ponto
    • Trava por cofre
  • Integração

    • Leitura protegida do sistema de clãs
    • Interface de armazenamento compartilhada da base