Int�gration de scripts lua

Version imprimable

Bonjour,
Je travaille actuellement sur un petit projet pour tester diff�rentes mani�res de rendre un programme plus modulaire : plugins, scripts, �
Le programme en lui-m�me est plut�t simple : il s'agit d'un jeu de cartes (dans le style des cartes Magic). Chaque carte peut �tre soit une cr�ature, soit un sort. Si c'est un sort, elle dispose d'une seule action (le sort en question). Si c'est une cr�ature, elle dispose de plusieurs (mais le nombre est d�fini). De plus, chaque carte dispose de certaines propri�t�s communes telles que le nom, description, niveau, �

Je cherche donc � impl�menter chaque carte sous forme de plugins, scripts en diff�rents langages, � afin d'avoir quelque chose le plus modulaire possible. Voil� ma classe Carte, toute simple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 class Carte { public: enum Type { Creature, Sort, Indefini, }; Carte(); virtual ~Carte(); virtual void debutTour(); virtual void invocation(); virtual void mort(); virtual int niveau() const; virtual int pv() const; virtual int pvMax() const; virtual std::string nom() const; private: int m_niveau; int m_pv; int m_pvMax; Type m_type; std::string m_nom; Joueur* m_prop; Joueur* m_adversaire; };
Chaque m�thode est d�finie vide dans le cpp, sauf les accesseurs, toutes les cartes n'ayant pas besoin de r�impl�menter chacune des actions. Ces m�thodes sont appel�es automatiquement par le reste du programme.

J'ai commenc� deux �chargeurs� de cartes : un sous la forme de plugins (en C++), qui avance bien et ne me pose pas de probl�me particulier. Le second consiste � charger un script lua d�finissant une carte. Dans un premier temps, je cherche � simplement d�finir les propri�t�s �basiques�, et non les actions. J'�tais parti sur l'exemple pr�sent� ici. J'arrive � faire dans un script lua une classe qui d�rive de Carte, et y appeler des m�thodes� Mais c'est l� que je me rends compte d'un gros soucis sur mon raisonnement : je n'ai aucun moyen de r�cup�rer cette carte dans mon code C++ (du moins, je n'en ai pas trouv�).

Et l�, je s�che� Je ne vois pas comment d�finir une classe en lua, qui contienne les m�mes propri�t�s qu'une classe C++, et la r�cup�rer en C++.

Si quelqu'un � la moindre piste, je suis preneur !
Merci.

28/08/2010, 10h22
Joel F

Une bonne mani�re de faire est d'avoir dans ton LUA des *fonctions* qui correspondent aux m�thodes de ton instance car bind� une LUA function est assez triviale

Chaque instance de ta classe C++ est construite en chargant un LUA qui contient une fonction par m�thode de la classe.

Bonjour,
Suite � quelques petits soucis de connexion internet, j'ai pas vraiment pu mettre ce topic � jour� Chose que je vais corriger tout de suite.
D�j�, Joel F, merci de ta r�ponse ;) Cependant, je n'ai pas pu la voir, et j'ai continu� le d�veloppement � c�t�, je suis parti sur une autre piste.
Avec luabind, j'ai r�ussi � instancier en lua une classe qui h�rite de ma classe Carte, et � r�cup�rer une instance, sous la forme de Carte*, en C++. Tout le code de cette partie est accessible ici. Mon code marche parfaitement pour une ou deux cartes� Jusqu'� 7, en fait. Mais d�s que je charge une 8� carte, l'appel � luaL_dofile me fait une jolie erreur de segmentation.

Voici la structure d'une carte :
Code:

