Ir para conteúdo
Grester

Guia de Edição de Missões do Grester

Recommended Posts

Dado o interesse por parte de alguns membros em começar a fazer missões, pretendo desta forma encorajar as pessoas a experimentarem fazer missões dividindo a aprendizagem por níveis de conhecimentos. Se tiveres alguma questão sobre alguma etapa ou excerto de código dos anexos, responde a este tópico com as tuas dúvidas. Este guia vai sendo atualizado com novas experiências que faço.

 

Iniciante: Principiante que está a descobrir como funciona e está estruturado o editor 3DEN, explorando os diversos menus e interagindo com o ambiente. O Interface organiza-se e interage-se da seguinte maneira:

  • Janela de edição - Ambiente 3D ou Mapa 2D premindo M;
  • Barra de menus superior e atalhos de ferramentas – “Scenario” para exportar a missão, “Attributes” para configurações da missão e “Settings” para definições do editor;
  • Janelas de acesso laterais - Objetos inseridos na missão à esquerda e biblioteca de objetos à direita. Premindo E/R;
  • Navegação da câmara 3D - W,A,S,D,Q,Z e botão direito do rato para rodar a câmara;
  • Menu de contexto - botão direito do rato num objeto;
  • Propriedades de diferentes tipos de objetos - duplo clique num objeto, ou última opção do menu de contexto;
  • Selecionar múltiplas unidades -  pode-se selecionar múltiplas unidades UMA POR UMA enquanto se pressiona o CTRL ou SELEÇÃO POR SELEÇÃO enquanto se pressiona o SHIFT.
  • Rodar objetos - manter premido SHIFT enquanto se clica numa unidade/seleção de unidades e mover o rato.

Experimenta fazer uma missão de teste:

  1. Constrói uma base ficcional utilizando alguns objetos estéticos e mete algumas unidades inimigas a protege-la.
    Na biblioteca de objetos, na primeira categoria "Objects" (F1), seleciona a subcategoria amarela (Props) e arrasta objetos de lá ou seleciona um e clica na janela de edição. Depois faz o mesmo para a subcategoria vermelha (OPFOR) e mete umas unidades enimigas.
  2. Mete uma unidade doutra equipa diferente e define-a como “Player” nas propriedades desse soldado e inicia a missão.
    Agora selecionamos a subcategoria azul (BLUFOR) e adicionamos uma unidade qualquer, de seguida abrimos a propriedades dessa unidade. Na janela que aparecer abrimos a secção "Control" e ativamos a opção "Player". Para iniciar a missão pressiona enter ou clica no botão inferior direito que diz "PLAY SCENARIO".

 

 

