GRAW2 GameModes

Machine Translated by Google
GHOST RECON : WARFIGHTER AVANCÉ 2
MODES DE JEU MP
v1.04
Par:
Grin_Wolfsong
Assisté par:
Grin_Chopstiks & Grin_GeckoGore
Contenu des documents
Chapitre 1 : Fichiers XML.............................................. .................................................. .3

Présentation.................................................. .................................................. ...........3
Fichiers utilisés.................................. .................................................. .........................3
World_Info.xml ..................... .................................................. ..............................4
Mission.xml ................ .................................................. .......................................5 Chapitre
2 : Modes de jeu originaux.. .................................................. ..................................7 Match
à mort par équipe ..................... .................................................. ..................................7
Match à mort ..................... .................................................. .....................................7
Siège........... .................................... .................................................. .......................7
Colline Hamburger........................ .................................................. ..................................8
Reconnaissance contre assaut.............. .................................................. ..................................8
Chapitre 3 : Coopération ............. .................................................. .......................................9
Fichiers...... .................................................. .................................................. ..............9
Configuration .................................. .................................................. ..................................10
Objets requis ................................. .................................................. ..................................11
Méthodes alternatives .............. .................................................. ..................................11
Chapitre 4 : Coopération de campagne ........... ............................................. ..................................12
Chapitre 5 : Modes de jeu personnalisés............. .................................................. ..............13
*_settings.xml ............................................... .................................................. ..................13
Problèmes.................................. .................................................. .......................................15
Chapitre 6 : Restrictions relatives aux kits
personnalisés.... .................................................. ..................16
*_ranks.xml................................ .................................................. ..................................16
Chapitre 7 : Classes personnalisées et kits................. .................................................. ............18
*_template.xml................................. .................................................. ..................18
Contenu de l'élément Soldat .................................. .................................................. ......19
xdéfinir................................................ .................................................. ..................................26
Soldats armés .................................. .................................................. ................................29
group_manager.xml .................. .................................................. ..................................31
Conclusion ....................... .................................................. ..................................................32
Annexe 1 : Liste des camouflages. .................................................. ...............................33
Camouflages .................. .................................................. .....................................33 Annexe
2 : Liste des armes........ .................................................. ...............................37 Fusils
d'assaut ................ .................................................. .....................................37 Mitrailleuses
et fusils compacts...... .................................................. ..........41
Mitrailleuses................................................. .................................................. .....42 Fusils
de sniper.................................................. .................................................. .............43
Armes de poing.................................. .................................................. ..................................44
Grenades .................................. .................................................. ..................................45 Armes Spéciales......
2
Chapitre 1 : Fichiers XML
Introduction
GRAW2 utilise un système de mode de jeu multijoueur unifié, qui permet aux concepteurs de niveaux de
configurer une seule carte pour qu'elle soit jouable dans plusieurs modes multijoueurs.
Pourtant, chaque mode a besoin de sa propre configuration en ce qui concerne les emplacements et les
objets, car leurs scripts sont conçus pour rechercher des noms différents lors de la lecture de chaque
mode. La raison en est bien sûr de permettre un placement différent pour des choses comme les
emplacements d'apparition et d'autres choses pour chaque mode spécifique. Ce document explique
comment configurer une carte avec tous les modes de jeu unifiés originaux, Team Detahmantch "TDM",
Deathmatch "DM", Siege "S", Hamburger Hill "HH" et Recon vs Assault "RvsA". Une fois que vous saurez
comment procéder, il sera facile d'ajouter d'autres modes de jeu personnalisés qui pourraient apparaître à
l'avenir, sur les cartes de votre choix.
Ce document couvrira également ce qui est nécessaire et comment créer un mode de jeu personnalisé
ainsi que des classes personnalisées et des restrictions de kit. Espérons que tout cela aidera la
communauté à développer des moyens personnalisés d'utiliser GRAW2 en multijoueur, ou au moins
aidera les serveurs à adapter davantage le jeu à leurs propres besoins.
Fichiers utilisés
Chaque mode de jeu possède ses propres fichiers XML avec ses règles et ses paramètres. Pour utiliser un
ensemble de règles et de paramètres sur une carte, il suffit d'inclure ces fichiers dans les cartes mission.xml
et de définir que la carte a le mode souhaité dans les cartes world_info.xml.
Dans le fichier mission.xml , vous spécifiez également quel *_ranks.xml utiliser pour chaque mode.
Les fichiers *_ranks.xml contiennent des données sur les classes et les kits pour chaque classe qui seront
sélectionnables par le joueur. Différents fichiers *_ranks.xml peuvent être attribués à différents modes de
jeu sur la même carte, ce qui aide les concepteurs de modes de jeu en créant des restrictions de kit pour
chaque mode de jeu si nécessaire.
Dans le world_info.xml , vous définissez que le mode de jeu est disponible sur la carte actuelle, quelle
minicarte utiliser et quel écran de chargement afficher avant le niveau lorsque chaque mode de jeu est
en cours de chargement.
Mappez les fichiers spécifiques

à modifier : world_info.xml
mission.xml
Fichiers spécifiques au mode de jeu à

utiliser : *_rules.xml *_settings.xml
Chaque mode de jeu doit se voir attribuer un fichier de restrictions de classe et de kit :
*_ranks*.xml
3
World_Info.xml
Examinons de plus près le world_info.xml pour l'une des cartes originales appelées "Timber", et en
cela concentronsnous sur les lignes pour le mode TDM .
Partie TDM de world_info.xml pour "Timber" :

<world_info path="/data/levels/common/tdm_settings.xml" type="tdm">
<texture name=”loading”
texture=”data/textures/atlas_gui/mission_gfx/load_mp_tdm_dm”
uv_rect=”0,0,2048,1080” width=”2048” height=”2048”/>
<texture name="minimap" texture="/data/textures/gui/timber_minimap"
uv_rect="0,0,1024,1024" width="1024" height="1024"/> </world_info>
Chaque mode de jeu est défini dans world_info.xml avec son propre élément de base appelé
"world_info". Il a deux attributs, dont le premier est nommé "chemin" et nécessite le chemin d'accès
au fichier de configuration des modes de jeu requis. La deuxième variable est nommée "type" et
vous demande de définir de quel mode de jeu il s'agit, dans ce cas "tdm".
Cet élément de base a deux souséléments comme contenu, et les deux sont nommés "texture".
Ceuxci sont utilisés pour définir la texture de l'écran de chargement et la texture de la minicarte. Le
premier attribut définit quel sousélément est utilisé pour quoi. Si un écran de chargement ou une mini
carte n'est pas défini, une texture en damier bleu et jaune sera affichée à sa place.
Pour définir une texture d'écran de chargement, il suffit de définir le premier attribut, "nom" sur
"chargement" , puis de définir l' attribut "texture" sur le chemin et le nom de la texture souhaitée.
"uv_rect" est pour les écrans de chargement d'origine avec la valeur "0,0,2048,1080". Le premier "0,0"
est les coordonnées du pixel dans le coin supérieur gauche de la section utilisée sur la texture comme
écran de chargement, suivi de "2048,1080" qui est les coordonnées du pixel dans le coin inférieur droit
de la section utilisée. Les deux coordonnées créent un rectangle autour de la section utilisée de la
texture qui sera affichée lors du chargement de la carte. Enfin, les deux attributs "width" et "height"
doivent recevoir les dimensions de la texture ellemême.
Pour définir une texture de minimap tout se fait de la même manière que pour un écran de chargement,
à l'exception de définir « name » comme « minimap » et qu'il faut lui donner une zone rectangulaire sur
la texture à utiliser. Et enfin la balise "world_info" est fermée autour du contenu.
Reconnaissance vs Assaut
RvsA nécessite quelques souséléments supplémentaires car il a des textures personnalisées qui
montrent sur la minicarte où se trouvent l'objectif ADATS, les camions de ravitaillement et le MULE.
Ceuxci sont ensuite placés avec le type d'élément "Objective" dans le
*_settings.xml, ou script de mission, en donnant la valeur "name" que vous avez définie pour la texture
dans le world_info.xml, à l'attribut "map_sprite" du "Objective ” type d'élément.
Remarque : Vous pouvez spécifier encore plus de souséléments pour attribuer différents environnements à
chaque mode, et même leur faire utiliser différents fichiers world.xml . Cela n'est utilisé pour aucune des cartes MP
originales, mais quelque chose avec lequel la communauté de modding peut jouer s'il en a envie.
4
Mission.xml
Passons maintenant à autre chose et regardons de plus près le fichier mission.xml pour la même carte
et le même mode de jeu que cidessus.
Partie TDM de mission.xml pour "Timber" :

