Lua. Как прочесть значение переменной из конфига.
можно сделать сам конфиг Lua сценарием и при загрузке просто выполнить его. То же самое можно применить и к сейвам. Все равно в таких файлах выполняются присваивания переменным строковых и численных значений.
LIVe А можно по подробней? Желательно с кодом.
Pa3DBaKp9IK Погугли LuaBind. Там примеры есть и документация, вроде все понятно. Писал с помощью нее такую штуку, сейчас под рукой к сожалению нет исходников.
----------------- В ++ коде есть вот такой вот класс конфига
----------------------- И вот такой вот файл генерации userType в lua (посуте это тодже h)
И все . в lua есть доступ к конфигу . ну разве что надо вызвать конструктор конфига .. после вызова которого конфиг будет инициализирован скриптом (И ВСЕ. )
юзаю я tolua++ . luabind не советую .
------------------- когда много объектов и много скриптов добавить новые классы в луа с помощью luabind настоящяя морока . и самое неудобное что проект собирается слишком долго . с tolua++ все намного проще и понятней ..
nstd приведи пожалуйста пример использования tolua++ к примеру для такого класса
и простейший скрипт который меняет данные. с C++ кодом который это все связывает. спасибо заранее.
Ок . ну вопервых этот класс опишем в файле test.h .
в принципе тут конструктор и деструктор не нужны . но лучше их написать . далее создаем специальный файл . назовем его *.pkg .
Фактически это тод-же хидер . тока тут что хотим то и указываем лишнее удаляем . (конструктор необходим если ходим дать возможность в скриптах создавать такой юзер тайп . ) . деструктор в принципе не обязателен .. т.к. в луа динамическое распределение памяти и объект он когданибудь сам уничтожит (хотя советую всетаки их описывать)
далее tolua++ это с одной стороны либа . с другой стороны это тулза которая генерит Сишник .. Собственно пекедж надо скормить ей чтобы она сгенерила код связки .. tolua.exe -o test.cpp -n TEST test.pkg
получается вот такой вот файл
test.cpp (его мы руками не пишем . все генерит тузла .. соответственно при каждом исправлении надо его перегенерять. Генерятся они очень быстро, хотя генерить при каждой сборки ен советую (каждой сборки проекта . не факт что какието его измения затронут интерфейса предоставляемого луа скриптам). )
Далее компилируете проект + ^^^ описанный выше Сишник ..
В момент инициализации lua вызываете функцию tolua_TEST_open
В скрипте test.lua можете как угодно юзать этот usertype
например вот так
local ob = GameObject(); ob.curState = 1; ob.isEmpty = false;
nstd Спасибо. ну что-то сильно много по сравнению с luabind
Генерится кода . в luabind код генерится компилятором по шаблонам . а тут он генерится тулзой .. все остальные затраты примерно одинаковые (разве что в luabind синтаксис далекий от хидеров) .
но это ровным счетом ничего не меняет .. ты размер *.obj посмотри ^^^ этого и luabind . и поймешь что luabind генерит кода гораздо больше . я когда переходил с luabind на tolua++ у меня разер либы уменьшился на 10Мб . при этом реально объектов там было забиндино одинаковое количество .
Да есть свои минусы . 1. нету множественного наследования (но можно обойти ))) . 1. объявить в пекаджах функции базового класса . 2. в скриптах юзать toloa.cast . приведение к другому типу . интересует более подробно могу написать пример . ) 2. при добавлении нового класса/функции/переменной нужно перегенерять связующий файл (VeraLocationEditorBind.cpp) . можно сделать скрипт запускающий ся перед компиляцией и проверяющий были ли изменения в пакеджах . если были то перегенерить файл если нет . то нет (у меня просто батник который я руками запускаю . меня устраивает . )
Плюсы . 1. Все генерится очень быстро (даже все классы CEGUI генерятся за пару секунд . попробуйте забиндить cegui luabind и вы получите такой гемор ))) который вам и не снился . проект будет компилироваться 2 часа ))) . кто пытался биндить luabind 20-40 классов тот меня поймет ))) . ) 2. маленький размер либы . прозрачный код, никаких шаблонов и малопонятного кода (один тока синтаксис биндов luabind . с точки зрения синтаксиса С++ это ахтунг ))) ) . . 3. гибкость намного больше . к примеру я не мог в luabind описать массив int b[10]; . приходилось писать обертки . в tolua можно, в tolua иногда приходится хитрить, но ++ кода и оберток писать не надо . 4. в luabind нельзя описать классы с приват конструктором . в случае когда ты биндиш чужую либу иногда приходится (я биндил PhysX). в toloa++ описываешь тока паблик методы . если нету конструктора в скриптах не сможет создать такой класс (но сможешь получить по средствам вызова метода другова класса World::createNode() ) 5. У меня не получилось в луа бинд биндить статик методы классов (getSingleton) в tolua легко и просто .
п.с. по пооду luabind может все и можно както сделать . может я просто плохо в нем разобрался ))) . но для меня однозначно tolua .
nstd при большом количестве экспортируемых данных луабинд существенно замедляет время линковки + сами файлы экспорта медленно компилируются + размер исполняемого модуля сильно раздувается (приходится для файлов экспорта ставить оптимизацию на размер, а не скорость)
Я вот просмотрел мануал tolua++ - на большинство вопросов ответов там не нашёл (либо плохо искал :)
nstd да + есть, но что не удобно что отдельно файлы нужно таскать для связки классов. luabind все в несколько строк подключает
у меня файлы *.pkg в проекте VC их я из VC и редактирую ..
+ у меня в быстром запуске(около пуска) ссылка на *.bat файл . в gen.bat файле вот такая вот команда .. tolua.exe -o ..\..\..\Vera\src\bind\VeraBind.cpp -n VeraBind ..\..\..\Vera\package\Vera\Vera.pkg
..\..\..\Vera\src\bind\VeraBind.cpp этот файл у меня тоже в проекте .
поэтому вся работа сводится к добавлению новых методов классов в Vera.pkg запуску gen.bat и нажатию F5 ))) .
В сравнении с LuaBind это 1 лишний клик вышки ))) . при этому значительное ускорение компилирования и гораздо больше гибкости .
Фактически можно написать какой нить скрипт в котором проверять обновились ли *.pkg и если обновились перегенерить код .. вставить заупск такого скрипта в VC и вопще ничем от Luabind отличаться не будет в плане удобности использования . тока мне это делать в лом . меня устраивает батник
nstd > при этому значительное ускорение компилирования и гораздо больше гибкости насчёт скорости компиляции и линковки - согласен а насчёт гибкости - а в чём tolua++ более гибкий по отношению к luabind-у?
p.s. если нетрудно, ответьте на вопросы поста №10, потому как для корректного сравнивания библиотек надо знать их функциональные возможности
Дмитрий Ясенев
# можно ли в скрипте породиться от класса, проэкспортированного с помощью tolua++? tolua++ таких возможностей не дает (если не ошибаюсь . ) # перегрузить его виртуальные функции? средствами tolua нет . (если не ошибаюсь . ) # поддерживается ли множественное наследование (и виртуальное) как для экспортируемых классов, так и для классов, определяемых в скриптах?
tolua++ (starting from version 1.0.4) supports multiple inheritance by allowing you to access the extra parents 'manually'.
For example, consider the following class:
class Slider : public Widget, public Range < . >;
An object of type 'Slider' will fully retain its inheritance with Widget, and will contain a 'member' of type Range, which will return the object cast to the correct base type.
slider = Slider:new() slider:show() -- a Widget method
slider:set_range(0, 100) -- this won't work, because -- set_range is a method from Range
slider.__Range__:set_range(0, 100) -- this is the correct way
This is an experimental feature.
Я же предпочитаю переносить некоторые функции в производный класс . чем описывать множественное наследование . # как реализована передача владения объектом?
если чесно точно не знаю ))) . у меня объекты либо принадлежат скриптам, либо ядру . И возможности создать объект в скриптах и поместить его в ядро нету . в скриптах я создаю дескрипторы передаю их в ядро и ядро создает нужные объекты .. которыми в дальнейшем управляю из скриптов .
GameObject* self = (GameObject*) tolua_tousertype(tolua_S,1,0);
TOLUA_API void* tolua_tousertype (lua_State* L, int narg, void* def) < if (lua_gettop(L)<abs(narg)) return def; else < void* u; if (!lua_isuserdata(L, narg)) < if (!push_table_instance(L, narg)) return NULL; >; u = lua_touserdata(L,narg); return (u==NULL) ? NULL : *((void**)u); /* nil represents NULL */ > >
TOLUA_API void tolua_pushusertype (lua_State* L, void* value, const char* type) < if (value == NULL) lua_pushnil(L); else < luaL_getmetatable(L, type); lua_pushstring(L,"tolua_ubox"); lua_rawget(L,-2); /* stack: mt ubox */ if (lua_isnil(L, -1)) < lua_pop(L, 1); lua_pushstring(L, "tolua_ubox"); lua_rawget(L, LUA_REGISTRYINDEX); >; lua_pushlightuserdata(L,value); lua_rawget(L,-2); /* stack: mt ubox ubox */ if (lua_isnil(L,-1)) < lua_pop(L,1); /* stack: mt ubox */ lua_pushlightuserdata(L,value); *(void**)lua_newuserdata(L,sizeof(void *)) = value; /* stack: mt ubox u newud */ lua_pushvalue(L,-1); /* stack: mt ubox u newud newud */ lua_insert(L,-4); /* stack: mt newud ubox u newud */ lua_rawset(L,-3); /* stack: mt newud ubox */ lua_pop(L,1); /* stack: mt newud */ /*luaL_getmetatable(L,type);*/ lua_pushvalue(L, -2); /* stack: mt newud mt */ lua_setmetatable(L,-2); /* stack: mt newud */
#ifdef LUA_VERSION_NUM lua_pushvalue(L, TOLUA_NOPEER); lua_setfenv(L, -2); #endif > else < /* check the need of updating the metatable to a more specialized class */ lua_insert(L,-2); /* stack: mt ubox ubox */ lua_pop(L,1); /* stack: mt ubox */ lua_pushstring(L,"tolua_super"); lua_rawget(L,LUA_REGISTRYINDEX); /* stack: mt ubox super */ lua_getmetatable(L,-2); /* stack: mt ubox super mt */ lua_rawget(L,-2); /* stack: mt ubox super super[mt] */ if (lua_istable(L,-1)) < lua_pushstring(L,type); /* stack: mt ubox super super[mt] type */ lua_rawget(L,-2); /* stack: mt ubox super super[mt] flag */ if (lua_toboolean(L,-1) == 1) /* if true */ < lua_pop(L,3); /* mt ubox*/ lua_remove(L, -2); return; > > /* type represents a more specilized type */ /*luaL_getmetatable(L,type); // stack: mt ubox super super[mt] flag mt */ lua_pushvalue(L, -5); /* stack: mt ubox super super[mt] flag mt */ lua_setmetatable(L,-5); /* stack: mt ubox super super[mt] flag */ lua_pop(L,3); /* stack: mt ubox */ > lua_remove(L, -2); /* stack: ubox*/ > >
# как экспортируются функции с референсами? в том числе на базовые типы (число)? С чем ))) . # можно ли проитерироваться по всем проэкспортированным классам/функциям? Опять же незнакомый термин ..( привести базовый класс к производному можно . хотя думаю это не то) # не было ли случаев, когда сгенерированный файл не компилится (например, по причине переполнения внутренних буферов компилятора)? если были, то что делать в таких случаях? небыло .. Скажем так . для разных либ я создаю разные пакеты . по то корым генерятся *.cpp . фактически у меня 4 файлы один из которых биндит
70 классов и 1000 функций размер файлы полтора мега .
ну в общем вот так . tolua.exe -o ..\..\..\Vera\src\bind\VeraCEGUIBind.cpp -n VeraCEGUI ..\..\..\Vera\package\CEGUI\CEGUI.pkg tolua.exe -o ..\..\..\Vera\src\bind\VeraBind.cpp -n VeraBind ..\..\..\Vera\package\Vera\Vera.pkg tolua.exe -o ..\..\..\Vera\src\bind\VeraBindPhysX.cpp -n VeraBindPhysX ..\..\..\Vera\package\PhysX\PhysX.pkg
L = lua_open(); luaL_openlibs (L);
tolua_VeraBind_open(L); tolua_VeraBindPhysX_open(L); tolua_VeraCEGUI_open(L); # есть ли поддержка комментариев экпортируемых методов/классов? если имеется ввиду наличие комментариев в *.pkg то да .. OgreBasic.pkg .
typedef float Real; typedef std::string _StringBase; typedef _StringBase String; typedef std::vector<String> StringVector;
Vector3(Real x, Real y, Real z); Vector3 operator - ( const Vector3& rkVector ) const; >;
# можно ли проэкспортировать функцию не член С++ класса, как член скриптового класса?
Вроде да (у меня когдато не получилось . ))) . после этого я не пытался) .
Using Regular functions as class methods
tolua++ (starting from version 1.0.5) uses the keyword tolua_outside to specify regular functions as methods and static methods of a class or struct. For example:
int x; int y; > Position;
Position* position_create(); void position_set(Position* pos, int x, int y);
static tolua_outside Position* position_create @ create(); tolua_outside void position_set @ set(int x, int y); >;
local pos = Position:create()
Note that the position_set method takes a pointer to Position as its first parameter, this is ommited on the tolua_outside declaration. Also note that we cannot name our methods new or new_local, or as overloaded operators (see next section), this will result in undefined behaviour.
Я вот просмотрел мануал tolua++ - на большинство вопросов ответов там не нашёл (либо плохо искал :)
ну вобщем я имел ввиду - гибкость при бинденге ++ классов в Lua(фактически забиндеть можно что угодно, в luabind мне приходилось писать обертки . другое дело, что иногда приходится химичить в пакете. описывая функции которых в классе нету ) . при этом возможности lua библиотека tolua почти не расширяет.