1 2 3 4 5 6 7 8 9 10 11 class 'ForestSpirit' (carte) function ForestSpirit:__init() carte.__init(self) end function ForestSpirit:test() print('ForestSpirit:test()') end a = ForestSpirit()
Et la callstack :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #0 0x0000000000000051 in ?? () #1 0x00007ffff69c5997 in std::auto_ptr<LuaWrapper>::~auto_ptr() () from ./libCore.so #2 0x00007ffff69c5b7b in luabind::detail::pointer_holder<std::auto_ptr<LuaWrapper>, LuaWrapper>::~pointer_holder() () from ./libCore.so #3 0x00007ffff5d09561 in luabind::detail::object_rep::~object_rep() () from /usr/lib/libluabind.so.0.9.0 #4 0x00007ffff5d09602 in luabind::detail::destroy_instance(lua_State*) () from /usr/lib/libluabind.so.0.9.0 #5 0x00007ffff5f1dff1 in luaD_precall () from /usr/lib/liblua.so.5 #6 0x00007ffff5f1e473 in luaD_call () from /usr/lib/liblua.so.5 #7 0x00007ffff5f1fc4e in GCTM () from /usr/lib/liblua.so.5 #8 0x00007ffff5f1fd5c in singlestep () from /usr/lib/liblua.so.5 #9 0x00007ffff5f20290 in luaC_step () from /usr/lib/liblua.so.5 #10 0x00007ffff5f1d854 in f_parser () from /usr/lib/liblua.so.5 #11 0x00007ffff5f1db77 in luaD_rawrunprotected () from /usr/lib/liblua.so.5 #12 0x00007ffff5f1dbde in luaD_pcall () from /usr/lib/liblua.so.5 #13 0x00007ffff5f1dca2 in luaD_protectedparser () from /usr/lib/liblua.so.5 #14 0x00007ffff5f19798 in lua_load () from /usr/lib/liblua.so.5 #15 0x00007ffff5f2982d in luaL_loadfile () from /usr/lib/liblua.so.5 #16 0x00007ffff69bc8e0 in ChargeurLua::instancierCarte(std::string const&) () from ./libCore.so
Petite pr�cision : LuaWrapper est une classe h�ritant de Carte qui me permet de faire l'interface entre une classe lua et du code C++, c'est ce que je r�cup�re via luabind.

J'ai essay� avec plusieurs cartes diff�rentes, dans un ordre diff�rent, il plante toujours sur la 8�.
En mettant un print('test') au d�but de chaque fichier lua charg�, il est affich� sur les 7 premiers, mais pas du tout sur le 8�.
Il y a quelque chose � faire de particulier avec lua pour lui faire r�server plus de m�moire ou autre ? �a fait plusieurs jours que je cherche dans la doc' et autres, je s�che�

01/09/2010, 16h56
vikki

Hello,
J'avais eu la m�me id�e que toi � une �poque (jeu de Magic) mais j'avais directement commenc� par la partie graphique bien violente pour me former � OpenGl :aie:
Pour le langage de script, il est �galement tr�s facile d'interfacer Python et C++ avec boost.python. Je m'en sert dans mon boulot et ce n'est vraiment que du bonheur. Le m�lange Python/C++ via boost.python est d�j� utilis� dans l'industrie du jeu vid�o notamment dans Civilisation 4 et 5 (donc pas n'importe quoi).
01/09/2010, 17h02
Kernald

J'ai aussi song� � de l'OpenGL pour la partie graphique, mais j'ai finalement opt� pour une autre approche : je d�veloppe pour le moment une librairie qui ne d�pend de rien de graphique, et une petite interface graphique avec Qt pour tester �a rapidement, l'interface est loin d'�tre d�finitive, je connais juste plut�t bien Qt, donc j'en profite. Au moins, cel� me permet de me concentrer sur le jeu en lui m�me� Et mes probl�mes de lua :)

J'avais remarqu� Boost.python oui, mais ce dernier attendra que je puisse charger une carte lua. En attendant, j'ai termin� le chargement de cartes sous la forme de plugins C++. J'ai pas test� les plugins statiques, mais les plugins dynamiques marchent comme sur des roulettes. C'est surtout ce probl�me de lua qui m'emb�te�

(Si l'id�e du projet t'int�resse toujours, on peut en parler en mp pour une interface en OpenGL ;))
01/09/2010, 17h18
vikki

Citation:

(Si l'id�e du projet t'int�resse toujours, on peut en parler en mp pour une interface en OpenGL )

