Roland

I will see what can be done with this one... maybe ... http://www.leadwerks.com/werkspace/page/api-reference/_/camera/camerasetrendertarget-r901

Hmm... I want to a snapshot of the object I'm picking in the world I'm walking in. The snapshot should be taken in real-time when I pick it.

In what I'm working I have an inventory showing items collected along the way. Those items are collected by picking them (using a raycast for that). Now that works great. Currently I have made an icon image for each item that can be picked and added to the inventory. The inventory then show a list of those icons. Even if that works I would really prefer to have some automation here. What I would like to do is to render the item picked to an icon image (32x32) and then use that image as icon. This way I wouldn't have to go through the trouble of making icons for every object that can be picked and added to the inventory. The render would also have to zoom in so the entity fills the image. Anyone have done such a thing or at least have some hints on how to do that?

Thanks all for the input. It makes it a bit clearer what the difference between the two callbacks are. As I have it now I have mouse-smoothing and such in UpdateWorld, seems that it would be better to have that in UpdatePhysics if I understand this correctly. Same for updating animations I guess.

Can anyone give some directions on when those should be used. What's the difference. I have in the example's that some actions are programmed in UpdateWorld and some in UpdatePhysics. I have a problem understanding the rule what to do where.

As Josh wrote, even if VR becomes a flop, the normal engine usage will still gain from this. So I wouldn't worry

Very well done. Congrats

Well... Forget it... Doesn't seem like such a popular suggestion

You are missing the point. I personally have no problem doing that. It's more a question about what's official supported.

There are now direct advantages other than you don't need to have two sets of project files if you are making your game for both Linux and Windows (and ..maybe later om MAC). The idea and advantage is to have one IDE and project for all platforms. Josh would also gain from that as he wouldn't have to keep track of project templates for several different IDE's.

Why not make life more easy and go for CodeBlocks on Windows as in Linux. One IDE for both environments. Saves time for the user and for you Josh. One IDE to support instead of two. And when the day for MAC comes CodeBlocks will work there also. Better for us users and better for you Josh as you don't have to jump between different IDE's not to talk about the maintenance of project files.

I would not recommend changing anything in the Leadwerks header to solve a local compilation problem. There is nothing wrong with the Leadwerks headers. The problem is local to your installation. Solve the path-include problems instead of editing the headers. Maybe you should give a re-installation of Leadwerks a try as the problems you describe should simply not exist in a fresh installation on Windows. If that doesn't work you could always post you project file here or PM me. Two files are of interest "projectname".vcxproj and PropertySheet.props, where "projectname" is the name of you project.

What does your build log say? Any more clues but just that sentence.

Thats strange 1. Is LeadwerksHeaderPath really pointing to the correct place? 2. If so, are the files really there? This is how it looks at my place

$(LeadwerksHeaderPath)\Libraries\OpenAL\include

Thanks Josh. That changed nothing. However I have found that the reason why its working for you is that you are having "using namespace Leadwerks;" in your headers. I tested by adding that to my example Doesn't work #include "Leadwerks.h"//lua class Test { public: Test( Leadwerks::Entity* e);//lua }; This works #include "Leadwerks.h"//lua using namespace Leadwerks; class Test { public Test(Entity* e);//lua }; Pgk-file (same in both cases) $#include "Leadwerks.h" $#include "Test.h" class Test { Test(Entity* ent ); }; I don't like to have 'using' in my headers but I'll guess I can live with that for my Lua-exposed classes so I guess we can say its solved then. Thanks for taking the time.

Really. Could you give a simple example. class Test { public: Test( Leadwerks::Entity* e ); }; gives an error at runtime saying that argument #2 is a Leadwerks::Model This works though class Test { public: Test( void* e ); }; in LUA Script.cpp = nil function Script:Start() cpp = Test:new( self.entity) end

Aha. That explains it

Thanks and glad you liked it

To be picky The public method ClearAnimations also have a potential memory leak as it can be called from anywhere and it erases all elements without deleting them. Easy fixed by moving the delete loop from the destructor to ClearAnimations AnimationManager::~AnimationManager() { ClearAnimations(); } void AnimationManager::ClearAnimations() { for (auto it = animations.begin(); it != animations.end(); ++it) { delete *it; } animations.clear(); }

Tested the C++ version. There's a memory leak here if (n < maxanim) { if (completedanimation->mode == false || completedanimation->endOfSequenceReached == true) { animations.erase(animations.begin() + n); } } should be something like if (n < maxanim) { if (completedanimation->mode == false || completedanimation->endOfSequenceReached == true) { delete animations[n]; // prevent memory leak animations.erase(animations.begin() + n); } }

Very interesting reading.

Great and thanks. Would be great if we didn't have to guess though

I like the idea. I'm making my game for both Windows and Linux. Thumbs up!