Amador: Novato que já percebeu como funciona o editor e está a dar os primeiros passos na edição de umas missões mais a sério. Fase de aprendizagem muito empolgante no sentido em que tenta por em prática todas as ideias que imaginou e quando não sabe como fazer alguma coisa, pergunta como concretizar tal ideia. Se realmente estiveres interessado em fazer missões eis algumas recomendações para te tornares um editor à séria:

  • Mostrar erros de scripts: Com a introdução de scripts nas missões torna-se importante saber quando estes produzem erros para que possam ser corrigidos. No launcher do Arma seleciona a opção "Parameters", depois "Show all parameters" e ativa a opção "Show script errors".
  • Subscreve o 3den Enhanced: Se realmente estiveres interessado em fazer missões com regularidade, este mod tornar-se-á essencial pois automatiza diversas funcionalidades que teriam que ser programadas à mão e adiciona inúmeras opções ao editor que por defeito não existem. Se por acaso a tua missão começar a manifestar erros estranhos/espontâneos vem falar comigo que eles têm solução.
  • Experimenta Waypoints: Fazer um grupo de soldados andar em patrulha e ver os vários estados de alerta e progressão que um grupo de AIs pode ter.
    Para adicionar um waypoint a um soldado/grupo seleciona o s/g e enquanto primes o SHIFT carrega com o botão direito do rato num sitio onde queres que o s/g se desloque. Se continuares a clicar acabas por fazer uma rota. Para fazeres uma patrulha acaba a rota onde começaste e abre os atributos do último waypoint que colocaste. Este waypoint por defeito é do tipo "MOVE", no entanto para que este s/g faça uma patrulha tens que alterar o waypoint para o tipo "CYCLE" clicando na lista de tipos. Se quiseres saber mais sobre os outros tipos de waypoints que existem visita esta página: https://community.bistudio.com/wiki/Waypoint_types
  • Experimenta Triggers: São “sensores” que reagem a um acontecimento, isto pode ser unidades presentes numa dada área ou uma comparação de verdades através de linhas de código. Os triggers podem ter uma área de deteção se pretenderes que ele seja ativado pela presença (ou não) de certas unidades na área dele (configurando as opções "Activation" e "Activation Type"), ou não ter tamanho pois a condição para ativação é com base numa linha de código como por exemplo a conclusão duma task. Os triggers podem ser configurados para ativar multiplas vezes e para só executarem a reação ao fim de X segundos ("Countdown") ou se só reage se a condição for verdade durante pelo menos X segundos ("Timeout").
  • Experimenta Tasks: Dar sensação de progressão numa missão informando os participantes das suas tarefas em mãos e de quando estas são concluídas. A criação da task inicial pode ser facilitada adicionando à missão um módulo "Create Task" no local do objetivo e editar os detalhes da task abrindo os atributos desse módulo. Para alterar o estado dum task perante um objetivo concluido e consequentemente criar uma nova task conjuga-se o uso dos módulos "Create Task" e "Set Task State" com Triggers, para que quando um Trigger "dispara" ele irá ativar os módulos inativos. Para tal sincroniza-se um Trigger com um "Set Task State" (botão direito do rato e selecionar a opção "Sync to" e depois clicar no módulo correspondente) e depois sincroniza-se o módulo do "Set Task State" com o módulo "Create Task" correspondente à task que se quer por exemplo concluir. De seguida sincroniza-se novamente com o mesmo trigger o novo "Create Task" para que ele crie uma task nova.
  • Experimenta Scripts: Com a introdução dos Triggers é quase garantido o surgimento da utilização de scripts. Para facilitar a implementação de certas funcionalidades úteis na maioria das missões por parte de pessoas com poucos ou nenhuns conhecimentos de programação, vou disponibilizar uma biblioteca com ficheiros de scripts pré feitos e explicação de como os usares para que a única preocupação do editor seja só saber como invocá-lo com certos parâmetros ou nem sequer isso.
    //Os scripts de invocação simples basta invocá-los assim
    execVM "FICHEIRO.sqf";
    //Isto parte do principio que os ficheiros estão na pasta raiz da missão, caso contrario será algo do género
    execVM "pasta\FICHEIRO.sqf";
    //Os que requererem parâmetros faz-se assim
    [PARAMETRO1, PARAMETRO2] execVM "FICHEIRO.sqf";
    //Se o script for invocado num campo 'init' de um objeto, tem que ser invocado assim
    null = [PARAMETRO1] execVM "FICHEIRO.sqf";

    Todos os scripts desenvolvidos por mim estão disponíveis na página de downloads na categoria de Scripts. Cada script incluí descrição de como o implementar numa missão.
    Biblioteca de Scripts

  • Experimenta Respawns: Apesar de as missões da ATFT não usufruírem de respawns estás à vontade para implementar respawns nas missões livres. É muito simples, na opção "Attributes" (Barra superior) selecionas "Multiplayer". Na secção de "Respawn" mudas o tipo de "Disabled" para "Respawn on custom position". Depois aumenta o "Respawn delay" para mais de 0 segundos se desejares. De seguida navegas para a categoria "Markers" (F6) na biblioteca e adicionas um marker à tua escolha na missão onde desejares que uma equipa faça respawn. A seguir abres os atributos desse marcador que acabaste de colocar e alteras o "Variable name" para o nome correspondente à equipa que pode fazer respawn lá (atenção às minúsculas) "respawn_west" (Blufor), "respawn_east" (Opfor) ou "respawn_guerrila" (Independentes).
  • Experimenta ZEUS: Apesar de o nome "Zeus" ter-se tornado conhecido no Arma pelo gamemode de haver um mestre que engendra uma missão para outros jogadores, esta funcionalidade também pode ser bastante útil para corrigir ou improvisar uma missão ao vivo. Para adicionares um Zeus à tua missão procura na biblioteca o módulo "Game Master" e adiciona um à missão. Abre os atributos desse módulo e na secção "System Specific..." ativa a opção "Forced Interface" e na opção "Default Addons" altera para "All addons (including unoficial ones)". No campo de texto "Owner" escreve um nome que desejares. De seguida na biblioteca na mesma categoria "System" onde se encontram os "Modules" seleciona a outra categoria chamada "Logic Entities" e procura pelo objeto "Zeus" e adiciona um à missão. Abre os atributos desse VirtualCurator e na secção "Init" digita no "Variable Name" o nome que à pouco deste ao "Owner" do módulo. De seguida na secção "Control" ativa a opção "Playable".

  • Binarização: Isto não é tanto algo a experimentar mas antes uma boa prática de desenvolvimento de missões. Quem quiser a explicação do porquê ser assim veja no nível avançado a metáfora, aqui vou simplesmente citar as recomendações:

    1. Desativar a binarização automática de novas missões - Abrir as preferências do editor (CTRL+K) e desativar "Binarize New Scenario Files".

    2. Ao guardar uma missão certificar que a binarização está desativada - "Attributes" -> "General", categoria "Misc" desativar "Binarize the Scenario File".

    3. Antes de exportar uma missão, guardar com binarização ativada - Inverso do passo 2.

    4. Após exportar missão voltar a guardar missão com binarização desativada - Repetir passo 2.

 