Arf, j'ai abandonn� le projet il y a fort (fort) longtemps. Surtout que j'ai plus du tout le temps pour l'instant.

Citation:

J'avais remarqu� Boost.python oui, mais ce dernier attendra que je puisse charger une carte lua. En attendant, j'ai termin� le chargement de cartes sous la forme de plugins C++. J'ai pas test� les plugins statiques, mais les plugins dynamiques marchent comme sur des roulettes. C'est surtout ce probl�me de lua qui m'emb�te�

�a semble planter � std::auto_ptr<LuaWrapper>::~auto_ptr(), donc surement sur un delete appel� sur un pointeur non initialis� ou d�j� d�sallou�. �a doit d�pendre de la mani�re dont tu manipule tes Carte*. Ou alors les Carte* stock�es sont trop grosses et le 8�me appel � new l�ve une exception que tu n'attrape pas (ou un malloc qui retourne NULL). Bref je connais pas Lua donc...:aie:

Je commence par g�n�rer une liste de cartes valides :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void ChargeurLua::genererListeCartes() {
    std::vector<std::string> fichiersLua;
    boost::filesystem::path chemin = boost::filesystem::initial_path() / "lua";
    iterDir(chemin, fichiersLua);
 
    for (std::vector<std::string>::const_iterator it = fichiersLua.begin(); it != fichiersLua.end(); ++it) {
        Carte* carte = instancierCarte(*it);
        if (carte) {
            m_nom2lua.insert(std::pair<std::string, std::string>(carte->nom(), *it));
            delete carte;
        }
    }
    std::cout << "génération ok" << std::endl;
}

fichiersLua contenant donc la liste de tous les fichiers portant l'extension .lua.

La m�thode instancierCarte est la suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Carte* ChargeurLua::instancierCarte(const std::string& pLua) {
    std::cout << "pLua : " << pLua << std::endl;
    bool s = luaL_dofile(m_ls, pLua.c_str());
 
    if (s != 0) {
        std::cout << "s : " << s << std::endl;
        erreursLua(s);
        return NULL;
    } else {
        Carte* carte = luabind::object_cast<Carte*>(luabind::globals(m_ls)["a"]);
        std::cout << "carte retournée : " << carte << std::endl;
        return carte;
    }
}

Et donc, l� dedans, �a plante � l'appel � luaL_dofile� Je suppose donc qu'il y a effectivement un probl�me de m�moire, mais o� ? Je ne sais pas.

01/09/2010, 17h50
vikki

D�j�: es-tu s�r que la 8 �me carte soit valide? un appel � 'object_cast<MaClasse*>' peut renvoyer un pointeur invalide dans certains cas et attention au delete derri�re...
Concernant ce delete justement, je suis pas certain qu'il soit n�cessaire. Le pointeur renvoy� par 'object_cast<MaClasse*>' r�f�rence un objet qui a �t� cr�� et qui sera d�truit par luabind (enfin, si ca ressemble � boost.python, ce qui semble �tre le cas), mais � v�rifier.
01/09/2010, 17h52
Kernald

Effectivement, c'est le delete qui ne lui plaisait pas� Je vais voir plus en d�tail pourquoi ;) Merci !

Edit: �a me pose un probl�me en fait� L'objet n'est valide que peu de temps. Je vais voir si il n'y a pas un autre moyen de r�cup�rer l'objet, sinon j'en ferais une copie.
12/09/2010, 16h58
pierreyoda

Bonjour,

d�j�, de ma propre exp�rience : il faut encandrer *TOUS* les appels � Lua de blocs try/catch :aie:
(donc ici le "luaL_doFile" et les "object_cast" de globals) :ccool:

PS : Je ne connaissais pas l'op�rateur "/" pour boost::path, merci bien :mouarf:
13/09/2010, 23h05
vikki

Citation:

d�j�, de ma propre exp�rience : il faut encandrer *TOUS* les appels � Lua de blocs try/catch
(donc ici le "luaL_doFile" et les "object_cast" de globals)

�a ressemble vraiment � boost.python...:aie: