Questions en vrac sur 2000, 2K3

doncamilo a écrit:

mettre sa sur le compte de la fatigue

Dit-il en postant à 4 heures du mat *tousse*tousse*
Ravi d'avoir pu t'aider en tout cas...

j'ai encore une petite question, est ce que les événement en processus parallèle bloquent les autres.

c'est pour un jeu de course, un processus parallèle fait avancer tout le temps le héros, il y a des bonus qui le font aller plus vite, je passe sur les bonus et rien, j'ai bien vérifier les conditions de déclenchement mais sa ne marche pas...

j'ai l'impression que l'event en processus parallèle empêche l’autre de fonctionner...

quelqu'un voit ce qu'il faudrait faire ?

Edit : j'ai trouver plus simple et mieux ^^, les bonus marchent

Non ils ne bloquent rien.

Tu as du faire une erreur quelque part.

Il me semble que la fonction "déplacer le héros" peut en effet bloquer les autres events (elle est prioritaire) même en processus parallèle
Moi je m'en servais pour permettre au joueur de viser dans plusieurs diretions sur maintient d'une touche sans utiliser d'event automatique.

Il y a une façon d'utiliser ça sans que ça ne bloque le reste et une qui fait bugguer... Seulement je ne saurais plus dire laquelle est laquelle, désolé

Déplacer un héros + repeter mouvement peut en effet bloquer un event parallèle, il ne faut jamais faire ce genre de choses en fait. ^^

je suis partit sur ce fonctionnement la, il faudrait que je trouve autre chose.

Edit : je ne vois pas comment le faire avancer tout seul sans processus parallèle ^^.

il y a une variable qui fait la direction ( de 1 a 8 ) et un event qui le fait avancer dans la direction de la variable, il y aurais une autre solution dans ce cas la ?

Pour faire avancer quoi ?

Sans comprendre comment marche ton jeu on ne peut pas te donner de solution optimale.

p'tite question rapide (je sais, je vais emmêler les pinceaux à tout le monde en la posant en même temps que Doncamilo...)
Est-il possible de créer des charset (sur RM2k3) qui sont plus grands que d'autres (ils font 24x32 par sprite originellement, est-ce qu'il est possible de les faire passer à 48x64 comme dans les RM plus récents?)

Non. Mais avec un patch ça se peut

Hééé je veux une banière Fedora user, Garywiss !!!!

edit: Nop ça va j'en ai trouvé une ^^

Relm : Le héros avance tout le temps, avec un event ( en processus parallèle) qui change en fonction d'une variable ( il avance dans 8 direction différente ).

quand j’appuie sur droite, la variable augmente et quand j’appuie a gauche elle baisse ( et tourne en rond ), avec une attente de 0.1 sec pour ne pas aller trop vite.

Le problème est que avec cette méthode la, les bonus de vitesse ne s'active pas, je voulais faire un accélérateur pour commencer.

je sais pas si c'est plus clair, sinon c'est pas grave, je recycle le jeu en micro machine ^^

Tu dois désactiver la première variable ou lui donner une valeur sans incidence (genre 10 ou 32435) sinon ce sera toujours elle sera toujours prise en charge et donc ta variable activée par tes bonus vitesses sera sans effet.

Ps: Si jamais c'est pas ça, prends des screenthots de ta progra.

Note : le nom de la section devrait être "Entraide", pas "Entre aides".

J'ai un problème.

J'essaie de déterminer si une touche est encore pressée, pour bloquer certaines choses tant qu'elle n'est pas relâchée (c'est censé servir à éviter d'exécuter en boucle une action lorsqu'on maintient la touche espace).
Mais ça ne marche pas. Essayez dans un projet RM2K3 ceci :
- faire tourner en boucle dans un event un appui touche Espace
- dans un autre event en boucle, créer une boucle dans laquelle il y a un "si variable Appui Touche = 0, alors afficher message "Prout" ".
Normalement, si vous maintenez la touche Espace, aucun prout ne devrait échapper. Pourtant, au bout d'un moment, chez moi, si. Et vous ? Je n'ai jamais eu ce problème avec RMVX.

Et sinon, une autre manière de repérer si une touche n'a pas été relâchée ?

ZimCassoulet a écrit:

Normalement, si vous maintenez la touche Espace, aucun prout ne devrait échapper. Pourtant, au bout d'un moment, chez moi, si. Et vous ? Je n'ai jamais eu ce problème avec RMVX.

Stop le cassoulet alors

Sérieusement, je suis très mauvais pour ce qui est event-making mais je peux me renseigner ailleurs pour ton problème!

Ah, apparemment c'est parce que RM réinitialise l'appui au bout d'un moment ou un truc du genre.
Manderr ou Joke avait une autre technique pour que ça fonctionne, euh va voir sur le topic de Survive v2 ou v2.5 je sais plus, il l'explique à un moment (sur e-m).

Lidenvice a écrit:

Pour un évènement seul et avec une touche appuyée seule (même si on peux utiliser la base pour plus de touches ) j'ai trouvé ça pour l'ensemble des RPG maker et qui marche relativement bien:

Étiquette: Loop
Condition si [TOUCHE DE VOTRE CHOIX] est pressée
Attendre 4 frames
aller à l'étiquette Loop
Fin

C'est une réponse reçu mais je suppose que c'est ce que tu faisais...

