BaseMission - ArmA 3

Les scripts et les missions des [V]Vétérans

Vous pouvez poser vos questions et poster vos scripts, le forum est ouvert à tous.
Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

BaseMission - Script de conversation d'IndeedPete

Message par Tyrghen » 12 août 2013, 13:39

Mise à jour: 29/09/2014

Tutoriel - Script de conversation d'IndeedPete

J'ai fait un mini tutoriel en français comprenant les fonctionnalités de base du script, mais voilà le fil officiel en anglais si vous voulez pousser plus loin:
http://forums.bistudio.com/showthread.p ... ost2655661


Deux éléments sont nécessaires pour faire fonctionner le script de conversation d'IndeedPete: le fichier "conversations.hpp" et une ligne de script sur l'IA qui doit utiliser la conversation.
Il y a beaucoup d'éléments optionnels et je conseille de les laisser de côté tant que vous n'en avez pas besoin.



1) Conversations.hpp

Dans les fichiers de la mission, sous le répertoire "mission" on trouve le fichier "conversations.hpp" qui est automatiquement intégré au fichier description.ext. Aucune edition n'est donc nécessaire de ce point de vue.
Le contenu du fichier "conversations.hpp" est assez simple, voici un exemple complet:

Code : Tout sélectionner

class Conversations
{
	class exit
	{
		condition = "";
		expression = "call IP_fnc_closeConversation;";
		responses[] = {};
		sentences[] = {"Au revoir"};
	};
	class start
	{
		arguments[] = {"(name player)"};
		responses[] = {"exit"};
		sentences[] = {
			"Bonjour l'ami, ça va bien?",
			"Oui merci %1."
		};
	};
};
Toutes les conversations doivent être englobées dans une classe appelée "Conversations". Elle est présente dans le fichier de base, inutile d'y toucher.
Chaque élément de conversation lui est repris dans une sous-classe à laquelle vous donnerez un nom logique dans le flux de la conversation.
Ici on a deux éléments de conversation:
  • start: assez logiquement, ce sera le début de notre conversation.
  • exit: qui met fin à la conversation.
Le contenu de ces classes est assez simple:
  • condition: (Optionnel) c'est une ligne de code a exécuter qui permet de savoir si cet élément de conversation est disponible ou pas, elle doit renvoyer true ou false
  • expression: (Optionnel) c'est une ligne de code a exécuter lorsqu'on active cet élément de conversation
  • arguments: (Optionnel) ce sont des variables utilisables dans les phrases de la conversation. Ici je prend le nom du joueur qui a ouvert la conversation, ça permet de personnaliser un peu.
  • responses: C'est la liste des autres éléments de conversation disponibles depuis l'élément courant. Dans le point "Start", le seul élément accessible est "exit", ce qui fait qu'au bas de la page de conversation on n'aura à disposition que le lien: "Au revoir"
  • sentences: Ce sont les lignes de conversation qui seront affichées dans la page. On peut en mettre autant qu'on veut, tout en sachant qu'à chaque ligne, on alterne entre le personnage et le joueur. Ca permet de créer une suite de questions/réponses.
    Attention! La première ligne est TOUJOURS prononcée par le joueur, c'est la ligne de conversation qu'il a choisie dans la liste.
Voici un exemple issu de notre Domination:
instructor_2.jpg

2) Initialisation de l'IA

On peut initialiser l'IA pour la conversation soit dans l'éditeur, soit dans un script, mais attention, ces lignes de code doivent s'exécuter sur TOUS les clients, sinon la conversation ne sera disponible que sur les clients qui ont été initialisés.
Si on a deux camps, on peut imaginer initialiser l'un ou l'autre contenu de conversation.

Initialisation de la conversation
La première et unique initialisation qui soit obligatoire est celle qui défini l'élément de conversation de départ:

Code : Tout sélectionner

[Journaliste, "start"] call IP_fnc_addConversation;
Le premier paramètre est l'objet qui reçoit la conversation, ici une unité nommée "journaliste" dans l'éditeur.
Le deuxième paramètre est l'élément de conversation de départ. Dans notre cas on a choisi "start". Mais dans un exemple de conversation plus complexe, on pourrait avoir différents éléments possibles.

Rien n'empêche d'appeler cette ligne de code dans un déclencheur par exemple, pour que la conversation ne soit disponible que lorsqu'on a accompli un certain objectif.

