Savoir si un événement en démarrage automatique est en train de tourner

[Zer0zer0x]

[Cette demande est ultra-personnelle, elle correspond à la création d'un système de mutex avec certains paramètres précis, pour les event makers. Mais surtout pour moi, en fait. L O L]

SALUT !

Serait-il possible de rajouter une commande dans RME pour savoir si un événement en démarrage automatique est en train de tourner ? Genre : is_automaticEV_running? Ce serait super gentil ! :)

Des bisous !! Bon courage !

[BastienDuplessier]

Tu peux le faire via une variable, non ?

[Zer0zer0x]

À rajouter à chaque EV en démarrage auto du projet ? Désolé, mais c'est hors de question, pour ma part. :(

C'est une source d'oublis, d'étourderies, de bugs ; en bref : l'horreur. :/

EDIT : Et ce serait relou parce que d'un projet à l'autre, y'aura toujours un CONNARD pour utiliser la variable numéro 5000 pour faire autre chose, par exemple. Quant à utiliser des labels pour être sûr de pouvoir "Transplanter" le système d'un projet à l'autre... On en revient aux risques déjà évoqués plus hauts.

[BilouMaster]

Tu dois bien connaître les conditions dans lesquelles ton événement en mode automatique est en exécution ou non... N'oublie pas que tu peux récupérer par exemple la valeur du switch local d'un autre événement.

C'est quoi ton problème, plus précisément ?

[Zer0zer0x]

C'est Boubou qui voudrait créer un événement commun en démarrage automatique (vide, ne contenant qu'une attente de 2 frames qui tournerait en boucle) qu'on activerait que s'il n'existe pas d'autre événement en démarrage automatique qui tourne à un instant t, afin de bloquer certaines interactions entre le joueur et le jeu... C'est la façon la moins dég' de bloquer le joueur, le menu, et autres, qu'on ait trouvée... :'( (En full events).

Aidez-nous à réaliser notre rêve. :(

[BilouMaster]

Mais tu peux avoir plusieurs événements automatiques qui tournent en même temps...

[Zer0zer0x]

Sous 2k3, oui. Plus sous Ace. :)

Sous Ace, le scénario est le suivant : Quand y'a deux événements en démarrage auto lancés en "Même temps" (ou légèrement décalés), le deuxième événement en démarrage auto attend que l'autre ait "Terminé" son intervention avant de se lancer. Ils s'enchaînent à la queue-leu-leu.

C'est plutôt stressant...

[BilouMaster]

A ta place j'aurais prévu d'avance un switch pour activer/désactiver la possibilité pour cet événement commun de se déclencher pendant chaque événement, j'imagine qui c'est un processus parallèle qui te pose problème...

[Zer0zer0x]

En l'occurrence, je demande la possibilité d'envisager une nouvelle commande, pas qu'on m'apprenne à maker. Sinon je l'aurais précisé. Dsl.

[BastienDuplessier]

RME est là pour apprendre aux gens à maker, c'est là le problème. Cacher des éventuels bugs avec une condition sur la présence ou non d'event commun en cours d'utilisation ce n'est pas ce que nous voulons. Je ferme donc cette issue. Si c'est une commande dont tu ne peux vraiment pas te passer, tu peux toujours réaliser un petit script qui l'ajoutera. C'est pas compliqué à faire.

[Zer0zer0x]

:'(

[gr-im]

Je pense que l'idée peut être utile dans la construction de système complexes. En effet, je pense qu'on a souvent l'habitude de ne faire qu'un seul événement commun qui gère, un peu à la manière d'une machine à état, tous les embranchements possibles. Cependant, je ne suis pas sur que ce soit du code idiomatique. Donc je propose d'écrire une commande qui permettrait de renvoyer l'événement automatique qui a la priorité sur les autres. Pas d'oppositions ?

[BilouMaster]

Sinon dans rm2k3 il me semble que tous les événements en mode automatique peuvent tourner ensemble comme des événements... automatiques en parallèle.

Sauf une flemme ou un oubli dans l’integration des modes automatiques, il y a une raison, un avantage à ce que le dernier mode automatique interromp le précédent ? Personnellement je pense que pouvoir configurer le moteur pour reprenne le comportement de 2k(3) ça serait pas mal. Je pourrais l’integrer à orms si j’y arrive sinon recommander RME avec orms si c’est intégré dans RME

sinon pour une commande renvoyant l’evenment en mode automatique prioritaire ça peut le faire

[BilouMaster]

et je déprécie clairement le fait qu’avec ce nouveau rm on ne puisse plus utiliser la technique de l’événement commun « attendre » en mode automatique, activable / desactivable quand on veut, genre, quand on veut gérer un moteur dynamique en processus parallèle et bloquer momentanément le joueur (très utilisé dans bogossstory)

Alors certes ça devrait fonctionner s’il s’agit exactement de faire mon exemple, mais il peut exister des cas où un autre événement en mode automatique vienne tout flinguer.

Ensuite pour les systèmes complexe qui doivent vraiment tout bloquer sauf son propre cours (menus, par exemple) se référer à #258

[hyperaho]

Sous 2k3, oui. Plus sous Ace. :)

