Brazilian Armed Forces (BRAF) Mod

Aqui consta o repositório do BRAF Mod, modificação para a plataforma Arma 3 inspiranda nas Forças Armadas Brasileiras, a ser utilizado por seus desenvolvedores procurando seguir boas práticas de programação. o versionamento do repositório é feito através do GIT utilizando o seguinte repositório:

http://dev.brafmod.com.br/projectbraf/braf

Checklist de Asset por LODs

LODs de distância

• LOD 1..n
  QUALQUER ASSET DEVE TER LODs DE DISTÂNCIA
• Usar modificador decimate (Blender) em 0.5 como fator entre um LOD e outro além de retirar partes pequenas de acordo com cada LOD de distância
• Utilizar somente um mapa UV, checar no Blender E no Object Builder o nº de mapas UV.
• Deve possuir as seguintes Named Properties: (Object Builder):
  • lodnoshadow = 1;
    Caso o modelo não possua LOD de sombra, seu valor deve ser 0 e devemos usar a seguinte named property no Geometry LOD:
    • sbsource = visualex
      • Utilizável somente em props e prédios em geral, nada que tenha View Pilot.

View Pilot

• O que é visto por piloto/motorista quando se trata de veículos
• O que é visto em primeira pessoa quando se trata de uniformes, peças de vestuário ou armas.

View Gunner

• O que é visto por atirador em veículos ou lançadores estáticos.

View Commander

• O que é visto por comandante em veículos.

View Cargo

• O que é visto por tripulação que não seja FFV (Firing from Vehicles), esta última vira ViewGunner.

Geometry

• É usado para ter colisão na engine do arma entre personagens e veículos contra objetos estáticos como árvore, casa e outras props de cenário.
• O modelo deve ser fechado, com geometria convexa, triangulado e com sharp edges.
• Uma vez importado para o Object Builder, selecione o objeto todo, vá em Structures -> Topology -> Find Components, em seguida adicione uma massa em kilogramas, condizente com o objeto real e no mínimo de 10kg.
• O nº de componentes criado no passo anterior não deve ultrapassar 400 componentes, e cada componente não pode ter mais de 255 triângulos.
• Não pode ter um segundo mapa UV.
• Pressupondo que o objeto esta no centro da cena, deve ter no máximo 200x200 metros, mais do que isso ele não calcula colisão, não existe limite para altura.
• Deve possuir as seguintes Named Properties:, todas em letras mínuscula (Object Builder):
  • autocenter = 1;
    • Caso você queira centralizar o objeto na cena.
  • reversed = 1;
    • Caso você queira mudar a orientação do objeto.
  • map = ????;
    • Variados valores disponíveis aqui, essa propriedade só é relevante para assets que irão em um mapa, permite que sejam mostrados os ícones no mapa 2D do jogo.
  • buoyancy = 1;
    • 1 -> objeto boiará.
    • 0 -> objeto não boiará.
  • aicovers = 1;
    • 1 -> IA vai usar o objeto como cobertura;
    • 0 -> Não vai usar;
  • canbeoccluded = 1;
    • 1 -> O objeto não será renderizado quando estiver atrás de objetosmaiores;
    • 0 -> Será renderizado;
  • canocclude = 1
    • 1 -> O objeto irá impedir o que estiver atrás de ser renderizado,conforme propriedade acima;
    • 0 -> Não impedirá;
  • damage/dammage = ???
    • engine -> O objeto explode quando destruído.
    • building -> O objeto irá afundar no solo e ser substituído por ummodelo em ruínas.
    • wreck -> O objeto será substituído por um modelo destruído,referenciado no LOD wreck.
    • tree -> O objeto irá tombar numa direção aleatória.
    • tent -> O objeto irá colapsar, chapado no chão.
    • wall -> O objeto irá tombar na direção do choque.
  • sbsource = shadowvolume
    • shadowvolume -> O objeto irá gerar sombra utilizando o LOD ShadowVolume.
    • visualex -> O objeto irá gerar sombra utilizando os LOD visuais, muito mais pesados, portanto utilizado somente em objetos estáticos.

Fire Geometry

• Utilizado para detectar colisão e efeitos de colisão entre projetis e qualquer tipo de objeto.
• Segue as mesmas regras gerais do LOD de Geometry, com a exceção de que não precisa ter massa e precisa ter o material de penetração (RVMAT) localizado em /a3/data_f/penetration/ aplicado a fim de calcular a balística intermediária do objeto quando atingido.
• precisam ter os proxies dos ocupantes do veículo, do contrário, não irão sofrer dano.

View Geometry

• Utilizado para cálculo de oclusão (a engine não renderizará o que estiver atrás do objeto), além disso é utilizado para fazer com que a IA do jogo enxergue ou não outras entidades em jogo.
• precisam ter os proxies dos ocupantes do veículo, do contrário, não serão atacados pela IA.
• Precisa ter menos de 3500 vértices em cada objeto.