Apesar de neste guia eu ter estruturado outro nível de aprendizagem superior ao “Amador”, este à partida já é capaz de fazer missões muito interessantes para quem gosta de fazer uma missão de tempos a tempos, sendo que o nível acima é direcionado a pessoas estudiosas/autodidatas que se interessem por aprender mais sobre como o Arma funciona. É também de salientar que estou a mostrar a minha maneira de editar missões, podendo estas serem feitas de outras maneiras com outros scripts ou através do uso de alguns módulos ESPECÍFICOS (pois salvo meia dúzia de módulos, existem muitos que ou funcionam mal ou estão simplesmente obsoletos e só produzem erros.)

 

Avançado: Com que então queres te dedicar a fazer missões ou possivelmente alguns mods à base de scripts? ;) Se tiveres conhecimentos de programação estarás mais à vontade para te dedicares neste nível, ainda assim há bastantes guias que auxiliam quem não tem conhecimentos de programação a mexer com scripts do Arma.
Pois o que há de destacar principalmente neste nível é o aprofundamento de conhecimentos de como funcionam os scripts no arma. O editor em si é bastante simples e prático de usar para criar missões "simples", no entanto para criar missões mais complexas e dinâmicas só mesmo através de scripts escritos fora do editor. Isto não quer dizer que não existam scripts desenvolvidos por algumas pessoas que foram concebidos para serem utilizados quase como se fossem um mod, no entanto há algumas técnicas de dinamização de missões para as quais não existem ferramentas automatizadoras desse processo (embora às vezes me dê vontade de o fazer). Nesses casos  não resta senão serem escritas à mão individualmente para cada missão.

Embora eu vá dar algumas ideias mais complexas para tu experimentares e que de certa forma até um amador as sabe por a funcionar, eu recomendo vivamente a aprenderes umas bases de como funcionam os scripts no Arma. Nunca te esqueças que se tiveres alguma dúvida há pelo menos dois sitios em que é altamemente provável obteres resposta: A Wiki da BIS onde existe documentação detalhada sobre praticamente tudo e o Forum da BIS onde as pessoas fazem perguntas mais especificas. Também podes perguntar a mim, mas o que eu provavelmente irei fazer com a tua pergunta é por no google e ver que link da BIS ele me mostra.

 

Ferramentas para escrita de scripts e alguns aspectos importantes sobre eles:

 

Alguns snippets úteis:

Spoiler

//Isto é um comentário, não copiar as frases com as barras.

//Texto a negrito é código, sublinhado é texto variável que tem de ser alterado consoante as vossas necessidades. “varNAME” refere-se à “Variable Name” definida nos atributos do objeto.

 

//Adicionar arsenal a qualquer objeto. No campo “Init” do objeto copiar esta linha de código:

this addAction ["Abrir Virtual Arsenal", {["Open",true] spawn BIS_fnc_arsenal}];

 

//Condição trigger ativa quando uma unidade especificada morre/destruída:

!alive varNAME;

 

//Reação de um trigger para terminar a missão:

["end1", true, true, true, true] call BIS_fnc_endMission;

 

//Imagem personalizada numa placa. No campo “Init” do objeto copiar esta linha de código:

this setObjectTexture [0, "NOMEdaIMAGEM.jpg"]

 

//Animar cancela com presença unidades num trigger:

//levantar, colocar no campo “On activation”

varNAME animate ["Door_1_rot", 1]

//descer, colocar no campo “On deactivation”

varNAME animate ["Door_1_rot", 0]

 

//Grupos dinâmicos. Criar os seguintes ficheiros .sqf com as seguintes linhas de código dentro de cada:

// initServer.sqf

["Initialize"] call BIS_fnc_dynamicGroups;

// initPlayerLocal.sqf

["InitializePlayer", [player]] call BIS_fnc_dynamicGroups;

 

//Respawn com loadout carregado do Arsenal. Criar os seguintes ficheiros .sqf com as seguintes linhas de código dentro de cada:

//onPlayerKilled.sqf

player setVariable ["Saved_Loadout",getUnitLoadout player];

//onPlayerRespawn.sqf

player setUnitLoadout (player getVariable ["Saved_Loadout",[]]);

 

 

//Adicionar waypoint a um grupo para atacar uma unidade específica.

