Mouchi

Moddeur Strategium
  • Compteur de contenus

    796
  • Inscription

  • Dernière visite

  • Jours gagnés

    13

Mouchi a gagné pour la dernière fois le 20 novembre 2016

Mouchi a eu le contenu le plus aimé !

1 abonné

À propos de Mouchi

  • Rang
    Membre actif

Information de Profil

  • Centres d'intérêts
    Jeux vidéos, Histoire, informatique, maths

Visiteurs récents du profil

3 132 visualisations du profil
  1. Je pense qu'il est bien suivi vu la fréquence des patchs (quasi quotidienne !). Avec les retours des joueurs, ils remplissent un post sur Steam où ils mettent tout ce qu'il manque au jeu. Les développeurs ont de quoi s'occuper .
  2. SimAiport est un jeu de gestion qui vous propose de concevoir, construire et gérer votre propre aéroport. Le site du jeu vend les fonctionnalités suivantes Des possibilités illimitées : Vous avez un contrôle à 100% et complet Simulation en profondeur : Tout est simulé individuellement, du check-in au départ Plaisir réaliste : Aussi réaliste que possible - mais en plus addictif et fun Du Terminal au Tarmac : vous êtes le BOSS Il détaille davantage en précisant Gameplay basé sur les systèmes : Tout a une intention dans SimAirport, rien n'est purement esthétique. Augmenter le bonheur des passagers, ajouter des files d'attentes pour accélérer la sécurité, et assigner de nouvelles réceptions pour l'embarquement des gros avions ! Tout ce que vous faites compte dans le gameplay challengeant de SimAirport Simulation haut de gamme : Notre équipe est sortie des sentiers battus. Tout est détaillé. des désirs individuels de passagers, des systèmes de bagages souterrains, des plannings personnalisables, et même le contenu des bennes à ordures ! Rien n'a été négligé Magnifiques graphiques - par Alice Bessoni : Une perspective 2D en top-down, vous être capable d'apprécier tous les petits détails - que vous jouiez d'une vue d'oiseau ou alors avec un zoom maximal. Steam Early Access - vous pouvez jouer aujourd'hui ! Vous pouvez prendre SimAirport et commencer à construire votre aéroport dès maintenant ! En nous rejoignant maintenant, vous serez capable d’interagir directement avec les développeurs qui participent activement, quotidiennement, aux discussions et qui écoutent et prennent en compte vos retours? Rendez-vous sur Steam. Le jeu n'est disponible qu'en anglais. Je ne sais pas s'il sera traduit. Cependant, le nombre de textes est relativement faible et les images aident à la compréhension si jamais on a des difficultés. Pour le rythme des mises à jour, j'ai l'impression qu'il est quasi quotidien au moment où j'écris. Je vous laisse voir cela sur le twitter du jeu. Pour terminer, voici le Let's Play (français) de Jay's Gaming qui m'a fait découvrir le jeu :
  3. En fait la boucle se cache dans les on_actions, c'est pour cela que je t'ai demandé quel était l'état de ton fichier. Mais bon revenons au début pour mieux répondre à ta question. Tu m'as dit que tu voulais que si ton personnage meurt alors l'ensemble de ces modifiers soient reportés à son héritier. Traduit de manière logique cela donnait : Tant que mon personnage a un modifier { - Je lui enlève un modifier - J'ajoute un modifier à son héritier } D'où la boucle et donc sa traduction informatique en while. Il fallait donc insérer ce code au meilleur endroit. C'est là que tu as les on_actions qui permettent de gérer les successions (donc la mort mais aussi le don, la conquête et l'usurpation). Ce que m'offre ces on_actions c'est le scope de l'ancien seigneur, le nouveau et le titre. Le on_actions arrive pour chacun des titres, il n'y a donc plus besoin de faire de boucle elle est déjà faite. L'algorithme se résume alors à Si le titre donnait le modifier { - J'enlève une quantité de 1 de modifier à l'ancien seigneur - J'ajoute cette quantité au nouveau }
  4. Voilà une proposition pour les events (le on_action reste inchangé) namespace = DMZ # Give the Demesnes1 modifier 1 year after starting the building # ROOT = Builder, FROM = The Holding Title character_event = { id = DMZ.201 hide_window = yes is_triggered_only = yes trigger = { FROM = { tier = baron holding_type = castle has_building = ca_great_hall_1 NOT = { has_title_flag = demesne1 } } } immediate = { FROM = { holder_scope = { add_character_modifier = { name = Demesnes1 duration = -1 stacking = yes } } set_title_flag = demesne1 } } } # Give the Demesnes1 modifier to the new holder and remove it to the old # ROOT is the character, FROM is the title, FROMFROM is the old holder character_event = { id = DMZ.202 is_triggered_only = yes trigger = { FROM = { is_feudal = yes has_building = ca_great_hall_1 } } immediate = { if = { limit = { FROMFROM = { has_character_modifier = Demesnes1 } } FROMFROM = { remove_character_modifiers = { modifier = Demesnes1 amount = 1 } } add_character_modifier = { name = Demesnes1 duration = -1 stacking = yes } } } }
  5. Sur le wiki tu as une liste plus complète des commandes pouvant être exécutées à la console. Comme l'opinion est souvent liée aux traits, tu peux soit retirer les mauvais, soit mettre des bons. Tu as la liste des traits sur cette page du wiki. Comme tu te mets les traits sur toi même, tu ne devrais pas avoir à préciser ton ID. Ainsi tu dois pouvoir faire. add_trait augustus Comme les traits ont d'autres effets que l'opinion et si tu ne veux pas trop déséquilibrer ta partie, en effet une disparition soudaine de ton personnage peut être la solution
  6. En fait tu peux tout simplement mettre un (title) flag pour empêcher de relancer l'event. Le flag a l'avantage d'être invisible pour le joueur. Sinon je pense que j'ai tout ce qu'il faut pour réfléchir à ta problématique de succession de l'effet.
  7. Les régions sont définies dans le fichier map/geographical_region.txt Ainsi un NOT = { region = world_europe } est une piste comme condition dans tes bâtiments. Pour le retrait de modifier, j'aurai besoin d'avoir la vue d'ensemble, notamment de voir ce que tu as comme on_actions.
  8. Holding_event n'existe pas, les types disponibles sont renseignés dans le wiki.
  9. D'après le wiki, tu peux enlever une certaine quantité d'un modifier. Tu peux faire une boucle while, qui consiste à "tant que le personnage a un modifier, je lui en enlève un pour le donner à son successeur". Il faut que tu arrives à insérer cela dans les events créés quitte à revoir leurs appels entre eux.
  10. On peut faire un mix de 1) et de 2) qui est que les domaines hors Europe n'aient un impact neutre sur la limite de domaine. Pour cela on peut faire en sorte que chaque domaine hors Europe augmente de 1 la limite de domaine (via un bâtiment ou pas). Pour la condition géographique, tu as trigger region. Comme les modificateurs identiques ne s'empilent, il faut coder un mécanisme d'évolution de ton modificateur. (En gros coder un assez grand nombre modificateurs pour chaque valeur totale de demesne_size à ajouter, et se débrouiller pour donner le bon).
  11. L'infini n'est malheureusement pas codable, tu pourras au mieux coder qu'un grand nombre de niveaux. Pour essayer de faire la meilleure réponse possible, il faut que je comprenne ton besoin. L'objectif est bien que les domaines hors Europe aient un impact nul sur la limite de taille? Je pensais que tu étais parti sur l'idée de faire un bâtiment pour ajouter +1 à la limite de domaine qui soit constructible partout hors Europe. J'ai du mal à suivre ce que tu veux faire. D'un côté tu veux mettre le bâtiments dans plusieurs comtés (sans restriction géographique) et additionner les effets, d'un autre côté construire plusieurs niveaux dans la capitale. Est-ce 2 pistes envisagées pour arriver à l'objectif initial? Est-ce un autre objectif?
  12. Pour la 1ère question, je n'ai pas encore de solutions satisfaisantes. Je pensais mettre autant de modifier qu'il faut dans l'event 203 mais je pense qu'il y a mieux à faire. Pour empêcher la construction hors capitale il faut que tu mettes le code plutôt dans le bloc potential ou trigger. Cf le wiki.
  13. En effet les croix rouges indiquent des conditions non remplies. MAIS, ces conditions sont dans le bloc FROM. Ce bloc n'a un sens que quand l'event est appelé par le on_actions, pas par la console.
  14. Je vais paraphraser le wiki alors. ROOT est le scope originel [et bien d'autres choses dans d'autres contextes] FROM est le scope qui a envoyé l'event [et bien d'autres choses dans d'autres contextes] PREV est le scope précédent. PREVPREV est le scope précédant le scope précédent. On peut chainer les PREV jusqu'à 4 fois. THIS est le scope courant. Le wiki donne l'exemple suivant province_event = { ... trigger = { #1 owner = { #2 top_liege = { #3 culture = PREV } #4 NOT = { #5 culture = ROOT } } } ... } Quand on est au niveau du #1, THIS = ROOT = la province qui a reçue l'event, PREV n'a pas de sens. Au niveau du #2, THIS = owner (le propriétaire de la province), PREV = ROOT Au niveau du #3, THIS = top_liege (le suzerain le plus haut du propriétaire de la province), PREV = owner (on a même PREVPREV = ROOT) Au niveau du #4, THIS = owner, PREV = ROOT Au niveau du #5, THIS = owner, PREV = ROOT. NOT n'est pas un nouveau scope.
  15. Comme toujours je vais paraphraser le wiki qui donne la réponse. PREV est le scope précédent dans la chaîne des scopes. Le wiki te donne l'exemple pour mieux comprendre ce que c'est. Je ne sais pas comment déclencher correctement des guerres, j'ai essayé une fois sans succès. Par contre je me suis servi plein de fois de PREV dans d'autres contextes sans problème. Le plus dur c'est de comprendre le concept de chaîne de scopes qui est expliqué dans le wiki.