Canardia

1) You can make as many games you want 2) The EULA is quite clumsy formulated, it basically wants to say that you can't make fully moddable games which would result in whole new games, but making little adjustments to a single game is OK

Parent the camera to a pivot and move the pivot, but rotate the camera. Use PointEntity on the pivot to align it to the target waypoint, and use PointEntity on the camera, to point to the look at target.

It's always child 0, unless it has been changed. I think also FindChild(scene,"terrain") works, and should be used to ensure future compatibility.

TTerrain terrain=GetChild(scene,0);

All I really need are two hotkeys, like F11 and F12 which both can launch a cmd or exe and get the sbx filename as parameter. Then I would put under F11 the actual game.exe, and under F12 the Code::Blocks IDE.

BlitzMax is a bit different than any other language, because it doesn't use the standard engine.dll. So you have to start your program like this: Framework Leadwerks.Engine Import "d:/le/Framework/Framework.bmx" Or whereever you installed Leadwerks Engine, I put it in D:LE because C: is for system only

Yeah, the x and y axis rotations are reversed in LE (compared to natural logic), but you can easily fix it by changing by adding a "-" sign in your C headers in the TurnEntity and RotateEntity functions. There you can also fix the cycle. Of course everyone has a different opinion how axes should be faced, and I find the idea that righter (x+), higher (y+), deeper (z+) is the most natural way for me.

New potatoes are actually quite good with salty butter.

Actually it does, when you use the SDL Haptic library. It supports also PS3 force feedback. Not sure if the driver supports it though, so maybe indeed some modification to the driver and/or haptic library is needed.

I think you can use XBOX controller on PC too, because I can use my PS3 controller on PC. I only installed a PS3 driver on my PC, and then it detects the PS3 controller like any ordinary joystick.

Also the pint sized stainless steel thermal Leadwerks Coffee Mug is missing! I have one

You can mix C++ and Lua quite seamlessly. You can have all the models have their own Lua scripts, which saves you a lot of coding on the C++ side.

I would use C++, because then you don't ever face performance problems when your game grows bigger and more complex. For example in my robot walker demo, I had to do quite a lot of iterations to calculate all the robots limbs, and I first made the demo with Lua, and then with C++ and the C++ version was about of 30-40 FPS faster. With C++ it's also easier to include various 3rd party libraries like SQLite3, WxWidgets, Qt, Force Feedback controllers, etc... Which you need to wrap and implement for Lua yourself.

Sounds like you are using a material which needs 2-3 textures, but you provide only 1 texture, so the remaining texture slots will get a random texture from GPU memory.

The students could work on a 32-bit and 64-bit Linux port too. Make sure they work under 64-bit Debian 6.0 Linux environment, so they learn to write cross-CPU code too, and test it under ARM, PowerPC, Intel, Motorola, etc....

You get a dynamically adjustable orthogonal projection by increasing the camera zoom, and then scaling the models down and/or moving the camera further away.

Maybe you need to tell CEGUI to pull the mouse button up again? if(MouseDown(1)) { mysystem->getSingleton().injectMouseButtonDown(CEGUI::MouseButton::LeftButton); mysystem->getSingleton().injectMouseButtonUp(CEGUI::MouseButton::LeftButton); }

But yeah, physics preserving teleports are possible and easy to do. I already did them in the LCP1 game years ago.

There's no need for that, because when the collision occurs, you can always check the position of entity0 or entity1.

I think it's neither. It's the global position of the collision itself. For example if two spheres collide, it would be a point on both sphere's hull.

Finding the correct structure for actual content and keeping also future content in mind, is not so easy. Usually you just start with one setup and then adjust it to better suit the needs in future. Unless, of course, you have already done that earlier and know what is best for all cases

I was just thinking, that there should be a seperate Tutorials section too, like there was before, because it would bring the benefit, that the Blogs/Articles/Tutorials would then not be too overcrowded over time, and it would be easier to look for a specific Article or Tutorial by browsing, if you can't find it via some Werkspace wide Search function. Also Blogs and Articles are more time-based, while Tutorials have nothing to do with time, but with topic order. Articles can be also topic based, if you look at them like a knowledgebase library, but that can be easily done with different sorted views, one by time, one by topic.

I still think the window class + keystroke macro should be possible with F5, or then F9 in Editor, if you do some wierd stuff with Lua states in F5. Or then you could add the possibility to write Lua or dll plug-ins for Editor, then the community can make that.

Ok, I think I got the idea. So kinda reusable and universal stuff goes into Articles, and specific stuff which applies only to my own projects, goes into Blogs (although it could be a lesson learned then also, but that's then again that overlap).

Ah ok, that explains why I always write Articles, because I always write technical articles about some tips & tricks or reviews about some products. The only place where I talk about myself would be Facebook then Hmm, does that mean that all the Blogs I wrote in Werkspace, should be actually moved to Articles then?