//Adicionar waypoint a grupo

_var = varGROUP addWaypoint [getPos varTARGET,0];

//Definir tipo do waypoint

_var  setWaypointType "DESTROY";

//Obter índice do waypoint atual do grupo

_var2 = currentWaypoint varGROUP;

//Conectar waypoint ao alvo.

[varGROUP, 0] waypointAttachVehicle varTARGET;

//Alterar waypoint atual do grupo.

varGROUP setCurrentWaypoint [varGROUP, (_var2+1)];

//Informação auxiliar:

https://community.bistudio.com/wiki/Category:Command_Group:_Waypoints

 

Tasks Avançadas: Normalmente eu prefiro fazer as minhas tasks através de linhas de código pois dão mais liberdade de personalização. Se quiseres ver em mais detalhe que funções existem lê esta wiki https://community.bistudio.com/wiki/Arma_3_Tasks_Overhaul, mas normalmente bastam as seguintes funções introduzidas num Trigger no campo "On Activation":

Existem Tasks "Normais" e as chamadas "SimpleTasks", não recomendo o uso das "SimpleTasks" pelos motivos aqui descritos.

 

Respawns Avançados: Já expliquei em mais detalhe o uso de respawns avançados neste post: http://www.armalusa.pt/index.php?/topic/2948-guia-para-edição-de-missões/&do=findComment&comment=9138

 

Quanto aos excertos e scripts de código mais complexos que já usei estão disponíveis na biblioteca de scripts ou por este tópico fora (sendo que neste caso eu faço relatórios exemplificativos), no entanto volto a frisar, se tens uma ideia para um script mas não sabes como fazer de raiz, procura porque é provável que já alguém tenha feito algo parecido.

 

O ridículo testamento sobre a binarização:

Spoiler

Para os curiosos do porquê aquelas boas práticas de binarização descritas no nível Amador eis uma explicação metafórica para quem percebe pouco de informática.

Imaginem que o Arma é uma criança que fala português e imaginem o editor como um cientista que fala inglês. A criança tem um vocabulário básico de português e o cientista tem um vocabulário extenso de inglês.

Quando se exporta uma missão não binarizada do editor para se jogar no arma, é como se o cientista estivesse a ler à criança uma tese de mestrado. Para a criança perceber o que o cientista está a dizer tem que haver alguém que traduza a tese do inglês para português. Além disso como a tese tem palavras difíceis, a criança tem de ir ver ao dicionário o que certas palavras significam.

Ao binarizar-se a missão está-se a traduzir a missão em algo mais fácil de compreender pelo Arma, para além da missão também ficar comprimida e mais pequena. No entanto as palavras difíceis continuam lá.*

E eis que tu perguntas: "Então se binarizar é algo que se deve fazer, porque não ter-se sempre ativo?"

Imaginando o mesmo caso como exemplo vamos pretender que nunca desligávamos a binarização. A criança cada vez que fosse ler a tese, bastava ir ver ao dicionário para perceber as palavras difíceis. Mas eis que de um dia para o outro a língua portuguesa sofre uma renovação do acordo ortográfico (update do Arma). Como acontece em qualquer tradução há coisas que não se conseguem traduzir perfeitamente à letra e nesses casos arranja-se expressões semelhantes. A criança como lhe foi ensinada o novo acordo ortográfico, quando for ler a tese que tinha sido traduzida segundo o acordo ortográfico antigo, não vai perceber algumas frases porque simplesmente deixaram de fazer sentido apesar de estarem em português. A única forma de voltar a dar sentido à tese, seria traduzir de novo a tese do inglês original mas desta vez segundo o novo acordo ortográfico e é aqui que surge o problema.

Ao ter-se a binarização ativa, deixa-se de ter acesso à tese original em inglês porque de cada vez que se grava a missão esta é automaticamente binarizada para a linguagem que o Arma percebe melhor. Quando o Arma (ou o 3den Enhanced) sofre uma atualização, a missão binarizada numa versão anterior poderá deixar de fazer sentido e quando forem editar/jogar esta vai dar erros. Como o editor já não tem acesso à missão que estava originalmente explicita (inglês do cientista) quando forem tentar desbinarizar/rebinarizar a missão para se atualizar segundo o novo update, vão perder informações geradas na versão anterior do Arma porque ele simplesmente as deixou de compreender.

Ao manterem as missões guardadas localmente de forma desbinarizada, caso o Arma sofra um update que gere erros na missão, se o erro for uma coisa simples, podes alterar à mão a missão num editor de texto (tipo o Notepad++) e corrigir o erro existente, evitando assim que seja o Arma a regravar só o que percebe da missão e dessa forma conservando o progresso que já desenvolveste na edição da missão.

