Conditions scriptées pour les pages des events.

  • 7 Réponses
  • 221 Vues
*

Hors ligne FL0RENT_

Conditions scriptées pour les pages des events.
« le: 06 mai 2018, 17:23:43 »
Les conditions de pages des évents d'RMXP sont assez limitées. (2 interrupteurs, une variable et un interrupteur local)
Ce script est fait pour pouvoir ajouter facilement des conditions de declenchement.
Il est autant compatible avec PSP qu'avec les scripts de base d'RMXP.

Dans le script Game_Event (le 1er si vous en avez plusieurs), cherchez cette ligne :
new_page = page

au dessus, ajoutez ceci :
#conditions scriptées pour le déclenchement de page
        #Par FL0RENT_
       
        tst = true
        for command in page.list
          if command.code == 108
            string = command.parameters[0]
            next if string.size < 10
            next if string[0..9] != "/page_cond"
            unless eval(string[10..-1])
              tst = false
              break
            end
          else
            break
          end
        end
        next unless tst


Pour ajouter des conditions a votre page d'event, il suffit de mettre, en ligne de commentaire /page_cond puis le script a vérifier.

Comme ceci :


Important : Pensez a mettre les lignes en question au dessus de toute autre commande d’évent.
Pour des raisons d'optimisation, le script s’arrête lorsqu'il tombe sur autre chose qu'une ligne de commentaire.


PS : si vous ne vous y connaissez pas trop en script, voici des exemples simples pour pouvoir utiliser plus d'interrupteurs/variables :

Pour verifier que la variable 10 vaut plus de 50 :
/page_cond $game_variables[10] > 50

Pour verifier que l'interrupteur 42 est désactivé :
/page_cond $game_switches[42] == false
 
Utilisateurs ayant remercié ce post : Aerun, Carchi

*

Hors ligne Leikt

Conditions scriptées pour les pages des events.
« Réponse #1 le: 10 mai 2018, 11:33:23 »
Pas mal du tout !

Pour optimiser encore plus la chose il faudrait que le jeu analyse les event de chaque map pour stocker les conditions dans les RPG::Rvent::Page directement.
Sous une forme prete a etre evaluer
Code de la condition, param, priorité :)

Parce que si je ne m'abise, le refresh est appelé souvent et la methode eval est lourde :/
 

*

Hors ligne FL0RENT_

Conditions scriptées pour les pages des events.
« Réponse #2 le: 10 mai 2018, 16:36:55 »
En fait, cette façon d'utiliser eval peut poser problème si beaucoup d’évents sur la même map ont leur page utilisant le script de verifiée en même temps.
Si c'est seulement quelques gros évents avec pas mal de conditions, par exemple, ça ne devrait pas poser de problèmes.

En plus, le code n'est pas exécuté si les conditions de déclenchement normales ne sont pas remplies.

Donc, oui, c'est possible d'avoir des ralentissement avec ce script, mais il faut vraiment le faire exprès.
Accessoirement, un évent en processus parallèle avec au moins une commande de script déclenche largement plus d'eval que 3 ou 4 évents qui utiliseraient ce script
(a moins qu'un évent en processus parallèle ne cause un paquet de refresh, en activant/desactivant des interrupteurs en boucle, par ex)

Citer
il faudrait que le jeu analyse les event de chaque map pour stocker les conditions dans les RPG::Rvent::Page directement.
Sous une forme prete a etre evaluer
Ça reviendrait a sacrifier 80% des possibilités du script pour pas grand chose, au final.
(ainsi qu'a le rendre plus complexe a installer)

L'opti c'est bien, mais l'opti pour l'opti, au détriment du reste, c'est non.

 

*

Hors ligne Leikt

Conditions scriptées pour les pages des events.
« Réponse #3 le: 10 mai 2018, 16:42:28 »
Il faudrait tester le script en conditions réelles (poussées) pour savoir s'il ralentit ou pas ^^
 

*

Hors ligne FL0RENT_

Conditions scriptées pour les pages des events.
« Réponse #4 le: 10 mai 2018, 17:23:41 »
Avec 27 évents a 3 pages, (une a 8 conditions prévues pour tomber sur true une frame sur 2, l'autre avec des rand) et un évent en processus parallèle qui refresh la map en boucle en activant/désactivant son interrupteur local A (qui sert pour les conditions scriptées des autres évents), les ralentissements sont a peine perceptibles (même pas sur qu'il y en ait, en fait)
Sachant que c'est ma map de test et qu'elle a déjà pas mal d’évents en processus parallèle.

Quoi qu'il en soit, ce script n'est pas spécialement prévu pour faire en évent le type de systèmes dynamiques qui devraient être faits directement en script, donc si au delà de ça il y a des ralentissements, c'est clairement le maker qui n'en fait pas un usage raisonnable et ce n'est pas spécialement mon problème.

Sinon, maintenant que j'y pense, le trainer_spotted de PSP est plus lourd qu'un usage normal ce système (et passe aussi par eval, vu le fonctionnement des conditions scriptés d'RM) et ne pose pas de problème.
 
Utilisateurs ayant remercié ce post : Leikt

Conditions scriptées pour les pages des events.
« Réponse #5 le: 13 mai 2018, 23:19:16 »
Les optimisations se font en release de projet.
Pokémon Gemme 3.9.7 n'exécute aucun eval (même pour trainer_spotted) car un script est passé sur tous les évènements avant release pour remplacer ces "eval" par des identifiants de fonction appelées automatiquement par les scripts quand ils voient l'identifiant passer. (Le but était d'éviter l'injection de script par CheatEngine mais ça a aussi pour effet de réduire les calculs effectués vu qu'on passe d'un eval à un to_i)
ln(yo) = <3
 
Utilisateurs ayant remercié ce post : yyyyj

*

Hors ligne Leikt

Conditions scriptées pour les pages des events.
« Réponse #6 le: 19 mai 2018, 11:04:13 »
Je suis curieux de savoir comment vous avez fait ^^
 

Conditions scriptées pour les pages des events.
« Réponse #7 le: 19 mai 2018, 17:03:22 »
Tous les évènements ont été inspectés et tout ce qui s'apparentait à du eval a été remplacer par un numéro correspondant à la signature du code écrit dedans, le code a été stocké dans un script lancé au début du jeu et les méthodes habituelles ont été remplacées.
ln(yo) = <3