Roland

What does your build log say? Any more clues but just that sentence.

Thats strange 1. Is LeadwerksHeaderPath really pointing to the correct place? 2. If so, are the files really there? This is how it looks at my place

$(LeadwerksHeaderPath)\Libraries\OpenAL\include

When defining a 'color' value in Script the alpha value shows up as 255 even if the default value is set to something else

Thanks Josh. That changed nothing. However I have found that the reason why its working for you is that you are having "using namespace Leadwerks;" in your headers. I tested by adding that to my example Doesn't work #include "Leadwerks.h"//lua class Test { public: Test( Leadwerks::Entity* e);//lua }; This works #include "Leadwerks.h"//lua using namespace Leadwerks; class Test { public Test(Entity* e);//lua }; Pgk-file (same in both cases) $#include "Leadwerks.h" $#include "Test.h" class Test { Test(Entity* ent ); }; I don't like to have 'using' in my headers but I'll guess I can live with that for my Lua-exposed classes so I guess we can say its solved then. Thanks for taking the time.

Really. Could you give a simple example. class Test { public: Test( Leadwerks::Entity* e ); }; gives an error at runtime saying that argument #2 is a Leadwerks::Model This works though class Test { public: Test( void* e ); }; in LUA Script.cpp = nil function Script:Start() cpp = Test:new( self.entity) end

Aha. That explains it

Thanks and glad you liked it

To be picky The public method ClearAnimations also have a potential memory leak as it can be called from anywhere and it erases all elements without deleting them. Easy fixed by moving the delete loop from the destructor to ClearAnimations AnimationManager::~AnimationManager() { ClearAnimations(); } void AnimationManager::ClearAnimations() { for (auto it = animations.begin(); it != animations.end(); ++it) { delete *it; } animations.clear(); }

Tested the C++ version. There's a memory leak here if (n < maxanim) { if (completedanimation->mode == false || completedanimation->endOfSequenceReached == true) { animations.erase(animations.begin() + n); } } should be something like if (n < maxanim) { if (completedanimation->mode == false || completedanimation->endOfSequenceReached == true) { delete animations[n]; // prevent memory leak animations.erase(animations.begin() + n); } }

Very interesting reading.

Great and thanks. Would be great if we didn't have to guess though

I like the idea. I'm making my game for both Windows and Linux. Thumbs up!

Of course you can pass Entitys from LUA to C++. Here is a fictional example on how I do that. Say we have a LUA script containing some Entity, say a Box Shape. Now we want to pass this Script and its entity to a C++ class for some work. I type in this just from my head so there might be some minor errors but you get the idea. What was talking about was those void* pointers. That works but it would have been nicer to use Leadwerks::Entity* pointers which they really are. RotatingBox.lua: LUA Script Script.TheBox box = nil --entity "The Box" Script.Speed speed = 0.5 --float "Speed" Script.cppworker = nil function Script.Start() cpp = CppWorker:new( self.entity ) -- passing our self to C++ end function Script:Update() cpp:rotate( self.box ) -- passing the box entity to C++ end CppWorker.h: C++ Class Header #pragma once #include "Leadwerks.h" class CppWorker { float _speed; public: // Have to use void* instead of Leadwerks::Entity* CppWorker( void* luascript_entity ); // Same here. Have to use void* instead of Leadwerks::Entity* void rotate(void* entity); }; CppWorker.cpp: C++ Class Source #include "CppWorker.h" CppWorker::CppWorker( void* luascript_entity ) { Leadwerks::Entity* luaentity = reinterpret_cast<Leadwerks::Entity*>(luascript_entity); //Script Entity from LUA // reading speed from LUA int stacksize = Leadwerks::Interpreter::GetStackSize(); luaentity->Push(); Leadwerks::Interpreter::GetField("script"); if (Leadwerks::Interpreter::IsTable()) { Leadwerks::Interpreter::GetField("Speed"); _speed = atof(Leadwerks::Interpreter::GetVariableValue().c_str()); } Leadwerks::Interpreter::SetStackSize(stacksize); } void CppWorker::rotate(void* entity) { Leadwerks::Entity* e = reinterpret_cast<Leadwerks::Entity*>(entity); e->Turn( 0, Leadwerks::Time::GetSpeed() * _speed, 0 ); } CppWorker: ToLua++ Source $#include "Leadwerks.h" $#include "CppWorker.h" class CppWorker { public: CppWorker( void* luascript_entity ); void rotate(void* entity); }; tolua++ -o CppWorker_.cpp -n CppWorker -H CppWorker_.h CppWorker.pkg Compilation Add CppWorker_.h and CppWorker_.cpp to the project and in App.cpp add #include "CppWorker_.h" at the top and then add this line at some convinient place in your App.cpp, something like this ... tolua_FpsPlayer_open(Leadwerks::Interpreter::L); if (!Interpreter::ExecuteFile(scriptpath)) ... .. Test Add the script RotatingBox.lua to some Entity in you scene and if your the box will rotate. The CppWorker does the rotation of the Lua Entity 'box' using the Lua value 'speed'. PS: Oh how I hate this forum editor that removes the tab-indentations in code

It's actually mostly annoying. It works with void* but typeless pointers isn't anything I really like having. And inside the function it's that extra reinterpret_cast<Leadwerks:: Entity*>(pointervalue) to do. Just wondered if anyone had come up with a way to make it cleanly

These guys are not documented

I have successfully managed to use toLua++ in order to expose my C++ classes to LUA. All works fine and dandy, however I have to use void* pointers in functions where there is a Entity* pointer. Its really no big problem but I would like to now if any one else know something about this. Example: class MyClass { public: MyClass(); void some_function( Leadwerks::Entity* e ); } That one causes a crash in LUA when some_function is called function Script.Start() myclass = MyClass:new() -- OK myclass:some_function( self.entity ) -- KRASH end Now if I instead use a void* all works great class MyClass { public: MyClass(); void some_function( void* e ); } This one works in LUA when some_function is called function Script.Start() myclass = MyClass:new() -- OK myclass:some_function( self.entity ) -- OK end I can understand that toLua++ apparently doesn't handle the Leadwerks::Entity* as expected. Is there anyone that have come across this little problem and if so how to fix it? I couldn't come up with something. Meanwhile I can live with the void* although I don't like it.

Great. Awesome and thanks

Update: It seems to be a Ubuntu 16.04 TLS problem. I backed to Ubuntu 14.04 TLS and the problem was gone.

Sounds great Josh

Don't make the same mistake as with the last 'off-road' experiment when LE was going mobile. I do believe this will go the same way, but that's me. Anyway there are one statement that worries me a bit. Do I read that post-processing is going away? Where do that leave us that do not aim at publishing any VR-games. Please explain a bit more about what this future idea leave us "normal" game makers. I'm just starting quite a intense effort here and don't wont to end up i same disaster as the last mobile-idea ended up in. An engine that went backwards two or three steps and took years to get well again. Tell me were not going there again and that I do not have to worry about that

This will be just great as there is no easy descent GUI in Linux that I know of. Either they are to bloated with tons of more or less weird stuff or to simple to use for any real task.

This sounds really great. Really looking forward to the release

Okay Josh. Thanks for testing. Will get a new look at it when I home again

I will obey the rules