[Easy Character Creation Tutorial]

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

[i deleted steam 3.2]

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

[[Linux, Steam] GTK controls renders wrong]

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

[C++ scripts]

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.

[Vote: Requested Features and Improvements]

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.

[Multi platform Publishing]

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

[New to leadwerks...noob question inside]

and how I can restore my original tutorial project now???

 

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

[RakNet Include Compile Error]

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)

[Requested Features and Improvements]

I can remember, when in the very beginning of Leadwerks 3.0 everyone wanted GUI-features... I wonder, why nobody put this here.

 

+ detection and removal of all unused resources from the release

 

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.

[Bug with included tutorial 07-AI and Events.map]

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)

[Character Controller Walking on Terrain=Memory Leak]

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.

 

P.S. Knowing about the third parameter for DrawStats() is really helping me test my other projects! Also, I couldn't find the DrawStats() function in the documentation; did I miss it or is it yet to be created?

 

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

[Character Controller Walking on Terrain=Memory Leak]

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.

[Character Controller Walking on Terrain=Memory Leak]

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?^^

[Cannot build, run or debug a level - help!]

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.

[Would it be possible to make objects explode into fragments?]

You can also explode faces aling their normal using a geo-shader (and animate it), but they wouldn't have any physics.

 

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

[Getting message that AL/al.h cannot be found]

It is OpenAL related ?

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)

[How to access the default buffer?]

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

[glu.h no such file or directory]

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)

[glu.h no such file or directory]

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

[fstream C2065]

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

[Memory Leak Detection]

You should go C++ to make a complete game with LE3, and keep Lua for simple stufrf only like some level logic as door , interactive stuff. C++ is the way to go in LE3 specially if you target better performance and have all language advantages and benefits.

 

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.

[Instancing?]

Try this:

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

[Memory Leak Detection]

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?

[cpp Get Terrain shader at runtime]

@shadmar

Yeah, but what actually is a surface? Just a group of vertices? If so, what separates the vertices from one surface from those in another one? Are those just user-defined groups of vertices? So why would a terrain have multiple surfaces ("surface" is defined as an array of 5 within the terrain-class, so this isn't something simply inherited)?

[cpp Get Terrain shader at runtime]

I believe, you have to use the surface. The following doesn't yield NULL:

Material* mat = terrain->surface[0]->GetMaterial();

 

Though I have no idea, what the index is for, maybe this can give you a push to the right direction.