Roland

Maybe a bug or behavior by design? If you have a CGS object with a child object. In the editor the child will rotate along with the parent object when the parent is rotated. That's Ok and expected behavior. However if you rotate the parent object by a script (simple Turn command) the child does not rotate, only the parent. Tested same thing with two mesh objects (fbx) and in that case both rotates as expected when parent is rotated (both by script and in the editor)

YES! Grid Snap .... a milestone Thanks Josh

Turn snap on/off

Okay. Yes. That was just a tiny cylinder (a surrogate for a key). No problem and good to know. I'll keep that in mind. Thanks

Okay. I have now tested with high lighting quality. No change. The shadow becomes a bit more blurry but thats all. Just for the sake of testing I turn ALL setting to their highest levels and same result, so I begin to think this either an Engine limitation or a bug

Thanks for the suggestion. Will not be able to test until tomorrow. Will report then how it goes.

Just wondering why the shadows don't start from the bottom of this CSG cylinder as they should. The box is also CSG. This way it looks like the cylinder is a bit up in the air although it isn't when running the program. Is it a bug or me missing something. The light is a normal directional light. Both CSG items has 'static¨' shadows on. I also tested with a mdl cylinder, same result. This will look really bad in a real game. In editor Running the program http://youtu.be/BkHAaXRiOQ0

Thanks for your comments Lunarovich. Yeah.. I'm getting into it now and like what i see. Have now coded a Player (class) which can pick up Pickable (class) items and handle them.The items picked up is subclasses of the Pickable (class) and handles the action taken on pickup them self. This way I can avoid tons of 'IF' statements and a terrible mess in my Player to get things done with the objects he touches, My conclusion so far is that LUA is a very nice way to approach the game development. Again. Thanks all for your comments. I now how and when to use classes in LUA. This is great and I will continue using LUA as far as possible.

Would be very handy in the Editor

Yes Josh. I'm getting into it now. Script "class" is a really nice thing to deal with. Cudos on that.

Thanks @Lunarovich for the link. That seems like a nice thing.

LUA is kind of nice while developing as you so quickly can change things in code and see the result. But as you say I'm a bit worried about making complex class structure in LUA. I know its possible but really not designed for. I might do it this way then. First make the code part I'm working on in LUA and then move it over to C++ ( Code conversion from LUA to C++ is no big deal ). In fact you could still have the editor variables in LUA and quite easy access them from C++. I will make some test with such a system where a C++ class uses the editor LUA variables and all other things are in C++.

Coming from the pure C++ world I have a question for you who used LUA for a while.In C++ I'm quite used to make classes of most things to keep things apart. Now I wonder if this approach will hold in LUA also considering speed. Or in an other way. Is there high speed penalties for accessing external class methods in Lua compared to simple functions or is the difference negligible

After having beeing away (far to long) doing other things I'm back and catching up. I have a game idea which I have started my preparations for. The game idea is actually not revolutionary in any way. Have been done before many times by many. Its the Explore An Environment, Being stopped by some difficulties that has to be solved before getting further on. The name of this is "Zero - In search of the void" or shortly just "Zero" Zero is heavily inspired from the old game "MYST" released back in 1991 without being a clone. The game is the exploring type of game where you have to solve different problems to get further on. No guns, No blood, No fighting. If you are finding that boring this is nothing for you. I'm just so tired of all shooting/fighting game. Actually I have no direct story besides the "explore -> solve -> next" so nothing new here, just same old stuff done so many times before but hopefully in a compelling way. It is a First-Person game, nothing special about that. Will use the FPSPlayer script as base and make modification where needed. Point and click to handle objects. A simple inventory will help you collecting useful things. So actually no fancy stuff, just a simple traditional game. I have an idea on how the game will be, but no written plot or something like that. That's not what I would recommend to others, but I will take things as the come, which may lead to throwing away stuff that did not go as expected or adding other things. I don't worry to much about that as I'm alone on this. Right now I havent any fancy screenshots to share except a logo.

Well... I can definitly tell that I have NO use of hair tesselation... I would be happy for just hair

+1

I can understand the goal of LE. It must be quite hard finding a successful road among all the competition out there. The reason I'm now using LE is in fact its simplicity (specially with LUA). I have to admit that I miss some of the advanced graphical stuff offered by the big dragons, but its no showstopper in my view. PBR is quite beautiful I have to say, but for my simple needs its not a big deal. I guess there are quite a number of "simple users as my self" out there whos primary goal is to make a small simple game with mostly premade components interacting by LUA scripting. Of course I would want both PBR, much better water, animated clouds and all that, but again. Not a big deal for small simple games, but much welcome if offered of course. One danger with the 'simple' approach Josh, could though be that LE ends up i just another FPS-creator, so watch out for that and don't throw away your graphic skills to much. LE must be better than the existing simple game creators although it doesn't have to compete with the big ones. All in all I think LE is on the right track. A BIT OFF-TOPIC (sorry about that) ---------------------------------------------- What I would like to see is more premade scripted game objects as different cameras, fires, explosions etc. that more or less could be dragged into the project. Another thing would be that the flowgraph editor would be expanded and made better. That tool is great for making life more easy even for non-programmers. Right now its a bit to simple for some serious use. With some grouping of objects where a number of related objects could be grouped and folded to one box or expanded for editing it would be great.

Yes. How could I forget the glue and all the newspapers. It's with a little tear in my eye I now remember me and my now deceased Father spending hours upon hours building the perfect model rail landscape together. A beautiful memory. Thanks for reminding me of that Josh

Whow. Did you also have a model railway with terrain. Cool. That was the first terrain I ever did, using mosquito-net, plaster, sawdust and colors. These days making a terrain is a bit more virtual but quite fun anyway.

Oh my good. It was even worse. Its one year and five months

So after 5 months it is still not documented. Maybe time to ..

Use the support mail I guess

Aswer to myself Found this one. Seems to be an extension to VS2013. Will test that one. Would be perfect for projects with both C++ and LUA https://babelua.codeplex.com/

Is there anyone using another LUA IDE than the built in. Nothing wrong with that one but its a bit limited. I'm not to familiar with what's out there and what suites Leadwerks nicely. Any suggestions? /Windows/