Roland

Couldn't say it better than Aggror, except even more patience, trial and error of course There are no shortcuts

Yes that worked. Thanks .. how in the heck could I forget about Release I'm soon in that age when it could be explained by dementia. Guess this is kind of solved then

When writing to a file using FileSystem/Stream the content is not flushed to disk directly when the filehandler is set to nil. A close() or flush() function would be a solution to this. Here is my test -- FILE IO TEST local fw = FileSystem:WriteFile("test.bin") if fw ~= nil then System:Print( "*** FILE WRITE" ) fw:WriteInt(12345) fw = nil end local fr = FileSystem:ReadFile("test.bin") if fr ~= nil then local value = fr:ReadInt() System:Print("*** FILE READ = " .. value ) fr = nil end The result ===================================================== *** FILE WRITE *** FILE READ = 0 ===================================================== After the program has finished the content is 12345 as it should be. Here is the same with LUA io-operations which works --- FILE IO TEST local fw = io.open("test.bin", "wb") if fw ~= nil then System:Print( "*** FILE WRITE" ) fw:write(12345) fw:close() end local fr = io.open("test.bin", "rb") if fr ~= nil then local value = fr:read() System:Print("*** FILE READ = " .. value ) fr:close() end and the correct result ===================================================== *** FILE WRITE *** FILE READ = 12345 =====================================================

Most impressing *thumbs up*

I reported this as a bug ages ago

Have you set a collision shape for the model? Model Editor/Physic

That was a nice one. I always have replaced the main with WinMain, changed the subsystem and fixed the argv stuff. This is far better. Great

Yeah. Here is a high five for the Flow Graph Josh

Thanks a lot Josh for the explanation

Ahh.. yes. Not the same thing. Sorry

http://www.leadwerks.com/werkspace/page/documentation/_/object/objectrelease-r21 http://www.leadwerks.com/werkspace/page/documentation/_/object/reference-counting-r613

I'll take your advice guys and go with the premade icons. Diving into this will probably get me into a long and winding sidetrack. Thanks

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.