<mission_script name="tdm">
<xi:include href="/data/levels/common/tdm_rules.xml"/> <xi:include href="/data/
levels/common/mp_ranks.xml"/> <xi:include href="mission_specific.xml ”/> </
mission_script>
L'élément de base pour chaque mode ici est "mission_script", qui a un attribut appelé "name" qui définit
pour quel mode de jeu, dans ce cas "tdm", il est utilisé.
Remarque : Il est important que cet attribut "name" pour les éléments "mission_script" soit le même
que le "type" donné à la balise "world_info" dans le fichier world_info.xml , ainsi que partout ailleurs
où nous rencontrerons ces jeux. identification du mode.
Cet élément de base peut contenir tous les scripts que vous souhaitez utiliser pour ce mode de jeu, mais
cela s'éloignerait de l'idée de partager les règles entre toutes les cartes utilisant le même mode de jeu.
Parce que nous voulons que les règles soient spécifiées dans le fichier *_rules.xml souhaité , nous
utilisons une commande XML appelée "xi:include", qui a un attribut nommé "href" qui nécessite le
chemin et le nom du fichier que nous voulons inclure dans le fichier mission.xml , qui dans ce cas est le
fichier tdm_rules.xml . Ce que cela fait, pour simplifier les choses, c'est qu'il copie tout ce qui se trouve à
l'intérieur de tdm_rules.xml dans le mission.xml, ce qui peut être fait entre n'importe quel fichier XML du
jeu si vous le souhaitez, alors maintenant vous avez appris une autre astuce XML. ;)
De la même manière, nous incluons le *_ranks.xml que nous voulons utiliser pour ce mode de jeu
spécifique. Ainsi, en faisant cela, le concepteur de niveau décide quelle arme peut être utilisée dans ce
mode de jeu spécifique sur cette carte spécifique. L'exemple cidessus utilise le fichier standard
mp_ranks.xml qui est utilisé pour tous les modes unifiés sauf RvsA dans le jeu original.
Remarque : Par l'explication précédente du fonctionnement de la commande « xi:include » , vous remarquerez peut
être maintenant que le code de restriction du kit n'est pas limité à être à l'intérieur d'un fichier *_ranks.xml . C'est en fait
également vrai pour tous les autres codes XML du jeu, qui ne doivent pas toujours être dans le fichier exact que je vous
montre dans les tutoriels, mais je vous recommande de diviser vos scripts XML comme nous l'avons fait pour vous
faciliter la tâche et avoir une meilleure vue d'ensemble des choses.
Astuce : comme n'importe quel fichier XML peut être inclus dans un autre, cela permet également le partage de script
entre les missions SP ou Coop. Le problème est qu'alors le concepteur de niveau doit s'assurer que tous les objets
utilisés dans le script inclus sont également présents sur la carte actuelle ou le jeu plantera ou mal fonctionnera d'une
autre manière, comme des missions qui ne peuvent pas se terminer ou similaires. Utilisezle donc avec précaution même
s'il peut parfois être utile.
5
Le dernier fichier inclus dans le fichier mission.xml dans l'exemple cidessus est
mission_specific.xml, qui est en fait un autre fichier de mission comme tdm_rules.xml.
Ce n'est pas nécessaire pour que le mode de jeu fonctionne, mais nous l'avons utilisé pour contenir
les éléments de script qui sont partagés par tous les modes de jeu et sont spécifiques à la carte.
Plus précisément, il contient le script pour les emplacements de la carte d'orientation pour
afficher les noms d'emplacement dans le HUD pour chaque joueur lorsqu'il entre dans l'un des
emplacements désignés pour les aider dans leur navigation.
Fermez enfin l' élément de base "mission_script" avec une balise de fin.
C'est toute l'édition XML nécessaire pour ajouter le mode de jeu TDM à une carte. Les autres
modes, à l'exception de RvsA, ont une implémentation identique. RvsA, comme décrit précédemment,
a seulement la différence qu'il a les sprites de carte qui doivent être définis, donc ce n'est vraiment
pas si différent des autres modes de jeu.
Bien que nous n'ayons pas encore terminé, nous devons encore nous assurer que tous les objets
utilisés dans le fichier *_rules.xml attribué sont présents sur la carte. Sinon, le jeu plantera lorsque
nous essaierons de créer un serveur exécutant cette carte avec le mode de jeu que nous avons ajouté.
Le chapitre suivant listera tous les objets qui doivent être placés pour que chacun des modes de jeu
unifiés originaux fonctionne, alors passons à cela.
6
Chapitre 2 : Modes de jeu originaux
Ce chapitre contient uniquement les informations nécessaires lors de l'ajout de l'un des modes de jeu unifiés d'origine à
une carte, sous la forme de listes d'objets que le script vous oblige à placer sur la carte dans l'éditeur de carte. Les listes
contiennent également les noms exacts qui doivent être utilisés pour chaque objet, et si quelque chose manque ou est
mal nommé, la carte plantera tout serveur qui a essayé de la démarrer dans ce mode de jeu.
Team Deathmatch "TDM" est un
mode simple à configurer dans l'éditeur de carte. Tout ce dont il a besoin, c'est de deux emplacements d'apparition, un
pour chaque côté.
tdm_spawn_a Lieu de spawn pour l'équipe américaine.
tdm_spawn_b Emplacement de spawn pour l'équipe Mex.
Deathmatch "DM"
nécessite la dispersion de 32 points d'apparition sur la carte. Ils ne doivent pas être placés dans l'ordre des numéros
car le frai se produit dans l'ordre. Cela peut être utilisé pour s'assurer que les joueurs n'apparaissent pas trop proches
les uns des autres au début d'un match lorsque seuls quelques joueurs sont sur le serveur au début.
De :
dm_spawn01 Point d'apparition 01.
À:
dm_spawn32 Point d'apparition 32.
Le siège
"S" nécessite un emplacement d'apparition pour chaque côté, ainsi qu'un emplacement pour le côté Mex à défendre.
s_spawn_a Lieu de spawn pour l'équipe américaine.
s_spawn_b Emplacement de spawn pour l'équipe Mex.
s_capture Emplacement pour Mex à défendre et US à capturer.
7
Hamburger Hill "HH"

nécessite un emplacement d'apparition pour chaque camp, ainsi qu'un emplacement pour que les deux
camps se battent.
La fumée sera placée par les règles dans la zone de capture. Pour tous les types de lieux à l'exception du polygone, la
fumée sera placée au centre de la zone. Lorsque le polygone est utilisé, la fumée sera placée là où le premier point est
placé.
hh_spawn_a Lieu de spawn pour l'équipe américaine.
hh_spawn_b Emplacement de spawn pour l'équipe Mex.
hh_capture Emplacement pour Mex à défendre et US à capturer.
Recon vs Assault "RvsA"
nécessite le plus de travail d'éditeur de carte.
Pour le côté Mex, il faut trois ADATS à protéger et un lieu d'apparition en connexion avec chaque ADAT. Quand ADAT A
est détruit, spawn A est désactivé, et ainsi de suite.
Pour le côté américain, il a besoin d'un emplacement de spawn initial ainsi que d'un emplacement de spawn en
connexion avec chaque ADAT pour le spawn de renfort lorsqu'un ADAT est détruit.
Pour les deux côtés, il a également besoin d'un emplacement d'assistance partagé autour de chaque ADAT. Cet
emplacement est utilisé par les joueurs Mex pour gagner des PV supplémentaires lorsqu'ils tuent un soldat américain à
l'intérieur, ainsi que pour récompenser des VP supplémentaires aux soldats américains lorsque l'ADAT est détruit s'ils se
trouvaient à l'intérieur de l'emplacement où le C4 a été placé. L'emplacement correspondant est désactivé une fois l'ADAT
détruit afin que les soldats Mex ne puissent plus gagner de PV supplémentaires à l'intérieur.
recon_spawn Lieu d'apparition initial pour l'équipe américaine.
agression_spawn_a Emplacement d'apparition pour l'équipe Mex tandis que l'ADAT A reste.
agression_spawn_b Emplacement d'apparition pour l'équipe Mex tandis que l'ADAT B reste.
agression_spawn_c Emplacement d'apparition pour l'équipe Mex tandis que l'ADAT C reste.
adat_spawn_a Lieu de réapparition de l'équipe américaine lorsque l'ADAT A est détruit.
adat_spawn_b Lieu de réapparition de l'équipe américaine lorsque l'ADAT B est détruit.
adat_spawn_c Lieu de réapparition de l'équipe américaine lorsque l'ADAT C a été détruit.
obj_a_assist Lieu de récompense combiné entourant ADAT A.
obj_b_assist Lieu de récompense combiné entourant ADAT B.
obj_c_assist Lieu de récompense combiné entourant ADAT C.
8
Chapitre 3 : Coop
Après avoir lu les chapitres précédents, vous vous demandez probablement ce qui est arrivé à Coop car il utilise
également le système de kit et peut être hébergé en combinaison avec les modes de jeu mentionnés cidessus sur
un serveur. La vérité est que Coop n'est pas un mode de jeu unifié car ce mode est construit sur des missions réelles
qui nécessitent un script spécial pour chaque carte sur laquelle il est utilisé, il ne serait donc pas possible de le rendre
unifié à moins d'avoir le même objectif et le même nombre d'ennemis sur chaque carte en était le but. Mais une partie
de la configuration est toujours la même même si Coop nécessite que vous créiez un script de mission complet, tout
comme pour Campaign Coop ou Single Player.
Fichiers
Même si Coop nécessite son propre script de mission, certaines parties de celuici sont partagées entre les cartes
et ce sont les parties qui définissent le mode et le rendent différent de Campaign Coop, comme lui permettre d'avoir
plus de joueurs en raison de ne pas étant limité par les limitations CrossCom.
Coop a son propre fichier coop_settings.xml qui définit ce qui est disponible dans le mode jeu sous forme de cartes
et d'interface, tout comme les autres modes MP. Nous couvrirons tous ces différents éléments trouvés dans les
fichiers *_settings.xml au chapitre 5 lors de la création de notre propre mode de jeu, donc pour l'instant laissonsles.
Il a également un coop_rules.xml, qui ne contient que des informations de base sur l'activation de l'emplacement
de spawn initial, comme vous pouvez le voir cidessous.
Le contenu de coop_rules.xml :
<coop_rules> <event name=”start_game”
type=”once”>
<element type= »SetSpawnLocation » location= »coop_spawn » set= »true
» side= »1 »/> </event>
<event name=”start_round” type=”once”> <element

type=”SetSpawnLocation” location=”coop_spawn” set=”true” side=”1”/>
<element type=”AllowSpawn” side=”1” quand =”always” after_start=”true”
start_time=”3”/> <element type=”Calculate”> <store target=”winner_counter”
source=”0”/> </element> <element type=”TriggerEvent” événement
=”start_mission”/> </event> </coop_rules>
Comme vous pouvez le voir, Coop pourrait en théorie être inclus sur la même carte que les autres modes de jeu car
il a sa propre balise "coop" , mais nous avons simplement choisi de ne pas l'implémenter comme ça dans la plupart
des cas car nous avions encore besoin d'avoir différents world.xml dans Coop, il était donc plus simple de les créer
dans des structures de dossiers séparées.
9
Installer
World_Info.xml Le
world_info.xml doit être configuré exactement de la même manière que pour les modes de jeu unifiés, avec une
balise "world_info" pointant vers le fichier coop_settings.xml , et ayant des éléments de contenu pointant vers
l'écran de chargement et la minicarte souhaités, et leurs coordonnées souhaitées.
Remarque : Comme Coop utilise des ennemis IA, assurezvous que le fichier world_info.xml inclut un élément qui pointe
vers le graphique IA de la carte, dont les autres modes n'ont pas besoin.
Mission.xml
Dans le fichier mission.xml , vous allez bien sûr scénariser vos missions entières avec des déclencheurs et
des événements comme décrit dans le didacticiel "GRAW2 : Script pour les débutants", mais en plus de cela,
vous devez attribuer un fichier de restriction de kit, car Coop utilise le système de kit, comme ainsi que
d'inclure le coop_rules.xml.
Utilisez les mêmes éléments "xi:include" que pour les autres modes de jeu, mais assurezvous qu'ils ne sont
inclus dans aucun événement de mission. Nous l'avons placé au début du script de mission après la balise
d'ouverture initiale "mission_script" pour le mode de jeu, tout comme pour les autres modes de jeu, mais la
différence est que les éléments "mission_script" ne doivent pas se refermer avant la fin du script entier pour la
mission coopérative.
Exemple de sortie de mission.xml appartenant à la carte "Coop Quarry" : <mission_script

name=”coop” type=”once”> <xi:include href="/data/levels/common/coop_rules.xml"/> <xi :include
href="/data/levels/common/coop_ranks_ogr_quarry.xml"/>
<event name=”start_game”> <element

type=”... <element type=”... </event>
<nom de l'événement="...
<element type="... <element
type="... </event> </
mission_script>
Remarque : J'ai vu que certains scripteurs ont implémenté leurs scripts Coop de différentes manières, mais je vous suggère de
rester sur ces lignes car cela devrait vous donner la meilleure vue d'ensemble.
Remarque : Comme vous pouvez le voir dans l'exemple cidessus, cette carte a un fichier spécial *_ranks.xml car il a été
conçu pour permettre au joueur d'utiliser des roquettes antichars, ce que les restrictions normales ne permettent pas.
Nous verrons comment les créer dans les chapitres 6 et 7.
dix
Objets requis "COOP" n'a
qu'un seul objet requis spécifié dans le fichier coop_rules.xml, qui est la zone d'insertion.
coop_spawn Lieu d'apparition de l'équipe de joueurs.
Ceci est uniquement utilisé comme emplacement de spawn initial. N'importe quel nombre d'emplacements de
réapparition peut ensuite être utilisé tout au long de la mission, qui peut être désactivé et activé pendant la mission
pour déplacer l'emplacement de réapparition au fur et à mesure que la mission progresse.
Comme il n'y a pas grand
chose à l'intérieur du fichier coop_rules.xml , et clairement rien de ce qui est vraiment nécessaire à part vérifier si
l'équipe est morte si elle ne joue pas avec des réapparitions infinies car les insertions peuvent être créées d'autres
manières dont le fichier n'a pas vraiment besoin pour être inclus.
La seule chose qu'il fait est de simplifier le début de la mission afin que vous puissiez rapidement entrer et commencer
à tester lors de la création de scripts et de la construction de votre mission. En plus de cela, je suppose que la
communauté sera limitée lors de son utilisation car cela ne convient pas aux insertions cinématographiques et à des
choses aussi fantaisistes. Donc, juste pour vous faire savoir que vous n'avez vraiment pas besoin d'utiliser le fichier
coop_rules.xml. Pour ce faire, n'ajoutez simplement pas la ligne include dans votre
mission.xml.
Exemple de mission.xml si "Coop Quarry" n'a pas utilisé coop_rules.xml : <mission_script

name="coop" type="once">
<xi:include href="/data/levels/common/coop_ranks_ogr_quarry.xml"/>
<event name=”start_game”> <element

type=”... <element type=”... </event>
<nom de l'événement="...
<element type="... <element
type="... </event> </
mission_script>
L'insertion dans Coop doit toujours se faire dans un lieu, pas dans un véhicule. C'est fait comme ça parce qu'il n'y a
pas de véhicules dans GRAW2 qui peuvent transporter/insérer une équipe de 12 hommes, et vous ne pouvez pas
diviser l'équipe entre plusieurs véhicules lors de l'insertion.
Important : si vous décidez de le faire, vous devez attribuer un emplacement de réapparition à l'équipe avant de les
configurer pour autoriser la réapparition.
D'accord. Je pense que cela termine tout ce qui a à voir avec les modes de jeu qui peuvent être hébergés dans le
même cycle de carte sur un serveur. Jetons maintenant un coup d'œil à la campagne Coop avant de passer à la
création d'un mode de jeu personnalisé.
11
Chapitre 4 : Coopération de campagne
Ce mode multijoueur est très différent des autres, et n'est pas configuré de la même manière et ne peut
pas être hébergé dans un cycle de carte avec les autres modes de jeu. Toutes les missions jouables dans
Campaign Coop sont également jouables en solo et vice versa.
Ils ont tous les deux les mêmes restrictions et possibilités. En d'autres termes, contrairement aux autres
modes multijoueurs, Campaign Coop utilise toutes les fonctionnalités crosscom, les cartes de briefing, l'écran
de sélection de kit gratuit, la possibilité d'ajouter l'IA à l'équipe, le chef d'équipe désigné avec accès à la carte
tactique satellite et à d'autres unités de soutien comme par exemple les frappes aériennes . Comme il est
limité, tout comme le mode solo, à une équipe de 4 hommes, tous les véhicules peuvent être utilisés pour
l'insertion et l'extraction, tout en permettant à plus d'ennemis et de graphiques d'être dans la scène en même
temps.
La seule chose qui diffère entre le mode solo et la coopération de campagne dans la configuration est une
seule variable dans le fichier world_info.xml, où la mission se voit attribuer sa place dans la campagne et
l'équipe par défaut est définie ainsi que les éventuelles restrictions de sélection d'armes pour le mission.
Cette variable est « coop », qui doit être attribuée à l' élément « campagne » et définie sur « true ». S'il n'est
pas utilisé, la valeur par défaut est "false" et la mission n'apparaîtra pas dans les listes de création de
serveur. C'est aussi simple que ça… une fois que vous avez les missions scénarisées. :P
Exemple de sortie de world_info.xml appartenant à "mission01": <campaign

name=”graw2” act=”1” order=”1” coop=”true”> <candidate name=”MITCHELL” kit=””
def_team=”true ”/> <nom du candidat=”BEASLEY” kit=”” def_team=”true”/> <nom
du candidat=”BROWN” kit=”” def_team=”true”/> <nom du candidat=”HUME” kit=””
def_team=”false”/> <candidate name=”JENKINS” kit=”” def_team=”false”/>
<candidate name=”RAMIREZ” kit=”” def_team=”true”/> <block_weapon
name=”barrett” /> <block_weapon name=”hk21e”/> <block_weapon name=”m32”/
> <block_weapon name=”predator” coop=”true”/> </campaign>
Comme vous pouvez le voir dans l'exemple cidessus, la variable "coop" peut également recevoir l'
élément "block_weapon" afin que l'arme ne soit pas non plus sélectionnable lors de la lecture de la
mission en mode Campagne Coop. Cela peut être utile à des fins de conception de mission car certaines
missions seront trop faciles si les joueurs sont autorisés à avoir des armes antichars, même si l'objectif n'est
que de retirer des ADAT inoffensifs ou des pièces d'artillerie car ils n'ont alors pas à obtenir au plus près
des objectifs pour les atteindre.
Pour obtenir de l'aide sur le script de la mission Coop de campagne, je devrai me référer au tutoriel "GRAW2 :
Script pour débutants", comme je l'ai fait dans la section Coop, car il couvre tous les différents éléments de
script que le jeu a à offrir.
Maintenant que le mode multijoueur final a été couvert, passons à la création d'un mode de jeu
personnalisé.
12
Chapitre 5 : Modes de jeu personnalisés
Après avoir vu comment tout est implémenté, vous avez probablement déjà compris qu'il est facile de
créer des modes de jeu personnalisés pour GRAW2. Tout ce dont un mode de jeu personnalisé a
besoin, c'est d'un XML de règles spéciales et d'un XML de paramètres spéciaux, ainsi que d'une
documentation sur les objets requis dont il a besoin pour que les gens puissent l'implémenter sur leurs
cartes, et vous êtes prêt à partir.
L'identifiant de mode de jeu donné aux attributs "type" et "name" dans les fichiers que nous avons
examinés au chapitre 1, comme "dm" pour deathmatch, peut être défini sur n'importe quoi tant qu'il est
le même dans les différents fichiers. Cela devrait également être documenté avec le reste des instructions
si vous envisagez de créer un mode de jeu unifié pour l'ensemble de la communauté.
Que devezvous savoir pour créer un nouveau mode de jeu ? Tout d'abord, vous avez besoin d'une
bonne idée et d'un plan logique sur la façon de le décomposer en un code pour que le jeu le comprenne,
et peutêtre aussi pour que les joueurs le comprennent facilement lorsqu'ils y seront confrontés pour la
première fois. Mais en plus du travail personnel de planification et de structuration de toute conception de
jeu, que devezvous savoir de spécifique à GRAW2 pour l'implémenter ?
Pour créer le fichier XML de règles, tout ce que vous devez savoir est le script de mission, comme
expliqué dans le tutoriel "GRAW2 : Scripting pour débutants". La plupart des éléments de ce document
peuvent être utilisés dans MP, et certains sont spécifiques à MP. Pour commencer, je suggère que vous
preniez l'une des règles d'origine et que vous la développiez/modifiiez pour vous familiariser avec le
script MP. Ce fichier est au cœur du mode de jeu, c'est donc là que vous passerez la plupart de votre
temps à ajuster et à ajouter des correctifs pour tous les cas particuliers qui pourraient devoir être traités.
Recon vs Assault a pris quelques essais avant de devenir ce que vous avez tous testé dans la bêta, la
démo et dans le jeu final. Cela a commencé de manière différente, mais les tests, la réévaluation et
l'ajustement du code en ont fait l'un des meilleurs modes MP que GRAW2 a à offrir. Rappelezvous
également qu'il ne s'agit que des règles du mode, et qu'en tant que tel, il ne devrait pas inclure quoi que
ce soit qui serait spécifique à la carte, c'est pourquoi vous verrez que le coop_rules.xml a très peu de
lignes car dans ce mode chaque carte a sa propre histoire de mission avec des unités placées et un flux
de mission.
Le XML des paramètres est un peu différent car il se compose presque uniquement de paramètres
variables pour ce que le mode de jeu doit utiliser dans le jeu, comme le système de balises, l'écran
d'état, les points de victoire, le nombre de côtés et la façon dont les tours doivent changer les équipes,
etc. au. Ici, vous définissez également ce que l'identifiant pour le mode de jeu, comme "dm" pour
deathmatch, est pour le mode de jeu. Nous examinerons de plus près ce fichier par la suite.
*_settings.xml Vous
pouvez définir un grand nombre de variables différentes ici ; tout ce que vous trouvez
dans sb_server_setting.xml peut être défini sur une nouvelle valeur dans ce fichier pour le mode de jeu
spécifique. Nous ne couvrirons que les variables utilisées dans le jeu original dans ce didacticiel (utilisez
tout le reste à vos risques et périls). Toutes ces affectations de variables doivent être entourées de la
balise "gametype_settings" .
13
Variable Description par défaut
contradictoire
false Définir si le mode de jeu est PvP/TvT. false Définir si
always_reload_map les scripts doivent être rechargés à chaque tour.
awa_distance 15000 Définissez la distance à laquelle l'indicateur d'incendie capte

les tirs entrants. round Définir le type de message à afficher à
end_round_message la fin des rounds.
vrai Définir si le match doit consister en un nombre pair de tours.

even_round
mode de jeu MPCoop Réglé sur "Personnalisé", ancienne variable GRAW1.

has_mp_map false Définir s'il utilise la carte MP. false Définir si
has_tag_data_system les données de balise doivent être affichées. true Définir si les
has_tag_system joueurs peuvent taguer.
has_xcom true Défini si les éléments crosscom du HUD sont utilisés.
hud_abc_objective false Définir si l'interface graphique de l'objectif ABC est

match_is_one_round affichée. false Définir si une correspondance est toujours
minimap_enemy_markers d'un tour. true Définir si les ennemis marqués s'affichent sur
la minicarte. minimap_friendly_markers true Définir si les membres de l'équipe s'affichent sur la

minicarte. minimap_player_marker true Définir si le joueur s'affiche sur la minicarte. false Définir
système_de_classement si le système de classement est utilisé pour les kits.
reset_kills_per_round false Définir si le killboard se réinitialise après chaque tour.
score_listing_type 0 Définir si le gagnant est le joueur avec le moins de décès si le

serveur est défini sur des réapparitions limitées.
fumigènes vrai Défini si l'IA ne peut pas voir à travers la fumée, empêche le
joueur de placer C4 dans la fumée.
spawn_on_side_switch vrai Définir si le spawn est autorisé après le changement

équipes.
Définissez la façon dont l'échange de rondes se produit. "côté"
swap_method côté fait changer d'équipe les joueurs, "spawn" garde les joueurs dans
la même équipe et permute les emplacements de spawn. "aucun"
garde tout pareil.
Ordinaire Définir si compte à rebours « normal » ou minuterie
timer_type
« mission » . false Définir si le meurtre d'équipe est récompensé.
tk_scoring
marqueurs_de_mise_à_jour équipe Définissez pour qui mettre à jour les marqueurs, "côté",
"équipe" ou "aucun" autre que le joueur. false Définir si des
use_side_score éléments de score latéraux dans le HUD sont utilisés.
use_sides deux
Définissez le nombre de côtés du joueur, "un" ou "deux".
use_victory_points vrai Définir si le système de points de victoire est
win_method utilisé. côté Définissez si le gagnant est « côté » ou seul « joueur ».
Remarque : "has_status_screen", "has_tacmap" et "show_teammates" sont également définis dans les

modes de jeu d'origine, mais ont été remplacés par d'autres options et ne sont plus utilisés.
14
La dernière partie nécessaire à l'intérieur de la balise "gametype_settings" est la balise "mission_script" , qui
doit avoir un élément "include" avec la variable "name" définie sur l'identifiant du mode de jeu que vous
souhaitez utiliser pour le mode de jeu.
Exemple :
<mission_script> <include
name="hh"/> </mission_script>
Cela définit le nom à rechercher dans le script de mission pour chaque carte sur laquelle il est désigné.
Exemple de code avec le nom utilisé à l'intérieur de cette balise dans

