Ma-Shell

I'm not too experienced in LUA but I would guess, you didn't define the key-value "name" for the ground and thus the function returning nil for that case and a comparison between nil and a String isn't possible (as said, I don't know about LUA, but I would guess that's the case). So have you tried checking whether it is nil before doing that? Something like: if pickinfo.entity:GetKeyValue("Name") then --This is the same as a comparison with ~= nil if pickinfo.entity:GetKeyValue("Name") == "Block" then pickinfo.entity:Release() end end

It should say LoadWeapon (with a big W)

Since at the end of the video you asked how you could include multiple animations into one file: http://eelstork.deviantart.com/art/Multiple-animations-in-the-same-file-Blender-Tut-321883259

1. In Steam do a right click on Leadwerks and choose "delete local data" (or something similar, can't say because my steam isn't set to English). 2. Tell Steam to download and install it again. 3. Have FUN

Don't want to interrupt anyone but SteamOS is going to be a supported distribution, as Josh wrote in http://www.leadwerks.com/werkspace/blog/1/entry-1192-refocusing-on-the-pc/ "Given the OUYA's failure, it should obviously be scrapped and replaced with SteamOS support." (Talking about the OUYA-stretchgoal of the kickstarter campaign) EDIT: I was a bit slow...

LUA is based on the idea that you attach your scripts to an object and give control to the program which then calls those scripts when needed. C++ is based on the idea that you make the program and not the scripts. This means, you have a lot more control what happens when. You usually have your main-function which gets executed once the program starts and once this function terminates your whole program exits. For the most applications you have something which is called the main-loop. This is a chunk of code that gets executed over and over until you tell it to exit. Usually this consists of your gameplay-mechanics, a world-update (physic) and a render call. Within this loop you can access all the entities and do what you want to them by iterating over the list of entities. I hope you can see the point that this is an entirely different approach. With the approach C++ uses, you have a lot more control over the executional flow and surely you can simulate something like scripting in C++, like Aggror and Rick mentioned but that is not the usual way, it is meant to be.

No, he didn't said anything regarding this but it would show him what features the community would like best and maybe it would influence his decisions.

Usually at the root of your project folder there is the windows-executable which has the ending ".exe" (e.g. if your project is called "test", this file should be "test.exe"). There should also be a file with the same name but without the extension (e.g. just "test"). This one is the Linux-executable, I guess. You only have to run this one instead of the ".exe".

In the Leadwerks-installation-folder there should be a copy of the MyGame-project. You can copy that one to your project-folder.

I guess, in step 6 you simply replaced the contents of the "Additional Dependencies"-field by "ws2_32.lib" instead of adding it to the entries that were already there? The field should say: lua51.lib;steam_api.lib;ws2_32.lib;Glu32.lib;OpenGL32.lib;winmm.lib;Psapi.lib;OpenAL32.lib;Leadwerks.lib;%(AdditionalDependencies)

I can remember, when in the very beginning of Leadwerks 3.0 everyone wanted GUI-features... I wonder, why nobody put this here. I think, this would be the root of all evil. You would have to check all strings from the code, because you can also load assets by code. Also what about assets that aren't even specified at compile-time? You can dynamically modify those strings, like e.g. in a LOD-system where you would e.g. name one level of a model barrel1.mdl and the other LOD-levels would just increase the number, like barrel2.mdl, barrel3.mdl etc. and the code would just take the model name and increase/decrease the number. This would not even be possible to be detectable.

I don't get this error. Am I correct in assuming, you are using the steam-build? Also is the crash appearing, when the sound is just finished playing? If all of this is the case, this could be correlating with the fix to this: http://www.leadwerks.com/werkspace/topic/10076-releasing-sounds/ (this fix isn't yet in the standalone, which I have, but it should be in the steam standard and beta)

What is the difference between "collectgarbage(collect)" and just "collectgarbage()"? In C++ there is not even an overload of that function that takes a parameter and it isn't documented. You are right, it isn't documented. I found out about it because I usually use C++ for my projects and VisualStudio has the nice Intelli-Sense where it told me, there was a third parameter called "extra" that defaulted to "false".

