39 réponses à ce sujet

[Gérauld]

Concernant les services payant, tu peux déjà utiliser comme ressource mon mod "louer les services d'un forgeron". Cela t'évitera de refaire le travail.
En t'inspirant du mod, tu pourras sans doute l'appliquer à d'autres services.

Idée pour ton mod :

J'avais également commencé à plancher sur un système de prix variant en fonction de ce que le joueur possède, de ce qu'il achète ou vend en fonction de chaque châtellerie. Avec des modifications de manière dynamique de certaines listes de niveau in-game (pas à partir du CK pour éviter des soucis). Uniquement pour certains matériaux et objets dans un premier temps (avec mise en mémoire des valeurs (par variables globales) car les listes de niveau se réinitialisent à chaque chargement du jeu).
En gros, si tu te retrouves avec 15 peaux de bêtes car tu as tout chassé sur la châtellerie, il y en aura moins en vente par ailleurs mais le prix de vente sera plus grand dans la châtellerie concernée. Si le joueur change de châtellerie et veux vendre les peaux, elles auront un prix normal, le joueur n'ayant pas augmenté le taux de mortalité du gibier là-bas.
Le joueur vend ses 15 peaux, le prix de ces peaux diminue car il y en a beaucoup en vente dans cette châtellerie.

Imaginez maintenant la prise en compte du nombre de mines de chaque type dans chaque châtellerie pour l'élaboration du prix de base des minerais.
Faire du commerce pourrait devenir plus intéressant et dynamique... Cependant, le prix de vente des minerais directement à la mine est fixe car défini par une quête. Il faudra éventuellement l'ajuster.


