Messages

MAJ des deux messages précédents pour refléter l'organisation des nouveaux serveurs de jeu.
Modifications :

• MAJ du script d'installation windows  [  lima.khanat.ninm.net  devient lirria.khaganat.net ]
• MAJ du script d'installation linux ( même chose que pour windows + modification du serveur de jeu panka : kh0.ninm.net devient panka.khaganat.net ]
• Correction de la version inline de script de synchronisation du premier message pour faire apparaître le nouveau nom de serveur.

Je voudrais juste revenir sur certaines des idées maîtresses  de cette proposition :

Ne pas instancier les appartements, mais au contraire répartir les maisons sur le territoire, des vrais maisons qui n'appartiennent qu'à une seule personne (ou entité selon le cas). C'est le cas dans d'autres jeux, et parfois on choisit une maison reculée, loin de la ville, nécessitant parfois de longues marches, mais unique par sa situation au bord de mer, ou sa décoration spécifique.

L'autre idée maîtresse il me semble est le concept de clef : plutôt qu'une interface IG de gestion de droits d''accès,
quoi de plus RP qu'une clef, qui peut être prêtée, échangée, volée, donnant accès à des lieux fermés normalement au publique. *Imagine le balayeur qui de par son métier à la clef de la chambre du khan et qui peut s'en vanter le soir au bar*. C'est une idée vraiment riche en potentialités.

Pour l'installation windows, j'ai créé un petit Zip qui se  trouve ici :

khanat-installer-windows.zip
Lorsque vous le dezzipez, il crée un dossier khanat contenant :

les executables rsync.exe,chmod.exe et 3 dll associées (cyggcc_s-1.dll, cygiconv-2.dll et cygwin1;dll)
un fichier client.cfg basique pour débuter
un fichier bat , "install_khanat.bat" qui est le script d'installation.


Il faut double cliquer sur le script "install_khanat.bat" pour lancer l'installation.
Cela ouvre un console 'DOS' dans laquelle rsync se lance et récupère un à un chaque fichier
de l''installation. Vous verrez des messages d'erreur à chaque ligne du genre "chmod n'arrive à pas a changer les droits", c'est normal, il ne peut appliquer les permissions linux sur un systèmes windows.
Compter une bonne heure pour l'installation car il doit télécharger 1,4Go de données.

Pour aller beaucoup plus vite, il suffit de copier le dossier 'data' de l'installation ryzom dans le sous-dossier 'data' de khanat. rsync.exe  ne rechargera que quelques fichiers qui ont changé, et cela permet une installation en moins de 5mn.

Bonjour
voici dans ce post un script d'installation du client et des datas du jeu pour le serveur khanat.
A la base ce script ne devrait contenir que 4 lignes que vous pouvez d'ailleurs saisir à la main
dans le dossier où vous voulez installer le jeu :

Code Sélectionner Étendre

# synchroniser le contenu du dossier 'data' avec celui du serveur ( 1,5Go, les mêmes fichier que ceux de ryzom )
rsync -avP lirria.khaganat.net::khanat-data/   ./data/
# synchroniser le contenu du dossier 'user' avec celui du serveur (les données spécifiques à khanat)
rsync -avP lirria.khaganat.net::khanat-user/   ./user/
# synchroniser le fichier "client_default.cfg" dans le dossier courant
rsync -avP lirria.khaganat.net::khanat-config/   ./
# synchroniser le binaire du  client (actuellement le binaire 32 bits officiel de ryzom)
rsync -avP lirria.khaganatnet::khanat-lin32bin/   ./
A cela il faut ajouter un fichier "client.cfg" qui devrait contenir au moins ces deux lignes :

Code Sélectionner Étendre

RootConfigFilename   = "client_default.cfg";
LanguageCode         = "fr";
Cependant le script d'installation est plus "friend", car il va essayer d'installer le jeu
intelligemment (notamment en réutilisant le dossier 'data' d'une installation ryzom ou
khanat  pour minimiser le recours au réseau) et puis tout cela avec une zoli interface
en mode texte.

Minuit, ce n'est sans doute pas l'heure idéale pour une 'release', j'ai du rater pas mal
des coquilles, mais n'hésitez pas à le tester et mettre vos commentaires ici.
J'essayerai demain d'ajouter des screens avec un petit tuto après une bonne nuit de sommeil.

https://dl.dropboxusercontent.com/u/208 ... install.sh

Note : l'option 3 "Private (VPS for DEV purpose)" n'est pas opérationnelle pour le moment.

Note : pour avoir toujours l'appartement "fyros" en fond quelque soit la race des vos personnage dans l'écran de sélection (pas celui de création) il faut également modifier le fichier "out_v2_select.xml", ligne 140 et suivantes  :

Code Sélectionner Étendre

<action handler="set" params="target_property=ui:outgame:charsel:slot@0:env:name |
value=switch(@UI:TEMP:CHARSLOT@0:PEOPLE, 'outgame_fyros.ig', 'outgame_fyros.ig', 'outgame_fyros.ig', 'outgame_fyros.ig')" />
voila donc la nouvelle version de ce fichier à ajouter à son dossier "user" :
out_v2_select.xml

Suite des expérimentations :

Yannk me l'avait fait remarquer de suite, mais j'avais fait semblant de considérer cela comme peccadille insignifiante. La réalité était toute autre, j'avais fouillé sans succès pour corriger ce problème : Dans l'écran de création du personnage, sur la case de sélection, les 4 races étaient toujours présentent.



