Guppy

wow well that made a the difference in the world, thanks <3

I did not - how do I do that?

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..

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

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 )

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

That same would be true of gui's - unless you fancy writing a complete gui manager in lua you will be using an external lib. But it may be a moot point as I just noticed that there was no .so emitted from my build, instead I got; /usr/bin/ld: /home/morten/.local/share/Steam/SteamApps/common/Leadwerks/Library/Linux/Debug/Leadwerks.a(Package.o): relocation R_X86_64_32S against `_ZTVN9Leadwerks7PackageE' can not be used when making a shared object; recompile with -fPIC /home/morten/.local/share/Steam/SteamApps/common/Leadwerks/Library/Linux/Debug/Leadwerks.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status had hoped that I could depend on getting the symbols from the executable running the lua instance, seems not