La différence principale est dans le 4 frames. Cela dit c'est une solution un peu sale : pas assez réactive, et, bien que plus fiable, pas assez fiable.

Grâce au message de kiki, j'ai trouvé une solution, qui est mieux que celle de Manderr : qui propose de mettre un attendre 0.0, ce qui est plus réactif que la solution Lidenvice, mais avec aussi un plus grand risque de buguer.

En fait, comme tu disais, l'appui touche se réinitialise de manière imprévisible. Du coup, moins on appelle la commande, moins il y a de chances qu'elle se réinitialise : donc plus le temps d'attente est long entre deux appels, moins elle a de chances de buguer sur la durée.

Il n'y a pas de solution miracle. La mienne est l'emploi d'un "sas de sécurité" : lorsque je constate que la variable Appui touche est égale à 0, j'attends 0.0, puis je refais une deuxième demande d'appui touche : si la variable est toujours à 0, je considère que la touche est relâchée ; mais si elle est revenue à 5 (la valeur de la touche espace) je remonte au premier niveau de test d'Appui touche.

C'est que s'il est plus ou moins probable qu'en testant tous les 0.0 attendre la variable finisse par égaler 0 bien que la touche soit maintenue, la probabilité que le bug se produise deux fois de suite (les deux niveaux de test) est bien moindre.
Pour limiter encore plus les risques, il est possible de ne tester que les 0.1 secondes (pour mon jeu au case par case, c'est bon, pas besoin d'une grande réactivité, et au pire c'est pas grave, ça fera juste comme si le joueur avait réappuyé sur espace - genre devant un coffre ça fera juste un message pour lui dire qu'il est vide) et/ou de rajouter un second sas de sécurité.

Problème résolu, et merci Choco et Kilam.

EDIT : un seul sas et un temps d'attente de 0.0, j'ai une erreur des fois au bout d'une minute. Le mieux, c'est deux sas avec 0.0 : trois 0.0 c'est plus rapide que deux 0.1 (plus réactif), et trois fois de suite une valeur de 0 encore moins probable que 2 de suite.

Sur RPg maker 2003 peut être oui, en effet que l'on peux eventuellement plus jouer sur les attentes 0.0. Ce qui à mon sens permet quand même des trucs plus sympas que attendre une frame.

Le système de variable d'appui touche incrémenté était ma première solution trouvée quand à l'appui de touche, mais dans certains cas, elle fonctionnait mal donc j'ai opté sur celle que je propose car elle est la plus efficace que j'avais testée. Simple aussi, permettant facilement sa réutilisation et l'imbrication de plusieurs touches. Il faut juste ajuster le temp d'attente en fonction de ce qu'on veux.

Reste qu'il existe aussi le système de dialogue entre deux events dont un event est loopé sur une attente lancé par l’événement touche.

Dans l'absolu, tout dépend de ce qu'on veux réaliser et l'effet qu'on veux donner.

Oui voilà, ça dépend beaucoup de plusieurs facteurs, où il faut équilibrer entre économie de ressources (la commande est gourmande), réactivité, et la gravité du bug s'il se produit. Là c'est la solution la plus sûre, mais quand on peut se permettre moins de précision, ta solution fait parfaitement l'affaire.

Il faut savoir par contre que le bug n'existe pas sur VX, donc pas besoin d'aucune frame d'attente !

Est-ce que quelqu'un d'un peu plus doué que moi pourrait rajouter un shotgun dans les mains du gars (avec le masque) en bas à droite de ce charset:



Pas besoin de le faire sur chaque animation, juste une suffira, il faudrait qu'on le voit tenir un shotgun quand il regarde vers la droite (encore une fois pas besoin de faire ça sur les 3 parties de son animation, juste celle du milieu, par exemple).

Jte fais ça dans la soirée, demain soir grand maximum mais ça devrait aller vite tkt. :p

hop

Si tu veux un truc mieux que ça demande toujours.

C'est juste parfait !

Merci beaucoup Kilam =]

Bonjour tout le monde !

J'ai une petite question qui m'a toujours posé problème, en plus je suis sûre que c'est le genre de truc qui est super évident.

Bref : je souhaite faire une petite cinématique d'intro, jusque là, tout va bien. Le seul truc, c'est que je souhaite que lorsque le jeu démarre, l'écran soit noir puis le héros parle, puis l'écran fait un fondu et hop ! La map apparait avec le héros dessus.

La technique que j'utilise :
- Un évent dans un coin, invisible et en déclenchement auto
- Là, je mets : transition écran - Instantanée (j'ai également tenté avec "Modifier le ton de l'écran en 0 dixième de seconde")
- Blabla du héros
- Fondu pour faire apparaître la map
- Reblabla du héros
- Activation d'un switch pour que l'évent auto ne se déclenche plus.

Alors, tout ça, ça fonctionne, mais mon seul soucis, c'est dès que l'écran-titre est passé, on a quand même pendant une fraction de seconde la map qui apparait avant que l'écran ne devienne noir...

Du coup, auriez-vous une solution pour que l'écran soit directement noir après l'écran-titre?

Ma méthode : La map où le joueur pop au début du jeu est une map noire, complètement vide. Celle-ci à l'aide d'un event en automatique fait le fondu en noir, puis nous tp sur la map d'intro.

Pareil que Dara, c'est la meilleure méthode à faire. Tous mes projets ont une map vide justement pour mettre une intro de ce genre