mildred wrote:
En fait, c'est simple: je cherche la correspondance d'un concept que j'au connu avec UnrealEngine (WheelOfTime): les zones.
Il suffisait d'ajouter un objet virtuel qu'on apelle "zone" dans un espace fermé pour que les paramètres de cette zone soient déployés sur toute la zone ... Par exemple, on ajoutait un WaterZone dans un trou au sol. Entre le trou et au dessus, on mettait un plan qui représente la surface de leau et lorsque le personnage entre dans l'eau: il passe en mode nage (il y a aussi un petit bruit deau lorsqu'on entre dans l'eau ...)
Raydium est bien plus généraliste que ça
Il ne prendra pas la responsabilité de jouer un son à ta place, par exemple.
Par contre, rien ne t'empêche de coder toi même ces comportements, avec toutes les nuances que tu souhaites. Une des idées possibles, par exemple, serait d'utiliser une geom statique (boite, probablement) et de surveiller les collisions entre ton/tes perso(s) et cette boite. A toi de programmer le comportement dans l'eau, aussi (probablement avec, entre autre, une gravité de zero, par exemple).
mildred wrote:
A mon avis, ce serait intéressant de mettre la documentation dans les sources pour la simple et bonne raison que ce serait plus facile de créer cette documentation. Lorsqu'on crée une nouvelle fonction par exemple on peut directement ajouter la documentation (rien que dire quels sont les paramètres en entrée, ce que la fonction retourne et ce quelle fait).
C'est plus simple que d'aller voir sur le wiki en même temps et de mettre la doc de la fonction créée.
J'avais aussi pensé à autre chose mais j'ai oublié.
J'utilise assez régulièrement Doxygen au boulot, et franchement je ne suis pas convaincu de l'intérêt pour Raydium.
D'un, la sortie est très basique, confuse, le code source est surchargé de \fn, \param qui rallongent d'autant le code source, et on se retrouve à maintenir deux choses différentes au même endroit.
Ensuite, en pratique, on code son algo et/ou son bloc de 10 fonctions (parce qu'on a la tête dedans), et on revient seulement après pour documenter (note : j'ai bien parlé de documentation, pas de commentaires).
Pourquoi ne pas plutot se rendre sur le Wiki, autrement plus convivial à la saisie et surtout à la lecture, pour réaliser cette tâche ? documentation toujours à jour, pour tout le monde.
Ce que j'essaye de dire, ça n'est pas que ces systèmes ne sont pas intéressants (au contraire, et sinon je ne m'en servirait pas pour mes dev
), mais plutôt qu'il ne sont pas forcéments si adaptés que ça pour produire une doc destinée à un utilisateur "final" de l'API, mais plus (à mon avis) pour produire de l'information à destination des autres développeurs du projet.
En résumé je ne sais pas ... peut être même que les deux solutions sont complémentaires.
mildred wrote:
Oui, c'est bien (merci, conaissait pas). Mais en fait, ce qui me gêne le plus c'est que dans une fonction il n'y a pas moyen de connaître quel est le fichier et la ligne qui a appelé la fonction. Ce serait très pratique pour soulever des erreurs (trigger_error).
Même si je n'ai jamais essayé, APD doit être capable de d'envoyer toutes ces infos au travers de apd_callstack().
Mais rien ne t'empêche d'implémenter un module Python, encore une fois