Utiliser une photo dans la conversation
Pour que l'écran de conversation soit un peu plus personnalisé, on peut ajouter une photo à la mission qui sera affichée dans l'écran de conversation. Pour lier l'image à l'IA on utilise le code suivant:

Code : Tout sélectionner

journaliste setVariable ["IP_Avatar", "mission\journaliste.jpg"];
"IP_avatar" est le nom de la variable placée sur l'unité qui défini la photo liée à l'unité.



3) Message automatique

Vous pouvez souhaiter qu'une IA interpelle un joueur lorsqu'il passe à proximité, pour cela, vous pouvez utiliser la ligne de code suivante dans un déclencheur ou dans un script:

Code : Tout sélectionner

nul = [Journaliste, format["Hé! viens par ici %1!",name player], "DIRECT",3] spawn IP_fnc_simpleSentence;
En gros, l'IA (toujours notre journaliste) va parler au joueur au travers d'une petite fenêtre qui s'affichera 3 secondes. On donne l'IA pour pouvoir en afficher la photo si celle-ci a été configurée.

Et voici un exemple issu de notre Domination:
instructor_1.jpg
Image

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

BaseMission - Les scripts pour les groupes d'IAs

Message par Tyrghen » 12 août 2013, 15:50

Mise à jour: 14/09/2014

Tutoriel - Scripts pour groupes d'IAs

Dans ce tutoriel je vais parcourir les scripts de base pour les groupes d'IAs. Le but de ces scripts est d'accélérer la création des missions en automatisant le placement et les mouvements des IAs tout en ajoutant une part dynamique à ce processus pour que même le créateur de mission ne sache pas où se trouvent les IAs.

Une mission d'exemple est disponible à la fin de ce fil avec les scripts détaillés ici.


1) Patrouille

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this] execVM "patrouille.sqf"
Sans autre paramètres, le script va créer aléatoirement une série de points par lesquels la patrouille passera.
La zone de patrouille a un rayon de 200m centrée sur le leader.

Notez bien que l'ordre des points de passage sera aléatoire, parce qu'à chaque point de passage, un script sélectionne aléatoirement le point de passage suivant.

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. (Optionnel) La position autour de laquelle le groupe doit patrouiller (utile pour créer un style de "renforts") mettre "getPos this" si vous voulez ajouter d'autres unités
  3. (Optionnel) Le rayon de la zone à patrouiller, par défaut 200m
scripts_ia_05.jpg
scripts_ia_10.jpg


2) Défense

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this] execVM "defendre.sqf"
Le groupe se placera dans les bâtiments alentours (à moins de 60m) s'il y en a, prendra place dans les armes statiques (à moins de 100m) comme tireur et attendra ensuite l'arrivée des ennemis.

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. (Optionnel) La position autour de laquelle le groupe doit se placer
scripts_ia_15.jpg
scripts_ia_20.jpg


3) Homé

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this] execVM "homed.sqf"
Le groupe se placera dans les bâtiments alentours (à 60m de distance max) s'il y en a et se placera dans ce que j'appelle des positions de combats. C'est à dire près des fenêtres, dans les couloirs, etc.
La GROSSE différence avec le script "défendre", c'est que les unités ne bougeront pas tant que:
  • Elles ne sont blessées
  • Elles n'ont pas engagé d'ennemis
  • Un joueur n'a pas tiré à proximité
On utilisera donc ce script si on veut garnir des bâtiments et s'assurer que les unités restent là jusqu'à ce que les joueurs soient à proximité.

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. (Optionnel) La position autour de laquelle le groupe doit se placer
scripts_ia_25.jpg
scripts_ia_30.jpg


4) Sniper

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this] execVM "sniper.sqf"
Le groupe se placera sur les toits des bâtiments alentours (à 100m par défaut) si les bâtiments ont été référencés dans les listes de bâtiments de la Base Mission. A l'heure où j'écris ce tuto (14/09/2014) tous les bâtiments d'Altis ont été référencés et donc auront des positions de sniper.
S'il n'y a pas assez de positions de sniper, les unités resteront au sol là où elles ont été placées initialement.

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. (Optionnel) La position autour de laquelle le groupe doit se placer
  3. (Optionnel) Le rayon de placement des unités (par défaut 100m)
scripts_ia_35.jpg
scripts_ia_40.jpg