mission.xml : <mission_script name="hh">
<xi:include href="/data/levels/common/mp_ranks.xml"/> <xi:include
href="/data/levels/common/hh_rules.xml"/> <xi:include
href="mission_specific.xml" ”/> </mission_script>
Cela devrait être tout pour créer votre propre mode de jeu personnalisé. ☺
Malheureusement, vous ne pouvez pas définir le texte à afficher pendant l'écran de chargement car il est codé
en dur uniquement avec les identifiants du mode de jeu multijoueur d'origine. Mais vous pouvez définir un
écran de chargement personnalisé, sur lequel vous pouvez dessiner ou écrire.
15
Chapitre 6 : Restrictions relatives aux kits personnalisés
Dans ce chapitre, nous allons créer une nouvelle sélection de kits qui limite le joueur à n'utiliser que des armes de
poing, ce qui nécessitera également la création de nouveaux kits, mais cela sera couvert au chapitre 7, donc pour
l'instant, concentronsnous sur la restriction des kits dossier. Après ce chapitre, vous devriez être en mesure de créer
votre propre restriction de kit pour tous vos besoins en matière de serveur et/ou de mode de jeu personnalisé.
La base du système de kit est que vous définissez quelles classes doivent être incluses lors de l'utilisation de ce fichier
de restriction de kit *_ranks.xml . Ensuite, vous ajoutez des variantes à chaque classe qui seront les kits alternatifs que
la classe est autorisée à sélectionner. Chaque classe peut recevoir des compétences spéciales en plus de la sélection
d'armes que vous ajoutez, que nous aborderons également dans le chapitre suivant lors de la création de nouvelles
classes et variantes. Commençons maintenant par examiner les fichiers XML des classements.
*_ranks.xml Pour
commencer, examinons une partie du fichier mp_ranks.xml , qui est le fichier de rangs de base utilisé pour tous les
modes originaux en plus de RvsA, sur toutes les cartes originales. Je l'ai réduit pour qu'il n'y ait qu'une seule classe,
avec 2 kits alternatifs chacun, pour chaque côté afin d'avoir une meilleure vue d'ensemble.
Extrait de mp_ranks.xml <default_ranks>
<veteran_data>
<team name="team_a">
<rank level="1">
<nom du modèle="mp_us_demo_1">
<variation name="mp_us_demo_2"/>
<variation name="mp_us_demo_3"/> </
template> </rank> </team> <team
name="team_b"> <rank level="1">
<nom du modèle="mp_mex_demo_1">
<variation name="mp_mex_demo_2"/>
<variation name="mp_mex_demo_3"/> </
template> </rank> </team> </veteran_data> </
default_ranks>
D'accord. Ici, nous avons une restriction de classe de démonstration uniquement avec 1 kit par défaut et 2
variantes de kit supplémentaires pour les côtés américain et mexicain. Comme vous pouvez le constater, la
structure des balises est assez basique et je ne pense pas avoir besoin de tout couvrir en détail.
16
Une chose importante à noter est qu'à l'intérieur des étiquettes d' équipe , qui séparent les kits des deux
côtés, il y a une étiquette de rang qui est définie au niveau 1. Cette étiquette permet de définir des kits à
différents niveaux pour les modes de jeu utilisant des points de victoire et le système de classement.
Lorsque vous créez des fichiers de classement pour d'autres modes, vous devez rester au niveau 1,
sinon les classes ne seront pas sélectionnables car les joueurs ne peuvent pas monter de niveau pour les
obtenir. Je ne sais pas à quel point il serait facile de créer un autre mode de jeu pour utiliser le système de
points de victoire, mais au moins cela peut être utile si quelqu'un veut créer de nouveaux kits pour RvsA.
Viennent ensuite les balises de modèle qui définissent une classe, suivies des balises de variation pour
les kits alternatifs de la classe.
Pour notre exemple, je veux créer une nouvelle classe appelée tireur pour chaque côté, qui devrait
être sélectionnable en 3 versions différentes car il y a 3 armes de poing différentes dans le jeu original,
il faut donc 2 variantes pour chaque côté en plus de la classe initiale. Je nommerai également le nouveau
fichier de rangs gunmen_ranks.xml.
The gunmen_ranks.xml :
<default_ranks>
<veteran_data> <team
name=”team_a”> <rank
level=”1”>
<nom du modèle = "mp_us_gunman_1">
<variation name=”mp_us_gunman_2”/>
<variation name=”mp_us_gunman_3”/> </
template> </rank> </team> <team name=”team_b”>
<rank level=”1”>
<nom du modèle = "mp_mex_gunman_1">

<variation name=”mp_mex_gunman_2”/>
<variation name=”mp_mex_gunman_3”/> </
template> </rank> </team> </veteran_data> </
default_ranks>
Cela devrait suffire pour ce fichier. Le problème maintenant est qu'il n'y a pas de
"mp_us_gunman_1", "mp_mex_gunman_1" ou l'une des autres variantes de la liste cidessus, où que
ce soit dans le jeu. Nous devrons donc également les créer, ce que nous ferons dans le chapitre suivant.
17
Chapitre 7 : Classes et kits personnalisés
Comme nous l'avons remarqué dans le dernier chapitre, lors de la création de nouvelles restrictions de kit,
et surtout s'il est conçu pour rendre jouable un nouveau mode de jeu personnalisé, nous avons parfois
besoin de plus de kits et/ou de classes que le jeu original n'a à offrir. Voyons donc comment créer la classe
de tireurs que je voulais avec des kits comprenant uniquement des armes de poing, ainsi que des kits
optionnels pour chacune des trois armes de poing dans GRAW2.
Comme nous l'avons également vu dans le dernier chapitre, différents kits pour une classe ne sont en
fait rien d'autre qu'une autre version de la même classe qui a une autre sélection d'armes et est définie
pour être utilisée comme une variation dans le fichier de restriction de kit. Chaque combinaison de classe
et de kit dans GRAW2 est appelée soldat. Tous les soldats sont définis à l'intérieur des fichiers
*_template.xml , nous allons donc voir ensuite à quoi ressemble le code XML à l'intérieur.
*_template.xml Comme
indiqué, les soldats dans GRAW2 sont définis dans des fichiers appelés *_template.xml, qui dans le jeu
original se trouvent tous dans le dossier data\lib\managers\xml .
Chaque soldat nécessite une grande quantité de balises différentes pour le définir, et pour éviter d'avoir
à les écrire toutes pour chaque variation de kit que nous voulons définir pour une classe, Grin utilise la
fonction xdefine en XML. Ce n'est pas nécessaire sauf bien sûr, mais nous verrons comment le faire plus
tard. Mais d'abord, nous verrons comment créer un soldat sans utiliser d'astuces XML fantaisistes. Pour
cela nous allons parcourir les balises de l'exemple soldat vu cidessous de haut en bas.
Exemple de soldat de mp_template réécrit sans utiliser xdefine : <soldier

name=”mp_us_rifleman_1”> <unit name=”ghost_domination”/> <head_unit
name=”ghost_head_mitchell”/> <texture_switch material=”camo”
texture=”self_illumination_texture” file=” data/textures/atlas_characters/
mul_camo_xy/
camo_02/camo_ACU_test_xy_df”/>
<color_switch material=”camo” color=”base_color”
valeur="0.54 0.50 0.47"/>
<stats block="base_data">
<var name=”public_name” value=”mp_title_rifleman 1”/> </stats> <stats
block=”human_data”> <var name=”icon_name” value=”us_rifleman”/> <var
name=”class_info” value= ”mp_rifleman_info”/> <nom de la
var=”veterans_tree_id” value=”4”/> <nom de la var=”tag_type” value=”none”/
> <nom de la var=”has_explosive” value=”1”/> <nom de la var
=”bomb_planting_time” value=”4”/> </stats> <weapon_unit name="g36"
clips=”5” gui_slot=”1”> <mod name=”aimpoint”/> </weapon_unit>
<weapon_unit name= ”mp5sd” clips=”4” gui_slot=”2”/> </soldier>
18
Élément de soldat
L' élément de base « soldat » dont nous savons que toutes les autres balises sont contenues,
définit un soldat qui peut être ajouté à un xml de rangs comme un « modèle » ou une « variante »
en utilisant la valeur donnée à l' attribut « name » . Pour cette raison, le nom du soldat doit être unique.
<nom du soldat = "mp_us_rifleman_1">

<...
<...
<...
</soldat>
Contenu de l'élément Soldat

Élément unitaire
L' élément "unité" reçoit le "nom" de l'unité de corps à utiliser. L'unité de corps est une version du
corps du personnage sans tête et avec un minimum d'équipement, définie dans un autre fichier XML
où elle est combinée avec les jeux d'animation du personnage à utiliser.
<unit name="ghost_domination"/>
Types d' unités Ghost disponibles :

ghost_rvsa domination_fantôme
Types d' unités fantômes

disponibles : mex_domination
Remarque : seules les unités utilisées dans le mode multijoueur d'origine sont répertoriées ici. Pour plus d'unités disponibles
dans GRAW2, que vous pouvez utiliser à vos propres risques de problèmes de performances, vérifiez dans group_manager.xml
tous les personnages utilisés en mode solo.
Élément de l'unité principale
L' élément "head_unit" reçoit le "nom" de la tête à utiliser.
<head_unit name=”ghost_head_mitchell”/>
Types d' unités de tête Ghost disponibles :

ghost_head_mitchell ghost_head_brown ghost_head_hume
ghost_head_jenkins ghost_head_ramirez ghost_head_beasley
Types d' unités de tête Mex disponibles :

mex_mp_head
Remarque : seules les unités principales utilisées dans le multijoueur d'origine sont répertoriées ici. Pour plus d'unités
disponibles dans GRAW2, que vous pouvez utiliser à vos propres risques de problèmes de performances, vérifiez dans
group_manager.xml tous les personnages utilisés en mode solo.
19
Élément d'unité d'engrenage
Pour personnaliser davantage la classe, des éléments optionnels "gear_unit" peuvent être ajoutés
dans n'importe quel nombre, avec leur "nom" individuel donné le nom de l'unité à ajouter à
l'apparence visuelle de la classe, comme par exemple "ghost_back_strap" ou "gear_hips_gear_04".
Avertissement : De nombreux joueurs avec beaucoup d'unités d'équipement peuvent affecter les performances. N'abusez pas de
cette fonctionnalité.
<gear_unit name=”ghost_back_strap”/> <gear_unit

name=”ghost_holster_01”/> <gear_unit
name=”ghost_hips_gear_01”/> <gear_unit
name=”ghost_torso_gear_02”/>
Types d'unités Ghost gear_unit

disponibles : ghost_back_strap ghost_holster_01 ghost_holster_02
ghost_hips_gear_01 ghost_hips_gear_02 ghost_hips_gear_03
ghost_hips_gear_04 ghost_torso_gear_01 ghost_torso_gear_02
ghost_torso_gear_03 ghost_torso_gear_04
Types d'unités gear_unit Mex