Ce qui est par contre déjà fait ou en cours par ailleurs (pour t'éviter de te prendre la tête à refaire la même chose) :

Concernant le transport, pas de soucis, je m'en occupe déjà dans un autre mod. Idem pour le transport de l'or (bourses, sacs de toile ou coffre transportables (ce dernier peut être mis sur un cheval)) Donc la "mule" c'est déjà fait. La capacité de transport des compagnons sera limitée afin d'éviter les tentations.

Pour la partie bûcheronne, la première modif (déjà faite) a consisté à ajouter au perso l'animation quand il ramasse et porte du bois et surtout de le limiter à 6 bouts de bois dans son inventaire. Obligeant le joueur à des allers-retours ou à faire un tas de bois par terre en attendant de pouvoir le vendre.
Par la suite, il sera ajouté la possibilité de couper certains arbres dans la forêt. (Couper (et non récolter) avec un tronc et une souche visibles) et de faire transporter le tronc par un cheval jusqu'à la scierie (visible sur le cheval). Ce bois sera nécessaire pour pouvoir utiliser la superbe scie.

Modifié par Gérauld, 11 juillet 2012 - 10:23.

[drakan]

Que d'idée !! Je vous remerci de vos contributions

Maintenant, je pense que ca va aller pour les idées qui donnerai de la valeur à l'argent. Si je met en oeuvre ne serais qu'un quart de tout ce qu'on a dit, tout le monde chercherai a avoir plus d'argent.


Mais avant de mettre en oeuvre ces idées, je vais devoir faire le script de base de mon mod...
Je compte attribuer à chaque ville une variable "offre" et "demande". Chaque jour, ces deux variables changeront. Toute la production de la ville s'incrémentera à l'offre et toutes les consommations seront incrémenté de la "demande". Le prix des objets suivra le cours de l'offre et la demande.

L'offre et la demande s'équilibreront grâce aux caravanes marchandes. Elles achetent la production et vend les denrées désirées.
Mais maintenant, imaginons que des bandits interceptes systématiquement les carvanes marchandes, l'offre et la demande sera totalement déséquilibré. Le prix sera alors très élevé pour la vente et très faible pour l'achat ...
Des cas de figure qui change cette equilibre on peut en inventer des milles et des cents ( ouverture d'une nouvelle mine, d'une nvl entreprise, la guerre entre deux factions, monopole du commerce etc )

Mais je pense que pour l'instant, je vais apprendre à scripter puis je m'attaquerais à mon planning:
- créer le système d'offre et de demande pour 3 villes pour une seul ressource.
- Integration des marchands dans le script pour équilibrer l'offre et la demande
- modélisation des marchands en route avec leur caravane
- changer les prix des marchands en fonction de l'offre et de la demande

Ces premières étapes me permettront de savoir si la base de mon mod fonctionne. Une fois ce fonctionnement de base vérifié, je pourrais alors terminer la base de mon mod, interger tout ce que nous avons parlé plus haut pour donner de la valeur à l'argent. Peut être même je integrerais ce mod à "le roy c'est moi"

Que pensez vous de ce mod ? N'est il pas trop ambitieux ? Certain aspect vous semble impossible?

Je te remerci gérauld pour ton aide. J'irai voir ton mod une fois que j'aurai appris à me servir des scripts

Citation

. bon ... je suis volontaire pour tester tout ça ... existe-t-il des formalité pour être testeur ?

Si mon speech ne t'a pas refroid, je serais content d'avoir de l'aide pour tester. Pour l'instant, je vais surtout me concentrer sur l'apprentissage de "papyrus"

[Gérauld]

Si tu veux un conseil, ne fais pas un script mais plusieurs scripts. Quand un mod contient de nombreuses fonctionnalités, il ne faut pas hésiter à préparer le terrain pour un menu qui permettra de les choisir.
De plus, il faut essayer de passer par des quêtes et des referencealias pour attacher les scripts. Ceci évite pas mal de soucis de compatibilité.
Il faut faire attention à ne pas mélanger plusieurs fonctionnalités dans la même quête si on veut par la suite faire un menu in-game.
Ces quêtes seront invisibles pour le joueur, elles ne servent que de support au mod.

Attention pour les caravanes de marchands. Il vaut mieux éviter d'utiliser les charriots autre que les STATIC...sous peine de bugs assez imprévisibles.

Pour le script appelé tous les jours (pour rafraichir tes variables (qui seront des variables globales sans doute), il ne faut pas utiliser l'instruction registerforupdategametime(24) mais registerforSINGLEupdategametime(24).
A la fin du script appelé, tu relanceras un registerforSINGLEupdategametime(24) conditionné par une variable globale ajoutée par le mod. Cela évite de polluer les sauvegardes et permet une désinstallation propre du mod.

A ta place, je commencerai par une ressource répandue (le minerai de fer par exemple) en donnant une valeur pour chaque châtellerie en fonction des mines présentes. Le premier truc à voir, avant d'ajouter une gestion d'évènements extérieurs, serait de coder les réactions à ce que fait le joueur (plus il obtient de minerai venant de cette châtellerie plus la demande est forte mais s'il a acheté ce minerai à un marchand, c'est qu'il y avait suffisamment d'offre...
Il serait dommage d'acheter à bas prix et revendre tout de suite très cher car on en a acheté beaucoup...
Le plus logique serait donc de commencer par gérer les réactions du joueur en premier...
Ce ou ces script(s) serai(en)t normalement attaché(s) par une quête.

Il est possible de modifier les listes de niveau in-game (modifier ce que les vendeurs ont) mais les modifications ne sont pas sauvegardées. Il faut donc stocker les modifications sous forme de variables globales par exemple et les appliquer à chaque chargement de partie.
Une autre méthode, plus simple, consiste à compter régulièrement combien ils ont d'objets et d'en ajouter ou retirer suivant les valeurs d'offre et de demande...
Le moyen le plus simple de n'utiliser qu'une variable est de faire en fonction du prix, qui est d etoute façon l'image du ratio offre/demande.

En espérant ne pas t'avoir embrouillé. Bon courage.

Modifié par Gérauld, 11 juillet 2012 - 19:30.

[drakan]

Pour ce qui est des scripts, je maîtrise encore très mal et je n'ai encore jamais vu encore de script attaché à une quete. Pour te donné mon niveau, j'était un bon scripteur sur morrowind. Là, j'en suis à faire le tutoriel "hello world" ^^ J'essairais de manipuler des scripts attaché à des quêtes et des referencealias pour en comprendre leur utilité.

En ce qui concerne les chariots, je n'ai absolument aucune idée de comment procéder. Je sais qu'on pouvais bouger des statiques sur morro, mais apparement comme tu dis, c'est bugué. Il faudra trouver une autre solution.

registerforSINGLEupdategametime(24) ----> c'est du chinois pour moi. En faisant le tuto, ca devrai mieux passer.

Citation

Il serait dommage d'acheter à bas prix et revendre tout de suite très cher car on en a acheté beaucoup...

En effet, ton idée est pertinente, il va falloir que j'y reflechisse... On pourrait penser à echanger unité par unité. De cette manière, le prix changera pdt l'achat.

Citation

Une autre méthode, plus simple, consiste à compter régulièrement combien ils ont d'objets et d'en ajouter ou retirer suivant les valeurs d'offre et de demande...

Je ne comprends pas trop. Je pensais initialement stocker dans des variables globales les prix de base. Une fois que tu va voir un marchand son inventaire va être mise à jour suivant les cours du marché LOCALEMENT. Pour faire cela, je compte utiliser la fonction SetGoldValue = Prix de base*ratio offre/demande


Je te remercie pour ton aide. Je vais aller tutorialiser un peu ...

Modifié par drakan, 11 juillet 2012 - 20:37.

[Gérauld]

drakan, le 11 juillet 2012 - 20:31, dit :

Citation

Une autre méthode, plus simple, consiste à compter régulièrement combien ils ont d'objets et d'en ajouter ou retirer suivant les valeurs d'offre et de demande...

Je ne comprends pas trop. Je pensais initialement stocker dans des variables globales les prix de base. Une fois que tu va voir un marchand son inventaire va être mise à jour suivant les cours du marché LOCALEMENT. Pour faire cela, je compte utiliser la fonction SetGoldValue = Prix de base*ratio offre/demande

Avoue qu'il serait quand même dommage de faire varier le prix mais pas les quantités de ressources en vente... Il existe un nombre limité de coffres de marchands dans Bordeciel, ce qui est plutôt une bonne chose.
En faisant une formlist et un script mis sur quelques gentils referencealias mis à jour ... à chaque changement de cellule par exemple et tapant uniquement dans la belle formlist... le script arrive sur le coffre du ou des marchands de la cellule et il modifie les quantité en fonction du ratio offre/demande ou du prix de l'objet dans la châtellerie... Vu que le changement est fait juste après le chargement de la cellule, on s'affranchit du respawn des coffres.

Il faut bien décomposer chaque partie comme ci-dessus. Le mieux étant d'écrire ce que l'on veut faire. Le reste viendra tout seul (lentement au début puis de plus en plus rapidement).

Bons tutos.

Sinon, n'hésite pas à regarder les objets et scripts du jeu vanilla et à comparer avec des mods pour voir un peu comment cela est architecturé et surtout les différences entre le placement des scripts vanilla (souvent directement sur l'objet) et celui fait par les mods (via des referencealias).
Pour ma part, je laisse toujours (sauf oubli) les sources des scripts dans les archives des mods. C'est fait pour être regardé...

[drakan]

Citation

Avoue qu'il serait quand même dommage de faire varier le prix mais pas les quantités de ressources en vente

Je ne sais pas ce qu'est une formlist ni des referencealias mais ce que tu dit est que chaque marchand aurai un budget limité? Ca me plairait.
Les villes ne revendent que leur surplus de production et les marchands ne peuvent qu'achater ces surplus. Ainsi il n'y a pas de d'objet à l'infini.

On pourrait aussi faire de même pour l'or... Imaginons un monde parfait : une monde ou il n'y a pas création d'argent
La première idée serait de fixer un budjet à chaque ville. Une fois la réserve d'argent dépassé, impossible d'échanger plus.
La deuxième idée serait de changer la valeur des objets d'une ville à l'autre en fonction de leur richesse. Une ville riche pourra proposer plus pour acheter un bien qu'une ville pauvre. La ville pauvre n'achetera pas d'objet exotique afin de pouvoir acheter des produits de première nécessité.
Mais pour l'instant, je n'ai pas vraiment d'idée adéquate pour faire le coefficient qui modifira encore les valeurs des biens.
Après, je ne sais pas si ca ne va pas déjà un peu trop loin


Mais fixer ses scripts à des réferences a tant d'importance? pour quelle raison ?
Sur morro, on pouvait fixer un script sur un objet ou sur une personne. Le script se lancait quand tu arrivais dans la cellule du perso ou de l'objet. L'autre solution était de lancer un script liée à rien. Le script étant toujours actif jusqu'a ce qu'on l'arrete.
Y a t il d'autre raison?

[Gérauld]

C'est surtout lié à des soucis de compatibilité. Quand tu attaches un script à un objet, c'est l'objet entier avec toutes ses infos qui est enregistré. De même si tu modifie une leveled list. Donc si deux mods touchent au même objet, seul les modifs du dernier mod chargé sont prises en compte.
Quand on passe par des referencealias, il n'y a plus ce problème.
L'objet n'est pas sauvegardé dans l'esp. Il n'y a que la quête et le referencealias. Donc le script est attaché sur l'objet même si un autre mod modifie l'objet. Plus de soucis de compatibilité (sauf si les deux mods ont la même fonction).
Par exemple, tu peux avoir un mod qui modifie directement le poids de tous les objets et un ou plusieurs autre(s) qui place(nt) un script par referencealias sans soucis.

Un script doit être attaché pour exister dans l'esp. Dans le cas où on ne passe pas par un referencealias, on l'attache directement à une quête.

Dans ce genre de mods, pour éviter l'usine à gaz et améliorer la fluidité d'exécution, le mieux est de passer par plusieurs scripts de taille réduite plutôt que par un énorme script qui serait lancé trop souvent.

Cela ne touche pas au FPS mais seulement à la vitesse d'exécution des scripts car ils se partagent un temps défini alloué par le jeu. Les scripts sont donc plus lents si on n'optimise pas un minimum le mod. Il ne faut également pas perdre de vue que le mod devra cohabiter avec d'autres mods qui ajoutent des scripts.

Pour les scripts devant se lancer à échéance régulière, il faut également faire très attention à ce qu'il ne puisse plus avoir d'appel au script pas la save après désactivation du mod d'où l'explication sur les registerforsingleupdategametime() (valable pour les registerforsingleupdate() ) quelques posts plus haut.

[drakan]

Pour ce qui est de la comptabilité, j'ai pigé. Merci de me l'avoir dis avant que je commence à programmer. Je n'aurai jamais penser que mettre un script pouvait poser problème. Il est possible d'en ajouter sur un objet ajouté par le mod mais pas sur un objet existant déjà. Le mieux est donc d'attacher le script à une quête ou passer par des réferencesalias .... ou par un script global.
Ces histoires d'attachement m'embete un peu. Par exemple, ne peut on pas simplement lancer un script par l'intermédiaire d'un actionneur. Ce script n'a alors pas à être ataché à un objet, non?

Citation

Cela ne touche pas au FPS mais seulement à la vitesse d'exécution des scripts car ils se partagent un temps défini alloué par le jeu. Les scripts sont donc plus lents si on n'optimise pas un minimum le mod. Il ne faut également pas perdre de vue que le mod devra cohabiter avec d'autres mods qui ajoutent des scripts.

Ah? Pour moi, à chaque frame, le script est entierement effectuer, quitte à ramer. Le diviser n'améliore pas le problème. A la limite, répartir l'execution du programme sur plusieurs frame est une solution.
Dans skyrim c'est different? un temps de calcul est alloué à chaque script?

J'avais avant fait un script principale qui tournait tout le temps dans mon mod de morrowind. Je vais te le présenter. Pourra tu me dire si il était trop lourd?

script lambda

..... deux à trois ligne de script pour compte le temps qui passe.

If x!= 1 then

fin du script

endif

....
suite du gros script
...

Citation

Pour les scripts devant se lancer à échéance régulière, il faut également faire très attention à ce qu'il ne puisse plus avoir d'appel au script pas la save après désactivation du mod d'où l'explication sur les registerforsingleupdategametime() (valable pour les registerforsingleupdate() ) quelques posts plus haut.

Je comprend le début de la phrase, je comprend la fin mais impossible de faire le lien. N'aurais tu pas oublier un mot?

Modifié par drakan, 12 juillet 2012 - 17:59.

[Gérauld]

Il y a tous les mots mais il y a une faute de frappe. Il faut remplacer "pas" par "par".
En clair, tu lances un register pour appeler un script toutes les minutes dans un mod et tu sauvegardes.
Tu désactives le mod et tu recharges ta partie... Il y a de bonnes chances que ton script (toujours présent sur le disque dur) continue à être appelé toutes les minutes.
Tandis que si c'est un register unique qui n'est relancé que si le mod est activé (test d'une variable globale ajoutée par le mod), le script ne sera plus appelé et la trace du mod dans la save s'effacera après le register unique qui était sauvegardé.

Skyrim traite le scripting de manière différente que celle que tu me décris.

Le temps alloué à l'ensemble des scripts est fixe. Ils n'influent donc pas sur les FPS et le reste. Les scripts ne sont déclenchés qu'à l'occasion des évènements qu'ils traitent (events) et se partagent ce temps.
Plus il y a d'instances de scripts à tourner moins ils exécuteront d'instructions dans le temps imparti vu qu'il le partage. Le même script peut se dérouler plusieurs fois en même temps si le ou les évènements déclencheurs de certaines parties ont lieu plusieurs fois d'affilée. Pour éviter des déclenchements multiples, on peut utiliser les STATE dans lesquels on peut traiter d'autres évènements ou aucun si on considère qu'une seule instance du script doit être démarrée à la fois.
Si un script suit certaines actions avec des tempos (utility.wait(durée), un décalage peut-être observé si de nombreux scripts viennent à tourner en même temps. Il ne sont pas donc pas déroulés entièrement à chaque frame et attende le prochain laps de temps qui leur est réservé pour continuer leur exécution.

Les joies du multi-threading avec une fenêtre temps fixe.

Un actionneur (activateur) est un objet. Une formlist est un objet. Une variable globale aussi. En gros, tous ce qui a un ID doit être considéré comme un objet, même s'il a un type différent.
Modifier un objet vanilla expose le mod à des soucis de compatibilité avec les autres mods y touchant, quelque  soit le type de l'objet.
Les objets où les scripts sont les bienvenus sont principalement ceux ajoutés par le mod. Après, il n'y a aucun interdit.

Un dernier truc, si tu sais que ton mod modifie grandement le fonctionnement et les caractéristiques d'un objet vanilla, il ne sera peut-être pas nécessaire de "prendre des gants" et de passer par un reference alias... Pourquoi? Parce que de toute façon, il y aura de grandes chances qu'un mod touchant à l'objet soit incompatible car proposant un fonctionnement différent pour l'objet voir des changements de caractéristiques contraires à ce que ton mod apportait.

[drakan]

Citation

Je comprend le début de la phrase, je comprend la fin mais impossible de faire le lien. N'aurais tu pas oublier un mot?

Ce n'était pas pour pinailler sur un détail. En fait, comme tu peut l'imaginer je bataille dur pour comprendre donc le moindre petit détail peut me perturbé ^^
Je pense qu'avec ce que tu m'a dis je comprends mieux comme faire en sorte que mon mod soit compatible avec les autres.

Citation

Plus il y a d'instances de scripts à tourner moins ils exécuteront d'instructions dans le temps imparti vu qu'il le partage.

Cela signifie qu'un script ne peut plus faire bloquer le jeu. Par exemple, on pourrai avoir une boucle qui tournerai indéfiniment.

En fesant des tuto et en lisant tes messages, il est clair que j'avais de gros lacune déjà sur morrowind en ce qui concerne les appellations : type, objets, reference...  Là, je me noie completement. Il va fallloir que je comptinue a potasser ca.

Au passage peut tu me dire la différence entre ces deux lignes:

Citation

MQ01Script myQuest
myQuest = GetOwningQuest() as MQ01Script

je replace ces lignes dans son contexte:

Citation

;I have a quest script with this in it:
scriptName MQ01Script extends Quest
int property deadCount auto

;I have a result script (OWNED by MQ01) with this in it:
MQ01Script myQuest ;declares a variable "myQuest" which is a TYPE of MQ01Script
myQuest = GetOwningQuest() as MQ01Script  ;sets the myQuest variable to it's owning quest as the type MQ01Script
float myDeadCount ;declaring the variable "myDeadCount"
myDeadCount = myQuest.deadCount    ;setting local variable to be the quest's property value
;you can also set the quest property thusly:
myQuest.deadCount = 10

Modifié par drakan, 12 juillet 2012 - 22:02.

[Gérauld]

Dans la première ligne tu déclares une variable dont le type est rattaché à un script (qui doit sûrement avoir l'extension extends quest).
La deuxième ligne donne une valeur à cette variable. Cette valeur est la quête détenant le script avec come type celui défini la ligne au-dessus. (le "as" sert à donner le type de l'info et peut sauver pas mal de scripts quand il est bien placé (pour passer d'un type form à weapon ou autre...)).

Il ne faut pas faire de boucles, au contraire. Cela prendrait énormément de temps aux autres scripts. Ces derniers ne pourraient plus balancer autant d'instructions à chaque fois qu'ils ont la main.

Vu que tu as scripté sur Morro, je te conseillerai plutôt de commencer par cette page :

http://www.creationk...vious_Scripting

et ensuite :

http://www.creationk...us_Introduction

Modifié par Gérauld, 12 juillet 2012 - 22:16.

[drakan]

Le mod va à priori ne pas se faire. Ma dernière année d'école d'ingénieur va m'accaparer tout mon temps. Peut être que je recommencerai quand je serais dans 6 mois, quand je serais en stage.
Je tiens à remercier Gérauld de son aide pour me faire comprendre comment marche CK. Mine de rien, j'ai pas mal progresser ^^

Modifié par drakan, 07 septembre 2012 - 16:48.

[Gérauld]

Et m**de. Moi qui comptait sur toi (quitte à te filer un coup de main), histoire de voir un jour ce mod sortir.
L'IRL (et tes études) avant tout.
Et puis, 6 mois, ce n'est pas grand chose quand on voit qu'il y a encore des trucs qui sont sortis récemment pour Morrowind...

[drakan]

sujet principal remis à jour
http://forum.wiwilan...8-mod-marchand/

[drakan]

J'ai peut être parler trop vite. Je ne maîtrise encore pas assez les IA pour progresser. Ca risque de prendre plus de temps. Mon but est trouver s'il y a moyen de  controler le trajet d'un marchand par un script en ayant les ref du mapmarker destination et les references du marchand.

Quoi qu'il en soit, une IA de marchand sur deux est terminé et fonctionne bien.La production, consommation, stock de chaque ville scripté. Mon script de pathfinding pour les routes marchandes devrait fonctionner ( ca ne parait pas mais trouver le chemin le plus court en passant par des points (villes) prédéfinies est compliqué ! ). Il ne reste plus qu'a lui dire de prendre le chemin tracé et faire l'IA du marchand une fois arrivé en ville.

En réponse à toutes les propositions et conseils de gérauld, le spoiler plus bas détaille le fonctionnement actuelle du mod si jamais tu reviens sur le site :

Spoiler

actuellement, j'ai planifier de faire que 3 scripts : script d'initialisation de tous les autres scripts, script noyau contenant toutes la plupart des valeurs (dont les conso, production et stocks) et enfin un script qui gère les marchand en déplacement.
Comme dis dans mon poste principale, mes scripts sont structuré afin de pouvoir l'adapté assez facilement à n'importe quel mod.
Il est fait aussi concu pour apporter le maximum avec le moins de consommation de CPU. En revanche, je n'ai pas épargné la mémoire vive mais je n'ai aucune idée de l'impact de mes variables sur la mémoire.


le script d'initialisation contient le dimensionnement des tableaux (new int ... ) , assigne leur valeurs, créer les itiniéraires des routes marchandes ( un marchand veut aller de la ville 1 à la ville 3 en passant par la ville 2)


le script principale
Est updaté toutes les 24 heures (réalisé par singletimeupdate...). Il met à jour les stocks après conso et production ce qui fait fluctuer les prix (qui sont mis à jour quand il y a besoin). prix = base * ( conso  +1 / stock +1 ) * autre modificateur
Ce script gere aussi l'IA des marchand. Chaque marchand pourra avoir des IA differentes. Je compte en faire trois.
- Le marchand con. Il ne se pose pas de question et va de ville en ville aléatoirement. Je ne sais pas si je vais scripter cette IA...
- Le marchand qui va vers la ville la plus avantageuse en fonction de ce qu'il a en stock et de ce qu'il peut acheter sur place. A faire
- Le marchand habitant ou possédé par une ville (IA déjà scripté). Il a la particularité de revenir à chaque fois à la ville de départ. C'est un peu comme une liaison commercial. Le but est de faire du profit mais avant cela de faire prosperer la ville d'ou il vient. Il va donc vers la ville qui propose un aller retour le plus profitable et se lance. Si jamais les prix ont fluctué en revenant à la ville de départ, il vend comme mm, même s'il y perd. IA déjà scripté, elle marche vraiment bien, voir trop bien.


Le problème réside donc dans le fait que l'IA est cheaté! comment faire du profit face à des marchand qui sont omnicient et qui calcul à la piece d'or près leur bénéfice? Il y a des dovakins qui vont être dégouté du marchandage ^^ Donc j'ai crée un système pour palier au problème : Les marchand ne sont plus omniscient et calcul leur profit qu'en fonction des infos qu'ils ont à disposition. De plus, ces informations sont datées. Pour que ca soit plus concret, un exemple : le marchand1 connait les prix, les stock et conso qu'avait la ville2 il y a 1 jour. Il possède la même chose des villes 3 et 4 mais ces informations ont 4 jour. Toutes les autres informations qu'il possède ont plus de 5 jours, ce qui est trop vieux : Elles ne seront pas pris en compte. Chaque jour, tous les marchands recoivent des informations de manières semi aléatoires en suivant la logique que se sont les voyageurs qui coloporte leur connaissances. De ce fait, les marchands auront que des informations vieilles des villes éloignés, ce qui les refroidira pour aller à ces villes. Ils n'y iront que si les profits seront vraiment importants. En plus de limiter de manière controlé l'efficacité des marchands, le système améliore grandement la consommation du CPU. Les marchand ne testent que les villes dont il a des infos.
Le script principale gere donc le script de lancement des caravanes et de l'attributions des infos. Le point faible de ce script est qu'il nécessite des tableaux de deux dimensions alors que les arrays n'accepte que une seule. J'ai utilisé des fonctions pour rémédier au problème mais ca alourdi la structure.
Tu m'avais également dit qu'il fallait gérer la réaction joueur pour éviter qu'il exploite des bugs comme achter massivement à bas prix pour faire augementer les prix d'un coup puis tout revendre à prix élevé. Ce coté est simplement géré en vendant un caisse de marchandise par un caisse (et c'est d'ailleur ce que fait aussi l'IA )




le script de gestion des caravanes est updaté. Pas encore trop touché. Contient les variables liée au trajet, donne l'ordre de voyager sur la route marchande choisi (pas encore trouvé cmt faire) , receptionne les marchands quand il entre dans une ville de passage (achat et vente opportuniste), receptionne le marchand quand il arrive à la ville visé et modifie les valeurs des stocks dans script principale.

Modifié par drakan, 25 juin 2014 - 19:30.