I just tested this and saw, it happened for me as well. Memory keeps increasing for terrain and for csg-box. I didn't wait to see, if there was a limit. I also noticed, this happens, if you just stand at one position and keep jumping (but not, if you don't do anything). Using self.context:DrawStats with the third parameter set to true, you also see the memory usage split into "script memory usage" and just "memory usage", where the latter one is the one, which keeps increasing, so it doesn't seem to be related to that particular script.

I guess, this could be because, as you move, more parts of the terrain have to be loaded into memory, so maybe some parts that are not visible in the beginning might get into view and have to be loaded into memory (just guessing here, I have no idea, how the terrain is implemented) and maybe the parts don't get released afterwards since keeping them in memory is cheaper than extracting them all over again (still guessing ). I will test tomorrow, if I can confirm the memory-increase on my machine (with standalone version) as well, but if it is as I guessed, this would be a normal behaviour. P.S.: Did I mention, I was only guessing?^^

If you created your project as a C++-project, you need to do as tjheldna said (compile it from VS). If it is a LUA-project, it should work out of the box.

Though this is a nice idea, it would be quite hard, getting it to look like the objects have a real volume (the video looks like it's only a thin sphere-surface).

I'm quite sure, this is. The install-script should install libopenal1:i386 and libopenal1. Maybe there was an error when installing those. Can you try installing them manually and check, whether they failed installing. sudo apt-get install libopenal1:i386 libopenal1 Maybe you had an old apt-database when running the install-script, so you could also try sudo apt-get update sudo apt-get upgrade And after that maybe try running the install-script again (though I think, this should not be necessary). (all the sudo-operations might ask you for your root-password)

Try using the context instead of Buffer:GetCurrent(). As far, as I remember, Context is inherited from Buffer (at least in C++) and your current buffer should usually be the context (as far, as you don't change it). It might be, that the current buffer only gets set somewhere in between App:Start() und App:Loop().

I can't remember having trouble with the SDL-library. I guess, those are linker-problems? You have to add "SDL" to the linker-options and add the path to the header-files to the include-directories in the compiler-options. (I am currently not on Linux but if I find the time and you need help with this, I can post a more detailed guide for you)

Why do you think, the file has to be at that location? For me the file GLU.h is in the folder from the windows-sdk, so for linux it seems you are missing a package. Did you run the install-script (install.sh)? I think, the missing library should be libglu1-mesa-dev, which you have to install via sudo apt-get install libglu1-mesa-dev If you didn't run the install-script, you should try running that first and only if that doesn't fix it, try the above (as I think, the missing library is a dependency of one of the libraries installed). You can do so by cd-ing to the leadwerks-directory and typing sudo ./install.sh

The problem is that in the files Stream.h and BankStream.h (from Leadwerks), EOF is explicitly undefined via #undef EOF because they have a method using this name. Including fstream before leadwerks fixes the problem, since the compiler first has EOF defined, when he reaches fstream and then, when going through the Leadwerks-Includes, it can be undefined. Also because EOF is a compiler-variable, I would prefer this method to the one Michael_J proposed. If you want to use EOF in your own code you will have to define it yourself, though (so you could just do both).

Well, Visual Leak Detector is a tool for C++ and memory leaks are C++-only (no problem for LUA) . The problem is, that even in a new LW-C++ project (even if you don't use any LUA-scripts), the LUA-Virtual Machine is started and claims and releases memory. I don't think, there is a way to disable this.

Try this: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entityinstance-r173

Hi, Valgrind isn't available for windows (which I assume you are using because of visual studio ) Visual Leak Detector is a nice piece of software. Sadly you can't really debug for memory leaks with Leadwerks 3, since the LUA-VM will always allocate and free memory. So when trying to use VLD or similar stuff with LW3, you will end up with 1000+ Memory Leaks found anywhere inside the LW-Lib. See http://www.leadwerks.com/werkspace/topic/9505-tons-of-memory-leaks-in-leadwerks/page__hl__leak for details. Actually I figure the only way of really testing for memory leaks is using System::GetMemoryUsage() where you still have to do a lot of analysing . Or does anyone have a better idea?