PARTIE 1

Je suis en train de retravailler un peu la façon dont l'exploitation des mines fonctionne en introduisant une notion nouvelle : un stock de la ressource exploitée.

 

Globalement, cela veut dire que chaque mine aura une capacité limitée.

 

Cette capacité sera aléatoire et déterminée à l'activation de la ressource minérale. Je table sur un stock initial prévu pour durer 20-50ans.
Le stock précis ne sera pas révélé, car il n'est pas réaliste d'avoir cette information, et de plus le système de consommation, décrit ensuite, ne permet pas vraiment une estimation de la durée de vie de la mine.
Ce stock sera diminué au fil de temps par l'exploitation de la mine. Bien sûr, si le bâtiment d’exploitation est d'un niveau plus élevé, le stock diminuera plus vite.
De même, l’évènement actuel d'accident à la mine, qui réduit la production pendant un temps, ralentira temporairement cette consommation du stock.
Une nouvel évènement qui traduira une hausse temporaire de productivité aura lui l'effet inverse.
Vous aurez également la possibilité, de faire rechercher de nouveaux filons, via décision, moyennant finances, pour prolonger la vie de votre exploitation minière.
Vous serez informés lorsque le niveau de stock devient bas (probablement une alerte, puis une relance).

 

Que ce passe-t-il une fois le stock épuisé ?

 

La décision de recherche de filon sera toujours disponible à ce moment là, mais il est possible que ce intervienne trop tard ou que vous ne trouviez plus de filon assez conséquent pour vraiment relancer la machine.
Sinon effectivement la mine fermera pour de bon.

 

Rechercher un nouveau site à exploiter dans la province est une possibilité que l'on étudie. Cela impliquerait une décision, accompagnée d'un processus de prospection donc pourquoi pas une chaîne d'events. A voir pour la suite.

 

 

D'un point de vue plus technique : ce feature ne sera pas présent dans le premier update pour la version du 2.5, qui est imminente
Cela ne concerne que le fer, au moins dans un premier temps. La ressource "sel" sera séparée des minerais. Il est possible que le bâtiment "mine" s'échelonne en 5 niveaux au lieu de 3 actuellement.

Source : %5BL3T%5D DEVjournal n°04 : les mines

PARTIE 2

On a attaqué l'encodage du feature. J'en profite donc pour vous montrez l'avancement et les dessous du coding, entre blabla et tutoriel !

 

Une fois le design plus ou moins ficelé, j'ai pu vous présenter sous forme de carnet de développement les caractéristiques du feature. Il s'agissait de la partie théorique, qui parfois demande quelques tests préalables pour la faisabilité du projet. Ensuite il faut se mettre au boulot et coder ce qu'on a promis On peut aussi coder et seulement ensuite présenter le produit fini. A titre personnel, j'aime bien présenter avant, car coucher sur le "papier" le feature et son fonctionnement aide beaucoup à mettre les idées en place. "Savoir expliquer, c'est savoir coder", oserais-je dire.

 

Tout d'abord, question d'organisation, j'ai un fichier qui liste tous les events, leurs ID, et nomment les fichiers dans lesquels on les retrouvent. Ce fichier est présent dans la version distribuée du mod. Cela évite les doublons permet de trouver un ID libre, de ranger et retrouver ses petits, et aussi de centraliser quand on travaille à plusieurs. Recommandé même en solo cela dit.

 

Extrait de ce fichier

#id = ECO.00130 #activation pour commerce -pierre- #id = ECO.00131 #activation pour commerce -pierre taille- #id = ECO.132 #décompte minerai on_action#id = ECO.133 #décompte minerai alerte1#id = ECO.134 #décompte minerai alerte2#id = ECO.132 #décompte minerai de décision#id = ECO.139 #décompte minerai mouchard#id = ECO.00140 #activation pour commerce -minerai -minerai fer- #id = ECO.00141 #activation pour commerce -minerai -sel gemme- #id = ECO.00142 #activation pour commerce -minerai -or#id = ECO.00143 #activation pour commerce -minerai -cuivre#id = ECO.00144 #activation pour commerce -minerai -metal-#id = ECO.00145 #activation pour commerce -minerai -outils-#id = ECO.00146 #activation pour commerce -minerai -sel raffine-#id = ECO.00147 #activation pour commerce -minerai -salaison-#id = ECO.00148 #activation pour commerce -minerai -armes-