disponibles : gear_dropleg_panel_left gear_left_leg_gear_01 gear_torso_gear_01
gear_dropleg_panel_right gear_left_leg_gear_02 gear_torso_gear_02
gear_right_leg_holster gear_left_leg_gear_03 gear_torso_gear_03
gear_hips_gear_01 gear_left_leg_gear_04 gear_torso_gear_04
gear_hips_gear_02 gear_hips_gear_04 gear_torso_gear_05
gear_hips_gear_03 gear_hips_gear_05 gear_torso_gear_06
Remarque : seules les unités d'équipement utilisées dans le mode multijoueur d'origine sont répertoriées ici. Pour plus d'unités
disponibles dans GRAW2, que vous pouvez utiliser à vos propres risques de problèmes de performances, vérifiez dans
group_manager.xml tous les personnages utilisés en mode solo.
Éléments de changement de texture et de changement de couleur
Les réglages de ces 2 éléments sont différents selon « l'unité » utilisée par le soldat , mais
ils fonctionnent toujours par paires. Les modèles de soldats mexicains utilisent un shader de
texture différent de celui des fantômes, et c'est la raison de cette différence. En conséquence, l'unité
mexicaine a besoin de 2 de chaque élément, tandis que les fantômes n'en ont besoin que de 1.
Ces éléments nécessitent des valeurs spéciales pour les types de camouflage disponibles. Pour
une liste complète des camouflages disponibles ainsi que sur quoi définir les variables "file" et
"value" pour chacun d'eux, voir l'annexe 1.
20
L' élément Ghost "texture_switch" a toujours la variable "material" définie sur "camo"
ainsi que la variable "texture" définie sur "self_illimunation_texture".
La variable "fichier" , d'autre part, doit recevoir le chemin et le nom de la texture de
camouflage à utiliser.
Version fantôme de texture_switch :

<texture_switch material=”camo” texture=”self_illumination_texture” file=”data/textures/
atlas_characters/mul_camo_xy/
camo_02/camo_ACU_test_xy_df"/>
<changement_couleur...
Le premier "texture_switch" mexicain fonctionne exactement de la même manière que la version

Ghost, tandis que le second fonctionne de la même manière à l'exception que sa variable "matériel"
doit être définie sur "engrenage". Notez que les deux doivent pointer vers le même "fichier".
Version mexicaine de texture_switch :

<texture_switch material=”camo” texture=”self_illumination_texture” file=”data/textures/
<color_switch...
<texture_switch material=”gear” texture=”self_illumination_texture” file=”data/textures/
<changement_couleur...
L'élément Ghost « color_switch » a toujours sa variable « material » définie sur «

camo » et sa variable « color » définie sur « base_color ». La seule variable qui varie,
selon le camouflage utilisé, est la "valeur" qui doit recevoir la valeur de teinte spécifique
désignée pour chaque texture.
Version fantôme de color_switch :

<texture_switch... <color_switch
material=”camo” color=”base_color”
valeur="0.54 0.50 0.47"/>
Le premier élément mexicain "color_switch" fonctionne comme la version Ghost à

l'exception que la "valeur" doit être définie sur "1 1 1" pour le gris moyen, car il ne doit
pas utiliser de valeur de teinte et rester neutre. Le deuxième élément mexicain
« color_switch » fonctionne également comme la version Ghost à une exception près, à
savoir que la variable « matériel » doit être définie sur « engrenage ». Notez que tout
comme avec le "texture_switch", les deux éléments doivent pointer vers le même "fichier".
Version mexicaine de color_switch :

<texture_switch... <color_switch
material=”camo” color=”base_color”
value=”1 1 1”/>
<texture_switch...
<color_switch material=”gear” color=”base_color”
valeur="0.54 0.50 0.47"/>
21
Données de base, élément

Stats L' élément « stats » avec sa variable « block » définie sur « base_data » doit avoir un
élément « var » comme contenu avec sa variable « name » définie sur « public_name » et la
variable « value » suivante sur le nom à afficher pour le kit dans l'écran de sélection.
<var name="public_name" value="mp_title_rifleman 1"/> </stats>
Human Data, élément Stats L'

élément "stats" avec sa variable "block" définie sur "human_data", a comme contenu un
nombre ou des éléments "var" qui sont requis et définissent à la fois les informations et les
compétences pour la classe spécifique.
<stats block="human_data">
<var nom="...
<var nom="...
<var nom="...
</stats>
Nom de l'icône, élément enfant Var Le

premier contenu "var" a sa variable "name" définie sur "icon_name" et la variable "value" suivante
doit recevoir le nom de l'icône à afficher sur l'écran de sélection du kit en combinaison avec le classer.
<var name="icon_name" value="us_rifleman"/>
Icônes de kits
disponibles : us_rifleman us_support us_sniper nous_scout
us_demolition mex_fusilier mex_support mex_sniper
mex_scout mex_demolition
Informations sur la classe, élément

enfant Var Le deuxième contenu "var" avec sa variable "name" définie sur "class_info" doit avoir sa
variable "value" étant donné le nom de la chaîne contenant les informations sur la classe à afficher
dans l'écran de sélection du kit .
<var name="class_info" value="mp_rifleman_info"/>
22
ID de l'arborescence des vétérans, élément enfant Var Le
troisième contenu « var » avec sa variable « nom » définie sur « veterans_tree_id » doit avoir sa « valeur » en fonction du
numéro que la classe doit avoir, qui doit être unique pour chaque classe utilisée à l'intérieur du même fichier de restriction de kit.
<var name="veterans_tree_id" value="4"/>
Type de balise, élément enfant Var Le quatrième
contenu « var » avec sa variable « name » définie sur « tag_type » devrait avoir sa variable « value » donnée une valeur qui
définit comment cette classe devrait interagir avec le système de balisage dans GRAW2. Utilisez "none" si la classe ne peut
pas marquer les ennemis, utilisez "detagger" si la classe peut supprimer les tags des membres de l'équipe, utilisez "tagger" si
la classe peut marquer en regardant un ennemi, et enfin utilisez "heart_beat" si le la classe peut marquer les ennemis à travers
les murs. Les façons dont cette compétence spéciale peut être définie pour différentes classes peuvent bien sûr être utiles à
connaître lors de la conception de modes de jeu personnalisés. Le paramètre par défaut est "tagger" si "tag_type" n'est pas
défini dans la classe.
<var name="tag_type" value="none"/>
Types de balises disponibles :

rien Mots clés détacher battement de coeur
Si le "tag_type" est défini sur autre chose que "none" , il y a 3 éléments supplémentaires qui peuvent être utilisés. Ces éléments
définissent à quelle distance une cible repérée doit être marquée, si la classe est capable de marquer à travers les murs et
également le rayon à l'intérieur duquel le marquage automatique se produit pour les classes définies sur "heart_beat". Cellesci
sont appelées "tag_distance", "tag_radius" et "tag_through", et sont détaillées cidessous.
Tag Distance, élément enfant Var Le contenu "var"
avec la variable "name" définie sur "tag_distance" est utilisé pour définir à quelle distance un ennemi repéré peut être localisé
par rapport au joueur et être marqué. La valeur par défaut est "15000" centimètres si elle n'est pas utilisée.
<var name="tag_distance" value="10000"/>
Tag Radius, élément enfant Var Le contenu "var"
avec la variable "name" définie sur "tag_radius" est utilisé pour définir la taille du rayon autour de toute classe définie sur
"heart_beat" , à l'intérieur duquel les ennemis sont automatiquement marqués. La valeur par défaut est "400" centimètres si elle
n'est pas utilisée.
<var name="tag_radius" value="500"/>
23
Tag Through, élément enfant Var Le contenu
"var" avec la variable "name" définie sur "tag_through" est utilisé pour définir si la classe est capable de
marquer les ennemis à travers les murs, et la valeur par défaut est "false" si elle n'est pas utilisée.
<var name="tag_through" value="$through"/>
A Explosive & Bomb Planting Time, Var Child Element Les cinquième et
sixième éléments « var » sont facultatifs et toujours utilisés ensemble. Ils ne sont nécessaires que si la
classe doit pouvoir poser des bombes sur des objets attachables. Si vous voulez cette compétence pour
votre classe, le premier des éléments "var" aura sa variable "name" définie sur "has_explosive" et l'
attribut "value" suivant recevra la valeur "1" pour permettre à la classe de poser des bombes. La valeur par
défaut de cet élément est "0", valeur qui est utilisée si la balise n'est pas incluse et empêche alors la classe
de poser des bombes sur des objets attachables.
L' élément "var" suivant , qui ne doit être utilisé qu'en combinaison avec le précédent, avec sa variable
"name" définie sur "bomb_planting_time", doit avoir sa variable "value" compte tenu du nombre de secondes
qu'il faudra pour que cette classe poser une bombe. Ainsi, avec cet élément, vous pouvez réellement donner
à différentes classes différentes compétences dans la pose d'explosifs, ce qui peut également être utile à
savoir lors de la conception de modes de jeu personnalisés.
<var name=”has_explosive” value=”1”/> <var

name=”bomb_planting_time” value=”4”/>
Une fois que tous les éléments enfants des éléments "stats" ont été ajoutés et que la balise de fin a été
ajoutée, il est temps de définir les armes disponibles lors de l'utilisation du soldat en tant que kit dans le jeu.
24
Élément d'unité d'arme N'importe
quel nombre d' éléments "weapon_unit" peut être utilisé pour un soldat. Ils nécessitent chacun que leur variable
"name" soit définie sur le nom de l'arme que vous souhaitez ajouter, suivie d'une variable "clips" étant donné le
nombre de clips que les armes doivent avoir dans le kit, et après cela une variable "gui_slot" définissez l'emplacement
de l'interface graphique qu'il doit occuper sur l'écran de sélection du kit.
Les armes qui ont des modules complémentaires peuvent recevoir du contenu sous la forme d' éléments "mod" pour
chaque module complémentaire que vous souhaitez ajouter. Définissez sa variable "name" sur le nom de l'addon à
ajouter bien sûr, et s'il s'agit d'un lancegrenades, il nécessite également une variable "clips" compte tenu du nombre
de tours supplémentaires qu'il devrait avoir.
<weapon_unit name=”g36” clips=”5” gui_slot=”1”> <mod

name=”aimpoint”/> </weapon_unit> <weapon_unit name=”mp5sd”
clips=”4” gui_slot=”2”/>
Remarque : La fonction d'affectation "gui_slot" n'est plus active dans le jeu.
Voir l'annexe 2 pour une liste complète des armes disponibles dans le jeu original, et leurs addons, et il montre
également sur quoi définir la variable "nom" pour chacune d'entre elles.
Terminez le soldat en fermant la balise "soldat" et c'est fait.
Questions possibles ?
Vous devriez maintenant avoir une meilleure idée de la façon de créer une nouvelle classe et un nouveau kit. Mais je
pense aussi que vous avez peutêtre une question ou deux, alors je vais répondre à certaines auxquelles je peux penser
tout de suite.
Q : Quelle est alors la différence entre une classe et un kit ?