J'avais décidé de reprendre tout à zéro. Je regarde le fichier « client_default.cfg » et note tous les fichiers servant à la gestion de l'écran de Création/Sélection du personnage :

Code Sélectionner Étendre

XMLOutGameInterfaceFiles = {
        "out_v2_config.xml",
        "out_v2_widgets.xml",
        "out_v2_connect.xml",
        "out_v2_intro.xml",
        "out_v2_select.xml",
        "out_v2_appear.xml",
        "out_v2_location.xml",
        "out_v2_crash.xml",
        "out_v2_hierarchy.xml",
        "out_v2_keys.xml",
};
Je récupère l'ensemble de ces fichiers à partir du dossier « code/ryzom/client/data/gamedev/interfaces_v3 » du code source de ryzomcore (on peut aussi décompresser le fichier gamedev.bnp, cela est équivalent ). et je commence à lire un par un chacun de ces fichiers afin de comprendre l'imbrication de l'ensemble des données.

Au passage je découvre des éléments surprenants. J'enfile mon casque de chantier, mes bottes, ma lampe frontale et je plonge sans un regard en arrière dans l'une de ces grottes. Explorer le code de ryzomcore, c'est comme se plonger dans l'étude des strates géologiques anciennes. Rien n'est jamais effacé. Le code, les données, s'empilent au dessus des précédentes, formant des filons qu'il faut suivre à la source avant de se rendre compte que nous arrivons dans un cul de sac. Cependant, cela demeure un travail fascinant, c'est ainsi qu'au détour d'un fichier je tombe sur celui-ci : « out_v2_location.xml ».

En regardant  le code XML, il parle du choix de localisation des avatar après création. Je n'ai pas souvenir d'un bouton localisation dans l'interface de création du personnage, alors je regarde plus attentivement le contenu de ce fichier, jusqu'à arriver ici :

Code Sélectionner Étendre

<proc id="init_menu_nbfyros">
<action handler="set" params="target_property=ui:outgame:location:loc3d:loc_fx:posx|value=-0.99"/>
<action handler="set" params="target_property=ui:outgame:location:loc3d:loc_fx:posy|value=0.45"/>
<action handler="set" params="target_property=ui:outgame:location:loc3d:loc_fx:posz|value=-0.06"/>

<action handler="set" params="target_property=ui:outgame:location:3d_menu_1:land:posz|value=0.0"/>
<action handler="set" params="target_property=ui:outgame:location:3d_menu_1:clouds:posz|value=0.0"/>

<!-- Villages Names -->
<action handler="set" params="target_property=ui:outgame:location:leftbuts:but0:hardtext|value='uiLocDest1Fyros'"/>
<action handler="set" params="target_property=ui:outgame:location:leftbuts:but1:hardtext|value='uiLocDest2Fyros'"/>
<action handler="set" params="target_property=ui:outgame:location:leftbuts:but2:hardtext|value='uiLocDest3Fyros'"/>
<action handler="set" params="target_property=ui:outgame:location:leftbuts:but3:hardtext|value='uiLocDest4Fyros'"/>
<action handler="set" params="target_property=ui:outgame:location:leftbuts:but4:hardtext|value='uiLocDest5Fyros'"/>

<!-- Aegus -->
[ .... supprimé pour faciliter la lecture .... ]

<!-- Kaemon -->
[ .... supprimé pour faciliter la lecture .... ]

<!-- Sekovix -->
[ .... supprimé pour faciliter la lecture .... ]

<!-- Phyxon -->
[ .... supprimé pour faciliter la lecture .... ]

<!-- Galemus -->
[ .... supprimé pour faciliter la lecture .... ]
</proc>
En regardant la définition des constantes «  uiLocDest1FyrosX » dans le fichier « fr.uxt » on retrouve le noms des villages fyros. Il s'agit des noms des villages des anciennes îles de départ, ici ceux de l'île fyros. Du coup il semble que le joueur pouvait sélectionner la ville de départ de son personnage à la création. Nous ne sommes pas limité à un « pop » dans un lieu unique comme sur silan !

Retour sur le fameux écran de choix des races. J'ai finalement trouvé la solution. Il s'agit  de la procédure « CP_init_Menus_3D_scene » (CP_ pour CreationPersonnage?) qui va initialiser le contenu des 5 fenêtres à gauche de l'écran. Au passage le corrige le fond 3D de chacune de ces fenêtres pour ne garder que l'appartement fyros, puis je retire l'insertion du personnage « tryker » dans la première fenêtre :

Code Sélectionner Étendre

<!-- Init Menu 3D Scene -->
<proc id="CP_init_Menus_3D_scene">
<action handler="set" params="target_property=ui:outgame:appear:3d_select:select_fx:started|value=1" />
<action handler="anim_start" params="anim=anim_app_select_fx" />

<action handler="set" params="target_property=ui:outgame:appear:3d_menu_1:env:name|value='outgame_fyros.ig'" />
<action handler="set" params="target_property=ui:outgame:appear:3d_menu_2:env:name|value='outgame_fyros.ig'" />
<action handler="set" params="target_property=ui:outgame:appear:3d_menu_3:env:name|value='outgame_fyros.ig'" />
<action handler="set" params="target_property=ui:outgame:appear:3d_menu_4:env:name|value='outgame_fyros.ig'" />
<action handler="set" params="target_property=ui:outgame:appear:3d_menu_5:env:name|value='outgame_fyros.ig'" />

