Guppy

Guessing the 32bit one is for the editor

Odd - the shared file ~/.steam/steam/SteamApps/common/Leadwerks/libsteam_api.so is indeed 32-bit but the one in the project dir is 64 bit - try linking against that There is also a 64bit version in ~/.steam/steam/SteamApps/common/Leadwerks/Library/Linux

You are missing a linker search path - try creating a blank c++ project in LE:steam and diffing the codeblock project files.

I think there is a perfectly fine forum already in place and don't see any reason to gut it.

I added a zip file "test_archive.zip" to the root of my project containing a folder with a single (empty) xml file test/test.xml. The standard app code finds and loads it as a package, however I cannot seem to verify it's existence from leadwerk; Leadwerks::Directory* dir=Leadwerks::FileSystem::LoadDir("test"); Return null and [/size][size=4]Leadwerks::FileSystem::VirtualFileSystem is empty aswell What I'm trying to achive is listing the contents of a directory as leadwerks sees it ( incl vfs, etc )

That is I believe by design as it's no longer valid for the current version of LE

Video is private

Any other ideas?

Do we really need to make this many topics for what is essential the same bug?

My point was ; not all methods are mapped to lua

He wants a list of functions (methods really) from the headder files - how is that any different than "digging through the source"

What would be the point? If you have the c++ version you have the header files, if you dont then you cant use them...

Is there something like glutReshapeFunc for leadwerks? That is a call back that can be registed to be notified when the user resizes the window.

bascially if you try to run a c++ project binary currently it will fail with "mygame: error while loading shared libraries: libsteam_api.so: cannot open shared object file: No such file or directory" now you can get around that by specifying LD_PATH=. mygame, but that is quite frankly ugly and inconvenient So please in Project -> Build options -> Linker settings -> Other linker options put -Wl,-rpath=\\$$$ORIGIN ( personally I use "-Wl,-rpath=\\$$$ORIGIN/sharedlibs/" to avoid causing clutter in the root dir but that's just me ) edit: swapped "." for \\$$$ORIGIN because as codeape pointed out you don't have to stand in the same directory to execute the file.

This applies to "mini game mode" only right?

Just notice that it does not yet work in linux, you can use window->maximize() to get more screen estate

Confirmed on Ubuntu LTS In addtion hitting the "get more games" button in the game player does open a tab in an existing browser but will then lock up the computer unless your very fast to close said tab again.

Google for "c++ on key release" or just use OIS and stop worrying about it

That was the sandbox checkmark I was refering to yes

as per: http://www.leadwerks.com/werkspace/topic/10573-lua-dynamic-libraries-not-enabled/ (I've request the topic moved or merged with this but I've no idea how to do that ) Seems LUA_USE_LINUX and/or LUA_USE_DLOPEN needs to be defined to enable dynamic library loading. I've provided a simple library to test with in the original thread.

Anyone with linux can download the very exciting plugin here; https://drive.google.com/file/d/0B7B0hlkpWcYWVmhkOEtaTFJ5bzA/edit?usp=sharing I put it in a subfolder named "plugin" but you can stick it anywhere - just adjust the path acordingly require("plugin/libLua-test") it exposes the functions "sayHi" and addTwo(....); System:Print(test.sayHi()) System:Print(test.addTwo(1,2,3,4)) _ This http://lua-users.org/lists/lua-l/2014-05/msg00267.html Seems to suggest that there is a missing define in the linux build

I get "Lua Error: error loading module 'plugin/libLua-test' from file './plugin/libLua-test.so':|dynamic libraries not enabled; check your Lua installation" When I try to load my own library. This thread http://www.leadwerks.com/werkspace/topic/10566-require/page__hl__require suggests that turning off sandbox will do the trick - I've tried it both in the LE editor and in c++ neither makes any difference. Since he made it work I'm thinking this could be the linux version having different lua permissions? Or is removing the sandbox check mark and doing Interpreter::sandboxmode=false; in App::Start() before loading the map not enough to turn off sandbox?

It this a windows feature? - because on linux it just crashes when for instance calling a function that doesn't exist

Steps to reproduce ; Tools > Options Under editor Font will say <None> click and select "DejaVu Sans Mono" 12pt Click ok Now re open the Menu Tools > Options and the entire editor crashes Other fonts gives different results - "Tlwg Typist" font instance sometimes causes an instant crash and some times you can repeat the above steps 10 times before it crashes. At first I suspected font with spaces in the names but even one word ones sometimes crashes.