Bravo pour la reprise de RME. Alors, non, pas du tout, ce que vous disiez m'a interpellé, alors j'ai essayé de voir au maximum comment ça se comportait réellement. (Pensez-vous, j'ai dû installer Wine... quelle horreur) ! Et contrairement à ce qui est dit, les évènements en mode automatiques se comportent exactement de la même manière que les évènements en processus parallèle. C'est un round-robin qui utilise chaque "relache" de Fiber pour passer la main au suivant. Donc la "manière" de donner la main à un autre événement automatique, ce serait juste de mettre un "attendre 1 frames" où toute commande qui rend la fibre.

Je pense qu'une commande comme celle proposée par @Grimimi n'a pas d'intérêt et que ça risque de poser des soucis sur la "terminaison" de l'automatique. De plus, il faudrait distinguer les évènements "sur la carte" des évènements communs. Donc je pense que l'on peut laisser au maker le loisir d'implémenter sa propre "trace" histoire de ne pas se prendre la tête avec une commande (à l'usage très spécifique) et qui oblige à "observer" beaucoup trop de mutations dans l'état.

[Cette demande est ultra-personnelle, elle correspond à la création d'un système de mutex avec certains paramètres précis, pour les event makers. Mais surtout pour moi, en fait. L O L]

La demande est ultra-personnelle, et je ne suis pas sur que tu aies bien compris ce qu'est un Mutex.

A bientôt.

[gr-im]

Oh, d'accord. Alors je ferme l'issue et je l'a retire du pipe 1.3.0. Merci pour tes retours !

[Zer0xxxx]

Vraiment navré de faire remonter cette issue ! (il se trouve que je suis de nouveau confronté au problème).

@hyperaho Je n'ai pas tout compris... ("Test" fait avec la version Steam de VX Ace)

Je pense, ceci dit, que le réel potentiel est dans #258 et non plus dans cette issue...

[BilouMaster]

Explique nous l'intérêt de mélanger deux modes automatiques et non un mode automatique et un processus parallèle comme tout le monde... Ce genre de problème se résous aisément en gérant bien ses événements à l'origine.

D'où le fait que je n'ai jamais rencontré ce problème, je veille à faire de la programmation qui coïncide avec les règles de base de RPG Maker, qui se vérifient aisément comme tu peux le constater.

[Zer0xxxxx]

@Jauke Parce que je n'aborde pas le problème pour mes projets dont je contrôle l'intégralité du code mais de pouvoir intégrer mon code dans les projets des autres ; donc je n'ai pas de contrôle là-dessus.

[xvw]

stop stop stop. La conversation commence sérieusement à me saouler.