J'ai la réponse d'un autre développeur qui a regardé le code.
La commande qui retire "200% de la modification journalière de ravitaillement" a en réalité l'effet suivant :
"taken supplies are percentage of the total supplies the country can produce if all of the IC is put on supplies"
Peu importe en fait l'heure à laquelle la décision de mobiliser est prise, ni le total de capacité industrielle alloué à la production de ravitaillement... Ce qui importe, c'est la valeur théorique du ravitaillement produit en une journée par un pays si l'ensemble de son industrie y est dédié. Donc pas de triche ou de contournement possible en principe.
Il m'a également confirmé qu'il trouvait ce système efficace et pertinent pour rendre compte des capacités réelles de mobilisation d'un pays, et donc des coûts afférents.
Supply et mobilisation
-
- Foudre de Guerre
- Messages : 1004
- Enregistré le : lun. janv. 15, 2007 11:50 am
- Contact :
- Lafrite
- Plombier CSS/PHP/SQL
- Messages : 13360
- Enregistré le : mar. août 17, 2004 8:04 pm
- Localisation : Baraque Friture
- Contact :
Re: Supply et mobilisation
Merci du retour
- aheuc
- Oil Tycoon
- Messages : 9519
- Enregistré le : dim. août 22, 2004 9:32 pm
- Meilleur jeu 2008 : Mount and Blades
- Meilleur jeu 2009 : Mod Europa Barbarorum
- Meilleur jeu 2010 : HOI2 Domesday/Armageddon
- Meilleur jeu 2011 : Minecraft
- Localisation : Y grenoblois
- Contact :
Re: Supply et mobilisation
+1. Merci de l'eclaircissment.
En F1, il y a deux positions importantes sur la grille de départ : La première, qui est la pole position; Et la dernière, qui est la Paul Belmondo.
Murray Walker (Apocryphe)
--
Murray Walker (Apocryphe)
--
-
- l'oeil de Stockholm
- Messages : 2329
- Enregistré le : jeu. sept. 02, 2004 12:41 pm
- Localisation : argh, je suis localisé!
- Contact :
Re: Supply et mobilisation
C'est bien, mais peu lisible. Idéalement, l'infobulle afficherait le total calculé, et non pas l'élément de calcul. Histoire de savoir que ça va me couter 1527 supplies, et de savoir ou je vais. Je crois vraiment que le problème est un problème de feed-back, pas de valeur en soi.
Et je me demande si le cout de la mobilisation générale ne pousse pas le cout au delà de la limite de stockage.
Et je me demande si le cout de la mobilisation générale ne pousse pas le cout au delà de la limite de stockage.
"il faut savoir demander beaucoup à son moteur, mais pas trop" Juan Manuel Fangio
-
- Foudre de Guerre
- Messages : 1004
- Enregistré le : lun. janv. 15, 2007 11:50 am
- Contact :
Re: Supply et mobilisation
Oui, je sais bien. Mais le dév l'a refusé car une telle info-bulle utiliserait trop de mémoire en calculant à chaque instant ladite valeur pour tous les pays...
-
- l'oeil de Stockholm
- Messages : 2329
- Enregistré le : jeu. sept. 02, 2004 12:41 pm
- Localisation : argh, je suis localisé!
- Contact :
Re: Supply et mobilisation
Je vois.
Et je suppose que trafiquer l'affichage de l'infobulle signifierait casser l'architecture du code, qui sans doute sépare strictement l'affichage du calcul. Ca, je le comprends parfaitement. Si on le fait, on est obligé d'avoir l'information en permanence pour tous les pays. C'est inévitable si on veut garder la maitrise du code. C'est normal.
Mais pour le coup, ça rend quand même l'action vachement moins lisible, et ça explique une bonne partie des réactions négatives : ça a bousillé 2-3 parties de Boudi et de quelques autres. Une à moi, aussi.
D'ailleurs, je vais faire un calcul. A vitesse max, on doit faire une trentaine d'heures par seconde(sans doute moins, mais admettons). On a dans les 100 pays. Chacun a une valeur de PP totaux calculée, et donc déjà disponible. Chacun a un multiplicateur de production de supplies, déjà disponible aussi(y'en a besoin pour décompter les supplies). Donc, ça fait dans les 3000 multiplications en virgule flottante par seconde. Chacune doit représenter 10 ou 20 cycles. On en est à, mettons, 50,000 cycles par seconde. 50 kHz. Même sur une vieille machine à 500 MHz, ça ne me parait pas énorme. Pas négligeable non plus, certes.
Pour ce qui est de la mémoire, euh, 1 chiffre en plus en virgule flottante par pays, ça fait 8 octets par pays. Pas convaincu par le cout en mémoire. Ou alors la structure du code est pourrie. Mais, logiquement, c'est juste une propriété à rajouter à la classe "pays"(quelle que soit son nom), et avec une seule consommation par instance(donc par pays). Si c'est horriblement couteux en mémoire à rajouter, ça fait vraiment, vraiment peur sur l'état du code.
Je ne parle pas d'un affichage de confort. Je parle d'une information vitale qui peut casser une partie de plusieurs heures si elle est mal comprise par le joueur. Je suis bien conscient que le cout n'est pas négligeable. Mais je pense que la frustration néée de son absence n'est pas un un caprice de wargamer gâté.
Et je suppose que trafiquer l'affichage de l'infobulle signifierait casser l'architecture du code, qui sans doute sépare strictement l'affichage du calcul. Ca, je le comprends parfaitement. Si on le fait, on est obligé d'avoir l'information en permanence pour tous les pays. C'est inévitable si on veut garder la maitrise du code. C'est normal.
Mais pour le coup, ça rend quand même l'action vachement moins lisible, et ça explique une bonne partie des réactions négatives : ça a bousillé 2-3 parties de Boudi et de quelques autres. Une à moi, aussi.
D'ailleurs, je vais faire un calcul. A vitesse max, on doit faire une trentaine d'heures par seconde(sans doute moins, mais admettons). On a dans les 100 pays. Chacun a une valeur de PP totaux calculée, et donc déjà disponible. Chacun a un multiplicateur de production de supplies, déjà disponible aussi(y'en a besoin pour décompter les supplies). Donc, ça fait dans les 3000 multiplications en virgule flottante par seconde. Chacune doit représenter 10 ou 20 cycles. On en est à, mettons, 50,000 cycles par seconde. 50 kHz. Même sur une vieille machine à 500 MHz, ça ne me parait pas énorme. Pas négligeable non plus, certes.
Pour ce qui est de la mémoire, euh, 1 chiffre en plus en virgule flottante par pays, ça fait 8 octets par pays. Pas convaincu par le cout en mémoire. Ou alors la structure du code est pourrie. Mais, logiquement, c'est juste une propriété à rajouter à la classe "pays"(quelle que soit son nom), et avec une seule consommation par instance(donc par pays). Si c'est horriblement couteux en mémoire à rajouter, ça fait vraiment, vraiment peur sur l'état du code.
Je ne parle pas d'un affichage de confort. Je parle d'une information vitale qui peut casser une partie de plusieurs heures si elle est mal comprise par le joueur. Je suis bien conscient que le cout n'est pas négligeable. Mais je pense que la frustration néée de son absence n'est pas un un caprice de wargamer gâté.
"il faut savoir demander beaucoup à son moteur, mais pas trop" Juan Manuel Fangio
-
- Foudre de Guerre
- Messages : 1004
- Enregistré le : lun. janv. 15, 2007 11:50 am
- Contact :
Re: Supply et mobilisation
Je sais bien et j'ai déjà exposé ces arguments. Le souci d'avoir un jeu qui tourne correctement l'emporte largement pour les autres développeurs.
Mais je vous attache en PJ un fichier modifié qui met en place une perte sèche de ravitaillement (compatible DH 1.02). De cette manière, vous avez l'info clairement affichée.
Mais je vous attache en PJ un fichier modifié qui met en place une perte sèche de ravitaillement (compatible DH 1.02). De cette manière, vous avez l'info clairement affichée.
- Fichiers joints
-
- Mobilization.rar
- (6.34 Kio) Téléchargé 132 fois
- Boudi
- Khan Océanique
- Messages : 31339
- Enregistré le : sam. août 28, 2004 12:47 pm
- Localisation : St-Etienne, FRANCE.
Re: Supply et mobilisation
Merci pour le retour. Avant de mobiliser il semble utile de pauser et de prendre sa Casio préférée.
« Et c’est parti ! (Поехали! [Poïekhali!]) »
https://fr.pobediteli.ru/
Un petit calcul, et on s’en va !
https://fr.pobediteli.ru/
Un petit calcul, et on s’en va !