Operation Flashpoint Dragon Rising Mission Editor Tutorial

Criando a Primeira Missão p4 - Scripts (Script dinâmico de detecção - Timers)

2009-11-25T15:30:00.000-08:00

Olá Pessoal. Hoje iremos falar sobre os scripts contidos na missão.

Como de praxe, antes de começarmos, para quem entrou a primeira vez no blog. Baixe os arquivos da missão e o entityDatabase.xml no post p1 do "Criando a Primeira Missão", aqui (http://ofp2editor.blogspot.com/2009/11/criando-primeira-missao-metralhadoras.html)

ATENÇÂO: Faça download novamente da missão pois houve correção nos scripts.

Antes de começarmos a falar dos scripts contidos na missão. Vamos falar de como funciona a utilização de scripts no OFP DR.

Os caras da Codemasters foram espertos. Ao invés de criarem toda uma biblioteca de comandos, funções e um interpretador para tudoi isso, como haviam feito os caras da Bohemia Interactive no Antigo Operation Flashpoint ou na série Armed Assault, eles simplesmente pegaram a biblioteca da linguagem Lua e incluíram no Jogo.

O que é a Linguagem LUA ?

Lua é uma linguagem desenvolvida por Brasileiros (êêêê !!!), criada pela Puc-Rio e originalmente projetada para estender aplicações. Lua nasceu e cresceu no Tecgraf, o Grupo de Tecnologia em Computação Gráfica da PUC-Rio. Atualmente, Lua é desenvolvida no laboratório Lablua. Tanto o Tecgraf quanto Lablua são laboratórios do Departamento de Informática da PUC-Rio.

Atualmente é utilizado em outras aplicações como Adobe Photoshop Lightroom, ou mesmo World of Warcraft, justamente para a criação de scripts e prototipagem. Ele também contempla sistemas embarcados através de uma máquina virtual, que também existe dentro do jogo.

A linguagem compreende todos os aspectos de uma linguagem orientada a objetos. Tipos de dados que trabalham como classes, com métodos próprios, semelhantes a javascript ou mesmo java.

Diferentemente do OFP ou Arma, onde você tinha um tratamento muito pobre para tipos de dados, agora com a LUA, o jogo pode contemplar tratamento e formatação de dados numéricos e strings. Métodos complexos de manejo de strings, arrays e outros tipos de dados, como splits, sorts, formats; inclui tipo de dados de Tabela, com definições de campos e registros; contempla funções de I/O permitindo o leitura e gravação de arquivos (durante a missão, o que permite interação com o jogo fora dele, através de um site por exemplo.). Enfim, a linguagem do jogo é tão poderosa, que você poderia até desenvolver uma aplicação para fins comerciais dentro dele (como um conversor de arquivo por exemplo).

Guia de Referências sobre o LUA

Segue abaixo um site com as referências e tutorialis para a Linguagem LUA.

http://lua-users.org/wiki/TutorialDirectory

Inserindo Scripts na Missão

Em teoria, não detalhamos os scripts, mas na prática se você acompanhou o blog desde o princípio, você já os criou para trabalhar com eventos como onMissionStart, onEnter ou onDeath.

Para poder trabalhar com scripts LUA dentro da missão iremos utilizar 1 dos 3 componentes na Caixa de Ferramentas Create.

Os componentes que você irá utilizar:

- Level Script caso você precise manipular eventos como onEnter, onDeath, onPlaceableKill, etc.

- Library Script caso você crie uma lib (conjunto) de scripts que serão exportados a outras missões. Ainda não testei como é feita essa exportação de dados.

- Secondary Script para criação de scripts secundários que também não manipula eventos.

Você pode ter mais de 1 tipo de componente, como 2 Levelscript na mesma missão, e caso você repita as funções, por exemplo ambos os componentes scripts chamando funções de onDeath, o jogo irá executar os 2 onDeath, tanto de um componente como do outro.

Em nossa missão existe 2 componentes Level Script. Um componente, o level.lua existe para tratar eventos específicos da missão, como o controle de triggers, as manipulações onDeath, onMission e etc. Um segundo componente, batizado de lib.lua, contém um conjunto de funções para trabalhar com um script responsável por gerenciar a detecção de unidades dentro da missão.

Script de Detecção de Unidades

Nesta missão para dar dinamismo ao jogo, resolvi criar um script que trabalha com uma lógica para detecção um pouco interessante. No jogo, originalmente quando você ataca um soldado, você é identificado de imediato, e o jogo irá chamar eventos onSuspected no mesmo momento, e isso não corresponde muito bem a realidade. A idéia é que nenhuma unidade é detectada e identificada de imediato. Num cenário real, os soldados do esquadrão se deparariam com a ameaça, identificariam a ameaça e depois pediriam reforço, e entre estas ações há um pequeno intervalo de tempo. Mesmo porque apenas um ou dois membro do esquadrão teriam acesso de rádio com a base.

Portanto a regra do script é a seguinte:

A partir do momento que o esquadrão(um echelon) inimigo detecta um player, o player terá x segundos para eliminar todo o esquadrão até que seja informado sua detecção.

Isso inclusive aumenta a coordenação de fogo por parte equipe, já que irá envolver sincronia.

Descrevendo os Scripts lib.lua

Na nossa missão, abra (com um duplo clique) o componente lib.lua.

Você irá cair no editor.

Repare que o componente lib.lua nada mais é do que um arquivo txt com um conjunto de funções "encapsuladas" em um componente separado.

Não existe arquivo externo de scripts. Tudo é feito dentro do próprio editor.

Vamos dissecar as funções deste script:

Antes de tudo iremos definir as variáveis utilizadas por este script, que são:

vetGrp - Matriz que irá guardar os grupos que detectaram presença até agora. É um vetor unidimensional, mas que compreende duas informações a cada "elemento", que são o hora da detecção (vale lembrar que o jogo trata o tempo em milisegundos, onde meia noite irá corresponder ao milisegundo 0) e o nome do elemento que detectou.

INIMIGO_DETECTADO - Variável booleana(verdadeiro / falso) que será responsável por informar se já houve detecção CONFIRMADA de inimigos. É apenas um "flag" caso queiramos parar o script para não ocupar o processador.

As variáveis no LUA respeitam o escopo. Portanto, em lib.lua, essas variáveis são locais dentro do script, portanto serão visívels para todas as funções contidas neste script. Veremos essas variáveis sendo usadas dentro das funções lib.lua.

Existem funções que são ignoradas dentro da missão porque não removi. é Lixo. Entre elas estão as duas primeiras monstra_mensagem (errei e nem percebi), countArray e onMissionStart, que nada mais faz do que tentar criar um componente timer, mas pelo que percebi o onTimer deste componente não funciona se escrito dentro de Level Script com outro nome, que não seja level.lua, por isso tanto o timer como as funções deste timer (libTimerEc e onTimer_libTimerEc) não funcionam.

Função TimerEchelonDeath

Esta função é responsável por incluir um grupo e o tempo máximo para detecção dentro da matriz vetGrp.

Ela recebe os parâmetros grupo e miliSeg, que são o nome do grupo(echelon) que detectou os players (um dado tipo string) e o tempo máximo em milisegundos até que este grupo reporte a detecção para a base.

Logo no início vemos as declarações das variáveis utilizadas dentro da função. Vale lembrar que aqui não precisamos declarar o tipo de dados(string, boolean, inteiro) para a variável, acredito que nem mesmo haveria problema para a execução em não declará-la como local, poderia sim haver conflitos em outros pontos, caso haja nomes semelhantes.

Em seguida vemos as primeiras instruções.

if INIMIGO_DETECTADO then

return;

end;

Aqui estou verificando se a variável local do script lib.lua INIMIGO_DETECTADO já está ativa, e caso esteja, sai da função com o return abortando a inclusão de novos elementos na tabela. Isso porque em nossa missão me basta que inimigos sejam detectados apenas uma vez.

if string.format("%s", grupo) == "nil" then

return;

end

Este trecho nada mais faz do que verificar se a variável grupo é o nome de um grupo válido. Do contrário, caso você crie uma unidade que não seja atrelada a um Echelon, essa variável virá com o conteúdo "nil" (de nulo). Portanto aqui, se o grupo vier como nulo, "nil", a função também é abortada.

Em seguida iremos verificar se o grupo já não está na contido no vetor vetGrp através do trecho:

i=0;

while i < #vetGrp do -- inicio de loop while

igrupo = vetGrp[i + 2];

if string.lower( grupo) == igrupo then -- inicio de if

return;

end -- fim de if

i=i + 2;

end -- fim de loop while

OBS: "--" serve para inserir comentarios

O que acontece é que dentro de um echelon, se você tiver 2 soldados e estes detectarem uma mesma unidade inimiga, serão chamados 2 eventos onSuspected, um para cada soldado que detectou o inimigo. Por isso faço este teste de duplicidade.

O que fiz foi criar uma variávei de indice i e a zerei , em seguida crio um loop while que diz que enquanto a variável i for menor do que o total de elementos do vetor vetGrp ( while i < #vetgrp do) , e o caractere # tem a função de retornar o número total de elementos dentro da matriz.

E dentro deste nó while (que compeende nas linhas de comentario inicio do loop até o fim do loop), irei ler os dados da matriz vetGrp e compará-lo com o parametro grupo passado na função.

Começo retirando o nome do grupo de dentro da matriz atraves da instrução da linha igrupo = vetGrp[i + 2];

Para você acessar o elemento de uma matriz, basta você informar nome_matriz[indice], cujo o indice é um numero de 1 até o total de elementos dessa matriz. Aqui, lembre-se, é uma matriz unidimensional que compreende um par de informações, a hora máxima(em milisegundos) para detecção e o nome do grupo. Portanto i(que se iniciou em 0) com mais 2 teremos 2, e assim no primeiro nó do loop, acessamos o nome do grupo do primeiro par de informações.

Em seguida com o trecho

if string.lower(grupo) == igrupo then

return;

end

Estou comparando se o nome do echelon na variável igrupo que retirei da matriz vetGrp, é igual ao nome do echelon passado como parâmetro através da variável grupo. Caso o grupo informado no parâmetro já exista dentro da matriz, então a função é abortada através do return.

Note que uso a função lower para transformar tudo em minúsculo. Faço isso porque o jogo converte tudo em lowercase. Se você criar um soldado com nome "soldadoDeCampo", caso você dê um display do nome desse soldado, será exibido "soldadodecampo". E atenção com isso, pois o LUA Script é Case Sensitive, ou seja, "soldadodecampo" é diferente de "SoldadoDeCampo" são informações diferentes. Por isso acostumem-se com esta função.

Em seguida incremento a variável de indice em 2 (2 passos), e assim, no próximo nó do loop, caso o índice continue a ser menor do que o numero total de elementos do vetor vetGrp, a variável i estará em 2, e o vetGrp[i+2] será vetGrp[4].

E assim repito as operações até que i seja igual ou maior do que o numero de elementos do vetor vetGrp. E caso não dê duplicidade ele continuará o código pois não abortou a função.

Depois disso, basta apenas inserirmos as informações no vetor vetGrp, através das linhas.

table.insert( vetGrp, (OFP:getMissionTime() + miliSeg));

table.insert( vetGrp, string.lower(grupo) );

A primeira linha iremos fazer a inserção da informação do tempo máximo para o grupo reportar detecção para a base. Como, na verdade, o tempo máximo é a hora do momento + o tempo de espera, fazemos essa soma nessa linha, através da função getMissionTime.

A segunda linha incluimos o nome do grupo, já gravando como minusculo inclusive.

E assim, toda a vez que um grupo AI inimigo detectar um player, ele irá incluir no vetor vetGrp, caso já não esteja incluído, o nome deste grupo, e a hora máxima para que todo este grupo AI inimigo esteja morto, do contrário ele irá reportar detecção.

Função verifDetecta()

O que está função irá fazer é exatamente o que eu disse no parágrafo anterior.

Ela irá percorrer todos os elementos do vetor em pares de 2 em 2, irá comparar se a hora atual é maior ou igual a hora máxima para reportar detecção.

Caso a hora atual seja maior ou igual a hora máxima retirada do vetGrp, então a função conta o número de AIs vivos dentro do echelon inimigo que detectou os players. Caso existam unidades vivas, então é reportado a detecção mudando a variável INIMIGO_DETECTADO para true (verdadeiro).

Vamos depurar a função:

Depois das declarações de variáveis locais da função, temos:

if INIMIGO_DETECTADO then

return;

end;

Aqui faço a mesma verificação da função TimerEchelonDeath, pois caso já tenha sido reportada detecção, então sai da função. Pois não me interessa ficar ocupando processador com tarefas que não serão mais utilizadas.

Neste trecho

i=0;

while i < #vetGrp do

valor = vetGrp[i+1];

grupo = vetGrp[i + 2];

if (OFP:getMissionTime() >= valor) then

if OFP:getEchelonSize(grupo)>0 then

INIMIGO_DETECTADO = true;

return;

else

table.remove(vetGrp, i + 2);

table.remove(vetGrp, i + 1);

end

else

i=i + 2;

end

Acima está todo o processo de verificação.

Como na função TimerEchelonDeath, irei percorrer todo o conteúdo do vetor vetGrp utilizando uma variávei de indice, a "i", e o loop "while i < #vetGrp do" , lembrando que o caractere # tem a função de retornar o número de elementos de um vetor.

A cada nó do loop procedo da mesma maneira, só que aqui capturo a informação de hora e grupo. através das linhas:

valor = vetGrp[i+1];

grupo = vetGrp[i + 2];

Depois comparo os valores de hora máxima contida no vetor vetGrp, que foi passada para a variável "valor", com a hora da missão, utilizando a função OFP:getMissionTime().

if (OFP:getMissionTime() >= valor) then

...

else

...

end

Caso a hora da missão seja maior ou igual a hora máxima então irei contar o número de unidades vivas dentro do echelon utilizando:

if OFP:getEchelonSize(grupo)>0 then

...

else

...

end

A função OFP:getEchelonSize retorna apenas as unidades vivas, a função OFP:getEchelonFullSize retorna as vivas + mortas.

E assim, caso tenhamos unidades vivas, irei informar a variável INIMIGO_DETECTADO com o valor true e sair da função, através das linhas:

INIMIGO_DETECTADO = true;

return;

E caso contrário, não tenhamos mais unidades vivas dentro deste echelon (pois todos foram mortos antes do tempo máximo), então não há mais porque verificarmos este echelon, logo, ele pode ser removido do vetor vetGrp para não cupar mais processamento. Isto é feito através das linhas:

table.remove(vetGrp, i + 2);

table.remove(vetGrp, i + 1);

Note que na remoção dos elementos, removo do maior para o menor. Isso porque o vetor funciona como uma pilha de argolas, e o índice aponta exatamente para a posição do elemento da pilha, logo por exemplo, se temos a[1] = "A", a[2]="B" e a[3]="C", quando removermos o a[2], que é "B" o novo, a[2], passará a ser "C".

Portanto, como você pode concluir, as linhas abaixo também funcionariam:

table.remove(vetGrp, i + 1);

Lembre-se, que como removemos 2 elementos, não precisamos avançar o índice, na variável "i". E é isso que fazemos quando deixamos esta atribuição (i=i + 2;) no else da comparação entre a hora atual e hora máxima para detecção. E assim, ele só incrementa a variável, caso nenhuma ação tenha sido tomada: nem detecção, e nem morte de todos os elementos do echelon que detectou.

Função retInimigoDetectado()

Essa função nada mais faz do que retornar o valor da variável INIMIGO_DETECTADO para aquem fez a chamada.

Eu poderia ler diretamente o valor da variável INIMIGO_DETECTADO, mas por convenção, desenvolvedores retornam atributos(variáveis que informam uma propriedade) através de métodos(funções).

Função restartTimerEchelonDeath()

Essa função tem a tarefa de reiniciar todo o processo, caso os players já tenham sido detectados e a variável INIMIGO_DETECTADO já esteja com valor true.

A função irá zerar a variável INIMIGO_DETECTADO com o valor false, e zerar o conteúdo da variável vetGrp, da seguinte maneira:

function restartTimerEchelonDeath(grupo, miliSeg)

INIMIGO_DETECTADO = false;

vetGrp={};

end

OBS: caso a linha "vetGrp={};" não esteja em sua missão, inclua. Pois não lembro de ter atualizado antes ou depois de ter upado a missão.

Pronto.

Nossa lib de detecção de players dinâmica está pronta. Iremos, agora, ver como iremos interagir com ela dentro da missão.

Voltando para o script level.lua

Antes de mais nada, para interagir com as funções do level script lib.lua, temos que declará-lo dentro do script level.lua para que suas funções possam ser legíveis.

Dentro do script level.lua, farei isso na função de evento onMissionStart, que lembrando, é chamada automaticamente no início da missão. Abra o script level.lua, clicando 2 vezes sobre ele, procure a função onMissionStart e na última linha da função, você verá:

lib = scripts.mission.lib;

Utilizei o nome da variável lib (que está em negrito) apenas para referenciar facilmente com o verdadeiro nome. Mas o nome desta variável poderia ser o que você preferir. Lembrando a partir desta variável que você terá acesso aos métodos(funções) do script lib.lua.

O nome que você informou em seu level script, no caso lib, deve ser passado na declaração informando o prefixo "scripts.mission.", como fiz.

Após declarado o script dentro do level.lua. Vamos ver agora os principais pontos de interação com o script.

Iremos começar pela função de evento onSuspected. Nela o que faço antes de tudo, é verificar se o que foi detectado é uma unidade west(USMC), se o seu detector é uma unidade east(PLA), e se a unidade west detectada, pertence ao echelon dos jogadores.

Verifico também se o inimigo já não reportou detecção (INIMIGO_DETECTADO) através da função lib.retInimigoDetectado().

Então a unidade que detectou seja válido e ainda não tenha sido reportado a base, iremos incluir este echelon lá na variável vetGrp, informando um tempo randonico de 4000 a 7000 milisegundos (4 a 7 segundos), utilizando a função TimerEchelonDeath(). Veja:

if (OFP:getSide(victim ) == 0) and (OFP:getSide(suspector) == 1) and ( string.lower(OFP:getParentEchelon(victim))== "grpplayer" ) then

if lib.retInimigoDetectado()==false then

lib.TimerEchelonDeath(OFP:getParentEchelon(suspector),

math.random (4000,7000));

end

OFP:setTimer("timerInimigo", 2000);

end

Note que após verificar se o status de detecção continua false e ter informado o grupo echelon e o tempo(sorteando um tempo aleatório entre 4 e 7 segundos), eu ajusto o componente timerInimigo para 2000 milisegundos(2 segundos) usando a função OFP:SetTimer()

Timers

Os timers são componentes utilizados, como vc já presume, para executar uma tarefa após um determinado tempo.

No antigo OFP você poderia gerar um delay no processamento do script simplesmente informando ~N (~ e o número em segundos) o tempo de espera. Isso não existe mais, pelo menos até onde eu sei.

Então, como não posso mais usar um loop while infinito utilizando um delay para uma verificação que se repete, eu tive que criar este componente timer. O timerInimigo é criado dentro da função onMissionStart(), na linha:

OFP:addTimer("timerInimigo", 1000);

O primeiro parâmetro, "timerInimigo" é o nome do componente timer, o segundo parâmetro é o tempo (em milisegundos) para a chamada do evento onTimer.

Quando você cria um componente timer, o jogo irá automaticamente fazer uma chamada a um evento onTimer_, onde aqui, é onTimer_timerInimigo(), veja:

function onTimer_timerInimigo()

lib.verifDetecta();

if lib.retInimigoDetectado()==true then

OFP:setObjectiveState("objSuspeita", "FAILED");

OFP:displaySystemMessage("Detectado");

OFP:disableEvent("onSuspected");

OFP:disableEvent("onTimer_timerInimigo");

end

OFP:setTimer("timerInimigo", 1000);

end

Vale lembrar que o timer não é cíclico. O evento onTimer é chamado uma única vez após o timer tiver sido, ou criado, ou "setado". Por isso, na linha em negrito, "seto" o timer para ser ativado novamente em 1 segundo (1000 milisegundos), através da função OFP:setTimer.

Continuando

E assim depois de ter inserido o grupo e o tempo máximo no vetor vetGrp, lá na função lib.timerEchelonDeath do script lib.lua, é hora de fazer a verificação deste tempo. E é exatamente o que você viu no código da função de evento onTimer_timerInimigo().

A cada passagem pela função de evento onTimer_timerInimigo() faço a verificação com a função lib.verifDetecta (que lembra ? Compara a hora máxima com hora atual, e verifica se o echelon tem unidades vivas), e caso tenha havido report de detecção a variável INIMIGO_DETECTADO lá em lib.lua será mudado para true.

E assim, quando eu fizer a chamada da função lib.retInimigoDetectado() (que nada mais faz do que me retornar o valor da variável INIMIGO_DETECTADO lá da lib.lua), entrarei na condição para executar as linhas:

OFP:setObjectiveState("objSuspeita", "FAILED");

Seta o elemento objSuspeita no mapa para failed.

OFP:displaySystemMessage("Detectado");

Exibe a mensagem "Detectado"

OFP:disableEvent("onSuspected");

Desabilita qualquer chamada ao evento onSuspected, pois o objetivo

já foi pro saco

OFP:disableEvent("onTimer_timerInimigo");

Desabilita o evento onTimer_timerInimigo, já que não precisamos verificar

nada.

Estes eventos é que se sucederão caso haja detecção. Mas você poderia incluir o que quisesse, poderia encerrar a missão como falha, poderia ativar a chamada de um reforço ou apoio, enfim, o que você quiser. Basta incluí-los dentro do nó if then:

if lib.retInimigoDetectado()==true then

...

Seus próprios comandos

...

end

É óbvio que para quem nunca mexeu com desenvolvimento ou programação, trabalhar com os scripts lua é tarefa um tanto incômoda. Por isso aconselho alguma familiarização dentro do próprio help que passei.

Espero ter sido útil.

Dúvidas, podem postar no comentário que eu recebo por e-mail.

Saudações.

Criando a Primeira Missão p3 - Unidades de Infantaria Customizadas

2009-11-21T09:54:00.000-08:00

Olá pessoal. Hoje falaremos a respeito de unidades customizadas.

Antes de começarmos a falar a respeito, não se esqueça de baixar e instalar os arquivos necessários para abrir a missão, que você encontra em http://ofp2editor.blogspot.com/2009/11/criando-primeira-missao-metralhadoras.html

Para criar essa primeira missão, eu havia pensado em criar uma campanha com missões exclusivamente black ops. E para isso, as unidades tinham que ser equipadas com armamento no turno e siliencioso.

Vasculhando o fórum da Codemasters, e mesmo o guia de comandos do help do mission editor, não consegui encontrar nenhuma função ou método para a troca de armas das unidades durante a missão, ou mesmo na entrada.

O único método que encontrei para fazer algo parecido foi um tópico sobre criação de unidades customizadas. Em resumo, você abre o "arquivo de definições de entidades" do editor, e insere lá dentro uma nova unidade com as armas e itens que você deseja incluir.

Este arquivo de entidades é um arquivo do tipo xml, que contém uma série de chaves de propriedade que indicarão o objeto a ser alterado. Ele se encontra no diretório do mission editor, e você terá que abrí-lo externamente (com um editor de texto, de preferência que abra arquivos xml, como o syneditor, ultra-edit, editplus, etc..).

O arquivo se encontra dentro do diretório do editor de missões do OFP DR, que geralmente fica em:

...\operation flashpoint dragon rising\Mission Editor\Database

O nome do arquivo é EntityDatabase.xml

Este arquivo é grande, tem quase 4mb, um tamanho grande para um arquivo do tipo texto. Por isso quando for abrí-lo em seu editor, não se assuste se isso demorar um pouco. NÂO SE ESQUEÇA DE FAZER UMA CÓPIA DE BACKUP DO ARQUIVO, POR SEGURANÇÃ.

Um arquivo padrão XML, em teoria é uma regra unificada entre os desenvolvedores de especificar objetos ou entidades estruturais de modo a organizar das as propriedades de forma hierárquica e legível . Na computação arquivos XML podem informar qualquer coisa, os dados de um fornecedor, dados de uma configuração de sistema, informações de sua agenda de endereços (como no outolook), enfim, qualquer coisa mesmo.

No mission editor, esses dados XML informarão entidades do jogo, desde armas, até unidades e veículos. E será em cima das unidades de infantaria que iremos implementar nossas unidades customizadas.

Abra o arquivo EntityDatabase.xml.

Ao abrir o arquivo, você irá ver uma porrada de chaves XML, cada uma definindo uma propriedade do elemento de entidade. As primeiras linhas são elementos de dados de configuração de tipos, somente adiante iremos encontrar dados dos elementos de unidades e veículos. Use a ferramenta find/search/procurar/pesquisar de seu editor para encontrar as entidades de infantaria informando a palavra "rifleman". A forma mais simples que encontrei para replicar as unidades é buscá-las no arquivo com o nome lá no mission editor, por exemplo "USMC Special Operations Rifleman", ou "USMC Medic", ou "PLA Sniper".

No meu arquivo, ao pesquisar a palavra rifleman, caí direto neste trecho.

O que vemos aí, são as definições necessárias para se compor uma unidade USMC Special Operations Rifleman. O trecho que compreende essas definições começa na linha 3120 e termina na linha 3139. Chamamos essas tags < >..< / > de início e fim de um elemento, caso houver mais elementos dentro de um elemento (<> <>..< / > < / > ), os elementos interiores são hierarquicamente descendentes dos elementos exteriores, chamados de filhos ou aqui, sub-elementos. A unidade é composta definindo seu elemento de tipo de "aparência" , seus sub-elementos de itens, armamentos primários, secundário. Aqui, cada elemento possui um ID (Não é FolderID ou ParentID), e como você já pode concluir ele é único e não pode se repetir no arquivo.

E assim vamos compor a nossa unidade customizada, utilizada para a missão.

Como a missão é noturna, quis pegas as unidades especiais de operações black op, que são os Hildalgos. Então fiz uma pesquisa no arquivo informando a palavra hidalgo, e caí na linha 39392, o elemento do soldado tipo "Hidalgo Stealth Variant" lá no editor. Então simplesmente peguei o trecho que fechava o elemento, e usando o CTRL + C e CTRL + V repliquei a unidade no arquivo. Depois disso tive que tirar suas duplicidades para não causar conflitos no mission editor e nem na missão criada.

O que é necessário alterar:

-Na linha do

-Todas as propriedades ID contidos neste trecho de EntityTemplate, que basicamente são as linhas "

Agora, procure dentro do arquivo EntityDatabase.xml que você baixou aqui do blog e pesquise utilizando o trecho "Psy Ops". E veja:

Note as alterações em Name, nos IDs (lembrando que este soldado será uma réplica do soldado hidalgono ), e em seu armamento e equipamento nos elementos Itens e SlotPrimaryB, SlotPrimaryF, e SlotSecondary.

O elemento SlotPrimaryF refere-se a arma que o soldado irá carregar nas mãos.

O elemento SlotPrimaryB refere-se a arma que o soldado irá carregar nas costas (B de Back).

O elemento SlotSecondary refere-se a arma de mão (pistola) que o soldado irá carregar.

Os elementos Itens de Item00 a Item07 irão definir as munições e equipamentos carregados. Lembre-se que os Itens devem incluem a munições das armas principais.

Segue uma lista que encontrei num tópico da Codemasters. O cara colocou os nomes das armas em negrito e seus respectivos nomes de munições como normal.

sa53m21 - M21 Sniper Rifle

am20mag762balls
am20mag762fmjs
am20mag762jhps
am20mag762fmj
am20mag762ball

sa11m2000 - M2000 Shotgun - DOES NOT WORK

sa10m1014 - M1014 Shotgun - DOES NOT WORK
am1she12buck
am1she12aphe

hw01javelin - FGM-148
ex49javelin

hw03smaw - SMAW
ex68smawheat
ex69smawhef

hw10fim92a - FIM-92A
ex72fim92a

sa12m16a4 - M16A4
sa15m16a4a - M16A4 w/ 203
sa13m16a4cqb - M16A4 w/ Eotech
sa14m16a4m - M16A4 w/ ACOG
sa16m16a4no - M16A4 w/ Night Optics
sa17m16a4s - M16A4 w/ Silencer
sa18m4a1 - M4A1
sa21m4a1a - M4A1 w/ 203
sa19m4a1cqb - M4A1 w/ Eotech
sa20m4a1m - M4A1 w/ ACOG
sa22m4a1no - M4A1 w/ Night Optics
sa23m4a1s - M4A1 w/ Silencer
am30mag556ball
am30mag556fmj
am30mag556jhp
am30mag556sub - USE WITH SILENCED WEAPONS

sa51m32 - M32
am6drum46he
am6drum46hedp

sa39m240 - M240 Medium MG - DOES NOT WORK

sa55m107 - M82 Rifle
sa56m107no - M82 w/ Night Optics
am10mag99fmj
am10mag99apds
am10mag99aphe

sa37m249 - M249 LMG
am200box556ball
am200box556fmj
am200box556jhp

sa40mk48 - Mk48 M0 Medium MG
sa41mk48cqb - Mk48 w/ Eotech - DOES NOT WORK
am100box762ball
am100box762fmj"

sa03mp5a4 - MP5
sa05mp5a5 - MP5 - DOES NOT WORK
sa06mp5sd3 - MP5 SD - DOES NOT WORK
sa04mp5a4no - MP5 w/ Night Optics - DOES NOT WORK
am30mag9ball
am30mag9fmj
am30mag9jhp

sa24mk16 - MK16 SCAR-L
sa30mk16s - MK16 SCAR-L w/ Silencer
sa26mk16cqb - MK16 SCAR-L w/ Eotech
sa28mk16a - MK16 SCAR-L w/ 203
am30mag556ball
am30mag556fmj
am30mag556jhp
am30mag556sub

sa25mk17 - MK17 SCAR-H
sa27mk17m - MK17 SCAR-H w/ ACOG
sa29mk17no - MK17 SCAR-H w/ Night Optics
am20mag762ball
am20mag762fmj

Essas são as definições dos nomes de armamentos e munições que integrarão as propriedades Values dos elementos de itens e armamentos. Basta trocá-los e informar sua quantidade.

Trabalhar com este arquivo ficou mais complicado para os modders, dificultando um pouco a criação de pacotes de addons para distribuição, já que para distribuir, terão que interagir com este arquivo.

Bom amigos. Por hoje ficamos por aqui. Faça experimentos, teste as armas e equipamentos e brinque à vontade.

No próximo tópico, vamos ver se eu falo a respeito do script de detecção da missão.

Saudações

Criando a Primeira Missão p2 - Apoio Externo (Reforço Inimigo) aéreo e blindado.

2009-11-19T22:35:00.000-08:00

Bom Pessoal.

Vamos continuar as explanações acerca de nossa primeira missão. Lembrando que seria ideal que você a baixasse e tivesse em sua máquina para acompanhar. Os arquivos e as explicações para baixar e "instalar" a missão segue aqui (http://ofp2editor.blogspot.com/2009/11/criando-primeira-missao-metralhadoras.html)

O assunto principal deste post serão os Reforços Inimigos vindos das redondezas. E para que um reforço externo funcione adequadamente, ou seja, ele deve ser chamado através de uma trigger ou condição específica do jogo, sair de onde está, se deslocar até o ponto e iniciar o combate. Não é difícil, mas pode envolver diferentes métodos e sempre usando diversos recursos, inclusive funções em script.

Em nosso mapa temos 5 conjuntos reforços, e digo conjunto porque alguns são echelons de infantaria, outros unidades blindadas com tripulação virtual, e outro um echelon de pilotos que irá entrar dentro helicóptero e seguir até o ponto ou rota.

A oeste da Estação de Bombeamento, em D21 X1Y6, temos 4 dos 5 conjuntos totais de grupos e unidades que integrarão o reforço até a Estação de Bombeamento quando ela for atacada.

Note que ao sudoeste, em H20 X4Y3 está o helicóptero com sua tripulação (desembarcada).

O Helicóptero e as infantarias e blindados irão prestar o reforço utilizando métodos diferentes. No o Heli, simplesmente levantará vôo e assumirá uma path para uma rota de patrulha cíclica. Para dar um realismo do tipo "Search and destroy" vamos mexer em doctrine e mood. Já as unidades de infantaria irão simplesmente moverem-se até o alvo utilizando a função OFP:defendPos, que como o próprio nome já diz, manda uma unidade/echelon defender uma posição.

ADENDO: Detectando Destruição de Elementos do Cenário.

Em nossa missão, o reforço terrestre só virá quando o objetivo principal de destruir o tanque de óleo tiver sido cumprido. Apanhei muito e ainda não acertei um método para descobrir se um elemento do mapa está ou não danificado.

Portanto, nessa missão tive que elaborar uma gambiarra. Note que "dentro" do tanque de óleo, deixei várias caixas de munição, cujo estas serão responsáveis por "informar" quando o tanque de óleo foi destruído, pois destruindo o tanque, a caixa de munição dentro dele será destruída por estar "próximo" a explosão.

Para o caso de elementos da palheta Props , o evento onDeath_nomeObjeto não irá servir para nos dizer que o objeto(no caso a caixa de munição) foi destruído. Neste caso, devemos usar a função de evento onPlaceableKill. Nomeei apenas uma das caixas de munição com o nome de municaoOleo que usaremos como condição dentro da função para saber se o que foi destruído foi realmente a caixa de munição e não qualquer outro objeto colocado no cenário. Pois lembre-se, que as funções de evento são genéricas a menos que você identifique o sufixo da função com o nome do objeto, como aqui por exemplo, poderíamos usar onPlaceableKill_municaoOleo.

Mas aqui preferí usar um if dentro da função e comparar com o nome do objeto que foi destruído é "municaoOleo". E caso seja verdadeiro, então move os reforços. A função então fica assim:

function onPlaceableKill(placeable, attacker)

--OFP:displaySystemMessage(placeable);

if placeable == "municaooleo" then

OFP:setObjectiveState("objective2", "COMPLETED");

OFP:setObjectiveState("objExtracao", "IN_PROGRESS");

OFP:displaySystemMessage("Estacao de Oleo destruida.");

OFP:displaySystemMessage("Retirar-se imediatamente. Mantenha-se sem ser detectado");

OFP:startParticleSystem( "FogoOleo1", 0 );

OFP:startParticleSystem( "FogoOleo2", 0 );

OFP:startParticleSystem( "FogoOleo3", 0 );

-- sequencia que move o hei

OFP:mountVehicle("grpHeli", "Heli1", "Any", "OVERRIDE" );

OFP:takeoff("grpHeli");

OFP:defendPos("grpHeli" , victim, 400,"OVERRIDE");

OFP:patrol("grpHeli", "WayHelip", "ECYCLIC", 0, "OVERRIDE");

-- fim da sequencia que move o hei

OFP:disableEvent("onPlaceableKill");

-- Movendo Reforcos vindos do oeste

OFP:defendPos( "grpRefBase1", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "grpRefBase2", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "tankRefBase1", "wpReforco", 400, "OVERRIDE" );

OFP:defendPos( "tankRefBase2", "wpReforco", 400, "OVERRIDE" );

end

Caso utilizasse a função de evento onPlaceableKill_municaoOleo, o código ficaria quase idêntico, só que sem o if.

function onPlaceableKill(placeable, attacker)

--OFP:displaySystemMessage(placeable);

OFP:setObjectiveState("objective2", "COMPLETED");

OFP:setObjectiveState("objExtracao", "IN_PROGRESS");

OFP:displaySystemMessage("Estacao de Oleo destruida.");

OFP:displaySystemMessage("Retirar-se imediatamente. Mantenha-se sem ser detectado");

OFP:startParticleSystem( "FogoOleo1", 0 );

OFP:startParticleSystem( "FogoOleo2", 0 );

OFP:startParticleSystem( "FogoOleo3", 0 );

-- sequencia que move o hei

OFP:mountVehicle("grpHeli", "Heli1", "Any", "OVERRIDE" );

OFP:takeoff("grpHeli");

OFP:defendPos("grpHeli" , victim, 400,"OVERRIDE");

OFP:patrol("grpHeli", "WayHelip", "ECYCLIC", 0, "OVERRIDE");

-- fim da sequencia que move o hei

OFP:disableEvent("onPlaceableKill_municaoOleo");

-- Movendo Reforcos vindos do oeste

OFP:defendPos( "grpRefBase1", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "grpRefBase2", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "tankRefBase1", "wpReforco", 400, "OVERRIDE" );

OFP:defendPos( "tankRefBase2", "wpReforco", 400, "OVERRIDE" );

end

Caso utilizasse a função de evento onPlaceableKill_municaoOleo, o código ficaria idêntico, só que sem o if.

Chamando o Reforço

Bom. Já vimos acima um dos casos de ativação de reforço inimigo: a destruição do Tanque de Óleo dentro da estação de bombeamento. Também haverá um outro caso de reforço que é se os jogadores forem detectados, porém isso é feito via um script de controle meio complexo e que será explicado em outro post, no entanto as funções são as mesmas, só irá mudar o local onde elas serão chamadas.

Vamos então entender as instruções da função onPlaceableKill. A primeira é o envio do helicóptero para a rota de patrulha. Segue abaixo o trecho.

-- sequencia que move o hei

OFP:mountVehicle("grpHeli", "Heli1", "Any", "OVERRIDE" );

OFP:takeoff("grpHeli");

OFP:defendPos("grpHeli" , victim, 400,"OVERRIDE");

OFP:patrol("grpHeli", "WayHelip", "ECYCLIC", 0, "OVERRIDE");

-- fim da sequencia que move o hei

A função mountVehicle ordena que o grupo entre dentro do heli.

A função takeoff manda o grupo decolar o heli.

A função defendPos deve ser ignorada, pois aí no código ela será sobrecarregada pela função patrol. O problema é que se vc usar mandar o Heli executar o defendpos, o que acontece é que o heli chega no local, pousa, os pilotos desembarcam e fazem a defesa.. é escroto.

A função patrol manda então helicóptero seguir o path WayHelip.

No caso das unidades terrestre, utilizaremos apenas a função defendPos informando o local, que é um waypoint único(nao é um path) chamado de wpReforco, mas que na verdade poderia ser qualquer objeto ou unidade colocada no mapa, ou até mesmo coordenadas puras (ainda nao testei).

As chamadas das funções defendPos das unidades terrestres ficaram assim:

-- Movendo Reforcos vindos do oeste

OFP:defendPos( "grpRefBase1", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "grpRefBase2", "wpReforco", 300, "OVERRIDE" );

OFP:defendPos( "tankRefBase1", "wpReforco", 400, "OVERRIDE" );

OFP:defendPos( "tankRefBase2", "wpReforco", 400, "OVERRIDE" );

E aí estão as chamadas das funções, informando o nome do grupo que vai prestar o reforço, o local onde o reforço será prestado, e o raio de ação dessas unidades de reforço.

Apenas para complementar o post, você poderia por exemplo colocar essas instruções dentro de uma função de evento onSuspected, que seria chamada quando alguém fosse detectado na missão. Por exemplo:

function onSuspected(victim, suspector)

-- capturando o nome do Echelon do soldado que detectou

local grupoAtaque = getParentEchelon(suspector)

--Verificando se a vítima é uma unidade dos americanos função getSide

-- 0=USMC 1 1=LPA

if (OFP:getSide(victim ) == 0) then

OFP:defendPos( grupoAtaque, victim, 100, "OVERRIDE" );

-- ou ainda a função searchAndDestroy

OFP:searchAndDestroy( grupoAtaque, victim, 100, false, "OVERRIDE" );

end

É isso, são diversas as formas que podemos trabalhar com grupos de reforços. Não explorei tudo ainda, mas podemos ainda regular a agressividade e a moral do grupo de reforço para dar uma maior imersão a batalha.

Peço aos leitores que consultem no help as funções citadas aqui hoje para que vcs entendam e passem a conhecer suas características e parâmetros. O help ainda é uma das melhores documentações que encontrei acerca do mission editor.

Por hoje é isso meus caros.

Saudações

Criando a Primeira Missão p1 - Metralhadoras, Veículos e Comboio

2009-11-14T22:49:00.001-08:00

Bom pessoal...

Nesta semana dei mais uma estudada no editor e nos fóruns da codemasters, e já consegui juntar informação suficiente para criar uma primeira missão, com objetivos primários, secundários, e até um scriptzinho inteligente para trabalhar detecção de inimigo.

Não cheguei a criar a missão para o blog, portanto, irei pegar a missão que tenho pronta, dissecá-la e tentar explicar passo a passo. Portanto não sei quantos posts levarei para explicar tudo, mesmo porque é muita coisa para um post só.

Vamos ao que interessa. O que há na missão ?

Unidades Customizadas, com armas Night Ops e Silienciadas.

Formação de Comboio (não basta apenas dar o move em formação columns).

Rendezvous Points.

Apoio aéro inimigo.

Objetivos Primários e Secundários.

Veículos normais e estáticos.

Começe baixando o arquivo da missão aqui

http://rapidshare.com/files/313223222/CP_M1.rar.html

Vocês não irão conseguir abrir o arquivo direto em seu editor porque no arquivo existem unidades customizadas. Para você conseguir "ler" a missão, você terá que baixar um arquivo chamado EntityDatabase.xml, que na verdade é o arquivo com a lista de unidades do editor (aliás isso vai ser uma complicação a mais para os modders de addons).. Explicarei mais adiante como alterar o arquivo. Segue o link do mesmo abaixo.
http://rapidshare.com/files/307236748/EntityDatabase.rar.html

Descompacte o arquivo na pasta database do mission editor, que normalmente fica em ...\operation flashpoint dragon rising\Mission Editor\Database
Faça uma cópia do EntityDatabase.xml caso vc queira retorná-lo algum dia.

Vamos então partir diretamente para o que ainda não foi falado no blog.

-Veículos

Ainda não havia falado nada sobre veículos no blog.
Em geral, os "veículos" tanto móveis quanto estáticos irão trabalhar com a mesma palheta de Editor de Propriedades: todos possuem os mesmos atributos para a edição, no entanto veículos móveis possuem mais atributos como armamento, efeitos sonoros e descrição dos lugares no veículo. Segue a imagem com as propriedades padrão de veículos.

Nesta missão existem veículos estáticos ( 4 Metralhadoras em D22 x3y4), veículos blindados (tanto na estação de óleo em D22 x3y4 como os reforços em D21X1Y5), ou de transporte sem armamento ou blindagem (o comboio), e 1 helicóptero

-Tripulação

Tripulação Virtual

Existem 2 tipos de tripulação dos veículos do jogo: as unidades e a "tripulação virtual" assim chamada(que só funciona com veículos blindados fechados). Para informar que um veículo possui tripulação virtual, basta ativar o botao "Has Virtual Crew", e caso ele não esteja habilitado para seleção é porque o veículo apenas permite tripulação "de verdade".

No mapa do mission editor, a indicação de uma unidade com tripulação virtual ou real são bem claras:
O veículo com tripulação real possui "bolinhas" ao lado direito indicando a respectiva unidade.
O veículo com tripulação virtual apenas assume a cor do lado (vermelho para LPA e Azul para USMC) e não possui nenhuma indicação.
Além disso dentro do jogo, veículos com tripulação virtual não permitem que jogadores acessem o driver, gunners ou commander do veículo em nenhum momento.

Tripulação Real

No caso da tripulação real, o procedimento será diferente, apenas mais trabalhoso.
Crie a(s) unidade(s) no mapa que irão integrar a tripulação do veículo. Importante você integrar todos os tripulantes do veículo dentro de um único Echelon. Crie 1 echelon por veículo, caso todos precisem "caminhar" juntos, crie um Squad e ligue os echelons dos veículos no squad.
Crie o(s) veículo(s).

Depois no Editor de Propriedades, no tópico Vehicle (visivel na imagem acima), há uma lista dos lugares disponíveis no veículo, chamada Seat. Basta apenas você selecionar o lugar na lista, pressionar o botão Pick e clicar na unidade que irá ocupar aquele lugar. Assim que você seleciona, a unidade então parece sumir do echelon ao qual estava linkada e irá aparecer como uma boilinha ao lado direito do veiculo.
Por padrão, ao assignar a unidade no veículo, ela já estará dentro dele (mount). O ofp sempre foi assim: ter um veículo assignado não significa que você está dentro dele. Então vc precisa linkar o veículo com a unidade e depois dar o mount para a unidade entrar no veículo. Com o botão pick vc já faz os 2. E caso você queira que o AI inicie a missão fora do veículo, basta selecioná-lo na lista Seat, pressionar o botal dismout e caso você queira que logo no início da missão ele corra e entre no veículo, basta ativar o Botão "Moving at Start", do contrário vc terá que usar a função OFP:mount via script.
Abaixo um exemplo de uma unidade montada, outra apenas linkada e outra sem link algum.

Abaixo um exemplo de um veículo completamente montado.

Metralhadoras

Pessoal, em teoria, para vc tripular uma metralhadora estática, o procedimento é o mesmo. No entanto, pelo que li no forum da codemaster, o jogo está bugado, e o pick do editor simplesmente não funciona no jogo (embora no editor pareça ter funcionado). Portanto teremos que linkar a unidade na metralhadora via funções scripts.
Não adianta você colocar o comando na função onMissionStart(), porque quando o cenário fica pesado e tem muitas unidades, o comando não funciona no início, tem que haver um delay(tempo). Portanto, você pode fazer isso, ou por um timer que irei falar mais adiante, ou por uma triggerzone (como eu fiz na missão).
O procedimento é o mesmo. Crie um echelon (dê um nome a ele), uma unidade apenas; link a unidade ao echelon e só.
Crie a metralhadora e também dê um nome a ela.

Agora, crie a triggerzone com uma distância suficiente para que precise de alguns para que você chegue nela.
Insira um elemento Level Script, que está em Systems -> Scripting. Dê 2 cliques no elemento para abrir o editor e crie função onEnter_nomeDaTriggerZone. Obviamente que a palavra "nomeDaTriggerZone' é para ser substituído pelo nome que você deu a sua triggerzone.
Dentro da função você irá executar o comando OFP:manEmplacementWeapon para fazer a unidade montar no veículo. A função deve ficar assim:

function onEnter_nomeDaTriggerZone(zoneName, unitName) OFP:manEmplacementWeapon("nome_echelon_mg_gunner", "nome_da_metralhadora", "OVERRIDE"); end

Os nomes em Itálico, são os nomes que você deu aos seus componentes no mapa, substitua-os.
Assim que você passar pela trigger, o soldado será montado na metralhadora.
Na nossa missão, a chamada OFP:manEmplacementWeapon está na função onEnter_trEnbIniPin, cujo a trigger trEnbIniPin é a primeira triggerzone logo abaixo das unidades USMC, basicamente no início da missão.

Waypoints

Na nossa missão, existem waypoints para unidades, veículos aéreos e veículos terrestres.
Dêem uma olhada nas coordenadas D22 X3Y4, que na verdade é a Estação de Bombeamento de Óleo, cujo é o objetivo principal da missão.
Notem que ao redor da base existe um único conjunto de Waypoints, que no editor possui um nome: Path Name (ou nome do caminho). Você não tem como nomear um path, ele monta o nome do primeiro waypoint do caminho, com a letra p no final. No caso da missão, o nome do primeiro waypoint é wayBasePatrol, e automaticamente o nome wayBasePatrolp foi gerado no campo Path Name.

Esse path não pertence apenas a um único echelon. Pelo contrário, ela pode ser compartilhada entre diversos echelons de qualquer lado (tanto China quanto Americano). Além disso, você pode fazer o grupo partir de qualquer ponto do caminho(path) e não apenas do início. Aqui por exemplo iremos fazer o echelon GrupoRef2 (abaixo a direita) iniciar o caminho a partir do primeiro waypoint. Já o GrupoRef1 (acima a esquerda) iniciará o caminho a partir do terceiro waypoint. E ambos iniciarão no modo cíclico, ou seja, ao chegar ao fim, o próximo waypoint será o primeiro.

Aqui no caso, utilizarei a função OFP:patrol, para fazer o grupo percorrer o caminho. E farei chamada na função de evento onMissionStart (assim que a missão for iniciada essa função é chamada), como vemos na nossa missão.

function onMissionStart()
...
...
OFP:patrol("GrupoRef2", "wayBasePatrolp", "ECYCLIC", 0, "OVERRIDE");
OFP:patrol("GrupoRef1", "wayBasePatrolp", "ECYCLIC", 2, "OVERRIDE");
...
...
end

Você também pode utilizar a função OFP:move. Não testei a diferença das duas. Ambas percorrem os caminhos dos waypoints (embora o OFP:move também funcione apenas com coordenadas de posições puras). Mas acredito que a diferença esteja no comportamento dos AIS.

Waypoints de Comboios

Apanhei para descobrir como criar um comboio que funcionasse. De início pensei que bastaria apenas eu criar um grupão, colocar todos dentro dos veículos, e mandálos seguir em uma estrada com Doctrine (o antigo Behaviour do ofp1) "At Ease" e em formação Column (coluna, ou a filinha indiana). Nada disso, na missão o comboio sempre saia da formação de coluna para formação linha ou V . Penei muito até que descobri o macete.

Em resumo, você tem que criar todos os veículos separados: crie o veículo que irá liderar o comboio, depois os outros que integrarão o mesmo. Você só irá definir o path, seja com o "Pick Waypoint", seja com o OFP:move ou OFP:patrol para o lider do comboio. Para todos os demais, você utilizará o comando OFP:follow.

Note que dentro da missão, lá na Estação de Bombeamento, exite um jeep e 2 caminhões de combustivel.
O jeep, chamado de jeepComboio, já possui o waypoint linkado direto no editor, e o comando follow para os caminhões(chamados de fuelTruck1 e fuelTruck2), estão na função onMissionStart(). Lembre-se que cada veículo deve possuir sua tripulação em um único echelon, e não se esqueça de nomear esses echelons, pois serão usados na chamada Follow. Aqui na missão, os nomes são EchelonTruck1 e EchelonTruck2.
Depois basta apenas mandar o grupo EchelonTruck1 (que pertence ao caminhao fuelTruck1) seguir(follow) o jeepComboio (estou mandando seguir o veiculo e não o grupo que tripula o jeep); e o grupo EchelonTruck2(do caminhão fuelTruck2) irá seguir o caminhão fuelTruck1.
Ficando assim:

function onMissionStart()
...
...
OFP:follow("EchelonTruck1", "jeepComboio", 30, "OVERRIDE");
OFP:follow("EchelonTruck2", "FuelTruck1", 30, "OVERRIDE");
...
...
end

Bom amigos. Acredito que já existe bastante informação para um tópico só. Ainda resta tratar alguns tipos de movimentos, como o defendPos, rapidMove, SearchAndDestroy, que na verdade todos possuem os mesmos parâmetros, o que muda é a forma com que o AI irá se mover.
Dêem também uma olhada no help do editor, na função OFP:setVehicleMood, que tem a tarefa de definir um comportamento para veículos (agressivo, passivo, etc).
Mais a frente também falarei de reforço aéreo: mount e waypoint dos pilotos.
Fuçem a vontade na missão. É tudo bem simples.

Saudações a todos.

Triggers (Triggerzones)

2009-11-08T10:09:00.000-08:00

Neste post irei falar a respeito de Trigges.

Houve significativas mudanças do conceito de triggers entre o Ofp1 e Ofp2. Agora as triggers basicamente são apenas Triggerzones, que só é ativada com a presença de uma unidade, seja ela AI ou player.

Na palheta Modify você não irá encontrar nenhum campo onde você configure a tarefa ou o script serem executados quando a Trigger for ativada.

Todo o controle, desde o que fazer quando alguem invade a triggerzone (função onEnter), ou quando a deixa (função onExit), serão manipulados através de scripts.

Aqui no caso, darei continuidade a missão que criamos lá no início (http://ofp2editor.blogspot.com/2009/11/passos-iniciais.html), inserindo a triggerzone, onde caso o player entre na triggerzone (que seria o suposto ponto de extração) a missão seja terminada.

Abra a sua missão, escolha um ponto de extração e insira uma Triggerzone. Para abra a Barra de Ferramentas na palheta Create, depois a Categoria Systems, expanda a pasta Mission e selecione o objeto "Triggers events when someone enter or exits" e o insira no mapa.

Ao inserir a triggerzone no mapa, ela terá o formato quadrado, que pode ser redimensionado através dos pontos das arestas, como eu fiz formando um losango, ou ainda você pode escolher a opção Circle, na palheta Modify do Editor de Propriedades. Nomeie esta trigger zone com PontoExtracao, ou o nome que preferir, mas lembre-se que este nome será usado futuramente.

Agora não há nada a faze mais com ela, senão ajeitar os detalhes como descricao.

Para deixar um pouco mais bonitinho, ficando o ponto visível no mapa, irei inserir um novo objeto "Mission Objective" (descrito em http://ofp2editor.blogspot.com/2009/11/passos-iniciais.html), só que agora irei configurá-lo como Objetivo Primário 2, e darei ele o nome de objExtracao.

As palhetas foram redimensionadas no editor para facilitar a visualização.

Só que agora, teremos que dar uma mexida nos scripts criados anteriormente e prepará-los para trabalhar com este novo objetivo, além de criarmos a função onEnter da triggerzone que será responsável por finalizar a missão.

Acesse o mesmo objeto levelScript já criado na missao do topico anterior.

Segue a alteração feita, que explicarei mais adiante.

As Alterações foram:

- A inclusão de uma variavel chamada obj1Completo para indicar se o objetivo principal foi cumprido ou não. Repare que logo no inicio da missão, no evento onMissionStart eu já atribuo a ela o valor 0, para dizer que o objetivo ainda não foi completo.

-Em seguida, no método onDeath incluino a mudança de estado através da função OFP:setObjectiveState do novo objetivo (ponto de extração). Note que estou informando o nome do objetivo (objExtracao) para a mudança de estado. Além disso altero o valor da variavel obj1Completo para 1, para identificar que o objetivo foi completo.

- A inclusão da função onEnter_PontoExtracao. Lembre-se que quando declaramos a função com o nome do objeto apos o prefixo "onEnter", estamos informando ao jogo que somente execute este método quando ouver invasões de zonas na trigger em questão, do contrário você terá que determinar por um if qual a triggerzone que foi ativada. Dentro da função onEnter_PontoExtracao, comparamos a variavel obj1Completo para saber se o objetivo principal foi ou não cumprido. Enquanto o valor da variavel for 0, mesmo que vc invada a triggerzone, nada ocorre, mas se a variavel tiver o valor 1, então ele muda o estado do objetivo para completo e finaliza a missão atraves da função missionCompleted().

Abaixo segue o código para copiar e colar

local obj1Completo;

function onMissionStart()

OFP:setObjectiveState("objective", "IN_PROGRESS");

obj1Completo = 0;

end

function onDeath(victim, killer)

if OFP:getEchelonSize("Echelon")==0 then

OFP:setObjectiveState("objective", "COMPLETED");

OFP:setObjectiveState("objExtracao", "IN_PROGRESS");

obj1Completo = 1;

end

function onEnter_PontoExtracao(zoneName, unitName)

if obj1Completo == 1 then

OFP:setObjectiveState("objExtracao", "COMPLETED");

OFP:missionCompleted();

end

Saudações

IlluminatusBR

Compilando e Testando a Missão (LiveLink)

2009-11-08T06:54:00.000-08:00

Neste tópico iremos falar da execução dos testes da missão.

Para executar uma missão criada pelo próprio usuário, é necessário antes "compilarmos" a missão criada. E podemos compilar a missão utilizando 3 funções distintas dentro do Editor: O Export, o Test Mission e o Test Mission with LiveLink.

Ambos compilam a missão e exibem mensagens de erro ou warnings, no entanto, como você pode imaginar, o Test Mission e o Test Mission with LiveLink iniciam o jogo com a missão.

Em resumo, quando estou criando a missão e quero apenas verificar se não há erros ou warnings, eu uso o Export, e ao compilar ele irá me informar quais waypoints estão assignados de forma errada ou qual unidade está posicionada informando altitude abaixo do nivel do chão ou do mar, enfim, verificações.

• Export

Não existe um botão próprio para a função export. Você encontrará está opção no Menu File, ou então pressionando CTRL + E.

Ao exportar a missão, surgirá a seguinte tela

O campo Game Instalation Folder é informado automaticamente.

O Mission Group é uma espécie de grupo de pastas(pois no fim, é isso que você irá ver no diretório) onde serão deixados os arquivos, caso você queira separar versões ou addons. Sei lá ! É importante ressaltar que durante o teste da Missão o jogo entra com um profile default(ainda nãodecobri como faço para apontar para meu profile) onde vc não pode usar suas configurações personalizadas dos controles.

Ao marcar a opção Binary Export, pelo o que pude perceber, compila e exporta o jogo em um arquivo binário único, que não há problemas em usá-lo utilizando o LiveLink (que explicarei adiante).

O Lua Scripts Export irá pré-compilar os scripts criados ou os waypoints, ou ambos.

E o campo Export Locations Preview é o nome do diretório onde efetivamente a missão será gravada, e este nome simplesmente utiliza o campo Game Instalation Folder e o Mission Group.

Ao pressionar OK, você compila e exporta o arquivo para o dierório.

• Test Mission

Já para esta função, existe tanto no menu Tools como em botão na Barra de Ferramentas Superior.

Ao executar o Test Mission, a missão será compilada, exportada, e o jogo será iniciado, o os botões Test Mission e Test Mission with Livelink serão desabilitados, e o botão de Stop(Kill Game) será habilitado.

O jogo é executado sem apresentação ou acesso por menus. Você já cai direto dentro da missão.

Não é preciso sair do jogo caso você faça alguma alteração na missão e precise recompilar e exportar novamente o arquivo. Basta apenas alternar (ALT+TAB) para o editor, Exportar (CTRL + E), voltar para o jogo e reiniciar a missão.

• Test Mission with LiveLink

Também com um botão na Barra de Ferramentas Superior, além do menu Tools, a execução do teste da missão com Livelink ativado tem apenas uma pequena, mas importante, diferença do Test Mission sem LiveLink: Você pode alterar a posição de objetos no editor e vê-los como ficou no jogo sem a necessidade de recompilar, exportar e Reiniciar a Missão, ou o Jogo.

No entanto ele ainda é bem limitado, e atende somente a alteração de Objetos de Categoria Prop. Não é possível alterar posições de veículos moveis ou estáticos, mesmo que vazios, e nem é possível criar objetos. Caso contrário, você terá que recompilar e exportar arquivo novamente através do CTRL+E e reinicar a missão.

Abaixo o Botão Test Mission with LiveLink.

Ainda não executei testes diretamente no jogo. Apenas sei que as missões exportadas serão encontradas em Single Missions.

É isso.

Saudações.

IlluminatusBR

Passos Iniciais

2009-11-07T18:50:00.000-08:00

Olá Pessoal... Sou fã da série desde agosto de 2001, e já no princípio, sempre gostei de mexer no editor do missões do OFP. E Aliás essa é a graça do jogo e por isso que jogo desde 2001: Sempre tem coisa nova.

E quero difundir o conhecimento entre os brazucas para que eu possa jogar uma missão sem saber o que está por vir.

Para entusiastas e profissionais de informática, o editor é um verdadeiro passatempo, possui instruções condicionais e de repetições, variáveis, matrizes, funções e scripts, mas para os jogadores, ele pode incomodar. Mas não há segredos.

A codemasters até que simplificou muito bem o editor, e pelo que pude notar, parece que houve uma grande evolução para a edição de scripts orientados por eventos. O conceito de trigger mudou também: agora você tem apenas as triggers zones (que só são ativadas por invasões de unidades), e todo o restante triggers de destroy, dammage e qualquer outro evento, passaram para funções de eventos, com OnDeath, OnDamage, OnLand, etc..

Para começarmos a editar missões, vamos partir dos elementos básicos da missão.

Neste tópico vamos tratar basicamente de:

- Editor

- Unidades e Grupos (Echelons)

- Waypoints

- Objetivos e Introdução a Scripts (Inevitavelmente)

• Editor

O Editor ficou mais complexo, lembrando muito uma ferramenta case de desenvolvimento gráfico, onde existem uma série de "palhetas" como mapa, objetos, propriedades, arquivos de script, e um editor de texto com sintax highlights próprias além de ferramentas como find, replace e autoedent.

É a mesma coisa de sempre: na Barra de Ferramentas Superior abaixo do Menu de Principal, você tem operações básicas de arquivos, edição, undo, redo, copy, paste, move, rotate, etc..

A Direita, na parte superior, estão a palheta de ferramentas de edição, onde você possui os "objetos" que podem ser criados (create) que estão divididos por categorias; você tem a o editor de entidades (que explicarei adiante); e o histórico de comandos (para vc poder desfazer aquela cagadinha)

A Direita, na parte inferior estão as palhetas de edição de propriedades em geral, tanto de objetos, como do ambiente missão, como das configurações da missão.

Não precisamos perder tempo em explicar os detalhes, mesmo porque ainda estou aprendendo (pra falar a verdade começei hoje). Além de que, a parte visual do editor é "intuitiva", as coisas estão muito bem descritas não precisando de maiores explicações.

Com o que falarei aqui, vocês mesmos podem fazer testes e ajudar a contribuir com as informações.

Segue apenas algumas dicas de atalhos:

-Clicar botão do roler você arrasta o mapa.

-Alt + Click Esquerdo(pressionado) em cima do objeto você rotaciona.

-Shift + Click Esquerdo(pressionado) em cima do objeto você espaça os objetos.

-Ctrl + Click Esquerdo em cima do objeto você seleciona mais de um objeto.

•Unidades e Grupos (Echelons)

Nosso próximo passo agora, é começar a missão com o mais elementar: as unidades.

Como é um pé-no-saco ficar recortando imagem, upando, ajustando texto e oscambau, eu vou fazer uma missão bem furreca de Invadir, Matar e Evacuar, e a morte será de um grupo de 4 soldados apenas. Irei selecionar qualquer local do mapa.

Na palheta de ferramentas de Edição, selecione a tab Create (abaixo da palheta), então selecione a categoria PLA (Chineses), e expanda a pasta Soldiers.

Selecione o soldado da lista que você queira colocar no mapa, e clique (não precisa arrastar) sobre o mapa. Ponha o soldado que você quiser. Os meus seguem abaixo:

Agora, para facilitar nossa vida, e não termos que futuramente alocar cada soldado em grupos de waypoints, é mais fácil agrupá-los todos em um grupo, e depois trabalhar somente com o grupo.

Para isso, existe um componente de sistema chamado Echelon, que nada mais é do que o antigo group do OFP. Claro que existe diferenças e bem melhores. Agora os groups estão divididos hierarquicamente em 3 grupos em ordem crescente de hierarquia: Fireteam, Squad e Platoon.

Um Grupo de Platoons pode possuir X grupos de Squads, que por sua vez pode possuir X grupos de Fireteams. Eu ainda não testei os limites. Sei apenas que em um Fireteam pode se apenas ter 5 soldados.

Enfim, adicione um Echelon, selecionando a categoria System, expandindo a pasta AI, selecionando o objeto Echelon e inserindo no mapa. Para linkar os soldados com o Echelon, pressione com o botao direito sobre o soldado e escolha a opção Pick Parent Echelon, e então selecione o Echelon Inserido

Depois de Linkar todos os soldados temos:

Agora, vamos adicionar os waypoints destes soldados. Novamente, eu aqui, irei fazer algo bem simples.

Para adicionar o waypoint, selecione a categoria System, expanda a pasta Mission e selecione o objeto Waypoint. E vá inserindo no mapa.

OBS: se você dá um clique e logo em seguida clica em outro lugar, os waypoints já saem linkados um no outro, mas caso você perca este link não tem problema, basta selecionar com o botão direito e selecionar Pick Next Waypoint e selecionar o próximo waypoint. Inclusive essa é a única forma de criar waypoints cíclicos (linkando o último com o primeiro).

Faça a rota como você preferir, e caso queira fazer waypoints cíclicos, como eu irei fazer, proceda conforme indicado acima.

Ficou então:

Isto, é uma vantagem do novo OFP: Os waypoints são objetos independentes dos grupos, e Isso possibilita que mais de um grupo(echelon) utilize os mesmos waypoints. Agora, resta apenas linkar o Echelon com o waypoint.

Para criar este link, clique com o botão direito sobre o Echelon criado e selecione a opção Pick Waypoint:

E por fim basta você clicar sobre o waypoint inicial, para ter:

Pronto. Minha patrulinha está pronta. Caso você queira incrementar fique a vontade.

•Objetivos

Agora, vamos dar andamento a missão criando o objetivo. Aqui, o objetivo será destruir o grupo criado.

Houveram também mudanças significativas do antigo OFP para o novo, no que diz respeito a objetivos e endmissions.

Agora, elas não criadas ou chamadas por triggers. O OFP2 criou um objeto próprio chamado de Objective, onde ali mesmo no editor de propriedades você já detalha o objetivo que será exibido no briefing e no resumo da missão.

Até agora, a única forma que consegui encontrar para interagir com elementos de Objetivo, foi através de scripts de eventos. Preste a atenção porque este é o item mais difícil do post de hoje.

No antigo OFP tinhamos que criar uma trigger e colocar a condição para determinar se o grupo havia sido morto. Agora aqui não, criamos uma função que é chamada quando o Grupo Morre, que por sua vez interage com o elemento de Objective.

Vamos primeiro criar o Objetivo. Para tal, selecione a Categoria Systems, o objeto Mission Objective e Insira o Objetivo no Mapa.

OBS: É importante lembrar que este Objetivo é visualizado dentro da missão através de Tag, portanto, para objetivos voltados a unidades móveis você tem que linkar o objetivo com o veiculo ou unidade em questão, através da propriedade Linked To (que se encontra na Palheta de Propriedades em Modify bem no final).

Apos criado o Objetivo, não esqueça de configurá-lo. Aqui estarei configurando-o para o tipo (Type) de "Primary Objective 1" e estou deixando o nome como Objetivo (poderia ser Objetivo1, Objetivo10, ou ate mesmo QualquerNome). O importante é que este nome será usado futuramente para referenciar este objetivo. Informe também sua descrição, se é visível ou não, enfim, deixei bem "bonitinho".

Agora, vem a hora de interagirmos com este objetivo, e para isso, iremos utilizar scripts.

•Introdução a Scripts

O antigo OFP não possuia um editor de texto para scripts vinculado ao editor de missões, e para trabalhar com eles tinhamos que criar arquivos externos e ficarmos pulando do editor de texto para o editor de missões do jogo via ALT + TAB. Isso agora acabou.

Agora, os scripts são criados no editor de texto interno do Mission Editor, e os scripts ficam vinculados a missão, e podem ser acessados através de um Objeto(icone) inserido no mapa, abrindo assim uma nova folha na palheta de arquivos abertos para a edição do texto.

Os Objetos de Scripts estão na Categoria Systems, na pasta Scripting.

Lá encontramos 3 tipos de objetos de script: Level Script (que pode trabalhar com funções de eventos, como iremos fazer agora ), Library Script (não trabalha com eventos, pode ser exportado e explicarei adiante a limitação) e Secondary Script (sei que não trabalha com eventos, e ainda não descobri a diferença para o Library).

Então vamos incluir um Objeto de Script na missão, selecionando o objeto Level Script e inserindo no mapa. Assim

E para acessar o editor de texto do Objeto de Script, basta apenas clicar 2 vezes sobre ele para ter:

Agora voltando aos Objetivos da missão, vamos primeiro informar que o Objetivo está em andamento.

Como eu só tenho um objetivo na missão, o andamento pode ser declarado logo no inicio da missão.

Para isso usamos um dos métodos de Eventos da missão: a função onMissionStart . Que é chamada toda a vez que a missão é iniciada.

Para facilitar, segue a sintaxe exatamente em texto:

function onMissionStart()

OFP:setObjectiveState("objective", "IN_PROGRESS");

end

Copie e cole isso no editor.

Lembra do nome do Objetivo ? ?Então, ele está aí, usado na função setObjectiveState para referenciá-lo. Já o segundo parâmetro informa que o objetivo está em progresso (IN_PROGRESS). Também pode ser "COMPLETED" ou "FAILED". Acredito que a finalidade da função setObjectiveState esteja óbvia dispensando maiores explicações.

Agora iremos definir o Evento que irá dar Objetivo como completo. Para isso, usarei um método de evento chamado onDeath.

No caso de algumas funções, como a própria OnDeath, é permitido definir diretamente o evento de morte de uma unidade apenas informando seu nome complementando o nome do método.

Por exemplo: Se você tem um soldado de nome Joao, basta apenas você declarar uma função chamada onDeath_Joao, e dessa maneira, somente quando o Joao morrer, o evento será chamado.

Acredito que trabalhar com a função onDeath normal pode até ser mais lento, porque você terá que descobrir (através de ifs) quem é o morto.

Vamos então criar a função onDeath para , sempre que alguém morre, descobrirmos qual a quantidade de unidades do grupo Echelon. Para isso usaremos a funcao getEchelonSize que retorna a quantidade de soldados VIVOS no grupo. Lembre-se que o nome que você definiu ou está no grupo tem que ser referenciado aqui. No caso o nome é "Echelon" mesmo, mas poderia ser qualquer nome.

Segue o codigo para você copiar e colar

function onDeath(victim, killer)

if OFP:getEchelonSize("Echelon")==0 then

OFP:setObjectiveState("objective", "COMPLETED");

end

Aqui você apenas está dizendo que caso todos os soldados do grupo Echelon estejam mortos, então o objetivo está completo.

Pronto, nossa missão está quase finalizada, restando apenas colocar o final, e definir os soldados Americanos. O final da missão na verdade pode ser chamado através de um método bem simples, chamado OFP:missionCompleted(), que poderia simplesmente ser colocado dentro da própria função onDeath, ficando assim:

function onDeath(victim, killer)

if OFP:getEchelonSize("Echelon")==0 then

OFP:setObjectiveState("objective", "COMPLETED");

OFP:missionCompleted();

end

Mas preferi não colocar o final ainda. Vamos deixar isso para o próximo tópico quando utilizarmos as triggers.

• Inserindo Unidades Americanas e Player

Não há segredo.

Para inserir um soldado americano, basta apenas você selecionar a categoria USMC e na pasta Soldiers. Para configurar seu soldado como player basta apenas, no Editor de Propriedades, na palheta Modify, ajustar o Control Mode para a opção Player.

Você pode também usar as regras de grupos Echelons, no entanto, em missões multiplayer, todos os players tem que estar apenas numa hierarquia de Echelons. Ou seja, caso sua missão tenha mais de 5 players, crie ou um squad com vários FireTeams.

Enfim pessoal.

Esse é o básico do Básico. Fuçem e acessem o help para saber a lista de métodos possíveis.

Espero ter ajudado.

Até a próxima.

IlluminatusBR