Guppy

Just a quick note here - the only supported linux flavor is Ubuntu and only the latest LTS. So unless you can replicate your bug there josh is going to close this as a non bug.

It's downloading the DLC for you - there is unfortunately not much indication of this, if you just wait a little while it should finish downloading and resume working normally

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

facepalm moment - turns out I had stubbed the "isFormatSupported" function in the rendermanager with return true; so err yeah just ignore this tread, I'll chalk it up to sleep deprivation

MyGUI uses it for colored text - suppose I'll have to find a way around that.

Managed to write and build a shared lib to do just this before I remebered that the linux version cannot load it yet and I've no way of compiling it on windows... oh well later ^^

It should be possible to create a lua lib that that can do the above for you [/size] require("libLua-cryptloader") cryptloader:LoadDir("Data/","password"); ofcourse you'd need to obfuscate the password a bit

I've been usingLeadwerks::Texture::RGB and Leadwerks::Texture::RGBATo pass to Leadwerks::Texture::Create(_width,_height,LEformat) But I also need to create textures with one color channel and one Llumiance channel + alpha (GL_LUMINANCE8_ALPHA8) - I've been using Leadwerks::Texture::Intensity16 for this which gets me the correct buffer size but when I bind the texture it just shows as black. So what should I use instead?

Steps to reproduce: Cause an update to the scene tree ( add csg, delete stuff, etc ) while on a different tab

Been wondering about that as well - I mean the kickstater alone generated 318 backers with indie or c++ licenses.

Point distance to plane:

Well V1 is not contained in mPlane so what did yiubexpect?

Ditto for gimp

I would really appreciate if this could get fixed it's just a define that needs to be well defined before re-combuilding

It varies with implementation, but I *think* it's always the same for gcc

And that is properly the source of your error - std::cout << "LC_ALL: "<< LC_ALL << std::endl; yields LC_ALL: 6 on my system

Not sure what 0 is But I would suggest setting it for LC_NUMERIC and LC_MONETARY, use the defines as the numeric value is implementation dependent; http://en.cppreference.com/w/cpp/locale/LC_categories

The font is garbled, the linux version refuses to load lua libs so it's hardcoded and I've not even begun handling inputs yet - but my Leadwerks myGUI platform is finally rendering \o/ Not a terribly exciting screenshot, but after a week of staring at code and loosing sleep to casts and rogue pointers I'll take any visual gratification I can get

It's fairly easy to fix the paths, old trick with a bit of Leadwerks flavor sprinkled on; chdir(FileSystem::ExtractDir(argv[0]).c_str()); I've no idea if it works in windows tho, I'll leave that as an excercise for the reader

LD manpage for $ORIGIN So that is definitively what we want

Try the origin thing that should be relative to the executable

btw if you want to specify multiple paths it's -Wl,-rpath=path1,-rpath=path2,-rpath=ad nauseam

Did you specify a relative path or an absolute one? if you specify a relative path ( like . or sharedlibs/ ) and do readelf -d myLeadwerksgame | grep -i rpath it should still show it as relative, no? In case it really doesn't work you could try using $ORIGIN, in order to specify that in code::blocks you need a bit of voodoo apparently; -Wl,-rpath=\\$$$ORIGIN you can make it a sub directory by changing appending /subdir/ Let me know how that works out for you

I think this; http://www.leadwerks.com/werkspace/topic/10588-codeblocks-specify-dynamic-lib-search-path-in-cbproject/ Answers your question