Dans le mod, chaque activation de ressource est un event avec le namespace ECO, suivi d'un nombre commençant par 100 pour les activations de ressources, le chiffre des dizaines regroupe les ressources ayant une même ressource-mère (ex. 140 = filière minerai), le dernier chiffre étant l'individualisation de chaque event. Un éventuel 4éme chiffre désignera un sous-event, pour les chaînes par exemple.
Tout ceci est bien sûr propre au mod.
Ici, j'ai décidé de "combler le trou" entre la filière pierre et la filière pour accoler mes nouveaux event à celle-ci. J'ai commencé à 132, ne sachant pas encore combien d'events il me faudra pour le feature.
Pour l'instant je pars sur un event que l'on va qualifier d'event de maintenance, qui fera le job de déduire annuellement les ressources du stock, deux events d'alerte, quand on approche de l'épuisement du stock, un event qui découlera d'une décision pour "renflouer" le stock (recherche d'un nouveau site, creuser plus profond etc. , avec pourquoi pas plusieurs branches et/ou divers events d'immersion (qui a parler de trouver un Balrog ?)
Et en petit dernier un event mouchard, dédié au testing ingame.

 

Bien entendu avec tout ça, les events ne vont pas se coder tout seul, donc au boulot !
Dans un souci de praticité, j'opte pour l'instant pour un fichier dédié.
Première étape, je sais que mon event de maintenance, pour revenir de manière cyclique a besoin d'être déclenché par le fichier on_action.txt. Je choisis la catégorie on_yearly_pulse, events.
J'indique donc simplement l'ID de l'event voulu dans le L3T_on_action du mod comme ceci :

#characteron_yearly_pulse = {	events = {		ECO.132	}

Il ne faut pas oublier d'impacter les éléments existant déjà, ici par exemple j'ai ajouté la définition de la variable "minerai_fer" et changé sa valeur pour donner un stock initial mors de l'activation de la ressources.
Ensuite on rentre dans le cœur du sujet. Je préviens, ça marche rarement du premier coup et en général on ne commence à côté qu'un boute de l'event pour voir s'il fonctionne. Ici il n'est pas complet, mais ce n'est pas la première mouture non plus, j'ai du jongler un peu avec les scopes, sous les bons conseil de Mouchi

# Consommation stock mines de fercharacter_event = {	id = ECO.132	hide_window = yes	ai = no	is_triggered_only = yes		trigger = {	#	}		immediate = {		any_title = {			limit = { 				tier = baron				holding_type = castle				location = { 					has_province_modifier = minerai2_fer					check_variable = { which = "stock_minerai" value =  100 } #seuil pour éviter d'arriver en stock négatif (=conso maxi * 2 ans + marge sécurité)					}				}							if = {				limit = {					has_building = CA_MINE_minerai_L1					NOT = {	has_building = CA_MINE_minerai_L2	}					NOT = {	has_building = CA_MINE_minerai_L3	}					}			owner = { character_event = { id = ECO.1391 days = 1 }}			location = { change_variable = { which = "stock_minerai" value =  -10 }}			}			if = {				limit = {								has_building = CA_MINE_minerai_L2					NOT = {	has_building = CA_MINE_minerai_L3	}					}			owner = { character_event = { id = ECO.1392 days = 1 }}			location = { change_variable = { which = "stock_minerai" value =  -20 }}			}			if = {				limit = {								has_building = CA_MINE_minerai_L3					}			owner = { character_event = { id = ECO.1393 days = 1 }}			location = { change_variable = { which = "stock_minerai" value =  -30 }}			}		}	}}

Je commence toujours par un commentaire pour nommer l'event ou dire ce qu'il fait.
Ensuite, son type, son ID.
hide_window = yes << l'event est masqué
ai = no << l'event n'est lancé qu'une seule fois par an, à un seul personnage, ais son effet couvre le monde entier
is_triggered_only = yes << déclenchement exclusif par le on_action

 

Je ne rentre pas dans tous les détails. Tous les effets sont dans le bloc immediate, l'event n'ayant pas d'option.
L'effet s'applique donc à tous les titres, de niveau baron, de type château, qui se trouvent dans une province ayant le modificateur "fer" actif et ayant un stock suffisant de minerai pour pouvoir en soustraire.
Le niveau de restriction suivant pour l'application, matérialisé par les les if = { limit = { }}, cible à quel niveau est le bâtiment d'exploitation minière (niveau 1, 2 ou 3), sachant que lorsque que le niveau 2 est construit, le niveau 1 existe encore, les bâtiments "se cumulant" lorsqu'ils prennent un niveau de développement supplémentaire. Chaque bloc if = { limit = { }} contient donc des conditions inter-exclusives, alors que le premier bloque limit est le socle commun.
Puis vient l'effet proprement dit, ici lancé un event mouchard et impacter le stock de minerai.

 

Le code très simple d'un des mouchards.

character_event = {	id = ECO.1391	desc = "DESCECO.1391"	picture = GFX_evt_castle_construction			ai = no	is_triggered_only = yes		option = {		name = "OK"	}}

Minimaliste, un type, un ID, un tag pour le texte, une illustration. Déclenché uniquement par l'event précédent, option unique et sans effet.
Une fois le code de localisation complété de la sorte (et toujours classé dans le bon fichier, en suivant les ID des events)

stock_minerai;;minerai de fer;;;;;;;;;;;;xDESCECO.1391;;Des nouvelles de nos mines de [From.Location.GetName]. \n La quantité de [From.Location.stock_minerai.GetName] encore disponible est évaluée à [From.Location.stock_minerai.GetValue] unités.  \nQuantité impactée de -10 unités.;;;;;;;;;;;;xDESCECO.1392;;Des nouvelles de nos mines de [From.Location.GetName]. \n La quantité de [From.Location.stock_minerai.GetName] encore disponible est évaluée à [From.Location.stock_minerai.GetValue] unités.  \nQuantité impactée de -20 unités.;;;;;;;;;;;;xDESCECO.1393;;Des nouvelles de nos mines de [From.Location.GetName]. \n La quantité de [From.Location.stock_minerai.GetName] encore disponible est évaluée à [From.Location.stock_minerai.GetValue] unités.  \nQuantité impactée de -30 unités.;;;;;;;;;;;;x

Le premier est le nom de la variable que j'utilise pour matérialiser le "stock" de minerai restant.
Tout le reste c'est du blabla, en fait seuls les champs dynamiques sont vraiment utiles.

 

Illustration en jeu :

 

Voilà j'ai fait le tour pour cette première phase, en espérant que vous avez trouvé cela intéressant dans le cadre du mod, par trop long à lire et que l'aspect pratique a levé un peu les mystérieuses limbes du modding des events

Source : %5BL3T%5D DEVjournal n°04 : les mines