Re : [MMF2.5] Aide aux variables dupliquées

Bonjour à tous.

J'ai une question qui me chagrine depuis un bon moment déjà :

Quand je crée un Actif avec des variable A,B,C,D etc... sur une map et que par exemple je dis :

Quand un objet ActifTir(un projectile par exemple) touche l'objet en question , alors la variable A de mon objet en question passe à 1. Quand cette variable A passe à 1 , alors je dis par exemple de créer un objet Y (exemple , une pièce) relatif à l'objet en question.

Jusque là tout va bien sauf que si je duplique mon objet en question et qu'un projectile tout l'un d'entre eux , alors l'action se fait pour chaque objet au lieu de seulement celui qui à été touché.

J'ai l'impression que malgré que les objets soit dupliqué  , ils ne sont pas indépendant au niveau de leur variables.

Ou alors y'a un truc que j'ai toujours pas vraiment compris....

Hello
Quand tu dupliques un objet c'est le meme objet mais instancié
Pour le distinguer d'un autre tu as plusieurs méthodes
Soit tu distribues une valeur à chacun > repartir la valeur ( différente pour chacun )
Soit tu le reconnais parce qu'au moment ou par exemple (ton curseur est au dessus de lui) > bah tu peux agir que sur lui
soit quand tu le créer tu mets une valeur unique dans une variable pour le reconnaître.
Bref il faut d'une part comprendre comment fusion fonctionne en faisant des tests, d'autre part imaginer des solutions en fonction de ce que tu veux faire.

A+ Pit

un petit exemple simple

Merci beaucoup de ton exemple , j'avais bien compris le fonctionnement de ton exemple , y'a pas de soucis là dessus.

Mais en fait le problème vien je pense de répartir une variable .

J'ai compris que quand j'utilise la fonctionne répartir 1 a la variable A , si je duplique , l'objet 1 aura 1 , puis le 2 aura 2 etc....

j'aimerais par exemple faire que :

Au démarrage , repartir 1 à la valeur modifiable A

Si valeurmodifiable A = valeur réparti de l'objet et si appuie sur touche A , alors on imagine l'objet bouger à droite.

Dans la pratique je sais faire l'appuie , le déplacement , l'appel d'une valeur fixe mais pas l'appel de la valeur réparti au démarrage.

Salut salut,

Je ne vois pas du tout ce que tu cherches à faire à répartir une valeur. Quel rapport avec le pièces au départ ?

exemple modifié

J'ai bricolé un truc d'après la description de ton premier message. La valeur A est bien différenciée pour chaque cible.

J'ai bien regarder vos exemples et effectivement je comprend bien le fonctionnement.

Mais c'est étrange car je dois alors avoir une erreur de programmation :

https://mega.co.nz/#!lwxhwbRK!ilqSNCIV1MwhXTr69D8VcFhLN9vJtjMaZl9yyR10uJo

Dans mon exemple normalement si j'ai bien tout fait , quand le trait rouge touche le carré vert , alors c'est le carré vert touché qui crée la ligne horizontal et quand il est plus touché alors ca s'arrete.

Mon exemple quand on touche le premier carré (avec fleche gauche droit pour bougé les carré) alors ça fonctionne mais des qu'on touche le deuxième bah le premier reste en fonctionnement...

Ça vient de

× █▌ est au dessus de ▌ [/li]

qui ne différencie pas les objets identiques.

(Et en passant. Je trouves qu'utiliser les comportement des objets rend la programmation confuse. Je te suggère d'utiliser des groupes, tu auras tout sous les yeux.)

[Edit]
j'ai trouvé une parrade. J'ai remplacer cette événement par :

Tout les 00"-01[/li]

          █▌ : soustraire 1 à Droite

Et au lieux de fixer la valeur à 1, j'ai mis 2.

Ah oui effectivement en mettant soustraire 1 ça fonctionne . Mais je comprend pas du tout pourquoi en enlevant 1 à droite tout le temps ça fonctionne?

Je n'ai pas suivie le problème mais pour ta question certaine valeur numérique débute à 0 et non à 1. Donc des fois il faut rectifier le tir.
Voilou.