*Uns parágrafos acima eu mencionei o seguinte "No entanto as palavras difíceis continuam lá." este é o motivo pelo qual cada vez que sai um update do Arma muitas missões antigas deixam de funcionar conforme se esperavam e pelo qual as missões do antigo Editor 2D têm que ser convertidas para o editor Eden. Essas missões é como se tivessem sido feitas com um dicionário antigo que se tornou obsoleto.

A solução imaginária para este problema das missões deixarem de funcionarem era se em vez de simplesmente serem traduzidas de uma língua para a outra através da binarização, elas em vez disso eram traduzidas para linguagem de bebé que é "compreendida universalmente e eternamente" através dum processo chamado compilação em que a missão seria integralmente traduzida para código máquina e cada instrução da missão em vez de ter que passar por um dicionário, era diretamente compreendida pelo próprio Arma sem necessidade dum intermediário que muda de tempos a tempos. Eu disse solução imaginária porque o Arma não foi concebido para permitir missões desse estilo, no entanto é como funcionam outros jogos/programas em problemas semelhantes.

 

 

Como nota de rodapé deixo algumas descobertas complexas que poderão ser de uso algum dia:

Partilhar este post


Link para o post
Partilhar em outros sites

Muito bom. Em tempos aventurei-me na criação de missões e perdi-me. Consigo fazer coisas básicas, mas quanto aos macros e triggers... aí é que cheguei e parei.

 

Obrigado pela ajuda, vou seguir com atenção.

Partilhar este post


Link para o post
Partilhar em outros sites

37 minutos atrás, TMaster disse:

Fica um video de como fazer um respawn,ou varios. Para como eu ,não fazerem o pessoal nascer dentro de agua :P basta por um marker (e não o modulo de respawn) com as seguintes designacões:  VER DESCRIÇÃO DA BIS

  • respawn_west
  • respawn_east
  • respawn_guerrila
  • respawn_civilian

 

 

Para que ensinar isso, se isso não passa de um sistema da "idade da pedra" comparado com os mais atualizados? Desde que o uso o Modulo do respawn, nunca tive problema.

Partilhar este post


Link para o post
Partilhar em outros sites

5 minutos atrás, SMiley disse:

 

Para que ensinar isso, se isso não passa de um sistema da "idade da pedra" comparado com os mais atualizados? Desde que o uso o Modulo do respawn, nunca tive problema.

Não está tão obsoleto quanto isso, estes à base de markers são gerais servem de respawn para tudo. Embora de certa forma tenho que concordar que é mais seguro usar os módulos de respawn.

Partilhar este post


Link para o post
Partilhar em outros sites

4 minutos atrás, Grester disse:

Não está tão obsoleto quanto isso, estes à base de markers são gerais servem de respawn para tudo. Embora de certa forma tenho que concordar que é mais seguro usar os módulos de respawn.

 

O que quis dizer foi mesmo que, já que existem sistemas mais avançados, por que razão se vai ensinar os antigos.

Partilhar este post


Link para o post
Partilhar em outros sites

Em 28/09/2016 at 16:32, SMiley disse:

O que quis dizer foi mesmo que, já que existem sistemas mais avançados, por que razão se vai ensinar os antigos.

Em 28/09/2016 at 17:14, TMaster disse:

Porque é como eu costumo fazer e nao sei o outro.

 

Ambos têm a sua importância porque se aplicam em situações diferentes.

Nos atributos Multiplayer duma missão, na secção de respawn ao mudar-se o tipo de "Disabled" para "Respawn on custom position" surgem novas tick boxes entre uma delas a chamada "Select respawn position". Eis as diferenças entre os dois métodos de respawn:

 

"Select respawn position" DESATIVADO , "Respawn marker" INEXISTENTE:

Spawn inicial na posição inicial da slot. Respawn no local da morte. Equivlente ao modo de respawn "Respawn on position of death".

 

"Select respawn position" DESATIVADO , "Respawn marker" EXISTE:

Spawn inicial na posição inicial da slot. Respawn no local do marker de respawn. Este é o método do Tmaster

 

"Select respawn position" ATIVADO , "Respawn delay" >0:

Spawn inicial na posição dum módulo escolhido. Respawn na posição dum módulo escolhido. Interessante numa missão de zeus pois podem ir sendo adicionados novos locais de respawn à medida que a missão vai decorrendo. Este é o método do SMiley.

 

"Select respawn position" ATIVADO , "Respawn delay" ZERO:

Spawn inicial na água.

 

Em 28/09/2016 at 17:14, TMaster disse:

mas ja agora espilica la como se faz.?

 

É muito simples, nos atributos da missão (barra superior de edição) selecionas multiplayer. Na secção de respawn mudas o tipo de "Disabled" para "Respawn on custom position".