R : Chaque soldat différent est une classe différente si quoi que ce soit d'autre que les étiquettes d'unités d'armes
sont différentes ; sinon, il ne s'agit que d'une variante de kit pour une classe, mais il peut également être utilisé dans
une classe par luimême.
Q : Doisje garder une trace de tout ce qui concerne les classes et les kits lors de la création d'un fichier de
restriction de kit ?
R : Non, la partie classe n'est utilisée qu'à partir du soldat que vous définissez comme modèle de classe, à partir de
tout soldat défini comme variante, le jeu ne prendra que les données d'unité d'arme et les combinera avec les données
de classe dans le modèle.
Ok… Maintenant, regardons comment cela fonctionne lorsque nous utilisons xdefine, ce qui éclaircira un peu plus la
différenciation des classes et des kits.
25
xdéfinir
Comme mentionné précédemment, Grin a utilisé xdefine dans les fichiers *_templates.xml . Cela a été
fait pour deux raisons. La première est que vous obtenez des fichiers plus structurés, car ils contiendraient
autrement beaucoup de code répétitif, ce qui est tout simplement gênant à parcourir lorsque vous
recherchez quelque chose. Et la seconde est que lorsque quelque chose doit être changé, vous n'avez
qu'à le faire une fois par xdefine et pas une fois par kit, ce qui est très long
épargnant.
Les programmeurs verront xdefine comme écrire des fonctions ou des méthodes (selon le langage).
Vous lui donnez un nom afin qu'il puisse être appelé ailleurs dans le script, suivi de toutes les variables
que vous souhaitez pouvoir saisir lors de son appel, où toutes les variables sont du type de données
chaîne. Pour ceux qui n'ont pas de connaissances de base en programmation, il faudra probablement
un peu plus de temps pour maîtriser xdefine et se sentir à l'aise avec son utilisation, mais vous y
arriverez à temps. Rappelezvous également que vous n'êtes pas obligé d'utiliser xdefine, c'est juste
une option.
Utilisons la classe que nous avons créée cidessus et travaillons avec elle pour essayer d'expliquer
xdefine à travers un exemple plutôt qu'à travers du texte. Nous commencerons par séparer la section
des armes de cette classe afin que le kit puisse facilement être attribué à différentes classes.
Exemple avec le kit comme

xdefine : <xdefine name=”kit_rifleman_1()”>
name=”aimpoint”/> </weapon_unit> <weapon_unit name
="mp5sd" clips=”4” gui_slot=”2”/> </xdefine>
<soldier name=”mp_us_rifleman_1”> <unit

name=”ghost_domination”/> <head_unit
name=”ghost_head_mitchell”/> <texture_switch
material=”camo” texture=”self_illumination_texture” file=”data/textures/atlas_characters/
mul_camo_xy/
camo_02/camo_ACU_test_xy_df”/>
<color_switch material=”camo" color="base_color”
valeur="0.54 0.50 0.47"/>
<var name=”public_name” value=”mp_title_rifleman 1”/> </stats> <stats
block=”human_data”> <var name=”tag_type” value=”none”/> <var
name=”icon_name” value= ”us_rifleman”/> <nom de la var=”class_info”
value=”mp_rifleman_info”/> <nom de la var=”veterans_tree_id” value=”4”/
> <nom de la var=”has_explosive” value=”1”/> <nom de la var
=”bomb_planting_time” value=”4”/> </stats> @kit_rifleman_1() </soldier>
26
Ce que nous avons fait, c'est retirer les lignes d'unités d'armes de l' élément soldat et les
entrer dans un nouvel élément xdefine . L' élément xdefine a été nommé "kit_rifleman_1()",
où la partie "()" est l'endroit où des variables d'entrée possibles auraient été ajoutées, ce que
nous aborderons plus tard. L' élément xdefine est ensuite appelé depuis l' élément soldat avec
la ligne "@kit_rifleman()", qui insère le contenu de l' élément xdefine avec ce nom là où se
trouve cette ligne d'appel, lorsque l' élément soldat est appelé par le jeu. Ainsi, l'exemple ci
dessus est finalement vu par le jeu exactement le même que l'exemple initial de ce chapitre. La
grande différence est que maintenant le kit est son propre élément séparé et peut, comme dit
précédemment, être utilisé avec une autre classe si cela devrait également avoir la possibilité de
sélectionner un G36 avec Aimpoint et un MP5SD secondaire, en n'incluant qu'une ligne dans ce
classer.
Allons plus loin et définissons le reste du contenu du soldat afin de pouvoir créer différentes
classes à partir du même moule. Pour ce faire, nous allons devoir utiliser des variables d'entrée
pour ce xdefine afin que les éléments qui doivent être différents pour chaque classe, comme la
chaîne de nom, la chaîne de description, le nom de l'icône, etc., puissent recevoir des valeurs
différentes chaque fois que le xdefine est appelé . .
Exemple avec kit et classe comme xdefine :

<xdefine name=”kit_rifleman_1()”>
name=”aimpoint”/> </weapon_unit> < weapon_unit name=
»mp5sd » clips= »4 » gui_slot= »2 »/> </xdefine>
<xdefine name="class_us_1(camo_path, tint_color, public_name,

icon_name, class_info, vt_id ) »> <unit name=
»ghost_domination »/> <head_unit name=
»ghost_head_mitchell »/> <texture_switch material=
»camo » texture= »self_illumination_texture » file= »data/textures/atlas_characters/mul_camo_xy/
$ camo_path”/> <color_switch material=”camo” color=”base_color” value=”$tint_color”/>
<stats block=”base_data”> <var name=”public_name” value=”$public_name”/> </stats > <stats
block=”human_data”> <var name=”tag_type” value=”none”/> <var name=”icon_name”
value=”$icon_name”/> <var name=”class_info” value=”$class_info ”/> <var
name=”veterans_tree_id” value=”$vt_id”/> <var name=”has_explosive” value=”1”/> <var
name=”bomb_planting_time” value=”4”/> </stats> </xdefine>
<nom du soldat=”mp_us_rifleman_1”>
@class_us_1(camo_02/camo_ACU_test_xy_df, 0.54 0.50 0.47, mp_title_rifleman
1, us_rifleman, mp_rifleman_info, 4)
@kit_rifleman_1() </
soldat>
27
Désormais, avec à la fois la classe et le kit comme leur propre xdefine, l'élément soldat est tout d'un coup très
petit et inclut juste la référence à quelle classe et quel kit utiliser pour cela. Cela nous donne un meilleur aperçu
de la relation entre les kits de classe que nous avons essayé de couvrir un peu plus tôt. Imaginez que vous ayez
un grand nombre de kits xdefine et 2 classes xdefine , qui sont utilisées pour créer 10 classes comme il y en a
dans mp_templates.xml, créer toutes les combinaisons possibles consiste simplement à créer les petits éléments
de soldat qui sélectionnent la classe et kit dont il a besoin à partir d'une plus grande base de données. Cela aurait
dû être beaucoup de code répétitif si xdefine n'avait pas été utilisé, et c'est maintenant un système beaucoup plus
facile à utiliser si quelque chose doit être changé dans toutes les classes par exemple.
Comme nous pouvons le voir dans le dernier exemple, la classe xdefine a reçu 6 variables d'entrée, ce qui
nécessite ensuite que nous donnions 6 valeurs séparées par "," lors de son appel. Les variables ne sont déclarées
qu'en insérant le nom que vous souhaitez utiliser entre les "()" et lorsque vous y faites référence à l'intérieur de
xdefine, le même nom est utilisé par avec un "$" devant. Ainsi, la variable définie comme "public_name" est ensuite
utilisée en écrivant "$public_name" où la valeur donnée à "public_name" doit être utilisée.
Comme nous pouvons également le voir, en plus d'utiliser des variables pour les informations spécifiques à la
classe, nous en avons également utilisé certaines pour intégrer le "camo_path" ainsi que "tint_color", qui nous
permettent de définir un camouflage différent pour chaque soldat utilisant cette classe xdefine.
Disons par exemple que nous voulons que "mp_us_rifleman_2" ait la même classe que "mp_us_rifleman_1",
mais un autre ensemble d'armes à utiliser comme variante du kit. Cela peut être rapidement accompli avec notre
configuration actuelle car la classe sera la même et seuls un nouveau kit xdefine et un nouvel élément de soldat ,
qui appelle les pièces nécessaires, doivent être créés.
Exemple de la même classe de carabinier avec différents kits :

<xdefine name=”kit_rifleman_1()”> <weapon_unit name=”g36”
clips=”5” gui_slot=”1”> <mod name=”aimpoint”/> </weapon_unit> <weapon_unit
name= »mp5sd » clips= »4 » gui_slot= »2 »/> </xdefine>
<xdefine name="kit_rifleman_2()">
<weapon_unit name=”m416” clips=”5” gui_slot=”1”> <mod
name=”aimpoint”/> </weapon_unit> </xdefine>
soldat>
soldat>
28
Je sais que cela peut être un peu compliqué au début, et il est vraiment difficile d'essayer d'expliquer de
manière à ce que les nonprogrammeurs puissent le comprendre. Mais au moins, je lui ai donné un coup de
feu. N'oubliez pas que si vous pensez que xdefine est trop compliqué à utiliser pour vous, ne l'utilisez tout
simplement pas et créez vos éléments de soudure comme indiqué précédemment dans ce chapitre.
Soldats armés
Nous allons maintenant utiliser tout ce que nous avons couvert jusqu'ici au chapitre 7 pour écrire les
classes et les kits nécessaires pour le gunmen_ranks.xml créé au chapitre 6.
Le fichier des rangs ne nécessite qu'une seule classe par côté qui aura 2 variantes supplémentaires chacune.
Nous allons commencer par créer la classe xdefine pour chaque camp, que nous appellerons «
class_us_gunman_1 » et « class_mex_gunman_1 ».
Les classes xdefine :

<xdefine name="class_us_gunman_1(head, camo_path, tint_color,
public_name, icon_name, class_info, vt_id ) »> <unit name=
»ghost_domination »/> <head_unit name= »$head »/>
<texture_switch material= »camo » texture=
»self_illumination_texture » file= »data/textures/atlas_characters/ mul_camo_xy/$camo_path”/
> <color_switch material=”camo” color=”base_color” value=”$tint_color”/> <stats
block=”base_data”> <var name=”public_name” value=”$public_name”/> </stats> <stats
block=”human_data”> <var name=”tag_type” value=”none”/> <var name=”icon_name”
value=”$icon_name”/> <var name=”class_info” value= ”$class_info”/> <var
name=”veterans_tree_id” value=”$vt_id”/> </stats> </xdefine>
<xdefine name=”class_mex_gunman_1(camo_path, tint_color, public_name,

icon_name, class_info, vt_id )”> <unit name=”mex_domination”/> <head_unit
name=”mex_mp_head”/> <texture_switch material=”camo”
texture=”self_illumination_texture ” file=”data/textures/atlas_characters/
mul_camo_xy/$camo_path”/> <color_switch material=”camo” color=”base_color”
value=”1 1 1”/>
<texture_switch material=”gear” texture=”self_illumination_texture” file=”data/textures/
atlas_characters/mul_camo_xy/$camo_path”/> <color_switch material=”gear”
color=”base_color” valeur =”$tint_color”/> <stats block=”base_data”> <var name=”public_name”
value=”$public_name”/> </stats> <stats block=”human_data”> <var name=”tag_type” valeur
=”none”/> <var name=”icon_name” value=”$icon_name”/> <var name=”class_info”
value=”$class_info”/> <var name=”veterans_tree_id” value=”$vt_id”/ > </stats> </xdefine>
29
Notez que la classe Ghost a une variable plus que la version mexicaine, qui est utilisée pour envoyer
dans quelle tête le soldat doit utiliser. Comme les Mexicains n'ont qu'une seule tête multijoueur, ce
n'est pas nécessaire pour eux.
Ensuite, nous allons créer les kits nécessaires, que nous appellerons "kit_gunmen_1", kit_gunmen_2"
et "kit_gunmen_3". Chaque kit utilisera l'une des armes de poing disponibles comme contenu afin qu'il
puisse être donné à un fantôme ou à un soldat mexicain lorsque ceuxci seront définis.
Les kits xdefine :