5) Embuscade

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this] execVM "embuscade.sqf"
Le groupe se placera face à la direction du leader dans l'éditeur et attaquera toutes les unités ennemies qui passent à moins de 40m.
Si une route est présente dans les 40m et que le paramètre optionnel du nombre de mines a été donné, le groupe posera des mines sur la route en face de leur position.

ATTENTION!!!! L'orientation du leader est PRIMORDIALE, le groupe fera face à cette direction!

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. (Optionnel) Le nombre de mines à placer
scripts_ia_45.jpg
scripts_ia_46.jpg
scripts_ia_46.jpg (10.67 Kio) Consulté 13043 fois
scripts_ia_50.jpg


6) Attaquer

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

nul = [this,"marqueur_destination"] execVM "attaquer.sqf"
Le groupe se lancera à l'attaque de la position désignée par le marqueur "marqueur_destination". Une fois arrivés sur place, le groupe recherchera dans une zone définie (par défaut 200m de rayon) des ennemis à attaquer.

Les paramètres possible sont:
  1. Une unité du groupe ou un groupe
  2. Le marqueur ou une position désignant la cible à atteindre, si c'est un marqueur et qu'il a une taille supérieure à 30m, il servira de rayon pour la zone cible.
  3. (Optionnel) Le rayon de la zone cible (par défaut 200m)
scripts_ia_55.jpg
scripts_ia_55.jpg (11.65 Kio) Consulté 13043 fois
scripts_ia_60.jpg
scripts_ia_65.jpg


Utiliser les scripts de manière différée

Il peut arriver que vous ne vouliez déclencher une patrouille, ou lancer l'assaut d'un point qu'à partir d'un certain moment. Par exemple, suite à un déclencheur.
Dans ce cas c'est très simple.
Soit, vous créez une variable globale contenant le groupe (par ex: grp_eny_1) ou bien vous donnez un nom au leader du groupe (par ex: lead_1).
Ensuite vous appelez le même script que ci-dessus dans la partie "activation" du déclencheur, mais vous remplacez "this" qui désigne l'unité par le nom de la variable créée.

Dans la ligne d'initalisation du leader, placer le code suivant:

Code : Tout sélectionner

GRP_ENY_1 = group this; doStop this;
Dans l'activation du déclencheur placez le code suivant:

Code : Tout sélectionner

nul = [GRP_ENY_1,"marqueur_destination"] execVM "attaquer.sqf"
Et voilà! Dans l'exemple ci-dessous, le groupe attaquera la position dès que des Blufor entrent dedans.
scripts_ia_70.jpg
scripts_ia_75.jpg
Pièces jointes
[V]Exemple.Stratis.zip
Version 2.07
(1.79 Mio) Téléchargé 402 fois
Image

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

BaseMission - Utilisation d'un client headless

Message par Tyrghen » 06 oct. 2013, 22:38

Mise à jour: 29/09/2014

Tutoriel - Utilisation d'un client headless

Dans ce tutoriel je vais parcourir les scripts et fonctions qu'on peut utiliser dans nos missions qui rendront transparente l'utilisation d'un client headless.
L'avantage d'un client headless c'est de pouvoir gérer l'ensemble des IAs ennemies (ou civiles, ou alliées) sur une machine autre que le serveur.
Débarrassé de ces calculs, le serveur sera plus performant, on aura moins de lag et plus de joueurs pourront participer à la mission.

L'utilisation d'un Headless nécessiterait normalement de nombreuses lignes de code pour assurer le fonctionnement de vos missions... mais pas avec la Base Mission, ça reste plus ou moins transparent et ce que vous testez en local, fonctionnera probablement directement avec le client headless sur le serveur.

Principe général

Si vous placez des IAs sur la carte de la mission, celle-ci sont automatiquement assignées au serveur. Du coup l'utilisation d'un headless n'a AUCUN intérêt!!!!
Pour que le client headless puisse faire son travail, il faut créer les unités à la volée pour que ce soit le headless qui s'occupe de la création. Ca nécessite donc un minimum de code. Mais vraiment très peu dans le cadre de la Base Mission.