Geometry PhysX

• Tipo de geometria especial utilizado para detecção e cálculo de colisão entre veículos em geral.
• Também seguem as regras gerais do Geometry, porém devem ser o mais simples possível, e com o menor nº de componentes possível (max 3 em geral) e sem massa.

Geometry Buoyancy

• Tipo de geometria especial utilizada para cálculo de volume de deslocamento em veículos aquáticos ou objetos que boiam na água.
• Também segue as regras gerais do Geometry e caso tenha mais de um componente, os mesmos não devem se intersectar.
• É relacionado com a massa definida no Geometry (e que também pode ser alterada via script).

Roadway

• É um tipo de superfície que permite que unidades caminhem sobre os objetos, sejam estáticos ou não.
• É representado por planos sobrepostos ao LOD de Geometry do objeto e utiliza uma textura localizada em /a3/data_f/surfaces/ para o efeito visual e sonoro ao caminhar sobre o objeto.
• Pressupondo que o objeto esta no centro da cena, pode ter no máximo 72x72 metros.

Memory

• Define pontos de luz, direção de armas de fogo, direção de faróis, direção de escapamento, direção de efeitos de fumaça, pivôs de rotação, eixos de translação, e demais pontos de controle em geral.

Shadow Volume

• Modelo 3D utilizado para o cast de sombra caso o sbsource do LOD Geometry seja diferente de visualex, e também possui n LODs de distância.
• O modelo deve ser fechado e triangulado, e deve ter sharp edges.

Hitpoints

• Define onde certas partes destrutíveis do objeto estão, como rodas, vidros, motor, etc.
• Referência: Arma 3 - Hitpoints

Wreck

• Modelo 3D utilizado para representar o objeto destruído quando o LOD Geometry possui a named property damage = wreck.

Path

• LOD importante para a IA definir o caminho em seu interior (prédios), não requerido em objetos que a IA não precise desviar de obstáculos.
• Vértices onde a IA pode parar precisam ser definidos por uma named selection do tipo "posXX" (XX é um número de 00 a 99).
• Os paths funcionam melhor quando posicionados 10 cm acima da superfície do Roadway.

Display Picture

• Imagem com fundo transparente e tamanho em potência de 2 (como qualquer arquivo .paa, Ex: 128x128px ou 64x128px) que será utilizada para representar o objeto na lista do editor de missões.
• Veículos também devem produzir uma displaypicture em tamanho 1x2 (128x256px por exemplo) para ser utilizado no arsenal ou na ORBAT.

Config de Assets

Os Mods no Arma 3 são um conjunto de PBO's (Public Bank of Files), que são nada mais do que pastas compactadas, que contém os arquivos de configuração e os assets do mod centralizadas no arquivo config.cpp na raíz da pasta em questão, todos os PBOs do BRAF comelam com o prefixo "braf_" para facilitar a identificação.

Padronização de Nomenclaturas

Todas as classes do mod e nomes de arquivos deverão ser precedidas pelo prefixo "braf" e seguir o padrão snake_case, onde todas as letras são em minúsculo e as palavras, não poderão haver carateres especiais como "ç" ou acentos como "í", mantendo de preferência em inglês, separadas por subtraços (" _ "), o motivo é que a engine/mikero por si só já transforma todas as classnames para este padrão, os nomes dos pbos também seguirão este padrão.
Exemplo:

"braf_uniform_rolledup_gloves"

• Classname da farda com manga dobrada e luvas

"braf_static"

• Classname do PBO de armamentos estáticos

Fechando o PBO

• Existem 2 maneiras de compactar uma pasta em um arquivo PBO, a primeira é pelo Addon Builder, disponível pelo Arma 3 Tools, que cumpre a missão de gerar um PBO a partir de uma pasta, porém testa o código muito grosseiramente. A segunda é pelo PBOProject (Mikero's Tools), que além de compactar a pasta em um PBO, também testa o código e o obfusca, garantindo mais segurança e testagem ao mod, o BRAF utiliza o Mikero e sempre que possível, obfusca o PBO.

• Um maior número de PBOs facilita a correção de bugs porém pode tornar o modo confuso, portanto tenta-se manter uma organização quanto ao tipo e juntar os assets que se relacionam em um mesmo PBO.

• Obfuscado x Não Obfuscado

  • A obfuscação do PBOProject (Mikero), garante mais uma camada de segurança e de testagem ao mod, porém implica limitações, nenhum arquivo poderá conter acentos ou caracteres especiais em seu nome e todas as texturas que forem chamadas após a criação do asset, como via script ou texturas de dado, deverão ficar em um pbo a parte. Mesmo quando não obfuscado, é recomendando usar o Mikero pois ele testa o código e aponta erros de sintaxe queo Addon Builder deixa passar, o que facilita a correção de bugs. Todos os PBOs do BRAF são binarizados, independente de serem ou não obfuscados.