Skip to main content
Compatibilidade tem dois objetivos: permitir que integrações antigas continuem chamando APIs conhecidas quando existe equivalente seguro, e impedir que dois bancos diferentes virem “fonte de verdade” ao mesmo tempo.

provide não é “rodar os dois”

O RCO pode responder por nomes legacy como rsg-appearance/compatibilidade VORP. Isso resolve dependências, mas o resource stock que foi substituído continua desligado.

Leitura é mais simples que escrita

Um script que só pergunta “o que o personagem está usando?” tende a ser fácil de compatibilizar. Um script que envia um skin blob completo e manda salvar pode sobrescrever rosto/cabelo com dados antigos. Para novas integrações, use a API do RCO diretamente.

SQL legacy não é autoridade

Depois que o personagem possui snapshot RCO, ler/gravar playerskins ou colunas antigas do VORP não substitui o snapshot canônico. Os dados antigos podem continuar existindo por segurança de migração; isso não significa que o RCO ainda salva neles.

Noclip / invisibilidade

Applies de aparência podem reconstruir/refreshar MetaPed. O RCO preserva visibilidade/alpha controlados externamente durante esse processo para evitar que /reloadskin force um admin invisível a aparecer. Se um noclip custom usa outro mecanismo, teste especificamente reload e ped replacement.

Para novas integrações