<xdefine name=”kit_gunmen_1()”>
<weapon_unit name=”beretta” clips=”5” gui_slot=”1”/> </xdefine>
<weapon_unit name=”glock” clips=”5” gui_slot=”1”/> </xdefine>
<weapon_unit name=”mk45” clips=”4” gui_slot=”1”/> </xdefine>
Nous n'avons pas besoin d'utiliser de variables pour cellesci, mais nous aurions pu l'utiliser pour
prendre différentes valeurs pour le nombre de clips par exemple.
Enfin, nous les combinerons en balises de soldat appelées "mp_us_gunman_1",

"mp_us_gunman_2", "mp_us_gunman_3", "mp_mex_gunman_1", "mp_mex_gunman_2" et
"mp_mex_gunman_3", c'est ce que nous avons dit à gunmen_ranks.xml de rechercher.
Les fantômes :
<nom du soldat = "mp_us_gunman_1">
@class_us_gunman_1(ghost_head_ramirez, camo_08/camo_coyote_xy_df,
0.82 0.78 0.63, Tireur 1, us_rifleman, mp_rifleman_info,
0) @kit_gunmen_1() </soldier>
<nom du soldat = "mp_us_gunman_2">

@class_us_gunman_1(ghost_head_jenkins, camo_06/camo_green_xy_df,
0.57 0.63 0.54, Tireur 2, us_rifleman, mp_rifleman_info,
0) @kit_gunmen_2() </soldier>
<soldier name=”mp_us_gunman_3”>
@class_us_gunman_1(ghost_head_hume, camo_14/camo_m90_xy_df, 0.40 0.46
0.40, Gunman 3, us_rifleman, mp_rifleman_info, 0) @kit_gunmen_3() </soldier>
30
Les Mexicains :
<nom du soldat = "mp_mex_gunman_1">
@class_mex_gunman_1(camo_10/camo_tigerstripe_xy_df, 0.48 0.50 0.44,
Tireur 1, mex_rifleman, mp_rifleman_info, 0)
@kit_gunmen_1() </
soldat>
<nom du soldat =”mp_mex_gunman_2”>

