Où mettre les "scripts maison" ?

Bonjour,

Quelqu'un peut il m'expliquer, même en termes "compliqués", la différence fondamentale entre les scripts que l'on peut installer avant "▼ Materials" et ceux que l'on DOIT installer après.

C'est assez déroutant pour un débutant de voir RME s'installer AVANT, de pouvoir en installer d'autres avant et de voir que certains ne supportent que d'être installés APRÈS sous peine de plantus pour des raisons de "stack".

Comment les reconnaître au premier coup d’œil ?

Euuuh, en reconnaissant le(s) niveau(x) sur lequel ils agissent? Donc connaître comment fonctionnent les différents scripts de base et savoir aussi à quelle niveau agissent les scripts maison? RME est général donc à placer avant et les script maison, plus particulier à placer après. Sinon, autre méthode premier coup d’œil, je vois pas et je crois pas qu'il y en a d'autres mais si il y en une méthode, ça m'intéresse aussi pour le coup.

La seule méthode que j'ai "intuitée" pour le moment, c'est :

Placer AVANT
Tester
Si erreur de "stack" => Placer APRÈS
Tester
Si "OK" -> Sortie, c'est bon
Si pas "OK" -> Pleurer.

C'est efficace mais ça fait franchement "amateur".

Si la méthode c'est

en reconnaissant le(s) niveau(x) sur lequel ils agissent

alors ma question devient : Comment reconnaît on le niveau sur lequel ils agissent ?

Les scripts sont compilés dans l'orde présenté sur le logiciel (haut en bas).
Ils sont rangés pas catégories :
▼ Game Objects c'est les modèles
▼ Sprites et ▼ Windows c'est les vues
▼ Scenes c'est les contrôleurs
le material ne sert à rien, c'est juste un repère.

Les scripts "maison" modifient pour la plupart les scripts de base donc si tu les compilent en premier, forcément, ça marche pas.

SI tu as un script qui modifie seulement un aspect de la carte, tu pourrais même le placer entre Scene_map et Scene_MenuBase
Mais clairement, ça serait le bordel.
Donc tu mets tout à la fin, ça passera.

C'est tout.

Après là où sa devient le bordel des fois c'est l'ordre dans les scripts "maison"