Les scripts d'objectifs (détruire.sqf, ramasser.sqf, etc.) s'exécuteront eux TOUJOURS sur le serveur, pour une simple et bonne raison.
Si votre client headless perd la connexion, pour une raison quelconque (eh oui... c'est ArmA 3) tous les scripts s'en trouveraient atteint et leur exécution serait stoppée, ce qui empêcherait complètement l'exécution des objectifs. Donc, ces scripts continuent à tourner sur le serveur pour éviter tout problème.

Dans les points qui suivent, je reprend les fonctions qui sont utiles avec le HC et leur utilisation, illustrées par des exemples, ainsi que les configurations nécessaires.



1) Préparer votre mission à recevoir un Headless

En théorie, on peut placer une unité ennemie sur carte et spécifier dans le mission.sqm que ce sera notre slot headless.
Mais 80% du temps, le Headless se connectera sur le tout premier slot dans la liste, probablement celui d'un de vos chefs de groupe.

Du coup, lorsque vous démarrez une mission compatible headless, la toute première unité alliée placée doit être hors d'un groupe et sera réservée pour le headless. Ca vous évitera de vous arracher les cheveux inutilement.
Nommez cette unité: HC_UNIT dans l'éditeur.

Editez ensuite le fichier "mission.sqm" créé pour votre mission (à l'aide du bloc note ou de notepad++) et recherchez le texte "HC_UNIT".
Vous devriez arriver dans la déclaration de l'unité. Créez une nouvelle ligne et ajoutez: forceHeadlessClient=1;
Notez que le fait d'ajouter cette ligne empêchera un joueur de s'y connecter, vous ne risquez donc pas de souci de ce côté.
Ce qui vous donne:

Code : Tout sélectionner

		class ItemXYZ
		{
			side="EAST";
			class Vehicles
			{
				items=1;
				class Item0
				{
					position[]={12345,0,12345};
					id=93;
					side="EAST";
					vehicle="O_Soldier_F";
					player="PLAY CDG";
					forceHeadlessClient=1;  //<<<<<<< ajouté ici
					leader=1;
					skill=0.60000002;
					text="HC_UNIT";
					init="this allowDamage false; this enableSimulation false; this hideObjectGlobal true;";
					description="Headless Client Unit, can not be chosen by a human player";
				};
			};
		};
Comme on peut le voir ci-dessus, j'ajoute généralement le code suivant à l'initialisation de mon unité HC:

Code : Tout sélectionner

this allowDamage false; this enableSimulation false; this hideObjectGlobal true;
Ce n'est pas obligatoire, mais je fais ça par habitude.

Ajoutez le marqueur de respawn du camp du headless!!! Si vous avez tout de même choisi de mettre votre Headless dans un autre camp sur la carte, pensez à placer le marqueur de respawn du camp correspondant ("respawn_west", "respawn_east", etc.) si ce n'est pas déjà fait...

Il est utile de noter que le camp du Headless n'a absolument AUCUNE importance!



2) Création de groupes: edt_fnc_spawn

La fonction edt_fnc_spawn de la Base Mission fait elle même les contrôles nécessaires pour la présence d'un client Headless.
Si un client est présent, elle générera un appel distant pour s'exécuter sur le client (sauf si le scrpt qui appelle edt_fnc_spawn est déjà sur un client headless).

Donc, au début de votre mission, il suffit de lancer un script sur le serveur (mettre dans un déclencheur la condition "isServer") la ligne de code suivante:

Code : Tout sélectionner

[["B_Soldier_F","B_Soldier_02_f","B_Soldier_03_f"], "marker_spawn", west,"patrol"] call edt_fnc_spawn;
Ce qui va créer sur le Headless, un groupe de 3 unités, du camp west, sur le marqueur "marker_spawn" et les initialiser avec le script de patrouille aléatoire.

Et si aucun headless n'est connecté, le script s'exécutera tout simplement sur le serveur. Votre mission se comportera donc exactement de la même manière.
Une alternative est d'appeler un script qui créera les unités avec la fonction "execHC", dont l'explication est plus loin ci-dessous.



3) Renforts: "parachutage.sqf", "renforts.sqf", "renfortsVeh.sqf"

Les différents scripts de renfort sont aussi adaptés pour utiliser automatiquement un Headless s'il est présent. Rien de plus simple donc, il suffit de mettre un déclencheur avec les conditions que vous souhaitez et le script lancera la création des renforts sur le serveur ou l'un des headless présents s'il y en a.
Exemple pour un parachutage sur un marqueur:

Code : Tout sélectionner