Ao alterares para essa configuração vão aparecer novas tick boxes, ativa a que diz "Select respawn position".*

O respawn delay não pode ser 0 segundos. (Caso contrário começas a missão na água.)

De seguida procuras o módulo "respawn position", abres os atributos do modulo e na opção "side" alteras para o side que entenderes. Se quiseres podes dar um nome a esse local de spawn para quando aparecer a janela de respawn ele aparece o nome que definiste.

 

*Esta opção tem implicações especiais caso queiras fazer uma missão com Zeus OU que as slots façam spawn inicial na posição onde foram colocadas.

Caso ativares essa opção, cada vez que morreres aparecerá uma janela de respawn para escolheres onde queres fazer respawn (mediante onde estiver colocado um módulo de "respawn position"), isto é interessante para missões com zeus ou que tenham multiplos pontos de respawn.

No entanto nestas missões em que esta opção está ativada, por defeito, um módulo de Zeus não pode ter a opção "Forced Interface" ativada caso contrário fica inutilizável. Bem como todas a slots/jogadores serão obrigad@s no inicio da missão a escolherem um ponto de spawn.

A forma de contornar estes problemas/particularidades é criando um ficheiro paralelo ao ficheiro da missão. Abres a pasta onde a tua missão está guardada (no meu caso por exemplo é "D:\Users\Grester\Documents\Arma 3 - Other Profiles\Grester\missions\PASTA DA MISSÃO") e criam um ficheiro chamado "description.ext". Editam esse ficheiro com um bloco de notas ou notepad++ e inserem a seguinte linha de código:


respawnOnStart = -1;

 

Changelog:

Adicionado ao nível de aspirante tutorial de respawn e zeus.

Partilhar este post


Link para o post
Partilhar em outros sites

Com o desenvolvimento da Operação Caucasus aprendi umas coisas sobre tasks que nunca me tinha apercebido e acho importante salientar para futuros editores.

Já retifiquei o guia mas vou clarificar o porquê de ter removido do guia as supostas "SimpleTasks" e adotado antes as "Tasks" normais.

  1. Antes de mais as simpleTasks não são assim tão simples. Enquanto que com as tasks "normais" um editor praticamente só precisa de 3 funções, nas simpleTasks para fazer as mesmas coisas ele precisa de 6, logo mais hipóteses de se enganar nalguma delas.
  2. Não são práticas de adaptar para multiplayer.  Ao contrário das "normais" que dão para definir a atribuição da task a todos os jogadores de um certo SIDE, nas simple tem-se que forçar o código a executar globalmente (e mesmo assim segundo os meus testes não parece ser garantido pois aquilo fartou-se de dar erros.)
  3. Não é só as funções que são diferentes, elas são intrinsecamente diferentes. Não se pode misturar tipos de código para uma task, e tal nota-se fácilmente que uma pessoa que queira usar as simpleTasks não pode usar o módulo "Create Task" porque a task criada pelo módulo é do tipo "normal", não simples. Logo para a concluir ele teria que usar as funções das normais.

Dado isto acho que tá dado o alerta e mais que justificada a recomendação.

 

Quero também explicar em mais detalhe uma inovação que escrevi nesta missão que poderá ser do interesse de outros editores, o "Criar Heli Spawn". Eis o código:


this addAction ["<t color='#FFFF00'>Criar Heli Spawn</t>",{

	[west, helo_mobil getPos [15,random 360],"Heli Spawn"] call BIS_fnc_addRespawnPosition;

	(parseText "<t color='#FFFF00'>Heli Spawn Criado</t>") remoteExec ["hint"];

	[helo_mobil, 0] remoteExec ["removeAction"];

},nil,0,false,true,"","true",5];

Páginas de apoio:

https://community.bistudio.com/wiki/addAction

https://community.bistudio.com/wiki/BIS_fnc_addRespawnPosition

https://community.bistudio.com/wiki/remoteExec

 

addAction com parâmetros personalizados:

Um addAction por defeito só exige no mínimo o texto a mostrar (que no meu caso até colori) e a sua reação (no meu caso foram 3 "scripts"). Neste caso em particular para evitar que o Heli Spawn fosse ativado por acidente, alterei os parametros do addAction para que este fosse menos intrusivo:

  • 0 - Prioridade 0 significa que quando uma pessoa fazer scroll ele vai aparecer no fim da lista, se a prioridade for alta (por exemplo 3, por defeito é 1.5) ele aparecerá mais em cima.
  • false - ShowOnWindow false significa que ele não vai aparecer no meio do monitor quando um jogador se apróxima dele, desta forma não facilita a sua ativação.
  • 5 - Radius 5 significa o quão próximo a pessoa tem que estar dele para aparecer na lista de scroll. Por defeito este valor é 15, reduzi para 5 para certificar-me que só quem está próximo do heli é que vai ter acesso a ela. Julgo que se tivesse posto 0/1 só quem estivesse dentro do helicóptero é que veria esta opção.