@class_mex_gunman_1(camo_09/camo_cityblock_yx_df, 0.59 0.55 0.59,
@kit_gunmen_2() </
soldat>
<nom du soldat=”mp_mex_gunman_3”>
@class_mex_gunman_1(camo_11/camo_flecktarn_xy_df, 0.49 0.52 0.46,
@kit_gunmen_3() </
soldat>
Dans l'exemple cidessus, nous avons utilisé la variable de tête supplémentaire pour les fantômes afin
de donner à chaque variation de kit sa propre tête. Nous avons également utilisé les variables de
camouflage afin que tous les kits des deux côtés aient un look différent. De plus, comme il n'y a pas
d'icône qu'un soldat utilise autre chose que des armes primaires ou secondaires, peu importe l'icône que
nous utilisons, donc "us_rifleman" et "mex_rifleman" devront faire l'affaire. Il en va de même pour leurs
textes descriptifs car nous n'avons pas défini de nouvelles chaînes pour ceuxci.
Maintenant, enregistrons toutes ces parties en tant que contenu dans un élément appelé "to_include", dans
un fichier appelé gunmen_templates.xml, et ce devrait être tout. Alors maintenant, le gunmen_ranks.xml
devrait être utilisable en l'assignant à une carte dans son mission.xml comme décrit au chapitre 1, donc
d'une certaine manière, nous avons bouclé la boucle. Mais… il reste encore quelque chose à faire.
group_manager.xml Le jeu ne
trouvera pas nos nouvelles déclarations de soldat dans gunmen_templates.xml car il ne sait pas qu'il
existe. Pour que cela fonctionne, ce fichier devra être ajouté à la liste des fichiers modèles dans
group_manager.xml.
C'est simple à faire. À la fin de group_manager.xml, nous trouvons une section appelée multijoueur,
où les autres modèles sont répertoriés. Donc, nous dupliquons simplement l'une de ces entrées et
changeons le nom du fichier à l'intérieur en gunmen_templates.xml, et cela devrait vraiment être tout.
Entrée nécessaire dans

group_manager : <xi:include href="gunmen_templates.xml#xpointer(/to_include/*)"/>
31
C'est
tout ce qu'il y a à faire pour configurer les modes de jeu multijoueurs originaux sur des cartes personnalisées,
configurer des modes de jeu personnalisés à utiliser avec le système unifié, ainsi que créer des classes
personnalisées, des kits et des restrictions de kit.
J'espère que ce document vous a permis de mieux comprendre le système de données utilisé pour configurer
et personnaliser les jeux multijoueurs, et qu'il contribuera à faire évoluer l'expérience de jeu pour la communauté.
Bonne chance.
Grin_Wolfsong, de sortie.
32
Annexe 1 : Liste de camouflage
Ce chapitre contient une liste de toutes les versions de camouflage incluses dans le jeu original,
ainsi que les valeurs nécessaires pour les utiliser lors de la création de modèles de soldat.
Les valeurs de "commutateur de couleur" de texture sont données en valeurs RVB doublées de 0 à 1 espace. Les
valeurs répertoriées cidessous sont celles utilisées avec chaque "commutateur de texture" dans le jeu original,
mais vous pouvez utiliser n'importe quelle valeur ici pour d'autres variations de couleur.
Camouflages
Camouflage ACU standard
Le paramètre du fichier d' éléments texture_switch :

data/textures/atlas_characters/mul_camo_xy/camo_02/camo_ACU_test_xy_df
Le paramètre de valeur des éléments color_switch :

0,54 0,50 0,47
Camouflage ACU marron

Données/textures/atlas_characters/mul_camo_xy/camo_05/camo_brown_xy_df

0,49 0,48 0,41
Camouflage ACU vert

data/textures/atlas_characters/mul_camo_xy/camo_06/camo_green_xy_df

0,57 0,63 0,54
33
Camouflage ACU gris

data/textures/atlas_characters/mul_camo_xy/camo_07/camo_grey_xy_df

0,50 0,60 0,60
Camouflage ACU Coyote

Données/textures/atlas_characters/mul_camo_xy/camo_08/camo_coyote_xy_df

0,82 0,78 0,63
Camouflage multicam

Données/textures/atlas_characters/mul_camo_xy/camo_03/camo_multicam_xy_df

0,82 0,78 0,63
Camouflage des bois

Données/textures/atlas_characters/mul_camo_xy/camo_04/camo_woodland_camo_xy_df

0,48 0,50 0,44
Camouflage SF Mex

Données/textures/atlas_characters/mul_camo_xy/camo_01/mex_sf_camo_xy_df

0,70 0,65 0,57
34
Camouflage à rayures tigrées

Données/textures/atlas_characters/mul_camo_xy/camo_10/camo_tigerstripe_xy_df

0,48 0,50 0,44
Camouflage de bloc urbain

Données/textures/atlas_characters/mul_camo_xy/camo_09/camo_cityblock_yx_df

0,59 0,55 0,59
Camouflage Flecktarn

Données/textures/atlas_characters/mul_camo_xy/camo_11/camo_flecktarn_xy_df

0,49 0,52 0,46
Camouflage Tropentarn

data/textures/atlas_characters/mul_camo_xy/camo_12/camo_tropentarn_xy_df

0,58 0,55 0,49
Camouflage du désert DPM

data/textures/atlas_characters/mul_camo_xy/camo_13/camo_dpm_desert_xy_df

0,56 0,52 0,47
35
Camouflage M90

data/textures/atlas_characters/mul_camo_xy/camo_14/camo_m90_xy_df

0,40 0,46 0,40
36
Annexe 2 : Liste des armes
Ce chapitre contient une liste de toutes les armes et de leurs extensions incluses dans le jeu
original, ainsi que les valeurs utilisées lors de la création de modèles de soldat.
Les armes sont répertoriées avec de vrais noms et si elles diffèrent des noms du jeu (ce qui est
généralement dû à des raisons de licence), le nom du jeu est indiqué entre parenthèses.
Remarque : toutes les armes, à l'exception des fusils de sniper Barrett M99 et HK MSG90, ont des viseurs en fer par défaut.
Avertissements Aucune arme ne peut utiliser à la fois le lancegrenades et la poignée avant comme
accessoires, car ils sont attachés à l'arme au même endroit. Cela plantera le jeu.
Assurezvous de ne pas attribuer plus d'une arme au même emplacement d'arme, sinon vous ferez
planter le jeu. Les emplacements disponibles sont principaux (utilisés par les fusils d'assaut, les
mitrailleuses et les fusils de sniper), secondaires (utilisés par les mitraillettes et les fusils compacts) et il
existe des emplacements spéciaux pour les armes de poing, les lancegrenades, les grenades explosives,
les grenades fumigènes et le prédateur. Vous ne pouvez donc pas avoir un fusil de sniper et un fusil
d'assaut dans le même kit par exemple.
Fusils d'assaut
Tempête Beretta Rx4
<weapon_unit name="rx4" clips="5" gui_slot="1"/>
<weapon_unit name=”rx4” clips=”5” gui_slot=”1”> <mod

name=”rx4_combat_sight”/> <mod name=”xl7” clips=”1”/>
</weapon_unit>
Arme principale :
Nom "rx4"
clips Nombre de clips pour arme dans le kit.
gui_slot Numéro de commande de l'arme dans le kit.
Modules complémentaires facultatifs de

nom de mod : rx4_combat_sight Viseur optique qui remplace le viseur en fer par défaut.
xl7
Lancegrenades (nécessite la variable "clips" ).
qd_suppresseur Suppresseur pour rendre l'arme silencieuse.
rx4_frontgrip Poignée avant pour rendre l'arme plus stable.
37
Crye Associates MRC
<weapon_unit name="crye" clips="5" gui_slot="1"/>
<weapon_unit name=”crye” clips=”5” gui_slot=”1”> <mod

name=”crye_combatsight”/> <mod name=”crye_grenade_launcher”
clips=”1”/> </weapon_unit>
Arme principale :
Nom
"pleurer"
Modules complémentaires facultatifs pour le

nom du mod : crye_combatsight Viseur optique qui remplace le viseur en fer par défaut.
crie_grenade_launcher Lancegrenades (nécessite la variable "clips" ).
silencieux_primaire Suppresseur pour rendre l'arme silencieuse.
FN SCARH / Mk.17
<weapon_unit name= »scar_heavy » clips= »6 » gui_slot= »1 »/>
<weapon_unit name=”scar_heavy” clips=”6” gui_slot=”1”> <mod name=”aimpoint”/

> <mod name=”scarh_grenade_launcher” clips=”1”/> </weapon_unit>
Arme principale :
Nom
« lourd_cicatrice »
Modules complémentaires facultatifs de nom

de mod : aimpoint Viseur optique qui remplace le viseur en fer par défaut.
scarh_grenade_launcher Lancegrenades (nécessite la variable « clips » ). silencieux_primaire
Suppresseur pour rendre l'arme silencieuse.
scarh_tactical_grip Poignée avant pour rendre l'arme plus stable.
38
FN SCARL / Mk.16
<weapon_unit name= »scar_light » clips= »5 » gui_slot= »1 »/>
<weapon_unit name=”scar_light” clips=”5” gui_slot=”1”> <mod name=”aimpoint”/>

<mod name=”silencer_primary”/> <mod name=”scar_grenade_launcher”
clips=”1”/> </weapon_unit>
Arme principale :
Nom
"lumière_cicatrice"

scar_grenade_launcher Lancegrenades (nécessite la variable "clips" ).
scar_tactical_grip Poignée avant pour rendre l'arme plus stable.
HK 416 (M416)
<weapon_unit name= »m416 » clips= »5 » gui_slot= »1 »/>
<weapon_unit name=”m416” clips=”5” gui_slot=”1”> <mod name=”aimpoint”/

> <mod name=”qd_suppressor”/> <mod name=”eglm” clips=”1”/>
</weapon_unit>
Arme principale :
Nom "m416"

gm Lancegrenades (nécessite la variable "clips" ).
m416_frontgrip Poignée avant pour rendre l'arme plus stable.
39
Hong Kong G36
<weapon_unit name= »g36 » clips= »5 » gui_slot= »1 »/>
<weapon_unit name=”g36” clips=”5” gui_slot=”1”> <mod name=”aimpoint”/

> <mod name=”silencer_primary”/> </weapon_unit>
Arme principale :
Nom
"g36"
Addons de nom de mod facultatifs :

viseur optique aimpoint qui remplace leviseur de fer par défaut.
m96_lampe de poche Lampe de poche montée sous le canon.
HK XM8 (M8)
<weapon_unit name=”m8” clips=”5” gui_slot=”1”> <mod

name=”m8_combatsight”/> <mod name=”silencer_primary”/> <mod
name=”eglm” clips=”1”/>
</weapon_unit>
Arme principale :
Nom "m8"
Ajouts facultatifs de nom de mod :

m8_combatsight Viseur optique qui remplace le viseur de fer par défaut.
gm Lancegrenades (nécessite la variable "clips" ).
40
Mitrailleuses et fusils compacts

HK G36C
<weapon_unit name= »g36_compact » clips= »4 » gui_slot= »2 »/>
<weapon_unit name=”g36_compact” clips=”4” gui_slot=”2”> <mod name=”aimpoint”/

> <mod name=”silencer_primary”/> </weapon_unit>
Arme principale :
Nom
"g36_compact"
Addons de nom de mod

facultatifs : viseur optique aimpoint
qui remplace le viseur de fer par défaut.
HK MP5A4
<weapon_unit name= »mp5a4 » clips= »4 » gui_slot= »2 »/>
<weapon_unit name=”mp5a4” clips=”4” gui_slot=”2”> <mod name=”aimpoint”/

> </weapon_unit>
Arme principale :
Nom
"mp5a4"
Addon de nom de mod facultatif :

aimpoint Viseur optique qui remplace le viseur de fer par défaut.
41
HK MP5SD3
<weapon_unit name= »mp5sd » clips= »4 » gui_slot= »2 »/>
<weapon_unit name=”mp5sd” clips=”4” gui_slot=”2”> <mod name=”aimpoint”/

> </weapon_unit>
Arme principale :
Nom
"mp5sd"

aimpoint Viseur optique qui remplace le viseur de fer par défaut.
HK XM8 Compact (M8 Compact)
<weapon_unit name= »m8_compact » clips= »4 » gui_slot= »2 »/>
<weapon_unit name= »m8_compact » clips= »4 » gui_slot= »2 »>

<mod name=”m8_combatsight”/> <mod
name=”silencer_secondaire”/> </weapon_unit>
Arme principale :
Nom
"m8_compact"
Addons de nom de mod

facultatifs : viseur optique aimpoint
silencieux_secondaire Suppresseur pour rendre l'arme silencieuse.
Mitrailleuses
FN Minimi SPW / Mk.46 LMG (SAW)
<weapon_unit name= »saw » clips= »3 » gui_slot= »1 »/>
Arme principale :
Nom "scie"
42
HK 21e (Mg21e)
<weapon_unit name= »hk21e » clips= »3 » gui_slot= »1 »/>
Arme principale :
Nom "hk21e"
Fusils de sniper
Barrette M99
<weapon_unit name= »barrett » clips= »20 » gui_slot= »1 »/>
Arme principale :
Nom "barrette"
clips Nombre de cartouches pour l'arme dans le kit.
Remarque : Le Barrett M99 est le seul fusil qui n'a qu'une cartouche par chargeur.
HK MSG90
<weapon_unit name= »msg90 » clips= »4 » gui_slot= »1 »/>
<weapon_unit name=”msg90” clips=”4” gui_slot=”1”> <mod

name=”silencer_primary”/> </weapon_unit>
Arme principale :
Nom
"msg90"

silencer_primary Suppresseur pour rendre l'arme silencieuse.
43
M14
<weapon_unit name= »m14 » clips= »4 » gui_slot= »1 »>

<mod name=”m14_scope”/> <mod
name=”qd_suppressor”/>
</weapon_unit>
Arme principale :
Nom "m14"
Modules complémentaires facultatifs pour

le nom du mod : m14_scope Sniper scope
Remarque : le M14 est le seul fusil de sniper qui n'a pas de lunette par défaut.
Bras latéraux
Beretta 92FS / M9
<weapon_unit name=”beretta” clips=”3” gui_slot=”2”/>
<weapon_unit name=”beretta” clips=”3” gui_slot=”2”> <mod

name=”silencer_secondaire”/> </weapon_unit>
Arme principale :
Nom "Berette"

44
HK45 tactique (Mk45)
<weapon_unit name=”mk45” clips=”5” gui_slot=”2”/>
<weapon_unit name= »mk45 » clips= »5 » gui_slot= »2 »>

<mod name="silencer_secondaire"/> </
weapon_unit>
Arme principale :
Nom "mk45"

Glock 18C
<weapon_unit name= »glock » clips= »4 » gui_slot= »2 »/>
<weapon_unit name= »glock » clips= »4 » gui_slot= »2 »>

<mod name="silencer_secondaire"/> </
weapon_unit>
Arme principale :
Nom
« glock »

grenades
Grenade fumigène AN/M8
<weapon_unit name= »anm8_thrower » clips= »1 » gui_slot= »4 »/>
Arme principale :
Nom
"anm8_thrower"
clips Nombre de grenades dans le kit.
Remarque : L'AN/M8 a son propre emplacement désigné et ne peut pas entrer en collision avec une autre arme assignée.
45
Grenade M61
<weapon_unit name= »m61_thrower » clips= »1 » gui_slot= »3 »/>
Arme principale :
Nom
"m61_thrower"
clips Nombre de grenades dans le kit.
Remarque : le M61 a son propre emplacement désigné et ne peut pas entrer en collision avec une autre arme assignée.
Armes spéciales
Lockheed Martin Predator SRAW / FGM172B SRAW (ZEUSMPAR)
<weapon_unit name=”prédateur” gui_slot=”4”/>
Arme principale :
Nom
"prédateur"
Remarque : le Predator a son propre emplacement désigné et ne peut pas entrer en collision avec une autre arme assignée.
Remarque : Le Predator n'est pas rechargeable, il n'a donc pas la variable "clips" .
Milkor MGL140 / M32 MGL
Arme principale :
Nom "m32"
clips Nombre de grenades supplémentaires dans le kit.
Remarque : le M32 utilise l'emplacement d'arme principal et lorsqu'il est dans un kit qui empêche le joueur
d'avoir un fusil d'assaut, un fusil de sniper ou une mitrailleuse.
46
RPG7
<weapon_unit name= »rpg7 » clips= »2 » gui_slot= »1 »/>
Arme principale :
Nom
"rpg7"
clips Nombre de fusées supplémentaires dans le kit.
Remarque : le RPG7 utilise l'emplacement d'arme principal et lorsqu'il est dans un kit qui empêche le joueur
d'avoir un fusil d'assaut, un fusil de sniper ou une mitrailleuse.
47

GRAW2 GameModes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

GRAW2 GameModes

Transféré par

Droits d'auteur :

Formats disponibles

Machine Translated by Google

GHOST RECON : WARFIGHTER AVANCÉ 2

Contenu des documents

Chapitre 1 : Fichiers XML.............................................. .................................................. .3

Chapitre 1 : Fichiers XML

Mappez les fichiers spécifiques

Fichiers spécifiques au mode de jeu à

Partie TDM de world_info.xml pour "Timber" :

Partie TDM de mission.xml pour "Timber" :

Chapitre 2 : Modes de jeu originaux

Team Deathmatch "TDM" est un

tdm_spawn_a Lieu de spawn pour l'équipe américaine.

tdm_spawn_b Emplacement de spawn pour l'équipe Mex.

s_spawn_a Lieu de spawn pour l'équipe américaine.

s_spawn_b Emplacement de spawn pour l'équipe Mex.

s_capture Emplacement pour Mex à défendre et US à capturer.

Hamburger Hill "HH"

hh_spawn_a Lieu de spawn pour l'équipe américaine.

hh_spawn_b Emplacement de spawn pour l'équipe Mex.

hh_capture Emplacement pour Mex à défendre et US à capturer.

Recon vs Assault "RvsA"

nécessite le plus de travail d'éditeur de carte.

recon_spawn Lieu d'apparition initial pour l'équipe américaine.

adat_spawn_a Lieu de réapparition de l'équipe américaine lorsque l'ADAT A est détruit.

adat_spawn_b Lieu de réapparition de l'équipe américaine lorsque l'ADAT B est détruit.

adat_spawn_c Lieu de réapparition de l'équipe américaine lorsque l'ADAT C a été détruit.

obj_a_assist Lieu de récompense combiné entourant ADAT A.

obj_b_assist Lieu de récompense combiné entourant ADAT B.

obj_c_assist Lieu de récompense combiné entourant ADAT C.

<event name=”start_round” type=”once”> <element

Exemple de sortie de mission.xml appartenant à la carte "Coop Quarry" : <mission_script

<event name=”start_game”> <element

Objets requis "COOP" n'a

coop_spawn Lieu d'apparition de l'équipe de joueurs.

Comme il n'y a pas grand­

Exemple de mission.xml si "Coop Quarry" n'a pas utilisé coop_rules.xml : <mission_script

<event name=”start_game”> <element

Chapitre 4 : Coopération de campagne

Exemple de sortie de world_info.xml appartenant à "mission01": <campaign

Chapitre 5 : Modes de jeu personnalisés

Variable Description par défaut

awa_distance 15000 Définissez la distance à laquelle l'indicateur d'incendie capte

vrai Définir si le match doit consister en un nombre pair de tours.

mode de jeu MPCoop Réglé sur "Personnalisé", ancienne variable GRAW1.

hud_abc_objective false Définir si l'interface graphique de l'objectif ABC est

la mini­carte. minimap_friendly_markers true Définir si les membres de l'équipe s'affichent sur la

score_listing_type 0 Définir si le gagnant est le joueur avec le moins de décès si le

spawn_on_side_switch vrai Définir si le spawn est autorisé après le changement

Définissez la façon dont l'échange de rondes se produit. "côté"

Remarque : "has_status_screen", "has_tacmap" et "show_teammates" sont également définis dans les

Exemple de code avec le nom utilisé à l'intérieur de cette balise dans

Chapitre 6 : Restrictions relatives aux kits personnalisés

Extrait de mp_ranks.xml <default_ranks>

<nom du modèle = "mp_mex_gunman_1">

Chapitre 7 : Classes et kits personnalisés

Exemple de soldat de mp_template réécrit sans utiliser xdefine : <soldier

<nom du soldat = "mp_us_rifleman_1">

Contenu de l'élément Soldat

Types d' unités Ghost disponibles :

Types d' unités fantômes

Élément de l'unité principale

L' élément "head_unit" reçoit le "nom" de la tête à utiliser.

Types d' unités de tête Ghost disponibles :

Comme il n'y a pas grand

la minicarte. minimap_friendly_markers true Définir si les membres de l'équipe s'affichent sur la