nul = ["marker_para"] execVM "parachutage.sqf";


4) Forcer l'exécution sur un HC si disponible: execHC

Afin de centraliser la création des unités ennemies (et de tout autre élément de décor dont vous avez besoin) vous pouvez souhaiter exécuter un script sur un Headless dans le cas où il serait présent ou sur le serveur, si aucun Headless n'est connecté. Pour cela, rien de plus simple.
Il suffit d'appeler votre script de la manière suivante:

Code : Tout sélectionner

["mission\mon_script.sqf"] call execHC;
Si vous souhaitez passer des paramètres à votre script, il suffit de les donner avant le nom du script, par exemple:

Code : Tout sélectionner

[1,journaliste,"mon paramètre", true, "mission\mon_script.sqf"] call execHC;
Dans le fichier "mon_script.sqf", la variable "_this" contiendra tous ces paramètres sauf le nom du script.

Notez aussi que vous pouvez appeler une fonction de la même façon:

Code : Tout sélectionner

["B_Soldier_F", "marker_spawn", west,"patrol", "edt_fnc_spawn"] call execHC;
La fonction execHC permet donc de ne pas devoir se soucier de la présence d'un client HC. Le client sera pris en compte s'il existe.

Remarque: Il est important de noter que vous ne POUVEZ PAS appeler les fonctions d'objectifs (edt_fnc_destroy, edt_fnc_pickup, detruire.sqf, ramasser.sqf, etc.) à l'aide de la fonction execHC, ces scripts devant TOUJOURS s'exécuter sur le serveur.
En effet, si on exécutait ces scripts sur le HC et que celui-ci se déconnecte, tous les scripts s'arrêtent, puisqu'ils ne sont exécutés que sur le HC...



5) Exemple dans une mission

En cours...
Image

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

Configurer les accès aux fonctionnalités

Message par Tyrghen » 07 oct. 2013, 10:13

Mise à jour: 13/10/2014

Tutoriel - Configurer les accès aux fonctionnalités

Pour gérez qui a accès à quoi, j'utilise le module MP Rights du framework MSO, légèrement modifié pour avoir un peu plus de flexibilité.


1) Configuration par défaut

Par défaut, la Base Mission utilise le fichier "mso\mso_uids.sqf" qui doit contenir le tableau des joueurs ayant des accès spéciaux.
mp_rights_05.jpg
mp_rights_05.jpg (6.4 Kio) Consulté 12974 fois


2) Configuration globalisée

Quand on a une team qui bouge, maintenir la config dans toutes les missions, c'est vite impossible.
Pour cette raison, le répertoire "mso" peut être placé (avec le fichier "mso_uids.sqf") dans la racine du serveur (là où se trouve ArmA3Server.exe).
De cette manière, les droits d'accès sont partagés par toutes les missions.

ATTENTION: pour que la mission utilise le fichier sur le serveur, il ne faut pas mettre de répertoire MSO dans la mission elle même.
mp_rights_10.jpg
mp_rights_10.jpg (16 Kio) Consulté 12974 fois


3) Contenu du fichier mso_uids.sqf

Le contenu du fichier est le suivant:

Code : Tout sélectionner

[
   ["ID_ARMA3", "GRADE",   ["role1","role2",...],"NomDuJoueur1"] // Joueur 1
  , ["ID_ARMA3", "GRADE",   ["role1","role2",...],"NomDuJoueur2"] // Joueur 2
]
Les différents paramètres pour un joueur sont:
  • ID_ArmA3: L'identifiant unique d'ArmA 3 qu'on retrouve dans son profil au travers du menu configurer d'ArmA 3.
  • GRADE: l'un des grades suivants: "PRIVATE","CORPORAL", "SERGEANT","LIEUTENANT".
    Ce grade conditionne l'accès à certaines fonctionnalités comme l'artillerie.
  • role1: la liste des rôles possibles au moment d'écrire ces lignes sont:
    • "dev": téléportation et mode fantôme pour le joueur
      "admin": accès aux menus admin et à l'ACV si actif
      "moderator": accès à la modération si active
      "pilot": accès aux véhicules aériens réservés
      "crew": accès aux postes de conducteur et tireur des véhicules terrestres réservés
      "member": accès à certaines fonctionnalités réservées aux membres de la team, inutilisé sur la Base Mission
  • NomDuJoueur: ce paramètre n'est pas obligatoire, mais s'il est remplit, un joueur qui se connecte avec le même nom qu'un membre sera éjecté