En connaissant tout le fonctionnement de RPG maker (dans l'idéal^^), si tu veux être sur que ça marche. RGSS, c'est de la progra orienté objet, donc faut déjà connaître la plupart des classes-mères et des classes-filles. Ça te permettra déjà de repérer les liens hiérarchiques entre les différents objets et de comprendre un certain nombre d'erreurs. Ensuite, il faudrait passer au niveau des fonctions/méthodes/etc. et là, ça devient vraiment hard. J'avais déjà essayer mais j'ai complétement abandonné depuis un petit bout de temps. Le truc que je te conseil, c'est de faire au cas par cas et de regarder à chaque fois les appels de fonctions et d'objets. Il y a pas vraiment d'autre moyen. Mais en même temps c'est faisable, les scripts de ace par exemple sont relativement simple à comprendre comparé à d'autres scripts. Les fonctions sont assez simples et généralement pas trop longues, les auteurs ont fait un beau boulot. Mais bon, après c'est des dizaines de milliers de ligne de code qu'il se faut taper, c'est extrêmement fastidieux.

En plus, il y a parfois certains appelle à des fonctions de base de ruby, donc il faut étudier ruby en plus si tu veut aller jusqu'au bout. Bref, c'est possible mais ça risque de te prendre plusieurs mois si tu a beaucoup de temps libre. Plus si tu n'en pas. Et sinon c'est au cas par cas.


Edit: Ici, tu pourra trouver qui pourra t'aider dans la compréhension des script de base. Là, c'en est un autre. Ça m'avait permis de comprendre pas mal de truc.

Edit2: j'ai fait plusieurs modif parce je disais des bêtises et que j'avais mal compris ce que disais Hinola, sorry, si vous les avez vu...

Yen a pas tant que ça de script qu'il faudra que tu mettes en 1er (tout en haut), et en général sont bien indiqué clairement dans les commentaires du scripts. Sont assez spécifique, et la majorité doivent être mis en bas.

Comme dit Hinola, ils réécrivent (ou mettent des alias) des fonctions déjà écrites dans ceux de base, donc le plus simple c'est de toujours les mettre en bas.

Après comme il dit aussi le soucis c'est surtout entre eux, et dans ce cas faut bien savoir ce qu'ils modifient chacun exactement.
Parce que genre si t'as un script 1 qui met un alias d'une fonction et qu'en dessous t'y mets un autre script qui va te reecrire entièrement cette fonction bah ça marchera pas.

Merci à tous et toutes pour vos informations, mais elles ne répondent pas à ma question.

Je n'ai jamais parlé de "tout en haut" ni de "tout en bas". Pas plus que je n'ai parlé de l'ordre dans lequel il faut les mettre les uns par rapport aux autres.
Je connais les contraintes des programmes interprétés, ou "pseudo compilés" comme c'est le cas ici, et non pas compilés réellement et qu'il faut définir la fonction AVANT de l'appeler. Problème qui ne se pose pas dans les "vrais compilés" puisque la compilation s'effectue en deux passes, la première pour syntaxer et récupérer TOUS les noms de fonctions (ou procédure, ou méthode, ou .... quel que soient le nom qu'on leur donne), la seconde pour effectivement générer de l'assembleur. Assembleur qui, ensuite, sera transformé en code machine..

Je parle de la séparation symbolisée par le mot "▼ Materials"

Il y a des scripts qui peuvent se mettre AVANT comme tous les scripts de Yanfly, et certains qui ne fonctionnent que s'ils sont APRES comme "Party System Swap" de Soulpour ou certain scripts de Hime dans lesquels il est précisé qu'il FAUT les mettre sous "▼ Materials" et qui ne fonctionnent pas si on les place au dessus, je l'ai testé.
Et il ne s'agit pas de l'ordre dans lequel ils sont placés.

Ma question n'est pas : Comment faire pour que ça marche
mais : Comment les reconnaitre.

Le système intuitif que j'indique plus haut fonctionne, mais il n'est pas élégant. De plus j'aime bien savoir le "pourquoi" des choses en plus du "comment".

J'ai commencé à développer des scripts et je voudrais bien savoir si il faut que j'indique, dans le mode d'emploi, des restrictions quand à leur place autrement qu'en les découvrant par des tests.

Shamugan, je sais très bien que c'est un gros boulot, comme toujours je ne lâche pas le morceau mais je demande si quelqu'un sait avant de chercher moi-même (cf ma signature).

PS: Je signale, à ceux qui ne le savent pas encore, que j'ai 30 ans d'analyse/programmation derrière moi et que même, ayant surtout fait de la programmation linéaire, si je ne suis pas familiarisé avec le langage Ruby, j'ai de très bonnes notions de la manière dont il fonctionne. J'ai déjà développé avec d'autres langages orientés objets.

La séparation est vide, donc si tu n'as que le dit script qui te dit "au dessus" de matérial, que tu l'mettes au dessus ou en dessous de cette ligne ça change rien.

C'est juste une démarcation pour se repérer. Et si ça dit de le mettre avant c'est probablement juste parce qu'ils réécrivent des fonctions.

Mais sinon pour les reconnaitre bah faut savoir c'que ça change et comment. J'sais pas c'que tu fais en script, mais si j'prends par exemple certaines de mes modifs, je réécris pas mal de fonctions qui sont ensuite réutilisées dans le SBS que j'utilise (qui n'est pas de moi donc me suis adapté à lui). Donc obligé de les mettre avant.

Mais j'vois pas comment t'aider plus que ça vu que ça dépend de ton script et de ceux avec qui ça risque d'interagir.
Et si t'as vraiment autant d'expérience j'avoue que j'vois pas c'qui bloque dans ce cas.

J'imaginais, naïvement, que la structure ou une déclaration quelconque pouvait donner une indication.... Mais bon, s'il n'y en a pas, je vais revenir à ma méthode expérimentale.

En ce qui concerne le simple "séparation" je suis moins affirmatif puisque j'ai fais le test de mettre plusieurs scripts dans un certain ordre AU DESSUS de la séparation, ça ne marchait pas, je les ai "coupés/collés" AU DESSOUS, tous et dans le même ordre, et là, ça marchait.

Je ne sais pas comment le système gère tout ça, mais on peut très bien imaginer qu'il lit la table des scripts (à gauche) et que, lorsqu'il arrive à "▼ Materials" il ne traite pas la suite exactement de la même manière. Il faudrait que je fasse des tests en enlevant la ligne en question. Mais là, je suis sur pas mal d'autres choses alors ce sera pour plus tard. Mais je comprendrai. Et comme je suis d'une honnêteté scrupuleuse, tout au moins en ce qui concerne l'expérimentation scientifique , je referai tout d'abord mes tests pour m'assurer que je n'ai pas oublié quelque chose dans la manip.

Zoltic a écrit:lorsqu'il arrive à "▼ Materials" il ne traite pas la suite exactement de la même manière.

Evidemment , ce n'est pas exactement pareil .
On est dans un language objet avec son fonctionnement de surcharge .

Mais faire des expériences là dessus , c'est pas la peine .
y'a une seule maniere de faire , c'est de mettre ton script en dessous . c'est comme ça que les developpeurs ont prévu que ça marcherait . ne va pas chercher plus loin et prend l'habitude de mettre tes scripts ou ceux que tu telecharges à ce niveau là .

Ils font que de la surcharge les scripteurs? Et quelle type de surcharge?
Enfin dans "materials", c'est sensé être que de la surcharge?
(si ça te dérange pas trop de répondre, je sais que ça peut être chiant de répondre donc j'irais chercher au pire)

Comme je l'ai dit, j'aime bien savoir comment ça marche. Je sais la curiosité est un vilain défaut mais c'est grâce à ça que j'étais très performants dans mon boulot. Je sais plein de trucs qui paraissent inutiles jusqu'au jour où ils deviennent primordiaux.

Ceci dit :

c'est comme ça que les développeurs ont prévu que ça marcherait

Si on ne faisait que ce que les concepteurs prévoient, on n'aurait, tous, que des programmes officiels payés et personne ne téléchargerai de musique ou de film avec Bittorrent.

Cherche pas, Shamugan, les scripts qui "annulent et remplacent" les "objets/classes/méthodes/... d'origine" sont légion.
C'est pour ça que l'ordre importe vachement. Parfois tu peux être amené, sans le savoir, a mettre deux scripts qui surchargent la même chose et tu sais pas qui aura le dernier mot.

NB: Le conflit dont je parle ailleurs au sujet de Yanfly et RME vient de là justement.

Oui, je sais mais je voulais des détails justement (un peu trop curieux aussi^^). Et "annulent et remplacent", c'est un des type de surcharge (je viens de voir le terme redéfinition aussi, moi je connaissais polymorphisme). Sinon, il y a les autres rédifinition/surdéfinition/surcharge qui change en fonction du type (qui ne remplace pas du coup) et les autres encore que je connais pas bien (avec les problèmes de convention en plus, chacun à sa petite expression dans son petit langage...). Mais du coup, celle qui ne remplacent ne pose pas de problème a priori, c'est pour que je demander de quelle type il parlait, sauf peut-être si c'est chargé dans le mauvais ordre (et encore j'ai des doutes du point de vue théorique). C'est pour ça que je pensais plus à des problèmes d'héritages de classe de mon côté aussi.

Sinon, ça me surprenait aussi qu'il ne parle que de surcharge, m'enfin bon, j'irais fouillé moi-même à l'occasion.

Étant donné que les types sont plutôt "simples", je ne pense pas à des "compléments" mais plutôt à des remplacement.
Les classes définies pour gérer le jeu sont définies une fois pour toute, mais l'ajout de paramètres à prendre en compte pour telle ou telle raison ne modifie pas la classe, d'un point de vue type,mais juste son contenu.
Ce qui permet d'utiliser les méthodes déjà créées et n'oblige qu'à en créer de nouvelles traitant uniquement les données ajoutées.
J'ai eu le problème de sauvegardes non lisibles après avoir ajouté un script, sans doute par manque de données dans la sauvegarde.
Et c'est dans ce sens que j'emploie "annule et remplace", annule la définition du contenu de la classe et la remplace par une nouvelle définition. Désolé je n'ai pas le vocabulaire pour désigner les composants d'une classe, que ces composants viennent par héritage ou directement.
Une classe n'étant qu'une structure au sens Pascal du terme, tu as le même problème si tu redéfinis ta structure en ajoutant un élément à l'intérieur.

Mais je peux me tromper. .... quoique......

Zoltic a écrit:Étant donné que les types sont plutôt "simples", je ne pense pas à des "compléments" mais plutôt à des remplacement.

Justement, j'aimerais en être sur parce si c'est pas le cas, ça a quand même des conséquences importantes.  

Zoltic a écrit:Les classes définies pour gérer le jeu sont définies une fois pour toute, mais l'ajout de paramètres à prendre en compte pour telle ou telle raison ne modifie pas la classe, d'un point de vue type,mais juste son contenu.
Ce qui permet d'utiliser les méthodes déjà créées et n'oblige qu'à en créer de nouvelles traitant uniquement les données ajoutées.

Je suis d'accord sur le fait que les classes de base restent inchangées (sauf cas extrême). Sur l'ajout de paramètre, j’entends bien aussi et ta dernière phrase aussi. Néanmoins ce qui m'a étonné, c'est de ne pas modifier directement les méthodes des classes de base (celle que tu appelle définies), pas juste ajouter. Supprimer celles inutilisées, par exemple. Ou élargir ce que l'on peut faire à ce niveau. Avec ce qu'avait dit Dricc, j'avais l'impression que les scripteurs ne travaillaient qu'avec la surcharge qui est très pratique et évite les problèmes, ça je le reconnais (c'est l'avantage de la progra objet). Et en plus comme il l'a dit, c'est la voie que les créateur de RPG maker ont proposer de suivre. Mais ils ont proposé aussi de travailler au niveau des classes de bases et de les modifier, on peut le voir avec certains fonctions et puis rien n'interdit de travailler à ce niveau (excepté la lourdeur et la complexité de la tâche^^). Travailler à ce niveau regorge de possibilités non négligeable de mon point de vue. De plus, ça peut être plus efficace de modifier le script à ce niveau et en fonction de ses attentes. Dans le sens d'une optimisation des performances du jeu en supprimant les fonctions inutiles ou autres, par exemple. M'enfin après, c'est parce j'ai interprété ce qu'à dit Dricc d'une certaine manière et peut-être qu'en fait, je ne l'ai pas compris.

(Et puis je parle, je parle mais j'ai pas encore fait mes preuves non plus. Je rêve d'optimiser le jeu pour pouvoir en mettre plein la vue au niveau des graphiques ou autre mais en attendant, côté pratique, j'ai pas trop le temps, je suis pas sur d'y arriver non plus, faut le dire ça aussi^^, et enfin, je deviens une sacré feignasse lorsqu'en j'entrevois pas tout de suite la solution, du genre excité mais qui abandonne vite   )

Zoltic a écrit:
J'ai eu le problème de sauvegardes non lisibles après avoir ajouté un script, sans doute par manque de données dans la sauvegarde.
Et c'est dans ce sens que j'emploie "annule et remplace", annule la définition du contenu de la classe et la remplace par une nouvelle définition.

D'accord ok mais ça change un peu les données du problème du coup si c'est effectivement ça. Mais le "sans doute", il est assuré ou plus ou moins assuré?

Zoltic a écrit:
Désolé je n'ai pas le vocabulaire pour désigner les composants d'une classe, que ces composants viennent par héritage ou directement.

Ne crois pas que je l'ai non plus! Je connais le phénomène, l'astuce (et encore, c'est un bien grand mot) mais après au niveau de la terminologie euh... Du moment que je le comprend pour moi, ça va   . Après quand il s'agit de communiquer, ben wikipédia est mon ami (ce que j'ai fait tout à l'heure) ou google (ou plus approfondi si c'est compliqué) ou alors je demande.


Enfin bref, ça m'a donner de bonnes réflexions et en plus, envie de retriturer dans les scripts (faut j'arrête de répondre à tes com', je devais arrêter de côté là, au moins provisoirement à cause du manque de temps, et c'est est train de me remotiver pour m'attaquer aux scripts >_< )

Aller trastouiller les routines de base pour les optimiser est certainement une grande idée, mais.... Ça oblige à, dans le désordre :
- tester TOUT ce qui existe déjà pour s'assurer de la compatibilité sous peine de rejet par la "communauté".
- modifier le système de création de nouveau projet pour mettre en place le "kernel optimisé"
- vérifier que légalement tu en as le droit. C'est une chose de faire des ajouts, c'en est une autre de modifier le système de base.
- assurer la maintenance et le S.A.V des produits durant très longtemps.

N'oublie pas qu'on parle de scripts gratuits réalisés par des passionnés qui cherchent, en partie au moins, le reconnaissance de leurs "pairs". (Je crois que c'est Zangther qui m'a dit que RME avait été très mal accueilli par la communauté anglophone au simple prétexte que c'était des français qui l'avait développé. Ce que je crois volontiers, connaissant le chauvinisme de beaucoup de personnes et pas seulement en France.)

Tu peux redéfinir tout ce que tu veux en ajoutant des surcharges, des remplacements, et autres. Mais ce serait suicidaire de vouloir toucher à la base. Et puis il y a des "routines" utiles comme la gestion physique des sauvegardes, ou l'éditeur de personnages alors autant ne pas les réécrire.

Je viens du JdR sur table, vous le savez tous, et les caractéristiques des personnages ne sont pas du tout les mêmes qu'ici. En plus des caracs "de base" comme "Force, Dextérité, Constitution, Intelligence, Sagesse, Charisme" on peut ajouter ce que l'on veut comme par exemple "Vitesse et Récupération". J'aimerai bien créer un jeu basé sur les mêmes. Mais je vais pas réécrire les routines de gestion des Noms, Surnoms, Image, etc....., là de simples surcharges suffiront, mais en ce qui concerne la gestion des combats, il me faudra TOUT réécrire et by-passer totalement les routine de calcul des coups et de leurs résultats tout en gardant les animations pour pas avoir à refaire tout.
Donc il faudra faire de tout sans, pour autant obliger les makers à abandonner leurs habitudes et leurs choix. Donc je vais être obligé de mettre à jour des caracs comme Attaque et Défense (qui pour moi dépendent de Force, Dextérité, Constitution et Classe d'Armure) pour permettre l'utilisation de ce qui existe, même si pour cela je dois les recalculer à partir de Force, Dextérité, etc...... Il y aura donc de la surcharge et du remplacement.

Pour "l'assurance" des mes déductions, j'ai pas encore les outils pour analyser plus finement, la console "debug" est très limitée et je sais pas encore écrire dedans à volonté. Mais j'ai une assez bonne intuition en ce qui concerne les causes de plantage des programmes.

Je ne sais pas si c'est une bonne ou mauvaise chose de te "remotiver", mais moi je le suis, alors faut pas m'en vouloir de réagir comme un passionné, ce que je suis.

Ya plusieurs choses a savoir :
la RGSS est une librairie créé en C++ réalisant un embeded Ruby pour en créer des classe exploitable dans le projet. Tel que Sprite, bitmap, Window, etc... C'est ce qui est chargé en premier. Et il est tout a fait possible d'en modifier le comportement par un script. Et ceux-ci ce placeront au début des ajouts, voir même pour faire simple au début de la liste si il ne surcharge pas des classes crée plus tard.

Si tu regardes, le fichier d'aide, seuls les classes du RGSS sont décrites. Un script peut donc soit :
- créer un nouvelle classe n'ayant que pour dépendance le RGSS, tu peux le mettre n'importe où.
- créer une nouvelle classe ou modifier une classe existante en héritant ou surchargeant une autre classe, il faut le mettre au dessus de tout ce qui est nécessaire a la définition des nouvelle méthode. Et ça seul le développeur du script peut le savoir.

Pas tellement Zoltic^^

Avec ce que viens de dire tonyryu, maintenant, j'en suis sur. J'avais vu un fou-furieux qui s'était même attaqué à l'interface C++/ruby mais sur le RGSS (donc XP, du coup) sur un forum anglais si je me rappelle. Donc là, moi à côté, je passe un bisounours. Et il avait réussi apparament!! (j'essayerai de le retrouver à l'occas)

Donc évidemment, après c'est beaucoup plus dur et risqué mais pas impossible. Et puis, c'est une gestion du temps aussi et une mesure de ces capacité. Moi, je suis capable de comprendre (enfin jusqu'à un certain point, la classe game_interpreteur, elle m'a tué par exemple) mais je pourrais pas le faire actuellement, pas le temps et il faut que je finisse mon master pour avoir un boulot^^. C'est comme pour les graphismes, passe 10 mois à t'entrainer sur du pixel art et tu pourra pt faire quelque chose de correct (je précise que je ne crois pas au talent, les circonstances et les avantages oui, mais le talent inné non, excepté pour certains truc bien précis comme une bonne oreille dès la naissance pour les musiciens, gros avantage mais pour le cerveau, la plupart des études montre qu'à part l'environnement de naissance, il y a pas grand chose d'autre qui joue).

Ah et sinon, en ce qui concerne ton intuition, ouais j'ai capté un peu ton fonctionnement et je ne doute pas de ça. J'avais (j'ai toujours d'ailleurs) des potes informaticiens qui arrivaient à trouver des solutions avec leurs intuition de manière beaucoup plus efficace que moi et plus rapidement surtout, je servais à rien dans ces cas là^^. Néanmoins, au niveau de la théorie et de la compréhension des languages et tout le bazar, il y en a aucun qui m'arrivais à la cheville alors qu'ils arrivaient à trouver des solutions sans comprendre vraiment d'où ça venait (ça m'a tuer ça, pour un théoricien, c'est vraiment la mort T_T). Bref, c'est un peu comme mon histoire de game design au niveau de la répartition des taches, j'ai pu travailler avec ces potes parce que je pouvais "orienter" leurs intuitions grâce à ma compréhension des théories et eux, ben trouver, les solutions effectives. Pour reprendre une phrase connu: "La théorie sans pratique est inutile, la pratique sans théorie est dangereuse", même si là il faudrait dire hasardeuse^^.

Ah et pour la question de me "remotiver", c'est moi qui cherche, ne change pas^^

Oye et thanks pour ces info Tonyryu. Mais du coup, au niveau du materials, c'est juste que c'est chargé en dernier du coup? Et quand tu dis surcharge en ruby, tu pense à quoi? (je demande pour repérer quelle type de surcharge est utilisé parce que je suis un peu perdu avec les termes des autres langages)

PS: Zoltic, si je me souviens, la seule chose à laquelle on n'a pas le droit de toucher sur RPG maker, c'est le logiciel. Et en pratique, lorsque tu modifie les scripts, tu ne peut modifier que le système de ton jeu, pas le logiciel.

PPS: je pensais aussi à une modification jeux par jeux, si il y a avait des schémas complet du fonctionnement des RPG maker, ça pourrais aller bien plus vite et ça serait possible à mon avis.

Shamugan a écrit:j'en suis sur. J'avais vu un fou-furieux qui s'était même attaqué à l'interface C++/ruby mais sur le RGSS

Je dois avoir encore le code source sur mon serveur, je m'étais arrêté à la classe Table, Bitmap et Audio. Je m'y remettrai bien pour la version VxAce si j'avais un peu plus de temps. Avec la nouvelle version de la librairie SFML, ya moyen d'aller vite.

Quant ont parle de surcharge en langage Ruby c'est un ENORME abus de langage, car on ne peut pas faire de surcharge (polymorphysme) tel qu'on peut le trouver sur des langages comme le C++. Il faut plutot dire redéfinition avec alias :

Code:

# Premiére définition
class Voiture
  def demarrer
    print "Démarrage de la voiture \n"
  end
end

# Nouvelle définition avec modification de la méthode demarrer
class Voiture
  alias old_demarrer demarrer
  def demarrer
    old_demarrer
    print "Avec plein de bruit en plus \n"
  end
end

maCaisse = Voiture.new
maCaisse.demarrer

ce qui va donner :

Code:

Démarrage de la voiture
Avec plein de bruit en plus

Et là, il devient évident que si l'on redéfinit avec alias une méthode déjà existante, l'ordre des redéfinitions peut avoir un impacte. Exemple :

Code:

# Premiére définition
class Calcul
  def tester
    return 15
  end
end

# Nouvelle définition avec modification de la méthode tester
class Calcul
  alias old_tester_A tester
  def tester
    valeur = old_tester_A
    return (valeur + 20)
  end
end

# Nouvelle définition avec modification de la méthode tester
class Calcul
  alias old_tester_B tester
  def tester
    valeur = old_tester_B
    return (valeur * 3)
  end
end

monCalcul = Calcul.new
print monCalcul.tester

et ça

Code:

# Premiére définition
class Calcul
  def tester
    return 15
  end
end

# Nouvelle définition avec modification de la méthode tester
class Calcul
  alias old_tester_B tester
  def tester
    valeur = old_tester_B
    return (valeur * 3)
  end
end

# Nouvelle définition avec modification de la méthode tester
class Calcul
  alias old_tester_A tester
  def tester
    valeur = old_tester_A
    return (valeur + 20)
  end
end

monCalcul = Calcul.new
print monCalcul.tester

Ne donnera pas le même résultat.


En ce qui concerne la modification du programme interne, non nous n'avons pas le droit. Je le sais très bien, car j'en avais demandé l'autorisation à Enterbrain pour virer l'interruption de l'interpreteur ruby en cas de perte de Focus. Ils m'ont répondu assez rapidement et de manière très cordiale, que je n'en avait pas le droit, et que ce n'était pas nécessaire au fonctionnement normal des projet. Sauf que moi, cette foutu pause et bien ça me faisait planté mon socket ouvert dans lequel venait s'empiler les trames réseau en attente jusqu'à explosion du buffer. Donc j'ai tenté de le décompiler avec succès et de le lancer en debug. Le code avait un système de protection qui ne le permettait pas. => Abandon de mon projet Online Azaruss

Ok, ouais, c'est encore différent de ce que je m'imaginais pour le coup^^. Thanks pour les explications, c'est assez important à savoir ça en plus.

Le programme interne? C'est-à-dire? À quelle niveau, on n'a plus le droit? Au niveau de tout ce qui apparaît dans le logiciel (ace par exemple), dans l'éditeur de script, on a le droit, non? C'est au niveau du dll qu'on a pas vraiment le droit non? J'avais essayé de fouiller dedans mais c'était galère et j'avais vu aussi que pour le RGSS3 c'était plus possible de bidouiller alors qu'avant pour les précédentes versions oui (et il y avait pas de sécurité aussi, je crois mais à vérifier)

Le programme interne est le Game.exe et la librairie RGSS, c'est là dedans que j'ai voulu taper.

L'éditeur fonctionne bien et n'as pas forcément besoin d'être modifié.

Les scripts ruby fourni dans un nouveau projet sont totalement libre de droit. On peut en faire ce que l'on veut.

Ok, du coup, c'est ce que j'avais à peu près compris. Thanks pour la réponse

Du coup on a quand même une relative bonne marge. Enfin, pour moi, vu que je pense pas aller jusqu'à modifier le programme interne. Et ça pose quoi comme type de limite de pas pouvoir toucher au programme interne si il y a une réponse simple? (et pas avec trop de termes techniques si possible parce j'ai beau être bon en informatique théorique, en informatique "pratique" je suis un peu un complet galérien )

Dans mes grandes heures sur VxAce, je voulais absolument réaliser un jeu online. Pour cela on utilise Win32api pour utiliser des dlls windows. hors un socket quant il est ouvert doit être lut en permanence pour ne pas laisser s'acumuler des donnés dedans. Hors le programme interne de rpgmaker met en pause l'interpreteur ruby quant on passe sur une autre fenêtre windows. Sauf que dans ce cas le socket n'est pas lu risquant un dépassement de l'espace mémoire réservé au fonctionnement de celui-ci. Ce qui provoque sa déconnexion. Et cette limite est clairement bloquante pour moi. C'est surtout pour cette raison que je me suis tourné vers la version MV.

On s'éloigne un peu du sujet de base.

Wooups, j'arrête, merci pour la réponse et désolé Zoltic

Shamugan : Pas de soucis, à partir du moment où j'ai eu une réponse et que c'est pas pour polémiquer, pas de problème avec moi.
J'aime juste pas mélanger les carottes et les barils de pétrole surtout quand je demande de ne pas le faire. Mais là, c'est des pommes de terres, ça reste des légumes. A la limite les infos produites ici sont utiles pour comprendre l'articulation des routines et donc la place de chaque routine. Ce qui n'est pas très éloigné de la réponse à la question première.

Tonyryu : Tu serais pas enseignant sur les bords ? Je suis descendant de 7 générations d'enseignants, y'a des signes que je sais reconnaître.
Si c'est le cas, tu pourrais pas trouver un peu de temps pour développer un schéma des routines et de leurs imbrications et, à la limite, publier quelques "trucs" utiles pour apprendre ?.
Comme me disait mon patron :
"A temps perdu, tu feras......
Non, quand tu auras du temps à perdre, tu le perdras et à temps perdu, tu feras......"