Discussion :

[leminorair]

Bonjour

J'espère poser ma question au bon endroit.

Pour le moment je n'ai pas encore de pb relatif au code mais je souhaiterai savoir si mes choix et ma réflexion sont les plus adaptés.

Le but de mon logiciel va être d'obtenir un objet en "fusionnant" plusieurs objets ( par exemple gilet + corset = cape, cape + corset =smoking)

Je prévois de fonctionner de la sorte :
-Via des combobox l'utilisateur renseigne les objets en sa possession dans une datagridview (DataGridPossédé)
-Il renseigne également dans une autre datagridview (DataGridCible) l'objet qu'il désire obtenir.
-une comparaison est effectué entre les 2 datagrid ( et logiquement elle échoue sinon cela veut dire que l'utilisateur possède déjà l'objet en question)
-si il y a échec une nouvelle datagrid est créé contenant les objets nécessaire à la création de l'objet cible (DataGridCible1)
-nvlle comparaison entre DataGridCible1 et DataGridPossédé.
- si comparaison positive on arrête la et il suffit de fusionner les 2 objets pour obtenir la cible désirée
-si comparaison négative on crée une DataGridCible2 à partir de la DataGridCible1
-et ainsi de suite (il faut supprimer les éléments de la DataGridPossédé une fois utilisé pour obtenir un élément des datagrid suivantes pour ne pas qu'il soient utilisé plusieurs fois)

Un "objet" que j'ai défini dans une bibliothèque de classe peut être de différentes catégories chacune ayant ses propres support suffixes préfixe.
Chaque support et affixe sont ordonnés suivant leurs valeurs
ex amulette faucon de la justesse, massue dentée du buveur de sang ( oui c'est poétique)
Les "recettes" sont stocké en dur dans des tableau.

Est ce que cette méthode est viable à terme cela ne risque t'il pas de créer des data grid view énorme?
Si jamais mon texte vous parait peu clair n'hésitez pas à me le dire je ferais des modifications en conséquence.
D'avance merci.

[Pol63]

moi j'ai pas compris le principe, mais surtout je n'ai pas compris la question

[casiii]

-Via des combobox l'utilisateur renseigne les objets en sa possession dans une datagridview (DataGridPossédé)

Dans tous les jeux et autres fantaisies qui permettent de fusionner, toi, tu décides de faire le chemin inverse ^^ (ce n'est pas un reproche hein !)

Pour toi, quel est le plus logique :
"Quel objet je peux faire avec x, y et z ? Si un objet est faisable, me manque-t-il des objets ?"
"Je veux l'objet x, quels objets il me faut ?"

Tu veux mettre en place la première phrase, alors qu'il est plus simple de mettre en place la 2ème :
- Liste des recettes (tu peux même filtrer en fonction des objets déjà possédés)
=> Différence entre recette et possessions
- Si pas de différences, création de l'objet
- Si différences, liste des objets manquants


Question : Tu ne prévois que la fusion de 2 objets et non n objets ?

[Pol63]

du coup je comprends mieux, enfin je pense ^^

je pense qu'il faudrait plutot un treeview
tu gardes dgvPossédé avec ce que tu as
sur un combobox tu dis ce que tu veux avoir

dans le treeview tu affiches tout ce qu'il faut pour l'avoir, en vert ce qui est dans possédé, en rouge ce qui ne l'est pas
si des éléménts sont aussi issus d'une fabrication, tu ajoutes un noeud sur l'élément (petit plus à gauche) et dessous tout ce qui entre dans la composition de celui ci, avec à nouveau vert si possédé et rouge si non
(peut etre gérer la quantité possédé s'il en faut plusieurs au final, genre orange si on en a mais pas assez pour tout)

éventuellement ouvrir par défauts les noeuds dont il manque quelque chose (contient du rouge ou orange), et laisser fermer ce qu'on peut faire
et tu peux aussi mettre un dgv qui récapitule tout ce qu'il manque en lisant tous les noeuds (tout ce qui est rouge, nombre nécessaire ; et tout ce qui est orange, nombre nécessaire - nombre possédé)

Dans tous les jeux et autres fantaisies qui permettent de fusionner, toi, tu décides de faire le chemin inverse ^^

je pense qu'il veut juste lister ce qui est nécessaire, chose qu'on retrouve dans beaucoup de jeux, comme LOL qui à partir d'un item t'affiche en dessous ce qu'il faut (et si tu l'as) et que si tu clic sur un des sous éléments tu peux à nouveau voir ce qu'il faut pour ce sous élément s'il est issu d'un craft aussi

[casiii]

je pense qu'il veut juste lister ce qui est nécessaire, chose qu'on retrouve dans beaucoup de jeux, comme LOL qui à partir d'un item t'affiche en dessous ce qu'il faut (et si tu l'as) et que si tu clic sur un des sous éléments tu peux à nouveau voir ce qu'il faut pour ce sous élément s'il est issu d'un craft aussi

J'avais pas vu ça comme ça en effet !
Après, ça dépend s'il a besoin de faire la recherche dans les deux sens ou non.

Le TreeView permet un meilleur "héritage" (et donc faire plus d'un niveau de "fusion", genre ce que tu à l'air de vouloir faire dans ton exemple).

[leminorair]

Je vous remercie pour vos réponses

Une petite capture d'écran pour vous montrez une liste de recette pour ceux que ça intéresse
http://hpics.li/50eb894

=> Différence entre recette et possessions
- Si pas de différences, création de l'objet
- Si différences, liste des objets manquants

J'ai vraiment du m'expliquer comme un manche car c'est précisément ce que je voulais faire ^^.

Question : Tu ne prévois que la fusion de 2 objets et non n objets ?

Non je prévois bien la fusion de n objets.
En gros si j'ai une liste avec 11 objets j'ai 11! possibilités de fusion (enfin plus car je suis pas obligé de fusionner l'intégralité des objets).
Donc calculer l'intégralité de ce que je peux obtenir me semble compliqué pour une grande liste.
Ca revient à tout tester et à ne sortir que le résultat qui convient c'est un peu bourrin non ?


Le treeview à en effet l'air d'une excellente idée qui à l'avantage en effet de proposer une visualisation qui correspond à la réalité du processus de fusion.
Par contre je ne me suis encore jamais servi de cette objet.Je vais allez potasser la documentation.

Merci pour vos éclairages encore une fois je pense que je n'aurai jamais eu l'idée d'utiliser un treeview qui semble pourtant la chose naturelle à utiliser.

[Pol63]

Ca revient à tout tester et à ne sortir que le résultat qui convient c'est un peu bourrin non ?

rien de grave là dedans, tu pourrais traiter des centaines de milliers de combinaisons en quelques dixièmes de secondes

[leminorair]

Je me suis peut être planté dans mes calculs mais je trouve 141 milliards d'opération pour une liste de 11 objets.

Petite question subsidiaire je viens de regarder rapidement mais il me semble qu'un nœud ne peut avoir qu'une seul racine

[Pol63]

j'avais mal lu et n'avais pas vu que le ! était un factoriel
n'empeche que 11 * 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 ca fait 39 916 800 chez moi (11² par contre ca commence à devenir gros ^^)
on arrondi à 40 Mega possibilités
si tu stockes des id (integer 4 octets) au lieu des noms, ca fait 160Mo de ram, ca reste utilisable (en ayant un dictionary par exemple pour faire le lien entre un id et un nom)

et si ca prend quelques secondes, tu fais 11 threads de recherche, ca divisera par 2 ou 4 (ou plus) ^^

après vu que les possibilités sont simples, tu n'es peut etre pas obligé de pré calculer toutes, mais seulement quand elles sont affichés
par contre l'image m'a encore plus embrouillé donc je ne comprends toujours pas ce que tu veux faire

[leminorair]

Ça n'est pas seulement un factoriel 11 car je ne suis pas obligé de fusionner l'intégralité de la liste. Pour avoir la liste exhaustive de ce que je peux obtenir à partir d'une liste je devrais aussi garder toutes les solutions issue de (11*10) +(11*10*9) etc.

C'est pour ça que la solution "bête" ou force brut de calculer tout et de sortir uniquement la bonne combinaison me semble peu efficace.
Je préfère donc rapprocher ça de la façon dont un humain le ferai. Ce qui permet en outre avec le treeview de mettre en évidence ce qu'il manque dans un chemin de fusion donnée.

Pour revenir sur l'image chaque "terme" est associé à un chiffre.
Short=1
Pantalon=2
jupe =3
kilt=4

Ensuite le tableau permet de savoir ce que l'on obtient en croisant 2 items.

X1234
11334
23243
33432
44324

donc short + kilt = kilt
short + jupe = jupe
short + pantalon = jupe

[casiii]

Ensuite le tableau permet de savoir ce que l'on obtient en croisant 2 items.

Donc c'est bien la fusion de 2 objets uniquement ?
Tu ne peux pas avoir 1 + 2 + 3 ? Ce qui reviendrait en fait à faire (1 + 2) + 3 selon ton tableau et donc, toujours une association de 2.

Par contre, tes tableaux n'ont aucune logique "mathématique" (est-ce normal ? ) : à des moments, n et n-1 ça donne n+1 et des fois ça donne n-1 ?
Erreur de calcul ou voulu ?
Sinon, ça te renvoie à tes cours sur les listes

[Pol63]

en fait la finalité c'est quoi ?
liste tout ce qui est possible ou donner les combinaisons possibles ?

si c'est pour lister comment c'est possible, il faut faire de la récursivité avec "détection de fin de cycle" qui permet de pas avoir tout à calculer, mais de savoir dans certains cas que là ca ne sert plus d'aller plus loin car on l'a déjà fait

[leminorair]

La finalité c'est de trouver le chemin de fusion le plus court ( tant qu'à faire) pour obtenir une cible à partir d'une liste prédéfinie.

@casiii oui c'est bien une fusion de 2 objets uniquement. Je me suis mépris sur ce que tu disais. On fusionne par paire mais on peut le faire plusieurs fois de suite.

n et n-1 ça donne n+1 et des fois ça donne n-1 ?

Les 3 derniers de chaque tableau bouclent entre eux autrement c'est linéaire.

[casiii]

Les 3 derniers de chaque tableau bouclent entre eux autrement c'est linéaire.

Bon, je viens de trouver une règle pour avoir les combinaisons possibles pour un objet (sauf les 3 dernières).
Mais uniquement dans le cas où tu sais quel objet final tu souhaites, et que ce soit une liste de chiffres (ID ? ^^) sans trou (ça fait beaucoup de si...)

N est l'objet recherché et donc exclu des combinaisons (quelle utilité de fusionner des objets pour avoir N si tu as déjà N ? )
n = N - 1
(a + b) = 2 x n où a et b != n
OU (a + b) = (2 x n) -1 où a et b sont les deux objets utilisés pour avoir N.

A partir de là, tu peux utiliser en récursivité pour savoir comment fusionner les objets manquants jusqu'à ce que tu arrive à une paire d'objets qui peut être récupéré via la fusion de 2x2 enfants (c'est clair ? )


Pour les 3 derniers, tu veux pas revoir ta règle ?

[leminorair]

C'est la que je me rends compte de mes lacunes ^^

Pour les 3 derniers ce n'est malheureusement pas moi qui ai codé le jeu (je me contente d'y jouer) Et la pratique montre que c'est comme ça que ça se passe.C'est pour ça que j'ai créé le tableau en dur.

n = N - 1
(a + b) = 2 x n où a et b != n
OU (a + b) = (2 x n) -1

Je me demande d'ou tu as pu tirer cette équation ^^.

Elle fonctionne bien évidemment parfaitement sauf si on veut fusionner (l'antépénultième avec le dernier) et (l'avant dernier avec le dernier) mais pour tout le reste ça marche.


Donc oui elle est clair mais ai je vraiment besoin de cette équation si je vais lire les solutions dans mon tableau ( qui lui prend en charge les bizarreries voulues par les devs)

edit

N est l'objet recherché et donc exclu des combinaisons (quelle utilité de fusionner des objets pour avoir N si tu as déjà N ? )

Dans les faits tu as parfaitement raison mais un objet ça n'est pas qu'un seul "élément" c'est constitué d'un support d'un préfixe et d'un suffixe.
Et on peut être amener à des fusions ou a=b=N mais pour seulement l'un des "élément" de l'objet ( pas les 3 sinon effectivement on se retrouve dans la situation que tu décris).

Cela sert si on a un item avec un préfixe fort et un suffixe faible on va vouloir conserver le préfixe tout en augmentant le suffixe par exemple.
Ou bien modifier uniquement le support pour pouvoir porter l'item ( oui dans ce jeu tout le monde peut porter un short ou un pantalon mais les hommes ne peuvent pas porter de jupe ^^).

par exemple
short renforcé esquive
+
short satiné réserve
=
short clouté soleil

J'obtiens bien un objet différent.

[casiii]

short renforcé esquive
+
short satiné réserve
=
short clouté soleil

J'obtiens bien un objet différent.

Donc tu fusionnes des propriétés, pas des objets (dans l'absolu ^^)
=> short + short = short
=> renforcé + satiné = clouté
=> esquive + réserve = soleil

Parce que du coup ça donne aussi ça ?

short renforcé réserve
+
short satiné esquive
=
short clouté soleil

Donc oui elle est clair mais ai je vraiment besoin de cette équation si je vais lire les solutions dans mon tableau ( qui lui prend en charge les bizarreries voulues par les devs)

Ca dépends du nombre de lignes que ton tableau a(aura)

Mais du coup, comment tu lis les solutions ? (parce que si tu passes par une équation, tu n'as pas forcément besoin de lire ton tableau ^^)

Et pour l'histoire des 3 derniers (qui doit sûrement être relatif à une sorte de "rareté" ? ^^), ça pose problème, vu que je pense que le nombre de propriétés peut être sujette à modification : Si tu augmente/diminue le nombre, tu dois refaire ton tableau pour les 3 derniers ?


Quand je vois tout ça, ça me fait vraiment penser à la génération dynamique des noms d'objets de World of Noobcraft

[leminorair]

Oui dans l'absolu ce sont des propriétés que je fusionne.
Je pensais en avoir fait mention dans mon premier post j'aurai du le dire de manière plus précise désolé.

C'est pour cela qu'il y a 3 tableaux dans l'image que j'ai postée.

Edit: j'ai 3 tableau par "types" d'objets
3 pour les pantalons ( supports , préfixes, suffixes)
3 pour les armures
3 pour les têtes
etc etc
C'est en effet un peu contraignant.

Le plus grand Tableau fait 28*28

En effet plus on grimpe dans les rangs et plus l'item est rare à l'état "naturel" et donc dur à merger.
Pour ce qui est des noms c'est de la traduction depuis le Polonais.

[casiii]

En effet plus on grimpe dans les rangs et plus l'item est rare à l'état "naturel" et donc dur à merger.
Pour ce qui est des noms c'est de la traduction depuis le Polonais.

Ok, mais la rareté est aussi du fait qu'il y a moins de propriétés qui peuvent amener à une propriété élevée.
Par contre, la rareté devrait être par rapport au centre du tableau et pas par rapport à son haut rang.

Parce que tu as plus de combinaisons possibles vers le centre du tableau (8-9 pour ton tableau 2) que vers le 2 ou le 16.
Tes propriétés de rang 1 et 2 ne peuvent pas être obtenus par la fusion (ce qui, en général, est une propriété d'items super rares ).

Question : Ces tableaux sont figés (l'ordre et les règles) ou tu peux les remanier à ta guise ?

[leminorair]

Ok, mais la rareté est aussi du fait qu'il y a moins de propriétés qui peuvent amener à une propriété élevée.

Oui c'est ce que j'entendais par plus dur à merger.
Si on reste dans les pantalons ^^ Il est très très rare de "looter" (pour reprendre un terme familier) du mortel.Et il est rare de trouver ce qui permettra de le merger en peu de fusion. Mais avec un grand nombre de fusion on peut "potentiellement" tout obtenir à partir des premiers items.

En effet on ne peut pas obtenir les 3 premières "propriétés" autrement qu'en les possédants.
Mais ça n'est pas grave car elles sont "lootable"(oui j'en fait un ajectif si je veux) très facilement et leurs caractéristiques dans le jeu sont proche du ridicule.

Question : Ces tableaux sont figés (l'ordre et les règles) ou tu peux les remanier à ta guise ?

Dans mon programme je peux les modifier à ma guise mais du coup ils vont me donner des réponses peu conforme à la réalité .
Plus sérieusement il est déjà arrivé que les créateurs du jeu modifient 1 tableau.Mais cela reste rarissime et à mon avis ne se reproduira pas. On peut donc considérer qu'ils sont fixe.