Il faut ajouter autant de lignes qu'il y a des joueurs dans la team... sans oublier les virgules :)


4) Créer vos propres accès

On peut utiliser cette configuration des droits dans différents scripts pour tester l'accès à des fonctionnalités avec la fonction: mp_rights_fnc_hasRoles

Le code ressemblerait à:

Code : Tout sélectionner

_hasAccess = [(getPlayerUID _unit),["member","admin"]] call mp_rights_fnc_hasRoles;
La fonction renverra "true" si l'unité désignée par "_unit" à les droits de type membre ou administrateur.

On peut évidemment ajouter dans le fichier mso_uids.sqf un autre accès, par exemple: "special".
Le test deviendrait:

Code : Tout sélectionner

_hasAccess = [(getPlayerUID _unit),["special"]] call mp_rights_fnc_hasRoles;
Image

gagi
Messages : 297
Inscription : 08 juil. 2013, 13:19

Re: BaseMission - ArmA 3

Message par gagi » 07 oct. 2013, 11:53

Ok j'avais survolé ta doc (trés bien faite d'ailleurs).

Mais un peu de mal à comprendre si c'est dynamique et si oui comment prendre cet outil en main.

Pas évident !

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

Re: BaseMission - ArmA 3

Message par Tyrghen » 07 oct. 2013, 13:12

Le plus simple c'est d'ouvrir la mission de démo et voir comment c'est fait ;)
Image

gagi
Messages : 297
Inscription : 08 juil. 2013, 13:19

Re: BaseMission - ArmA 3

Message par gagi » 07 oct. 2013, 14:20

OK j'ai ouvert la mission.

donc en gros avec l'ACV tu peux faire appel à ces scripts de manière dynamique? Ou bien prévoir à l'avance la mission.

C'est comme un MCC un peu? (sauf que mcc j'y comprend rien).

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

Re: BaseMission - ArmA 3

Message par Tyrghen » 07 oct. 2013, 14:45

L'ACV est un des outils, mais tu peux créer une mission dans l'éditeur avec des objectifs et tout, pas besoin de l'ACV pour ça.
Simplement les fonctions de la basemission te permette de créer un objectif et les tâches associées de manière très simple avec une petite ligne de script, pas besoin d'écrire pleins de code et de lier pleins de trucs.

Quand ça aura un peu avancé je ferai une petite documentation par l'exemple de la construction d'une mission :)
Image

gagi
Messages : 297
Inscription : 08 juil. 2013, 13:19

Re: BaseMission - ArmA 3

Message par gagi » 07 oct. 2013, 14:54

OK je vais essayer de faire ça en dynamique : ça peut être marrant. Je veux dire : ok pour faire une mission bien propre dans l'éditeur.

Mais je vois surtout ça pour egayer les missions le soir entre amis : et ne pas que les gens aient besoin de se reconnecter à une nouvelle mission. Ca casse l'ambiance de devoir relancer un serveur et de retélécharger une mission. Enfin je trouve.

Déjà faire spawner qq groupes de fantassins sur une main : ça surprend et ça tient bien les gens en haleine :)

Avatar de l’utilisateur
Tyrghen
Membre des [V]Vétérans
Messages : 4125
Inscription : 14 oct. 2012, 22:47

Re: BaseMission - ArmA 3

Message par Tyrghen » 07 oct. 2013, 15:23

Ah ben justement, tu viens de mettre le doigt sur ce qu'était Foreveron, ma mission dans ArmA 2.

Tu lançais 1 mission, et dans la mission tu lançais la mission à jouer, la suivante, etc.

C'est ce vers quoi je compte aller, mais bon, tout porter vers ArmA 3 ça ne s'est pas fait tout seul...
En plus il y avait une série d'aménagements que je voulais faire.

Mais l'idée c'est ça.

Et bon, je regarde aussi pour pouvoir charger des fichiers de missions que tu déposerais sur le serveur lui-même, donc pas besoin de télécharger quoi que ce soit, il suffirait de placer la nouvelle mission sur le serveur pendant que tu es déjà en jeu et tu la charge à la volée.
Mais là on est un pas plus loin.

Enfin, c'est ce vers quoi je travaille.
Image

Répondre