ok c'est étrange mais logique. Merci beaucoup de vos explications.

C'est pas du tout ça ici.

En fait, au départ tu testais si le carré et le laser ne se touchaient pas. Or quand le laser passait du premier carré sur le second, la condition n'était pas vérifiée.
Ce que j'ai fait c'est juste un décompte pour que le laser qui part à droite s’arrête au bout de 2 centième de seconde. Mais le laser qui touche toujours carré remet toujours ce décompte à 2.

D'après l'objectif à atteindre, il y a prise de pieds dans le tapis.

Nota:
Attention à la façon de disposer les objets dans la scène, suivant le procédé la valeur ne se répartit pas de la même façon.

Au fait on le choisit comment ton objet (carré vert)?

Si tu réponds correctement à la question, tu trouveras la meilleure manière d'identifier ton carré vert.

Edit:
Astuce Identification.mfa 111 Ko
https://mega.co.nz/#!fJYmRC6Y!BPehtAWet7IhnOv9TqZunR1viNhs6VPLcFZgv4fz1Kw

Identification Actif.mfa 99 Ko
https://mega.co.nz/#!jRgFQYBI!OEn3s23ACmetVf4cuFGgazK33R7Ff7sWCBJDjQskIko

ok d'accord. En fait c'est quand même compliqué à mettre en oeuvre pour une simple action de choix d'objet.

j'ai bien remarqué que si je précise une collision entre deux objet alors seul les deux objets en questions sont concernés. donc la détection se fait par contact. Ce qu'il y a de bizarre c'est que la détection fonctionne bien avec un objet mais dès qu'on en rajoute plusieurs bah ça bug pas mal (que ce soit monstre , objet divers etc...)

La détection des collision fonctionne très bien avec plusieurs objets. C'est la non-collision qui n'est pas différenciée.

Il y a deux choses à bien capter, voire trois.

Un objet peut être identifiable dès le début de la scène via une variable.

Un objet peut être identifié en cours de jeu.

Il y a la collision entre deux objets >> action temporaire.

Il y a la superposition entre deux objets >> action permanente.

Il n'y a pas la superposition entre deux objets >> action permanente.

Il est très facile d'avoir des bugs, si tu utilises des actions antinomiques.

Exemple antinomique très connu:

Il y a superposition entre deux objet >> action permanente >> CTF joue un son.

Edit:
A mon humble avis tu n'as pas besoin d'une astuce pour identifier ton objet, mais de comprendre une logique implacable, afin d'atteindre tes objectifs.

Oui vous avez complètement raison. J'utilise énormement quand un actif est au dessus de....Donc il serait plus interessant de faire :

Quand un actif est au dessus de ... alors variable A = 1

et si variable A = 1 alors ...... ici on programme.

Et après je rajoute : toutes les 0,01 s : soustraire 1 à Variable A

?

Non! On a complétement tord.

Tu as le don de compliquer une chose simple, évite de cacher tes misérables (pénibles) conditions dans des comportements gadgets.

Tu n'as pas besoin d'identifier ton carré vert.
Il suffit juste d'utiliser la condition en collision (collision entre).

CR_Djipi.mfa 51 Ko
https://mega.co.nz/#!DExEwKwI!SdkckV_8x-dughsPPQu1gsK2LF7xyBFi4biraSTEOHA

Edit:
Sur un "gros" projet si tu caches tes lignes, bonjour la galère, mets plutôt en place des groupes d'événements, plus facile à activer et désactiver afin de trouver un bug.
N'hésite pas à commenter tes lignes, quand on revient sur le projet, c'est plus facile de replonger dans le bain.
Tes conditions sont pénibles et misérables, parce qu'il faut aller les chercher.

On ne met pas une variable pour faire joli, une variable sert à atteindre un objectif précis.
Visiblement ton cahier des charges est à revoir.

Si tu n'arrives pas à faire la différence entre collision et superposition, qu'est ce que l'on va faire de toi? (humour)

Comme le dit Pit fais des tests, essaye de capter comment fonctionne CFT.

mes plutôt ta valeur à 2. Ça évite qu'elle passe à 0 quand la collision est toujours vérifiée.