Guppy

I assume by tab you mean like the ones that each script get? So now bug I guess - linux have no lua debug tab

Maybe a stupid question but how do I debug in Lua? I can set a break point but I cannot set watches or inspect variables and if something goes wrong or I make a typo it just crashed with no warning. Shouldn't there be a lua console or something?

Looks like 1 bit alpha testing - but that's a thing from dem olden days if I were to guess I'd say the shader looked at the alpha value and did something like if alpha > X then 1 else 0. What shader are you using?

*cough* doxygen *cough* I've even been tempted to add the comments my self but as they will get overriden by updates..

In that case there remains two possible error causes; libsteam_api.so is NOT in the same directory as your executable ( or is broken, try replacing it with the with one from a fresh project ) Your missreading the error and what you see is just the "no running steam instance found" message

IIRC setting color to 0,0,0,0 will not tint the image

To illustrate the problem more clearly than the above ramblings; Holding down shift and hitting h,e,l,l,o results in: H:16 D:16 H:72 D:72 H:69 D:69 H:76 D:76 H:76 D:76 H:79 D:79 with this code for( int i=0; i < 256; i++ ){ if ( window->keyhitstate[i] ) std::cerr << "H:" << std::to_string(i) << std::endl; if ( window->keydownstate[i] ) std::cerr << "D:" << std::to_string(i) << std::endl; } Where each new letter should also have a D:16

As I continue on this today something has changed - keyhitstate and keydownstate will both only ever hold 1 character, holding down for instance shift and a will result in only the last key pressed being set to true. The same is true for holding down multiple characters. std::string inputBuffer=""; int c=0; for( int i=0; i < 256; i++ ){ if (window->keyhitstate[i]){ inputBuffer+=static_cast<char>(i); inputBuffer+=" ["+std::to_string(i)+"]"; inputBuffer+=","; c++; } } if ( c > 0 ) { inputBuffer=std::to_string(c)+" characters: "+inputBuffer; } window->FlushKeys(); I figured this was due to the beta code, but even after uninstalling leadwerks and re-installing and rebuilding my project the problem persists. So something else is afoot here, but what?

That's not entirely accurate as I wrote above it's still used to load binary lua plugins ( when not in sandbox mode )

While not I'm 100% certain I believe that require is used for including binary plugins and include is used to include scripts. Also require is turned off in sandbox mode, not sure about include

Did you actually rebuild? what does readelf -d yourgameexe | grep -i rpath write?

Lua libs on linux still isn't working - sendt you a PM with a potential fix and a way to test

(this is a bit long winded - you can just skip to the Question bit if you like) I'm currently writing an even system to wrap around ( among other things ) the Leadwerks input, this dispatches events that follows this design Now the event manger dispatches them as Event* but some listeners may want to make use of the more specialized version so it needs to know if it is capable of that before attempting a downcast as the true type is not known at compile time. There are several approaches to solve this; 1) give event a "virtual std::string getEventClass()=0;" and compare to that The drawback here are string comparison ( which you could solve with hashing ) and inheritance ( a mouseEvent is still UI event but will fail the check ) 2) A variation of the above where each class must push a hash of their class name onto a stack, and the stack is then checked. This works but is somewhat cumbersome as anyone creating a new event class must remember to push the class name onto the stack or risk breaking the chain. 3) use dynamic_cast this was my first idea, using the code below; template <class cmpType> bool isType(const cmpType* src){ return dynamic_cast<const cmpType*>(this) != 0; } It works but leaves a lot to be desired for readability and anoyingly you need to pass an instance of what your trying to compare to rather than just a class. So I took to the web trying to see if anyone had solved the contract ( / acyclic visitor / reflective visitor ) pattern in C++. What I found was a lot of people saying the sky would fall if one were to use dynamic_cast - but nobody offered an opinion as to why. Question: Why is dynamic_cast evil?

This is where I'm tempted to simply post a snarky "could you possibly be a bit more vague?" But really you have very little information in your post for anyone trying to help you, perhaps include; What version of leadwerks your using How you attempted to integrate it what you have already tried in order to fix it Also this is a very handy document that far to few people have read; http://www.catb.org/esr/faqs/smart-questions.html

looking forward to testing this

Yes but we cannot monetise it can we?

Set freelook to false - not at the Comp atm. So there be further chances needed

Remove the camera form the c++ code - ør the lua FPS vontroler wont work

Have you compiled the c++ project?

Is there a way to get raw key presses in Leadwerks? I mean getting an the actuall letter "A" rather than a Leadwerks::Key::A My first naive approach after noticing that window->keyhitstate was 256 long was to simply convert it to ascii; std::string inputbuffer=""; for( int i=0; i < 256; i++ ){ if (window->keyhitstate[i]){ [size=3]inputbuffer[/size]+=static_cast<char>(i); } } window->FlushKeys(); However that gets me all keys as uppercase and f1-12 as lower case letters - and even if it worked there is a very high risk of getting inputs out of order I worry that reading the keys manually will either prevent leadwerks input from working or yield no results as leadwerks already emptied the keyboard buffer.

Get the C++ version and code as much of the logic as you can in LUA then use C++ for the bits that you cannot solve in LUA. ( if you just compile a new C++ project with no changes you bascially create the LUA client )

Spent all morning figuring this one out and distilling it to it's very essence; if you do Leadwerks::Window::GetCurrent()->GetMousePosition(); inside app::start the world will fall though you - or more specific; CSG boxes wont get drawn and barrels, etc will start falling while the FPS controller just hangs there. Reason I'm trying to do the above is to have my gui class as encapsulated and easy to use as possible - so rather than requiring the user to pass a valid window instance it just grabs the current if none are specified. I've several workaround ( like initializing on first draw call, etc ) but I don't understand why it's happing this way, I mean there should be no difference between calling through one pointer or another.

I was indeed attempting humor ( trying to indicate that through the use of smilies ) since the OP asked for "boolean" rather than "boolean operations"

I'm thinking it was to save memory - works just fine now I've told it that format isn't supported

Bool a = true; Your welcome