<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,0)" params="dbdst=UI:TEMP:M1_1|dbsrc=UI:TEMP:FY_MALE" />
<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,0)" params="dbdst=UI:TEMP:M1_2|dbsrc=UI:TEMP:MA_MALE" />
<!-- <action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,0)" params="dbdst=UI:TEMP:M1_3|dbsrc=UI:TEMP:TR_MALE" /> -->
<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,0)" params="dbdst=UI:TEMP:M1_4|dbsrc=UI:TEMP:ZO_MALE" />

<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,1)" params="dbdst=UI:TEMP:M1_1|dbsrc=UI:TEMP:FY_FEMALE" />
<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,1)" params="dbdst=UI:TEMP:M1_2|dbsrc=UI:TEMP:MA_FEMALE" />
<!-- <action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,1)" params="dbdst=UI:TEMP:M1_3|dbsrc=UI:TEMP:TR_FEMALE" /> -->
<action handler="copy" cond="eq(@UI:TEMP:CHAR3D:VPA:SEX,1)" params="dbdst=UI:TEMP:M1_4|dbsrc=UI:TEMP:ZO_FEMALE" />   
Plus loin dans le code, je réagence le placement du personnage matis pour qu'il apparaisse au milieu (M1_1, M1_2, M1_3, M_4 sont respectivement les personnages fryos, matis, tryker et zoraï du menu 1) :

Code Sélectionner Étendre

<!-- scene 3d Menu 1-->
<scene3d id="3d_menu_1" x="3" y="-3" w="200" h="150" posref="TL TL" curcam="cam" curcs="env" render_layer="-2" user_interaction="false"
ambient="128 96 64" sun_ambient="0 0 0" sun_diffuse="255 255 196" sun_specular="0 0 0" sun_direction="-1.0 1.0 -1.0" >

<character3d id="char1" dblink="UI:TEMP:M1_1" pos="-1.0 25.8 1.0" rot="0.0 0.0 45.0" />
<character3d id="char2" dblink="UI:TEMP:M1_2" pos="0.0 26.2 1.0" rot="0.0 0.0 15.0" />
<!-- <character3d id="char2" dblink="UI:TEMP:M1_2" pos="-0.4 26.2 1.0" rot="0.0 0.0 15.0" /> -->
<!-- <character3d id="char3" dblink="UI:TEMP:M1_3" pos="0.4 25.8 1.0" rot="0.0 0.0 -15.0" /> -->
<character3d id="char4" dblink="UI:TEMP:M1_4" pos="1.2 26.4 1.0" rot="0.0 0.0 -45.0" />

<camera id="cam" fov="80" pos="0.0 24.0 2.3" target="0.0 26.5 2.1" roll="0" />

<light id="back" pos="0.0 28.2 1.6" color="96 64 32" near="2.5" far="4.0" />
<light id="lgt" pos="0.0 25.3 2.48" color="255 255 255" near="3.0" far="4.0" />
<ig id="env" name="outgame_fyros.ig" pos="0 0 0.15" />

<shape id="shadow1" name="shadow.shape" pos="-1.0 25.8 1.0" rot="0.0 0.0 0.0" />
<shape id="shadow2" name="shadow.shape" pos="0.0 26.2 1.0" rot="0.0 0.0 0.0" />
<!-- <shape id="shadow2" name="shadow.shape" pos="-0.4 26.2 1.0" rot="0.0 0.0 0.0" /> -->
<!-- <shape id="shadow3" name="shadow.shape" pos="0.4 25.8 1.0" rot="0.0 0.0 0.0" /> -->
<shape id="shadow4" name="shadow.shape" pos="1.2 26.4 1.0" rot="0.0 0.0 0.0" />      

