Bienvenue
visiteur !

Index du forum > Vos créations > Mes travaux divers

Aller à la page 1 2 3 4 5

Reprise du message précédent:

storm lord - posté le 04/05/2014 à 23:05:50 (10 messages postés) ❤ 0

Salut solidboko, Je suis prêt à payer pour ton truc ! sérieusement, cela fait des années que je cherche un éditeur de jeu style "rpgmaker" mais avec ces graphismes la. Ta version 8, graphiquement parlant, c'est le nirvana pour moi! 90% de mes jeux/daubes ont des graphismes Game boy (4couleurs, 16x16), d'où mon intérêt. C'est une offre sérieuse que je te propose, penses-y à l'occasion, je suivrai ton travail avec intérêt et assiduité et s'il s'avère que ton projet prenne une direction "éditeur de jeu", je te ferai à nouveau une offre. En attendant, tu as mes félicitations pour ton travail exceptionnel. storm

Suite du sujet:

Wanoklox - posté le 05/05/2014 à 01:05:31 (2211 messages postés) ❤ 0
	Citation: O-M-G

solidboko - posté le 05/05/2014 à 22:39:48 (292 messages postés) ❤ 0
	Tout d'abord merci à vous deux ! L'orientation du projet est en train de se préciser. A ce jour, je regarde ce que je souhaite et ce dont je suis capable. Ce qui serait bien, c'est que vous participiez au cahier des charges ! Dites-moi ce que vous aimeriez trouver dedans, si je devais en faire un éditeur de jeu. Concrètement, si je le fais, ça sera un éditeur entièrement codé en Ruby et entièrement open source. Donc, niveau performances, ça sera suffisant pour avoir le rendu des screens présents dans mon post précédent, mais vous pourrez pas faire de RPG plus complexe que ce mélange sprites / bâtiments low poly. Cela dit, c'est l'objectif du moteur et de l'éditeur Pour l'interface, ça ne sera pas la même que RPG Maker. Je vois un truc assez simple mais avec une esthétique vraiment différente, même si la plupart des fonctions de RM seront dedans, avec d'autres en plus (3D oblige). Et nouveau soft oblige, j'aurai une approche peut être un peu plus pratique sur certaines choses liées à la distribution. J'ai en tête par exemple la possibilité que les dialogues soient regroupés dans un fichier texte pour faciliter la correction orthographique via un copier / coller dans Word, ou encore pour la traduction du jeu en plusieurs langues. Le modèle économique n'est pas figé. Il sera distribué gratuitement, ça c'est certain, et je placerai un lien "don paypal" sur le site, et ceux qui ont les moyens et l'envie de me remercier en monétisant un peu le temps passé pourront alors le faire. L'éditeur devrait comprendre : - un éditeur d'objet 3D basique pour concevoir le genre de bâtiments des screens précédents (forme et texture) sans avoir besoin de logiciel 3D - un importeur d'objets 3D faits sous des logiciels 3D tout de même (car certains éléments ne seront pas forcément réalisables via l'éditeur d'objets) - un éditeur de maps dont on pourra définir le relief et sur lequel on pourra placer les bâtiments / objets 3D - un éditeur de logique de jeu (events) minimaliste, à compléter selon les besoins. Et les scripteurs pourront modifier la plupart du moteur, puisqu'il sera conçu en Ruby. A voir. Et évidemment, sortie : when it's done.
Maker un jour, maker toujours.

zeus81 - posté le 05/05/2014 à 22:49:53 (11071 messages postés) ❤ 0
	Tu peux pas utiliser des filtres antialiasing/anistropique ? Vu la complexité des modèles 3D utilisés tu devrais pouvoir les foutre à fond.

Dyeel - posté le 05/05/2014 à 23:00:12 (200 messages postés) ❤ 0

C'est vraiment abusé, c'est trop classe! Ça donne vraiment envie, c'est beau et tu proposes vraiment des idées intéressantes. Pour l'éditeur, tu as dit que tu reprendrais la plupart des fonctions de RM, mais si c'est le cas, pense à l'ergonomie! Beaucoup de makers (et j'en ai fait partie) se sont cassés les dents sur la progra évenementielle, et ne pas pouvoir charger une image par son nom, ou avoir de variables pouvant contenir du texte, ou ne pas pouvoir choisir une variable ayant l'ID d'une autre variable était vraiment pénible. (Bien que la dernière chose que j'ai citée était présente sur 2k3). Donc sans faire trop abstrait pour laisser un accès assez large, pense quand même aux options simplificatrices En tout cas, super projet, que je suis avec toujours autant de plaisir!

Umea - posté le 05/05/2014 à 23:03:43 (79 messages postés) ❤ 0
o/ smiley non-nazi cot cot	Woaw, faut avouer que ça a la classe quand même tout ça o/ C'est vraiment joli,et on voit que c'est du travail, bravo ^^ J'ai hâte de voir les prochains screen è.é bonne continuation o/
"Pour un bon plan il faut toujours une brouette"

storm lord - posté le 06/05/2014 à 00:00:59 (10 messages postés) ❤ 0

Ca fait plaisir à entendre ! Personnellement, ta version 9 est déjà trop évoluée pour moi, en terme de 3D. La 8 était tip-top, mais il n'est pas question que tu te brides pour moi/nous, mais garde juste en tête que tout le monde n'aura pas besoin de toutes tes features. deux/trois points qui mériteraient peut être d'être approfondis: -pouvoir choisir le degré de complexité des reliefs (cubes parfaits, arrondis, pyramidaux ...). -Implémenter une sorte de "gestionnaire de données" et d"événements communs" comme dans les rpg-maker, afin de rendre le Rubi optionnel. -Laisser libre choix dans les capacités du/des personnages : sauter des reliefs [on] [off], rotation souris [on] [off], vue intérieur [on] [off]... voilà, surement de simples évidences, mais ce sont des idées, ça donne du grain à moudre. Mais je vais te dire franchement, t'as fait un tel boulot que j'ai un peu de mal à "critiquer". J'ai vu plein de projet en raycasting, mode 7 et autres, et le tient est le seul à retranscrire le monde que mon esprit d'enfant parcourait en jouant à zelda GB, on s'y croirait... Je sais pas, une histoire de proportion peut-être. En tout cas ta version 8 la, elle me fait voyager.

solidboko - posté le 06/05/2014 à 17:03:43 (292 messages postés) ❤ 0
	zeus81> On doit pouvoir ajouter ça. Je ne connais que la fonction glHint pour réaliser ces ajustements. Si tu as un autre moyen, je suis preneur. Dyeel> Charger une image par son nom, je ne suis pas sûr de comprendre ce que ça veut dire. Spontanément, je pense que tu fais référence au fait qu'il faut sous RPG Maker utiliser le numéro de l'image chargée pour y appliquer des déplacements / transformations ? A moins que tu ne veuilles pouvoir charger une image depuis un texte contenu dans une variable ? D'ailleurs, le texte dans une variable, parlons-en ! J'ai été tellement frustré que ça ne soit pas possible sous RPG Maker que tu peux compter sur moi pour l'ajouter. Idem pour la notion de "pointeur" (variable contenant l'ID d'une variable). Umea> Merci ! storm lord> Je peux facilement paramétrer la taille des tiles utilisée. Donc rien n'empêchera d'utiliser le soft pour du tile 8x8, 16x16, ou 32x32. Pour la complexité du relief, je vois ce que tu veux dire. Je réfléchis encore à cette partie de toutes façons. Oui il est prévu que Ruby ne soit pas obligatoire pour "programmer" la logique de son jeu. Je prévois bien un système d'event. Pour les personnalisations que tu vises, aussi, ça peut se faire, comme la fameuse inversion de l'axe vertical de la souris
Maker un jour, maker toujours.

Ødd Clock - posté le 06/05/2014 à 17:35:09 (540 messages postés) ❤ 0
Il s'avère que le temps passe sans vous voir.	Tu as plus ou moins compris le truc Solid, en effet ce serait afficher une image par le biais d'un texte ou d'une valeur d'une variable. En gros sur RM tu sais que pour l'instant on est obligé de faire comme ça : <> condition si variable "prout etc" = 1 <>afficher image "prout blabla1" <> condition si variable "prout etc" = 2 <>afficher image "prout blabla2" et etc pour autant de conditions (pour afficher une barre de vie par exemple) Là, ce serait plus une fonction du genre : <> afficher une image : dont l'ID est égale à la valeur de la variable "prout etc" Comme quand tu fais "activer switch : dont l'ID est égale à la variable "prout etc" mais pour les images ou alors <> afficher une image : dont le nom est la variable "prout etc" En gros pour s'éviter des tonnes et des tonnes de fourchettes de conditions comme on doit le faire actuellement sous RM. Sinon chapeau le boulot, j'ai vraiment hâte de tester une version utilisable
SwingSoft Productions - Studio de jeux amateurs | A-RPG : Forstale - La Légende des Grands Sauveurs | Ma Galerie | Page Facebook de Forstale

solidboko - posté le 06/05/2014 à 18:57:20 (292 messages postés) ❤ 0
	Je vois. C'est totalement faisable. En Ruby, je peux stocker des images dans un tableau ou dans un Hash (tableau associatif dont la clé peut être du texte). En gros, je peux tout à fait faire, en vulgarisant : <>Image["prout"] = Image.new("prout.png") et du coup : image_a_dessiner = "prout" <>DessinerImage(image_a_dessiner, 0, 0) Après, le soucis, c'est que la clé doit être unique. Il est impossible d'avoir deux noms identiques pour désigner deux images différentes. Donc au moment de la création d'une image via une commande d'event, si on fixe un nom, il faudra que je fasse une alerte du genre "nom déjà utilisé". C'est totalement faisable. On pourrait aussi (et c'est peut être même mieux) utiliser le nom du fichier comme clé, comme ça on est sûrs que le nom n'est pas utilisable deux fois. Ce soucis n'est pas rencontré sur un tableau, puisqu'on se contente à chaque nouvelle image d'incrémenter de 1 la taille du tableau. C'est le système de RPG Maker. Enfin, c'est plutôt le système qu'aurait pu (dû ?) utiliser RPG Maker, car eux vont encore plus loin : ils utilisent un tableau, mais dont les dimensions sont fixes, raison pour laquelle on est limités à 20/40 images (selon la version) et je ne sais pas pour VX/VX Ace mais je suppose que c'est limité aussi. A se demander d'ailleurs si ce n'est pas pour ça qu'ils n'ont pas permis d'utiliser une variable pour en spécifier le numéro, par peur du "out of range" si la variable valait par exemple 21 et qu'on ne peut pas dépasser 20 pictures. Donc à voir ce qui sera le plus pratique, mais il n'y aura pas ces limitations dans mon programme, et on pourra utiliser une variable contenant un nombre ou du texte pour sélectionner l'image à dessiner dans la commande dessiner_image. D'ailleurs, concernant le dessin d'images, on peut envisager pas mal d'ajouts, notamment le fait de pouvoir ne dessiner qu'une portion de l'image. Je pense que ça serait encore plus pratique pour une barre de vie par exemple. Et cette proportion pourrait aussi être contenue dans une variable. Et quitte à passer pour un troll, tu sais qu'on est pas obligés sur RM (>2003) de passer par les commandes d'event pour afficher une image. Par un script, de mémoire $game_pictures[0].draw(0, 0), tu peux passer le numéro de l'image via une variable. Mais c'est du code, pas de l'event, je l'accorde . Et ce n'est donc pas possible avec les versions 2000 et 2003.
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 19:50:45 (200 messages postés) ❤ 0

Odd Clock a bien résumé ce que je voulais dire sur les images^^ Et pour les string et les pointeurs, c'est parfait Pour l'affichage des images... Je pense que pouvoir afficher une seule image par nom de fichier est pas terrible... Je pense que tu pourrais garder le fait de gérer une image par son ID (et ainsi faire un array d'images), et de faire une option pour changer l'image avec un string et pas en faisant 50 conditions comme l'a expliqué Odd Clock. Ca permettrait aussi de gérer les images de manière plus abstraite (itérations, etc...). Citation: ne dessiner qu'une portion de l'image. Oui, ce serait pas mal comme option aussi^^ Mais le plus important selon moi est de pouvoir coder plus vite que sous RM, sans devoir faire 20 conditions pour un truc basique (ceux qui ont fait un système d'affichage custom en event le savent : rien qu'afficher un mot à l'écran est terriblement long à faire.), et je pense que c'est ça qu'il faut éviter un maximum ^^

solidboko - posté le 06/05/2014 à 20:05:20 (292 messages postés) ❤ 0
	Une itération se fait mieux via un compteur, et donc des nombres. On peut aussi énumérer via un tableau de mots, mais le remplir sera surement fastidieux, et il serait impossible de prédire l'ordre d'affichage avec des mots. Un exemple comme ça qui me vient en tête, mais ça peut commencer à être un peu complexe peut être, c'est créer des "listes d'images", et de permettre un défilement. Mais c'est peut être empiéter un peu sur les planches de sprites, qui ont exactement le même rôle et le même fonctionnement. Et j'aimerais pas forcément vous tenter de charger des images gigantesques en nombre pour faire une animation, alors que je vais vous permettre d'animer une caméra 3D pour faire des cinématiques. Donc en gros, l'idée ça serait de créer un tableau d'images comme RPG Maker, mais de simplement pouvoir dire : afficherImage[variable_contenant_id_de_l_image]. Mais ça contraint toujours de savoir quelle image est dans quel ID. On approche, mais c'est pas encore parfait ! Alors que si l'ID est du texte, au moins, on peut appeler son image "barre_de_vie" ou je ne sais quoi. Et au pire, rien n'empêche l'utilisateur de l'appeler "0" s'il veut garder des nombres (qui seront en fait du texte). Et de toutes façons, on parle clairement ici de menus / HUD. Le reste, sur la map, c'est de la 3D. Donc on parlera plus de la même manière que sous RPG Maker. On parlera modèle 3D, sprites. Mais le même principe peut être appliqué.
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 20:38:47 (200 messages postés) ❤ 0

Comme ce sera plus parlant qu'un pavé, voilà mon idée, basée sur le système d'affichage d'image de RMXP (en haut l'original, en bas ce qu'il faudrait) : Spoiler (cliquez pour afficher) Je pense que garder les images dans un tableau est une meilleure idée : - pas de limite d'affichage d'une image identique, car si on a besoin d'en mettre une image 4 fois, il faut pouvoir le faire. - on peut aller chercher une image facilement, pour l'afficher, la déplacer, lui faire effectuer une rotation etc, rien qu'avec un id stocké dans une variable. - le nom est indépendant de l'image : le fichier de l'image peut être changé si on veut, dynamiquement dans le jeu, donc l'indexation par string est moins bonne si on réfléchit comme ça... D'autant que si on doit effectuer un même traitement sur 100 images à l'écran, il est plus judicieux de passer par un procédé itératif, qui, comme tu l'as dit, sera mieux avec des entiers.

Ødd Clock - posté le 06/05/2014 à 20:44:54 (540 messages postés) ❤ 0
Il s'avère que le temps passe sans vous voir.	solidboko a dit: Et quitte à passer pour un troll, tu sais qu'on est pas obligés sur RM (>2003) de passer par les commandes d'event pour afficher une image. Par un script, de mémoire $game_pictures[0].draw(0, 0), tu peux passer le numéro de l'image via une variable. Mais c'est du code, pas de l'event, je l'accorde . Et ce n'est donc pas possible avec les versions 2000 et 2003. Ah baaaah j'en sais rien, je bosse sur RM2003 comme tout bon maker devrait le faire Tant mieux si c'est faisable, ça va vraiment permettre de simplifier la prog' en tous cas
SwingSoft Productions - Studio de jeux amateurs | A-RPG : Forstale - La Légende des Grands Sauveurs | Ma Galerie | Page Facebook de Forstale

zeus81 - posté le 06/05/2014 à 20:53:34 (11071 messages postés) ❤ 0
	Citation: zeus81> On doit pouvoir ajouter ça. Je ne connais que la fonction glHint pour réaliser ces ajustements. Si tu as un autre moyen, je suis preneur. J'y connait rien en 3D donc je vais pas pouvoir t'aider. T'as qu'à faire des recherches sur le MSAA ou SSAA.

solidboko - posté le 06/05/2014 à 20:57:18 (292 messages postés) ❤ 0
	Odd Clock> Je m'en doutais bien, t'inquiètes. zeus81> Je me renseignerai. Je sais que glHint permet d'améliorer la perspective et de casser un peu l'aliasing. Il doit y avoir d'autres manières, c'est du peaufinage mais je verrai en temps voulu. Dyeel> Très bonne initiative ! Le truc dommage, et qui me faisait penser qu'utiliser le nom de fichier était une bonne idée, c'est qu'on va devoir charger l'image pour pouvoir l'afficher. En pseudo code, ça donnerait genre <>Charger image : 1, "test.png" <>Charger image : 2, "test2.png" <>Charger image : 3, "test3.png" <>Assigner variable : 001_image a afficher, 2 <>Dessiner image : 001_image_a_afficher, [0, 0], 255, 90... Et c'est peut être dommage de devoir se faire chier à faire ça. Pas si simple, hein ?
Maker un jour, maker toujours.

Hellper - posté le 06/05/2014 à 21:07:21 (5402 messages postés) ❤ 0
Tonton Hellper	Pourquoi charger l'image avant de dessiner ?
La liste des raisons pour lesquelles le making se meurt, la cinquième va vous étoner | Des projets abandonnés, source d'inspiration :D | Mes jeux

solidboko - posté le 06/05/2014 à 21:16:42 (292 messages postés) ❤ 0
	C'est justement tout le débat, mon cher Hellper Nous nous demandons quelle serait la meilleure manière de gérer un affichage dynamique d'image, où serait variable l'image à dessiner. Nous avons un dossier GFX contenant des images. Mettons qu'on vous permette d'être plus organisés que sous RPG Maker, et que vous ayez le droit de mettre même des sous-dossiers, soyons fous. Je suis en train de concevoir un superbe jeu de pierre-ciseau-feuille, le mini jeu rétro par excellence pour quiconque a manipulé de petits singes pendant son enfance. J'ai un sous-dossier "PCF" dans mon dossier GFX. Je fais faire un choix à mon joueur, et j'ai besoin d'en garder une trace afin de pouvoir comparer avec le CPU. Nous avons déjà décidé que nous pourrons sauvegarder le résultat sous format texte dans notre variable. <>afficher choix : <>.. si pierre <>.... changerVariable 005:CHOIX_PCF, "pierre" <>.. si ciseau <>.... changerVariable 005:CHOIX_PCF, "ciseau" <>.. si feuille <>.... changerVariable 005:CHOIX_PCF, "feuille" Bon, le CPU a aussi son choix de fait dans sa propre variable <> changerVariable 006::CHOIX_CPU, random("pierre", "ciseau", "feuille") On veut afficher les vignettes. On pourrait donc imaginer : <> definir image, "pierre", "GFX/PCF/pierre.png" <> definir image, "ciseau", "GFX/PCF/ciseau.png" <> definir image, "feuille", "GFX/PCF/feuille.png" et afficher le résultat <>Afficher image, 005:CHOIX_PCF, [0, 0] <>Afficher image, 006:CHOIX_CPU, [200, 0] Et ça fonctionnerait bien. Mais on a dû charger l'image pour lui affecter un identifiant connu. Alors que si on charge pas les images, on doit passer par un identifiant qui ne changera jamais, comme son nom (il y a peu de chance que le nom change).
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 21:37:39 (200 messages postés) ❤ 0

Je suis d'accord avec toi dans l'idée de la simplicité, on veut afficher l'image de la pierre, on appelle l'image d'ID "pierre", mais bon c'est vite limité... Je reviens aux itérations qui sont quand même un élément hyper important qu'on peut pas utiliser pour les pictures dans RM. Et dans ton exemple précédent, ce que tu fais c'est un cache en fait, non? Tu crées le contenu des images (dont un bitmap), et "afficher image" te permet d'afficher une copie de ce bitmap sur un certain endroit de l'écran? D'ailleurs, faire : <> definir image, "pierre", "GFX/PCF/pierre.png" <>Afficher image, "pierre", [0, 0] est pareil que faire : <> definir image, 1, "GFX/PCF/pierre.png" <>Afficher image, 1, [0, 0] Non? En fait je pense qu'avant de se poser toutes ces questions, faudrait voir ce que tu cherches à faire... Tu veux créer des images avant de pouvoir les placer à l'écran? Ou tu fais tout d'un coup comme dans RM ?

solidboko - posté le 06/05/2014 à 21:45:28 (292 messages postés) ❤ 0
	Ce qui ne revient pas au même dans l'exemple que j'ai imaginé, c'est qu'on utilise directement le résultat du choix dans le dessin de l'image. Et ce résultat du choix va aussi permettre de tester qui a gagné ou s'il y a égalité, d'une pierre, deux coups quoi. Et non ce n'est pas un cache. On utilise OpenGL, même pour la 2D ! Donc, en gros, on charge des textures, et on dessine un quad à l'écran aux coordonnées souhaitées, et on affecte à ce quad la texture dont le nom est le même que le résultat du choix. Donne-moi un exemple où une itération serait utile.
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 22:00:01 (200 messages postés) ❤ 0
	Mmmh la première chose qui me vient est un système d'inventaire custom où le gars veut afficher un à un ses icônes d'objets, à des coordonnés précises. Donc itération pour le numéro de l'image, et cet entier servira aussi au calcul du x/y de cette image.

Hellper - posté le 06/05/2014 à 22:05:55 (5402 messages postés) ❤ 0
Tonton Hellper	Typiquement l'itération est utile à partir du moment où on veut afficher une image sans se préocuper de l'image en elle-même.
La liste des raisons pour lesquelles le making se meurt, la cinquième va vous étoner | Des projets abandonnés, source d'inspiration :D | Mes jeux

solidboko - posté le 06/05/2014 à 22:10:20 (292 messages postés) ❤ 0
	J'ai des milliers de réponses en script lol. En event, c'est déjà plus dur à imaginer. On part sur la notion de boucle. En Ruby, on peut facilement créer des boucles, car les objets de regroupement sont des Enumerable. Spontanément, pour ton exemple, je ferais une planche de sprite avec les icones, ou un sous dossier contenant toutes les images concernées. Du coup, on pourrait imaginer créer une collection, et un genre de traitement par lot. <>DefinirCollectionImage, "items", "GFX/CMS/items" <>DefinirVariableLocale, x, 0 <>DefinirVariableLocale, y, 0 <>TraitementLot, "items" ..DessinerImage, ElementCourant, x, y ..DefinirVariable, x, +, 26 <> Pourrait par exemple parcourir la collection et dessiner le tout avec 10 pixels d'intervalles sur X à chaque fois. Un truc dans ce genre là. En Ruby pur, ça donnerait : Portion de code : Tout sélectionner 1 2 3 items = Gosu::Image.load_tiles(fenetre, "gfx/cms/items.png", 16, 16, true) x, z = 0, 0 items.each {|item| item.draw(x, y, 0); x += item.width + 10}
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 22:17:39 (200 messages postés) ❤ 0

Ah ouais ok mais bon c'était pas évident que tu ferais un système de collection D'autant que si tu utilises un consommable, il faut modifier la collection etc... Mais j'ai l'impression qu'on contourne un problème pas très compliqué avec une méthode compliquée, non? Ou c'est moi ^^' Après, tu as sans doute plus d'expérience que moi en progra, mais je vois plus d'intérets aux entiers qu'aux strings pour l'ID ^^ Enfin bon, va falloir peser le pour et le contre selon ce que tu proposes à côté (comme les collections par exemple) Edit : Ah oui mais l'intérêt du système d'events c'est de faire une interface ergonomique et la plus simple possible pour les makers qui connaissent pas le ruby

solidboko - posté le 06/05/2014 à 22:24:25 (292 messages postés) ❤ 0
	Je pense avoir compris ce que tu voyais. En gros si on a par exemple fixé 10 éléments graphiques de ton CMS dans des images, qui correspondent à des ID de 1 à 10, on pourrait faire : <>BOUCLE, 001:VARIABLE_BOUCLE, 1, 10 ..ChangerVariable 002:X, 001:VARIABLE_BOUCLE, x, 26 ..AfficherImage 001:VARIABLE_BOUCLE, [002:X, 0] <>
Maker un jour, maker toujours.

Dyeel - posté le 06/05/2014 à 22:28:41 (200 messages postés) ❤ 0

Oui c'est ça. Un bête for dont la variable de boucle permet de choisir l'image, la position x, y, voire plus. Parce que si ton image est indexée par un string, il te faut une variable en plus pour faire des choses identiques, et si une seule image est possible pour le string en question, je peux pas afficher deux objets identiques de mon inventaire à deux places différentes. Mais ça c'est pour un seul exemple. Faut voir ce que ça apporterait à côté aussi...

Aller à la page 1 2 3 4 5

Index du forum > Vos créations > Mes travaux divers