Canardia

So far all your questions have been answered in decent time,the question about terrain blending can be answered only by Josh, which he has also already done, "so what's the problem?" --Rammstein

Basically you have 3 levels of support available when you buy the engine: 1) Tutorials, Documentation and Forum Search 2) New answers from people in the Forum 3) Bug Tracker and Leadwerks support mail

You can put "Thanks to the Leadwerks Community for GameLib", as lots of code and ideas in it is donated by different people from the LE community I think the video player should be also part of it, but I need to ask Niosop for permission; and Tyler's web browser.

That can be easily added, since the zombie follows just a vector of waypoints. So an complex AI only needs to place new entries in the waypoint vector, which is very simple in C++. You can also move waypoints on the fly. You can also add your own AI the same way right now, so you don't have to wait until I write some A* class.

That's basically how the player controller works in gamelib. You can steer it with keyboard or movement commands. The zombie AI which is just following waypoints, is using the same TPLayer class as the player, but it's controlled by the computer. The player entity which the player controls, can be changed on the fly to any other player entity too, so you could step into the AI zombie and take over the controls, then your old corpse would stay dead unless you assign it's corpse to the AI engine.

But someone could start a paid support hotline, if Josh doesn't mind Most of us here are freelancers, indies, entrepreneurs, and little teams, who are often looking for new business ideas. I see sometimes requests for code examples, but going after each such request takes a lot of time, and I want to get my own projects also done. However, I wouldn't mind to get few bucks if someone wants me to do a demo with source code. Smaller code examples are of course usually answered on the forum for free, I'm talking more about more complex demos which need several hours of work to do, even when using gamelib.

When you make the leo project, does it have engine.cpp and leo.cpp in the source list? And when using gamelib, you need only gamelib.cpp in the source list. gamelib project: #include "gamelib.h" source list: gamelib.cpp leo project: #include "leo.h" source list: engine.cpp, leo.cpp procedural project: #include "engine.h" source list: engine.cpp

You shouldn't get the same error when you make a new project with nothing in it. Just make a simple test program and don't use the old gamelib demo.

Have you tried to make a new project? Maybe you have some wierd settings in your project which you are compiling.

Usually when you don't get a response on these forums in 5 minutes, it means that nobody knows the answer

The windmill is using the old Lua script, I have converted mine to the new Lua and it works in both Editor and GameLib.

LEO uses only the integrated Framework. LEO never used the C++ Framewerk, since that is a standalone class.

You need to do: SetVegetationShadowMode(1); in your code. Editor has by default the vegation shadow mode: "sometimes" enabled, so you need to enable vegetation shadows in your code. You could also change the vegetation shadow mode in Editor to: "always", but that's not a good idea I think, because then you can't turn the shadows on/off by code.

Yeah, picking up objects, moving objects, and inventory system will come to gamelib also. Although its not officially maintained by Leadwerks, you still get a tested and working library with reusable functions for your game, so you don't have to code everything from scratch. I think I'll also split gamelib into seperate class files in future, so you can use only parts of gamelib.

The procedural C++ headers are the mostly for easier conversion to other languages. It would be a huge task to convert LEO to all other languages (and many languages don't even have full OOP capability), so the procedural headers are kinda like the minimum you need to convert. There is no additional maintenance for LEO, since LEO uses the procedural headers, so you would need to write the new DLL imports anyway.

Yes, but then you don't use LEO, but only procedural C++. I think in the long run every game needs more and more OOP when things get more complex.

UPS() works also in C++, if you code your main loop correctly. The raw version of the main loop should be like this: UpdateAppTime(); UpdateWorld(AppSpeed()); RenderWorld(); but since everyone should use LEO Framework, it should look like this: fw.Update(); fw.Render();

You can still use it for games which don't use Lua, also in LE 2.3. You could also use it for games which use Lua, but then you need to customize a few entity scripts.

A convex hull has all its face normals facing outwards, so that no face normals ever intersect eachother. That's why you get those "shortcuts" over faces which are not convex, like on the lower left corner of the last pic. So the last pic is a correct convex hull, the first pic is a binary tree hull.

Try to uninstall the Windows SDK and install the "last known good" one: http://www.microsoft.com/downloads/details.aspx?FamilyId=484269E2-3B89-47E3-8EB7-1F2BE6D7123A&displaylang=en

Yes, LEO is using Framework, not Framewerk. And ArBuZ is using LEO Framework also: Framework *fw1=new Framework(); However, he seems to be passing **fw to Lua, and not *fw, that might be the problem.

If you do SetPosition on a physics body in each frame, then it might also do the same, as a missing fw.Update(). You should use AddBodyForce with CalcBodyVelocity to simulate SetPosition on physics bodies.

This fast movement happens when you don't call fw.Update() in each frame. It then tries to catch up the lost time when you next time call fw.Update().

Maybe the new Platform SDK is buggy then, I still use the Windows SDK from August 2007. In gamelib there is the line "#include <gl/glut.h>" that should correctly bind the opengl .lib files, and you don't need to do anything else to use glBegin, glEnd and such commands then.

One thing that slows code designers is also this: Make the Model properties window update without having to restart Editor when making changes in the Model's script.