Puis je regarde le contenu du fichier « fr.uxt » ( les textes associés aux éléments d'interface ) et je corrige les noms des races (lignes 19753 et suivantes ) :

Code Sélectionner Étendre

// HASH_VALUE 911214414E53083A
// INDEX 4767
uiCP_Specie_Fyros [UCIKARA]

// HASH_VALUE 8BC1D82A0A62AC3D
// INDEX 4768
uiCP_Specie_Matis [TCARA]

// HASH_VALUE CCC308468E730837
// INDEX 4769
uiCP_Specie_Tryker [TRYKER]

// HASH_VALUE 09D214334D52D036
// INDEX 4770
uiCP_Specie_Zorai [RUNZATRA]
Du coup, on obtient en résutat :




Pour finir il y a eux quelques autres modifications ailleurs, du coup voici le fichier "ou_v2_appear.xml" complet
out_v2_appear.xml
important : il faudrait aussi modifier le fichier fr.uxt et en.uxt  pour avoir les corrections sur les noms des races

Journal d'expérimentation

Aujourd'hui je voulais savoir comment réduire drastiquement la taille occupée par le dossier data de ryzom. L'idée est de se créer sa propre installation de khanat, sans les 1,5 Go de données du client officiel en fichier  compresssé. Mon regard se tourne en premier vers le client ryzom core

http://sourceforge.net/projects/ryzom/files/ :

Code Sélectionner Étendre

ryzom_setup_644.exe    1.5 GB
ryzom_client_open.7z    652.6 MB
Plus que 600 Mo, je le récupère et l'installe sur mon poste puis compare  avec le dossier data du ryzom officiel.

Les fichiers packed_sheets (les data sheets) sont tous de tailles différentes, normal c'est ce qui devrait changer.
Les bnp (fichiers compressés contenant les modèles 3d et textures) sont tous les même (à une exception prêt).
Dans la version ryzom core, il manque les fichiers bnp des continent à savoir :

Code Sélectionner Étendre

terre_*.bnp
zorai_*.bnp
tryker_*.bnp
sources_*.bnp
route_gouffre_*.bnp
primes_racines_*.bnp
nexus_*.bnp
matis_*.bnp
fyros_*
bagne_*
il ne reste que comme continent
newbieland_*.bnp

les fichiers bnp en relation avec le ring  "r2_*.bnp" on également été supprimés :

Code Sélectionner Étendre

r2_buffer.dat       r2_forest_pz.bnp    r2_lakes_pz.bnp
r2_desert2.bnp      r2_jungle2.bnp      r2_misc.bnp
r2_desert.bnp       r2_jungle.bnp       r2_roots2.bnp
r2_desert_maps.bnp  r2_jungle_maps.bnp  r2_roots.bnp
r2_desert_pz.bnp    r2_jungle_pz.bnp    r2_roots_maps.bnp
r2_forest2.bnp      r2_lakes2.bnp       r2_roots_pz.bnp
r2_forest.bnp       r2_lakes.bnp        
r2_forest_maps.bnp  r2_lakes_maps.bnp  
J'ai quelques idées pour supprimer encore plus de données
par exemple le gros de l'espace disque est représenté par les tenues :

Code Sélectionner Étendre

54M characters_animations.bnp
77M characters_maps_fy_hof_armor00_hr.bnp
85M characters_maps_fy_hof_armor01_hr.bnp
6,7M characters_maps_fy_hof_caster01_hr.bnp
9,6M characters_maps_fy_hof_cheveux_hr.bnp
55M characters_maps_fy_hof_civil01_hr.bnp
17M characters_maps_fy_hof_underwear_hr.bnp
11M characters_maps_fy_hof_visage_hr.bnp
66M characters_maps_fy_hom_armor00_hr.bnp
67M characters_maps_fy_hom_armor01_hr.bnp
856K characters_maps_fy_hom_barman_hr.bnp
4,0K characters_maps_fy_hom_casque01_hr.bnp
8,1M characters_maps_fy_hom_caster01_hr.bnp
13M characters_maps_fy_hom_cheveux_hr.bnp
86M characters_maps_fy_hom_civil01_hr.bnp
2,1M characters_maps_fy_hom_ruflaket_hr.bnp
5,4M characters_maps_fy_hom_underwear_hr.bnp
11M characters_maps_fy_hom_visage_hr.bnp
135M characters_maps_hr.bnp
87M characters_maps_ma_hof_armor00_hr.bnp
32M characters_maps_ma_hof_armor01_hr.bnp
8,1M characters_maps_ma_hof_casque01_hr.bnp
8,1M characters_maps_ma_hof_caster01_hr.bnp
12M characters_maps_ma_hof_cheveux_hr.bnp
87M characters_maps_ma_hof_civil01_hr.bnp
17M characters_maps_ma_hof_underwear_hr.bnp
12M characters_maps_ma_hof_visage_hr.bnp
25M characters_maps_ma_hom_armor00_hr.bnp
33M characters_maps_ma_hom_armor01_hr.bnp
4,0K characters_maps_ma_hom_casque01_hr.bnp
8,1M characters_maps_ma_hom_caster01_hr.bnp
13M characters_maps_ma_hom_cheveux_hr.bnp
43M characters_maps_ma_hom_civil01_hr.bnp
11M characters_maps_ma_hom_underwear_hr.bnp
12M characters_maps_ma_hom_visage_hr.bnp
91M characters_maps_tr_hof_armor00_hr.bnp
39M characters_maps_tr_hof_armor01_hr.bnp
4,0K characters_maps_tr_hof_casque01_hr.bnp
6,7M characters_maps_tr_hof_caster01_hr.bnp
12M characters_maps_tr_hof_cheveux_hr.bnp
87M characters_maps_tr_hof_civil01_hr.bnp
11M characters_maps_tr_hof_refugee_hr.bnp
16M characters_maps_tr_hof_underwear_hr.bnp
11M characters_maps_tr_hof_visage_hr.bnp
64M characters_maps_tr_hom_armor00_hr.bnp
38M characters_maps_tr_hom_armor01_hr.bnp
4,0K characters_maps_tr_hom_casque01_hr.bnp
6,7M characters_maps_tr_hom_caster01_hr.bnp
13M characters_maps_tr_hom_cheveux_hr.bnp
96M characters_maps_tr_hom_civil01_hr.bnp
23M characters_maps_tr_hom_refugee_hr.bnp
8,6M characters_maps_tr_hom_underwear_hr.bnp
11M characters_maps_tr_hom_visage_hr.bnp
107M characters_maps_zo_hof_armor00_hr.bnp
122M characters_maps_zo_hof_armor01_hr.bnp
4,0K characters_maps_zo_hof_casque01_hr.bnp
6,7M characters_maps_zo_hof_caster01_hr.bnp
12M characters_maps_zo_hof_cheveux_hr.bnp
98M characters_maps_zo_hof_civil01_hr.bnp
22M characters_maps_zo_hof_underwear_hr.bnp
6,9M characters_maps_zo_hof_visage_hr.bnp
113M characters_maps_zo_hom_armor00_hr.bnp
104M characters_maps_zo_hom_armor01_hr.bnp
4,0K characters_maps_zo_hom_casque01_hr.bnp
7,1M characters_maps_zo_hom_caster01_hr.bnp
13M characters_maps_zo_hom_cheveux_hr.bnp
48M characters_maps_zo_hom_civil01_hr.bnp
11M characters_maps_zo_hom_underwear_hr.bnp
6,8M characters_maps_zo_hom_visage_hr.bnp
41M characters_shapes.bnp
1,2M characters_skeletons.bnp
8,0K characters_swt.bnp
« character_map_* » sont les textures des tenues. Il m'apparait que nous pouvons toutes les supprimer, ne gardant pour le moment que la tenue de refugié puis introduisant une à une nos tenues

Idem pour la faune

Code Sélectionner Étendre

29M fauna_animations.bnp
112M fauna_maps.bnp
43M fauna_shapes.bnp
1,2M fauna_skeletons.bnp
4,0K fauna_swt.bnp
Pour le moment nous n'utilisons que le yubo, pourquoi garder toutes ces données inutiles ?
D'ailleurs de toute façon nous voulons  revoir les principes de nommages des textures et shape et autres éléments. Il est donc préférable de tout réintroduire  élément par élément en fonction des besoins et avec notre organisation de « fichiers » et « noms ». Cela permettrait entre autres de supprimer les références aux « noms » ryzomiens qui restent à mon sens propriétés de jeu ryzom même si les assets sont libres.

Mais avant de m'attaquer à tout cela, je voulais aussi revoir l'écran de sélection des personnages.

J'avais trouvé dans le dossier
« code/ryzom/common/data_leveldesign/leveldesign/Game_elem/CreatePerso » les datasheet définissant les caractéristiques des races de l'écran de création

Code Sélectionner Étendre

$ ls
fyros_craftsman.starting_role  matis_craftsman.starting_role  _parent                         tryker.race_stats              zorai.race_stats
fyros_fighter.starting_role    matis_fighter.starting_role    tryker_craftsman.starting_role  zorai_craftsman.starting_role
fyros_harvester.starting_role  matis_harvester.starting_role  tryker_fighter.starting_role    zorai_fighter.starting_role
fyros_magician.starting_role   matis_magician.starting_role   tryker_harvester.starting_role  zorai_harvester.starting_role
fyros.race_stats               matis.race_stats               tryker_magician.starting_role   zorai_magician.starting_role
Ces datasheets référencent ceux du dossier
« code/ryzom/common/data_leveldesign/leveldesign/Game_elem/Creature/Npc/parent/_basics_3D »
pour les modèles 3D utilisés. Ce qui fait qu'il est facile de changer « l'apparence » de ces races en éditant ces fichiers :

Code Sélectionner Étendre

_basics_3D$ ls
_fyros_female.creature  _homin_attack.creature    _karavan_male.creature  _matis_male.creature     _tryker_male.creature   _zorai_male.creature
_fyros_male.creature    _karavan_female.creature  _matis_female.creature  _tryker_female.creature  _zorai_female.creature
Mais voilà, ces fichiers permettent de définir les races de l'écran de création, mais pas d'indiquer au client la liste des races à proposer lors de la création. Je regarde dans le dossier « code/ryzom/common/data_leveldesign/primitives » qui doit contenir  les définitions globales du jeu, mais je ne trouve aucune référence aux mots « fyros », « matis », etc... Alors je me rends du coté du canal #ryzom sur freenode et on m'oriente plutôt vers les fichiers xml de définition des écrans d''interface. C'est à dire dans :
« code/ryzom/client/data/gamedev/interfaces_v3 » qui correspond au contenu du fichier « gamedev.bnp » dans le dossier data du client

Mon but est simple, j'aimerai que nous repartions sur des races à nous. La première étape consiste à virer les races existantes et de n'en garder que 2 ( 2 pour gérer  tous les aspects sélections ) et de diminuer de moitié la taille occupée par les assets des ces classes donc. Après des recherches, des tests, des « segmentation fault » en éditant les fichiers j'ai enfin trouvé la solution. Le fichier concerné s'appelle : « out_v2_appear.xml » qui décrit l'interface de l'écran de création des personnages :

J'ai finalement trouvé ligne 1840 et suivantes les boutons de la race « matis » et « tryker » dans le menu de création. Races que j'ai supprimé (oui c'est arbitraires ces deux races, mais fallait garder les zoraï  pour les PNJ déjà présents, et j'ai un perso fyros sur mon serveur de test *tire la langue* ).

Code Sélectionner Étendre

<ctrl style="opt_button" id="fyros_but" posref="TL TL" x="60" y="-88" hardtext="uiCP_Specie_Fyros"
onover="play_sound" params_over="name=specie_but_over"
onclick_l="proc" params_l="proc_select_specie|0"/>

<!--  remove the matis and tryker choice for species
<ctrl style="opt_button" id="matis_but" posparent="fyros_but" posref="BL TL" hardtext="uiCP_Specie_Matis"
onover="play_sound" params_over="name=specie_but_over"
onclick_l="proc" params_l="proc_select_specie|1"/>

<ctrl style="opt_button" id="tryker_but" posparent="matis_but" posref="BL TL" hardtext="uiCP_Specie_Tryker"
onover="play_sound" params_over="name=specie_but_over"
onclick_l="proc" params_l="proc_select_specie|2"/>
-->

<ctrl style="opt_button" id="zorai_but" posparent="fyros_but" posref="BL TL" hardtext="uiCP_Specie_Zorai"
onover="play_sound" params_over="name=specie_but_over"
onclick_l="proc" params_l="proc_select_specie|3"/>


<group id="logos" posref="TL TL" x="28" y="-80" h="380" w="44" >
<view type="bitmap" id="fyros" posref="TL TL" texture="opt_on_fyros.tga" global_color="false" />
<!--
<view type="bitmap" id="matis" posparent="fyros" y="" posref="BL TL" texture="opt_on_matis.tga" global_color="false" />
<view type="bitmap" id="tryker" posparent="matis" y="" posref="BL TL" texture="opt_on_tryker.tga" global_color="false" />
-->
<view type="bitmap" id="zorai" posparent="fyros" y="" posref="BL TL" texture="opt_on_zorai.tga" global_color="false" />
</group>
Au passage je trouve aussi comment ne garder qu'un seul fond, en l'occurence l'appartement fyros pour tous les écrans :

lignes 940 et suivantes :

Code Sélectionner Étendre

<!-- Change Landscape -->
<action handler="set" cond="eq(@UI:TEMP:CHAR3D:PEOPLE,0)" params="target_property=ui:outgame:appear:char3d:env:name|value='outgame_fyros.ig'" />
<action handler="set" cond="eq(@UI:TEMP:CHAR3D:PEOPLE,1)" params="target_property=ui:outgame:appear:char3d:env:name|value='outgame_fyros.ig'" />
<action handler="set" cond="eq(@UI:TEMP:CHAR3D:PEOPLE,2)" params="target_property=ui:outgame:appear:char3d:env:name|value='outgame_fyros.ig'" />
<action handler="set" cond="eq(@UI:TEMP:CHAR3D:PEOPLE,3)" params="target_property=ui:outgame:appear:char3d:env:name|value='outgame_fyros.ig'" />
j'ai remplacé les « outgame_XXXX.ig » contenant les nom des fichiers 3D des apparts par ceux des fyros. Cela permettra d'avoir un client encore plus léger.

Résultat



Voila l'écran que l'appart est fyros malgré la création d'un personnage zoraï. De plus le menu de choix des races ne propose que « fyros » ou « zoraï ».

Cependant,  j'ai eu un problème après ces tests :

$ ./khanat_client-2013-12-17
HEY!
XML reading failed!
Interface XML reading failed!
Some XML files are corrupted and may have been removed.
Ryzom may need to be restarted to run properly.
Would you like to quit now?
(Y)es or (N)o ?N
Erreur de segmentation

Systématiquement, mon client plantait lors de la connexion après sélection du personnage. Comme j'avais édité par mal de fichiers lors de mes expériences, j'ai remis une installation de base avec le client open ryzom. Même résultat. Finalement je suis repassé sur l'installation officiel en appliquant ma modification et là plus de plantage.

A priori les datas du client_open_ryzom sont trop anciennes et ne fonctionnent pas avec notre serveur de test. Du coup j'ai  recopié le dossier data du ryzom officile et j'ai supprimé manuellement tous les BNP retirés dans le client open_ryzom Cette fois cela fonctionne. Prochaines étapes, continuer à nettoyer les BNP pour fournir à Za un client occupant un espace minimum pour ceux ayant une bande passante réduite.

Pour les curieux, voila le fichier modifié de l'interface à copier dans le dossier "user" pour obtenir ce résultat ;
out_v2_appear.xml

Note : je n'ai fait que retirer les entrées du menu "matis" et "tyrker", le client continue de charger les données sur ces races pour le moment.

J'aime bien l'idée du mode inversé : payer un projet à venir, cela me semble plus logique  et plus juste aussi, tout en pouvant attirer des participants talentueux.
L'idée d'une bourse à récompense  avec sondage me gêne. j'imagine assez facilement les frustrations de certains, les dents qui vont grincer, estimant que cette bourse devait revenir à untel ou untel.

A mon avis, la thésaurisation de l'argent traduit que le joueur trouve cela plus intéressant de garder son argent que de l'investir dans le jeu. C'est un gros problème, cela veut dire que le jeu en lui-même n'a plus rien à offrir d'intéressant en investissement qui peut supplanter ce désir d'avoir une jolie somme sur son compte.

Je pense qu'il ne faut pas s'arrêter à un cas particulier mais envisager la vie d'un serveur dans sa totalité. Il peut très bien y avoir des choses à faire intéressantes cependant si tu projettes le fonctionnement d'un serveur sur plusieurs années alors des situations de thésaurisation peuvent apparaître. Ce fut le cas avec ryzom avant le "merge", un serveur avec plus que quelques actifs et pourtant une masse de ressources  issues de la période ou les serveurs étaient bondés.

Ce qui est important à mon sens de noter, c'est qu'un serveur de jeu est un monde clos et de taille réduite. Il faut donc des mécanismes permettant d'éviter la création infini de ressources virtuelles (que cela soit la monnaie comme ce fut le cas sur ryry avant, ou tout autre élément). L'idée d'une dégradation lente des matières est un mécanisme en soit, qui comme tu le notes, ne doit pas cacher par ailleurs un manque de choses intéressantes à faire sur le serveur de jeu. J'aime bien le concept car il permet aussi de pousser les joueurs à mettre en vente les ressources, donc favoriser l'échange, et évite pour le même raisonnement le farming pure et simple de rois dans l'optique d'accumulation et sans intention réel de produire quelque chose qui servirait aux joueur. Bien entendu si ce mécanisme est mal équilibré, il peut tendre à devenir "injuste" et par exemple défavoriser le joueur causal, alors que bien pensée il les favorisera en leur permettant de chasser les rois qui ne seront plus "farmés" ou de trouver ce qu'il leur faut sur le marché matière.

Le problème de la licence est un casse tête juridique qui n'est pas si simple. Je voudrais partager avec vous ma réflexion de ces derniers jours. J'ai repris le jeu de carte pour en faire une version libre de droit. J'ai donc redessiné le cadre des cartes, et j'ai refait tous les petits icones y apparaissant en exploitant les ressources de « openclipart.org »

De ce coté, pas de souci : http://openclipart.org/share (enfin à priori), ces cliparts sont dans le domaine public.

Mais on en arrive à l'illustration. Prenant le cas de la carte runzatra. Le wip a été réalisé par Yannk qui l'attribue à la personne morale « khaganat ». Cependant, ce wip est basé sur le modèle 3D des assets ryzom qui est en licence  CC BY. Du coup la licence qui devrait apparaître sur la carte est « Illustration : licence CC BY ryzom,khaganat ». J'ai décidé de faire simple et mettre aussi le modèle de carte en CC-BY attribué à khanagat pour simplifier le tout.

Donc là on part du principe qu'on a pas utilisé des textures provenant d'une autre source avec un licence spécifique ou même un modèle 3D, parce que de toute façon la place sur la carte est limitée :p

A présent prenant le cas de la carte équipement « rouleau pâtissier ». Dans ce cas j'avais voulu utiliser une photo. D'abord trouver une photo libre de droit n'est pas évident. Pleins de moteurs proposent des bases d'images libres de droit, mais non gratuites ! Finalement j'ai trouvé une solution : utiliser la base des images flickr mais avec le moteur de recherche avancé en cochant l'option « photo en licence creative common »
http://www.flickr.com/search/advanced/

Du coup j'ai trouvé cette image « http://www.flickr.com/photos/snugglepup/3319250273/ » qui pourrait servir pour la carte « rouleau pâtissier ». D'ailleurs toute la série des 400 images mettant en scène le nounours pourrait être exploitée pour nos cartes stanzas mais là n'est pas la question. La licence de cette image est CC BY-NC et demande donc de créditer l'auteur.

La carte devrait être libellée ainsi : « Photo:licence CC BY-NC Snugg LePup (flickr) »
Au final c'est un vrai casse tête juridique, à moins de se simplifier la vie en ne prenant que des ressources du domaine publique ou CC-SA uniquement, il faut indiquer la source et créditer chaque carte. Le problème serait le même multiplié par un gros facteur pour les ressources IG.


(note: carte vite fait pour illustrer le problème, couleur et image à revoir)

Ne faudrait il pas imposer de suite une licence unique pour nos ressources et rejeter toute ressources non compatible ?

• CC Attributation => casse tête, il faudrait créditer chaque auteur.
• CC NC => pas de produit dérivé commercial, il faudrait donc aussi les identifier nominalement pour éviter dans un futur que la question ne se pose.

Le yubo a-t-il le dromadaire pour ancêtre ? C'est une question de fond d'autant qu'il a l'air de survivre dans des environnements aux ressources rares comme le désert. Mais alors où stocke-t-il ses réserves de nourritures et d'eau ? N'aurait-il pas une bosse caché ? Il me fallait une réponse à cette question primordial qui hante mes nuits.

Justement, cette nuit j'ai fait un rêve : les problèmes de formats des modèles 3D, la complexité des scripts de la pipeline de génération des data du jeu, tout cela m'avait fait oublier une vérité fondamentale : les scripts d'export des assets 3D lancent 3dsmax et utilisent une macro pour exporter des modèles 3d. Donc si je laisse de coté toute la partie collision, gestion des animations, lod, etc,  modifier un modèle 3D simple revient à l'éditer sous 3dsmax et cliquer sur le bouton "exporter au format « .shape »" de NEL (un mesh 3d) dans 3ds max.
Est-ce vraiment si simple ? Pouvais-je ainsi zapper toute la machine à gaz de la pipeline graphique pour modifier IG des objets simples ? Il me fallait en avoir le cœur net. Je repense alors à mon questionnement sur le yubo et je me dis que c'est l'occasion ou jamais de vérifier ma théorie sur son arbre d'évolution.

Dans la base des assets 3d libérés de ryzom je retrouve le fichier 3D du yubo :
W:databasestufftrykeragentsmonstersfamilierdagTR_MO_Dag.max
(note : TR => TRyker, MO => MOnster, Dag => nom du yubo dans les assets)
Il me faut vérifier que c'est bien ce fichier qui est utilisé IG sur silan. Je décompile les deux fichiers BNP du dossier data de ryzom «fauna_shape.bnp» et «fauna_skeletons.bnp» avec l'outil «bnp_make»  et effectivement dedans il y a dedans les deux fichiers : «TR_MO_Dag.shape» et «TR_MO_dag.skel».
A présent je passe sous 3DS Max, première étape il me faut trouver la fenêtre d'export du plugin NEL, après quelques tâtonnements je fini par y accéder :



Il me reste à éditer la bosse sur le dos du yubo puis exporter le modèle au format NEL «.shape» ( pour la mesh de l'objet) et au format «.skel» pour le squelette du yubo (il me semble qu'il faut aussi réexporter le squelette, car il doit indiquer les surfaces sur lesquels il agit, et celles-ci ont changé).



J'obtiens les deux fichiers « TR_MO_Dag.shape » et « TR_MO_dag.skel » (https://dl.dropboxusercontent.com/u/208 ... _Dag.shape et https://dl.dropboxusercontent.com/u/208 ... O_dag.skel) que j'ajoute dans le dossier « user » de ryzom. Il ne me reste plus qu'a croiser les doigts et espérer que j'ai eu raison. Je lance ryzom et me connecte à silan, dans la zone de chasse de yubos :



Eureka ! les yubos ont bien les dromadaires pour ancêtres !

[Spoiler]

Les caractéristiques du mobs et de son sort ont été déterminés lors du déroulement du combat :

Spoiler for Hiden:

Question bestiaire  :  savez-vous à quoi fait référence ces deux cartes ?

Tour de jeu 5:
phase (a) : Se déplacer + jouer une carte
Joueur runzatra : Fuit de Q.07 en N.06 (3PM).
Runzatra Joue la carte « équiper » et remplace la carte équipement « rouleau pâtissier » par la carte accélérateur magique « Orbe magique aux fruits de klums» et sa puissance en magie rouge. Au prochain tour il pourra profiter de toute la puissance de ses sorts de magie.



Casse-noisette se déplace de R.06 en O.06 (3PM) et revient au contact de runzatra.



Casse-noisette joue la carte sort de mêlée « Chtchelkountchik »

La vie de runzatra passe de 650 à 300. L'attaque a fait donc 350 DMG en mêlée.
Runzatra comprend que ce sort à un temps de relance de 2TR.

Runzatra abandonne la partie, dans 2 tours il sera mort. Le temps de relance d'accélération ne lui laisse aucune chance de fuir d'ici là. Conclusion il aurait dû attaquer le mobs à distance avec la magie rouge et éviter le contact de mêlée pour gagner

Tour de jeu 4:
phase (a) : Se déplacer + jouer une carte
Joueur runzatra : Ne se déplace pas, il est au contact
Joueur runzatra : joue sa carte sort mêlée « coup puissant », 80 DMG mêlée.


Les PV de casse-noisette passe de 390 à 350.  Runzatra en déduit une forte résistance naturelle
de casse-noisette aux attaques de mêlée ( 40 PR ).
Joueur casse-noisette : ne joue aucune carte et ne se déplace pas pour rester au contact.




phase (b) : se déplacer éventuellement s'il reste des PM non utilisés.
Runzatra fuit de T.06 en Q.07 (3PM)
Casse noisette le talonne en allant de U.08 à R.07 (3PM)

phase (c) : gérer les TR (temps de relance) et TE (temps d'effet)
Runzatra ramasse sa carte "coup puissant".
Runzatra décrémente de 1 le marqueur de temps de relance  de la carte retournée « accélération »
Que fait casse-noisette ? Brouillard de guerre :p

Observation : l'approche attaque de  mêlée est un échec, runzatra ne peut tabler que sur un temps de relance long du sort  « Chtchelkountchik » et sur la faiblesse constatée de casse-noisette à la magie rouge. Il doit se mordre les doigts d'avoir brûler sa carte accélération qui aurait été vitale pour lui permettre de s'éloigner du mobs et jouer les attaques à distance.

Tour de jeu 3:
phase (a) : Se déplacer + jouer une carte
Joueur runzatra : se déplace de Q.07 en T.06 (3PM). Il est encore éloigné du mobs et ne peut utiliser ses stanzas de mêlée.
Joueur runzatra : joue sa carte sort magie rouge de base (il n'a pas d'accélérateur magique équipé) pour tester les résistances du mobs. La vie de casse-noisette passe de 455à 390. Il en déduit une faiblesse de -20 PR en magie rouge


Joueur casse-noisette :  W.07 en U.07 (2PM). Le mobs est au conact du runzatra.
Joueur casse-noisette joue la carte sort de mêlée « Chtchelkountchik »

La vie de runzatra passe de 1000 à 650. L'attaque a fait donc 350 DMG en mêlée.
Runzatra comprend qu'il doit fuir le corps à corps ou tabler sur un temps de relance important du sort de case-noisette et peut être une faiblesse de ce mobs en mêlée.




phase (b) : se déplacer éventuellement s'il reste des PM non utilisés.
Néant, runzatra n'a plus de PM et casse-noisette préfère rester au contact

phase (c) : gérer les TR (temps de relance) et TE (temps d'effet)

Runzatra ramasse sa carte sort de magie rouge.
Runzatra décrémente de 1 le marqueur de temps de relance  de la carte retournée « accélération »
Que fait casse-noisette ? Brouillard de guerre :p