Laurens

That looks good Ken, well done

I am not using LEO, I very much prefer the C-API. It never gets in the way

Aren't we already collecting problems and solutions in special forum sections? I'm sensing that you want to turn this forum in some sort of Stack Overflow for Leadwerks but I think the only difference is in the presentation. Your FAQ is a great initiative but it is only a matter of time before it gets to large and we are going to need a search function just for that one thread People should probably use the search function more often. Although you can't really blame the trail users, not having access to the sub forums and all.

While I am not familiar with LEO, keep in mind that when you're doing IsVisible between two meshes, you need to hide both meshes prior to testing or the result will always evaluate to false.

This is really good stuff Rick, can't wait to play!

Well, that's essentially what I am doing now. I am relying on CountChildren and GetChild to maintain the list of children of the scene. When loading, it just new's the appropriate classes and when a list of instances is needed, it grabs the children of the TEntity and casts the user data to the appropriate class again. It does feel kinda clunky though so that is why I was wondering how other people solved this particular problem.

That looks great! It truly looks like your looking at a hand-painted picture, I love it.

Hi guys, I am interested in how people have glued Leadwerk's TEntity and their own codebase together. Right now I have a C++ class Entity that forms the base class for all my other objects. I had problems properly deleting the object and the actual TEntity it was wrapping. Imagine you have a Scene class that inherits from Entity. The scene class has a number of child TEntity's of which the corresponding C++ class has also been new'ed during the loading process. Now, if you delete the Scene, freeing the entity, the engine will automatically free the childs of that entity. The result is that the TEntities are properly deleted but the C++ objects remain because they never have had their destructor called. To solve this I added the free callback to my entities, calling the destructor of the TEntity's user data in the callback function. It is not hard to see this will end up in a loop and solved it like so: void _stdcall FreeEntityCallback(TEntity entity) { Entity* e = reinterpret_cast<Entity*> (GetEntityUserData(entity)); SetEntityUserData(entity, 0); delete e; } Entity::~Entity() { if (GetEntityUserData(_entity) != 0) { SetEntityCallback(_entity, 0, ENTITYCALLBACK_FREE); FreeEntity(_entity); } } I am interested to hear how other people have solved this particular problem. How have you wrapped Leadwerk's TEntity? Thanks!

Unless you are writing your own raycast functions, you will still need Newton. In fact, I don't think the engine even starts without the DLL present.

Then you have to copy all folders over to your project folder, and modify the path settings in Editor. Correct. Back before some version I don't remember, you had to manually iterate through all the childs of the loaded scene and instantiate any lights and assorted other entities yourself. Today, LoadScene will load everything, no further setup required. No, unloading the scene is enough. You don't have to delete all the entities in it, they are all childs of the scene. Cheers!

A while back I switched from VS2010 to NetBeans and haven't looked back. The IntelliSense is on about the same level as VS2010 and the fact I don't have to redistribute a bulky runtime is a plus. Additionally NetBeans has native support for C++ unit tests whereas VS2010 Express does not, which was my main reason to switch. Here's a tutorial if you please :-) http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials/_/programming/cpp/c-netbeans-and-leadwerks-r53

That looks great Aily! Thanks

Good stuff Vetal. I don't think I can add more to what has already been said. Cheers

If I were you I would focus on getting a game out first, and then using a profiler to optimize wherever it is necessary. You don't want to waste time optimizing routines that wouldn't have ever posed a bottleneck to begin with.

Hi Mike, Thanks for your response! Everything is on the server as it is and clients only have full knowledge over the player they are controlling in the game and not the others. The need for representation classes is that I will still need to render the other players, i.e. if the player to my left is holding three cards I need to render the backfaces of three cards. The client won't know which cards it are, simply because it is never told him/her, but I will need to know the amount in any case. In other words, the "ghost" of the player you're controlling yourself needs to be more knowledgeable of the game state than of any of the other players and I ran into the problem that this distinction cannot always be properly made by using the same data structures. If I have a Hand class for example, it has a method +Add(Card card): void. It obviously adds a card to the hand of the player but a remote client that is not dealt that particular card can't know which card it was and cannot call that method. The HandRepresentation class therefore exposes an +Add(): void method that simply increases the card count for that hand. So I guess all I'm asking is: how do you (or others for that matter) separate a full-knowledge (about him/herself) local client from the remote clients on a class-level? Do you use the same data structures or make two separate structures for each purpose like I did? I hope I made myself clear Cheers!

Hi guys (and gals), I have been playing around with networking lately and have come up with a multiplayer architecture that works reasonably well. I did however not forsee how easy it would be to hack when all clients have full knowledge over each other as they do right now. I came up with the following functioning solution: In the context of a card game, for each domain object (such as a Deck, Hand, etc.) I have a representative counterpart (DeckRepresentation, HandRepresentation, etc.). For example, a Hand object contains a number of concrete Card objects that tell the player what rank and suit it is. A HandRepresentation only contains an integer representing the number of cards in the actual hand. The idea is that each player only has a reference to the full Hand object it is controlling him/herself, and HandRepresentation's for the other players. I guess you could say the representations are simply stubs for the real thing. This leads to a small class explosion because I need two of everything. This is tedious to maintain (even though in the context of a card game the number of classes is pretty limited) and was hoping to get some input as to what you guys think of this solution. I would also be very interested to hear how others have tackled this particular issue. Thanks!

That's not so bad Thanks!

Leadwerks is perfectly capable of dynamically raising and lowering the terrain. It's what you're doing in the editor after all, although I wouldn't know the exact commands not having tried so myself.

What would the licensing be like if one would decide to use the Awesomium wrapper for a commercial product?

When I said awkward I meant the way it is part of the engine. I would probably have never gotten those spiffy effects to work without pouring hours and hours in myself and gratefully use it but I think it should have been a more integral part of the engine because right now, it feels like a bandaid. Yes, that feels right

I believe Josh said there would be no "Framewo/erk" in LE3. And let's be honest, it's an awkward addition as it is.

If you're not using Leadwerks server-side for physics or anything then there's nothing stopping you. Streaming terrain is not mandatory.

I tend to disagree. Granted, Unity has a far better editor, but engine-wise I think LE runs circles around Unity, in both eye-candy and API usability.

Compiling is not encrypting. Obfuscating the code would probably more effective, although I'm not sure if there are any Lua obfuscators.

Yeah but his problem is that the converters are not in the evaluation version