François Berhn - posté le 20/06/2016 à 23:15:00. (5402 messages postés)
Bah en fait en ruby les variables ne stockent pas des valeurs mais des références à ces valeurs. Du coup quand tu fais array2 = array1, tu met dans la variable array2 la même référence que dans array1. Et c'est pareil pour int2 = int1.
En fait la nuance qui fait que ça ne marche pas de la même manière c'est qu'un int est un objet immuable là ou un array est un objet mutable.
Du coup dans la première fonction le x += 1 va créer une nouvelle valeur et faire pointer la variable locale x sur cette valeur. Ce qui fait que, si le x local et le x hors de la fonction avaient une référence partagée, ce n'est plus le cas après assignation d'une nouvelle valeur.
Cependant, dans le cas de l'array, il s'agit d'objet mutable et la commande x[0] = "coucou" ne va pas créer un nouvel objet mais modifier l'objet en place et de fait les deux variable vont continuer à pointer la même valeur.
Voici d'ailleurs une vidéo qui explique bien le truc (en python mais le principe est le même)
François Berhn - posté le 02/06/2016 à 17:44:08. (5402 messages postés)
Pour accéder au chat il faut te rendre su ce lien : http://groupe.rpg-maker.fr/ ou sur le lien chat en haut à droite de la page
Edit : Pour le système : Voilà comment faire.
Déjà, comme mon système utilise RME, il faut que tu l'installe. Une solution simple que je te propose c'est de télécharger ce fichier : https://www.dropbox.com/s/e8t5righcxw84zb/Scripts.rvdata2?dl=0 et de la mettre dans le dossier data de ton projet.
En gros ce que ça va faire c'est supprimer les script additionnels (qui sont potentiellement source de ralentissement), ça restaure les script de base que tu aurait pu modifier et ça installe RME ainsi qu'un autre script : l'event-printer (qui peut être intéressant mais que tu peux supprimer si tu le désire).
Par contre ça risque de casser pas mal de tes systèmes donc je te conseille de faire une copie de sauvegarde du projet avant de faire cette manipulation. Bien sûr tu va surement me demander pourquoi supprimer les autres scripts. Pour moi la raison est assez simple, et je crois que d'autres personnes te l'ont dit avant : pour faire toi-même les systèmes. Certes cela prendra plus de temps pour réaliser ce que tu veux, mais tu aura bien plus de contrôle sur ta création et ça évite le soucis de scripts qui buguent et que tu ne pourra probablement pas corriger toi-même (sauf erreur de ma part). Ou que tu ne pourra pas modifier non plus à ta convenance.
En fait, ce que j'aime avec RME c'est qu'il nécessite un savoir intermédiaire par rapport à la création de script tout en ayant une souplesse suffisante pour faire pleine de choses
(oui pour le coup je t'ai pas encore expliqué le système mais ça va venir, dans un second edit)
Edit² : Alors voilà le système :
Déjà crée un event commun en processus parallèle et met ceci dedans :
Pour t'expliquer rapidement le fonctionnement de RME, il se base sur l'event scripting, c'est à dire de commandes script dans la commande "script" de RM, présent en page 3.
Ce que fais ce code, c'est qu'en boucle il va attendre une seconde puis rajouter 1 à la variable 12 de rpg maker.
Si tu veux utiliser une autre variable que la variable 12, il te suffit de changer le nombre entre les "[]" pour donner l'id de la variable que tu veux incrémenter. Pour mon exemple je vais continue d'utiliser la variable 12mais tu pourra du coup changer chaque occurrence du 12 que tu verra à ta convenance, en t'assurant de garder le même id et ne bien mettre un nombre positif.
En fait l'idée derrière c'est d'avoir une variable qui en permanence compte les secondes. Du coup si tu veux speeder l'écoulement de temps, tu peux par exemple faire ceci :
Pour faire qu'une minute IG soit égale à une seconde en vrai.
Ensuite ce que tu va faire c'est un event que tu pourra copier-coller autant de fois que tu voudra et donc dont le code sera assez souple pour éviter d'avoir à faire des retouches à chaque nouveau copier-coller. Pour ce faire, RME rajoute un outil très intéressant que sont les variables locales.
En gros une variable locale c'est comme une variable globale qui au lieu de n'être désignée que par un identifiant est aussi désigné par un id de map et d'event. Par exemple pour modifier la variable 3 de l'event 5 sur la map 11 comme je l'ai fait plus haut pour la variable 12, je peux écrire :
Ou pour faire plus souple, si je m'assure que la commande est écrite dans l'event voulu, je peux modifier cette commande en ne mettant que l'id de la variable. C'est à dire que si dans mon event 5 de la map 11 je met cette ligne :
RME prendra les id de map et d'event de l'event qui execute cette commande et saura modifier la bonne variable en conséquence.
L'intérêt c'est que du coup la version simplifié désigne une variable qui dépend de l'event qui l'execute et du coup on n'a pas besoin de modifier la variable à chaque copie, RME s'en chargera tout seul.
Du coup revenons à nos moutons.
Donc tu crée un event à deux pages :
Pour la première tu lui donne l'apparence de l'objet à récolter et tu met le code pour fournir l'objet au joueur. Puis tu rajoute ceci ensuite :
En gros ça stocke dans la variable locale 0 le temps IG passé depuis le début de la partie. C'est ce qui nous servira pour savoir combien de temps est passé depuis que l'objet a été pris.
Puis sur la seconde page tu le met en processus parallèle vec comme condition que l'interrupteur local A soit activé et tu met ce code.
Qui vas dire que : si le temps passé depuis e début de partie moins le temps passé depuis la récolte est supérieur à une heure IG, alors je désactive l'interrupteur local A
Et voilà. Bien sûr j'ai mis le 3600 pour que l'objet respawn toutes les heures IG mais tu peux augmenter la valeur pour diminuer la fréquence.
Et voilà, je pense avoir tout dit. Bien sûr ça ne gère par encore l'affichage de l'heure mais je vais en rester là pour le moment ^^
(En sachant que peut être géré en quelques lignes )
François Berhn - posté le 02/06/2016 à 12:05:27. (5402 messages postés)
Danzaiver... utiliser 75 variables juste pour 15 objets... je vois pas en quoi ton systèmes est meilleur que celui d'Aurora...
En plus mettre dans ton exemple "de ce qu'il faut faire" des conditions imbriquées quand elles n'ont pas besoin de l'être...
(Sans parler du fait que gérer le temps avec des "si variable minute est égal à 60 alors ajouter 1 à la variable heure et mettre la variable minute à 0" c'est "naïf" mais pas du tout compact, ni pratique d'ailleurs)
Enfin bref, je suis la personne dont parle Verehn dans son message, comme je n'ai pas eu le plaisir de te (LeonHeart54115) voir sur le chat qu'il te recommandais de voir, je me permet de te proposer deux solutions possibles à ton problème, qui n'utilisent pas une pléthore d'event communs ou de variables, qui sont basées sur RME, et qui sont très compactes.
Évidemment si tu en prend une l'autre ne servira à rien aussi je vais me contenter pour l'instant de te donner les avantages et inconvénient des deux pour que tu puisse me dire laquelle conviendrait le mieux à ton projet
La première solution permet de gérer, sans utiliser de processus parallèle qui tournerai durant tout le jeu. Ce pendant en plus de compter le temps quand le joueur n'est plus sur la map, elle le compte aussi le temps :
- Quand le joueur n'a plus la fenêtre du jeu active.
- Quand le joueur ferme le jeu.
De fait cette méthode est surtout à utiliser quand tu veux que le temps pas au même rythme que le temps réel, comme dans animal crossig.
La seconde méthode est moins compacte mais offre en fait plus de souplesse, par exemple dans les gestion de l'écoulement du temps. Pour simplifier c'est presque la proposition de Danzaiver, mais qui bénéficierais des avantage de RME et d'être fait pas un vrai programmeur (je plaisante ). Elle a d'ailleurs l’avantage d'être faisable sans RME mais c'est un peu pus long à mettre en place.
Et j'ai d'ailleurs une troisième idée d'implémentation, dont je ne parlerais pas pour le moment car elle ne correspondra peut-être pas à tes attentes et je n'ai pas finit de la penser totalement.
En tout cas si une de mes deux propositions t'intéresse et que tu as des question, n'hésite pas à m'envoyer un message ou a venir sur le chat (je suis dessus presque tout le temps) et je serais ravi de t'aider
François Berhn - posté le 05/08/2015 à 13:07:01. (5402 messages postés)
Bof monos, je suis pas très fan du style à contours noir/foncés.
Par contre il faudrait peut-être changer les couleurs du pot qui se fond un peu dans le parquet.
Chat
)