[parametros] call BIS_fnc_addRespawnPosition:

Esta é a função que se usa para criar um respawn, por defeito a função corre globalmente pelo que não se tem que forçar a sua divulgação global. Define-se nos parâmetros o SIDE para qual o spawn é disponibilizado e o local onde este é criado. O que eu fiz para definir um ponto aleatório foi usar o "getPos" para gerar um local a 15m de distância em volta do helicóptero. Supostamente era mais aconselhável usar antes a função https://community.bistudio.com/wiki/BIS_fnc_findSafePos pois garante que um local seguro (não dentro de rochas,etc) é gerado. No entanto a função não parava de dar erros e não estava a aceitar a posição do helicoptero pelo que desisti e optei por usei a outra metodologia mais simples e leve.

 

Dilvulgação global de scripts:

Como os "scripts" removeAction e hint só executam localmente tive que os forçar a serem dilvugados globalmente, para tal usei a função "remoteExec".

Partilhar este post


Link para o post
Partilhar em outros sites

Apesar de não ter dado nas vistas poderá ser útil a alguém futuramente. Deixo aqui dois excertos de script que usei durante a missão da ATFT.

A situação era um civil (presidente) que estava refém num veiculo com inimigos. O objetivo era salvar o presidente, para tal fiz dois scripts.

(Os bots civis tendem a sair dos veículos onde estão presentes bots doutras fações. Possivelmente desativando parâmetros de AI poderá ser possível evitar isso, mas nunca testei o suficiente. Uma vez estudado bem a questão, o algoritmo poderia ser comprimido a um único script ao invés de dois separados.)

 

O 1º script para "forçar" o refém a sair do veiculo coloca-se no init do veiculo onde o refém está dentro.


this addAction ["<t color='#FFFF00'>Retirar Presidente</t>",{

  //comando para fazer o bot sair do veiculo (mesmo que esteja como "hostage" ou com AIs desativadas (é como se fosse um eject)

	doGetOut presidente;

	[veiculo, 0] remoteExec ["removeAction"];

},nil,5,true,true,"","true",5];

O 2º script para o refém se juntar à equipa do jogador que interagiu com ele. Coloca-se no init do refém.


this addAction ["<t color='#FFFF00'>Salvar Presidente</t>",{ 

  //adiciona o bot ao grupo do jogador. "_this select 1" é quem interagiu com a Action

 [presidente] join group (_this select 1); 

 [presidente, 0] remoteExec ["removeAction"]; 

},nil,5,true,true,"","true",3];

 

Partilhar este post


Link para o post
Partilhar em outros sites

A propósito da Operação Serpente Estranguladora em que os jogadores não foram capazes de reparar veículos isto deveu-se provavelmente às slots não serem engenheiros.

Se o editor da missão não desejar propositadamente usar as slots de engenheiro e não utilizar o EdenEnhanced (que facilita o que vou mencionar de seguida) têm de indicar manualmente que aquele jogador é capaz de fazer isto ou aquilo.

No init do jogador escrevem um ou mais dos seguintes comandos:


//Para definir como engenheiro

this setUnitTrait ["Engineer",true];

//Para definir como médico

this setUnitTrait ["Medic",true];

//Para definir como sapador

this setUnitTrait ["ExplosiveSpecialist",true];

//Para definir como hacker de UAVs

this setUnitTrait ["UAVHacker",true];

Nota extra: Uma slot Engenheiro é simultaneamente engenheiro e sapador. No entanto se só definirem manualmente um jogador como engenheiro ele não será sapador.

(Para os curiosos em saberem o porquê então de se potencialmente usar uma slot sapador e posteriormente definir como engenheiro, em vez de se usar diretamente uma slot engenheiro, é que uma slot sapador é capaz de detetar minas mais longe que um engenheiro. Esta definição não é possível alterar com nenhum comando pelo que esta abordagem poderá ter algum interesse numa missão mais rica em explosivos/minas.)

Partilhar este post


Link para o post
Partilhar em outros sites

Mod Highlight para Edição de Missões

Stars Editing Suite

http://steamcommunity.com/sharedfiles/filedetails/?id=850302437

 

Em suma um mod que permite no editor por estradas, rochas, árvores e arbustos que por defeito não dão para inserir no editor.

É de salientar que os AIs não vão seguir as estradas e iram chocar contra rochas e árvores colocadas artificialmente pelo que há que utilizar este mod com precaução. É mais engraçado para criar cidades fictícias para missões PVP.

Este mod não cria dependências na missão pelo que os jogadores não teram que subscrever o mod.

Partilhar este post


Link para o post
Partilhar em outros sites

37 minutos atrás, DEVGRU disse:

Mas eu queria mesmo o muito pedido módulo de terraforming para o Eden. Duvido sinceramente que o tenhamos alguma vez.

Não digo que seja impossível dado que já vi coisas no arma que nunca pensei um mod fosse capaz de fazer, mas tal modificação implica o manuseamento de informações "hardcoded" num terreno e a não ser que as modificações fossem temporárias exclusivas de uma só missão, implicaria manusear informações muito reconditas e de provável dificil acesso a um mod interagir. Teria que ser algo implementado pela BIS, mas a própria BIS nem facilita sequer a criação de novos terrenos de raiz quanto mais modificações on the fly.

Partilhar este post


Link para o post
Partilhar em outros sites

4 minutos atrás, Grester disse:

Não digo que seja impossível dado que já vi coisas no arma que nunca pensei um mod fosse capaz de fazer, mas tal modificação implica o manuseamento de informações "hardcoded" num terreno e a não ser que as modificações fossem temporárias exclusivas de uma só missão, implicaria manusear informações muito reconditas e de provável dificil acesso a um mod interagir. Teria que ser algo implementado pela BIS, mas a própria BIS nem facilita sequer a criação de novos terrenos de raiz quanto mais modificações on the fly.

 

Sim, pela BIS. Nem pensei em mods, mas num "módulo" para o Eden como foi o Zeus para o jogo. 

 

Eu nem sei como a malta faz terreno sem esse módulo. Deve ser tudo à base de uns e zeros, sem feedback visual. É por isso que vejo montes de erros nos mapas de mods. Mas pronto. 

Partilhar este post


Link para o post
Partilhar em outros sites

17 minutos atrás, DEVGRU disse:

Sim, pela BIS. Nem pensei em mods, mas num "módulo" para o Eden como foi o Zeus para o jogo.

Eu nem sei como a malta faz terreno sem esse módulo. Deve ser tudo à base de uns e zeros, sem feedback visual. É por isso que vejo montes de erros nos mapas de mods. Mas pronto. 

A BIS (que sabe usar as ferramentas que eles fizeram) usam software deles que automatiza a geração de terrenos com base em mapas GIS que são super detalhados e não meras imagens de satelite e heightmaps do google maps. Eu ainda fui doido o suficiente para tentar seguir os tutoriais deles mas são inúteis.

Em vez disso a forma como os modders fazem é quase que à mão. Vão buscar as imagens de satélite, os mapas topográficos, metem na misturadora e depois de terem a massa metem as pepitas de chocolate por cima, um por uma à mão. Não é difícil mas dá trabalho isto falando se usarmos a ferramenta de criação de terrenos da BIS, o chamado Bulldozer. Existe outra alternativa feita por modders o x-cam e aliás saiu há bem pouco tempo um terreno feito no x-cam que está sensacional. Não sei se o x-cam permite fazer essa mistura de topografia e imagens satélite ou se simplesmente serve para por edifícios, algo que a BIS incluiu no editor 3den a capacidade de exportar os edifícios postos num terreno vazio preenchidos para depois juntar no projeto do bulldozer (tarefa que se for feita no bulldozer é pouco produtiva pois é à base do editor 2D demodê).

Fazer um terreno por si não é difícil, mas dá muito trabalho.

Partilhar este post


Link para o post
Partilhar em outros sites

@DEVGRU / @TMaster , como forma de reduzir possíveis bugs espontâneos e acelerar o processo de respawn, sugiro o uso do script anexado neste post. O que faz é automaticamente recarrega o loadout que a pessoa tinha quando fechou o arsenal. A única coisa a fazer é escrever a seguinte linha no init.sqf ' execVM "respawnLoadout.sqf"; ' (o Tmaster percebe). respawnLoadout.sqf

 

Changelog:

Tutorial atualizado com melhores práticas e overall reorganizado.

Biblioteca de Scripts criada para facilitar armazenamento, procura e atualização dos mesmos.

 

Partilhar este post


Link para o post
Partilhar em outros sites

Fica a dica para futuros e atuais editores de missões. Por favor não metam um "sleep" num trigger. Irá vos poupar uns cabelos brancos, obrigado.

(O editor deixa-vos meter mas na realidade a missão vai começar a estoirar por todos os lados.)

 

Update: O problema em si não era só do "sleep" mas de qualquer forma não vale a pena lá meterem.

Partilhar este post


Link para o post
Partilhar em outros sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Visitante
Responder

×   Você colou conteúdo com formatação.   Remover formatação

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Criar Novo...