Rick

I agree actually. It would be great to just look at the ideas floating around. We are doing this to try and build a community who has a little bit of say in some features. They could have a sense of ownership in the direction some of the game does into really. It would be interesting to make a game from scratch with something like this. Like just a big list of features are available and people vote on what they want and that's what gets worked on

This is really all about the structure of your code since anything you want to be drawn must be drawn every frame. This means you'll end up with boolean to check when things should be drawn. There are way more advanced ways of doing this like state machines but they are fairly intrusive into your overall code design. The "simple" (and I have this in quotes because for small games this works but for complex games simple turns into a nightmare to manage) way is to do something like: bool showInitDialog = true; void Draw() { if(showInitDialog) { // draw the dialog } } void Update() { // determine when to set showInitDialog to false by either a timer or user interaction }

We'll get there

You may know that but a new person coming into LE and only has Lua version isn't going to know that.

That's what the OP was saying. These constants don't seem to be available in the docs. Mack added to the comment section so we can see the constant name (and we make the assumption it's the same name in Lua).

We're getting away from it in our game because things are just getting to be too much and we can't organize it without features that promote organization. Connections are breaking when we update prefabs and it's just becoming too painful to deal with. I'm a big fan of flowgraphs but I'm of the mindset that if you're going to have one then go all the way with it. Sort of half committing to it is almost worse than not having it for anyone who has a decent sized game. Currently for small examples or demos it's fine but that's it. The "connection" between node and entity should be a soft connection. Yes, this can bring run-time errors if an entity is removed but still referenced in a node but at least you don't force manual reconnections when things are updated. That's the biggest pain of them all. During game development entities get update constantly.

I didn't. I should do probably do that, but yeah it'll be interesting to see what Josh comes up with.

I have 3 at work and would love to do that at home but don't have enough desktop space. I think 3 is a sweet spot. LE editor on 1, VS on another, and a browser on the 3rd googling for coding stuff. In actuality I hate the fact that the Lua editor is always on top and connected to the LE editor. Often with 2 monitors I have the LE editor open on 1 and the Lua editor on the other, but I then have my browser open behind the Lua editor. So then I google and want to keep my page open but when I click the world editor it also brings the Lua editor to the front over my browser. I hate that they are connected. I honestly don't step through the Lua editor much because it has some bugs I've noticed and isn't very fluid as VS when debugging so I should just use another editor but it's annoying having to flip over to LE to run. I suppose Notepadd++ (and others) probably have some macros that I could run a batch file that I make to run the debug or release exe with parameters. I was playing around with making an editor using node-webkit and it was going fairly well as it was just combining existing javascript libraries, but I just don't have the time to get into some of the finer details that make a great editor. Not enough hours in the day Honestly http://luaedit.sourceforge.net/media.html looks perfect!

You gotta run dual monitors. I couldn't code without that anymore. It's just way to nice.

I find multiple scripts to basically be just like designing any other system. In C++ I create many classes to do various things and link them together. Right now basically I make Lua "classes" for various functionality and add them into the 1 script and hook them up. This isn't any different than multiple scripts though. This just makes me have to create a container scripts to attach to the entity that holds my other Lua classes that actually have the functionality manually. In a sense LE sort of does this with the AnimationManager script and that's good because it's good to logically break up the code for readability and maintainability.

I personally think this is good, but I find it interesting that people seem to like this fact that software is making it onto Steam but some are the same that hate the idea of the Windows App store. Steam is literally the same thing. Steam could be considered worse perhaps since it's slowly becoming the defacto app store for all platforms which means they will hold a ton of power which means you will basically be forced to release your software on Steam if you want to reach the masses, but that also means you are giving Valve 30% of your sales. I just find all the non-game software starting to get on Steam to be interesting.

Basically more Visual Studio like features

I think what beo6 might have been suggestion is that you do a mouse pick. That'll return a point on the 3D floor where your mouse is over. Now you have a Vec3 location. Now you can use some function like Point() to point your turret to that around the Y axis. Now this won't work if you can see empty space like in your screenshot because picking won't happen there but it will on the floor. So if your camera is angled in such a way (more top/down) where you never see blank space this method will work.

So the camera follows the tank and the camera follows it. Can you rotate this camera with the mouse like more 3rd person games or is the camera always at the tanks back and rotates when the tank rotates OR rotates with the gun on top of the tank? So with this are you saying you want the 3D gun on top of the tank to rotate around the Y axis based on where the 2D mouse is around the gun?

What is your goal here? What is the final result you are after? In 3rd person generally you would each frame move the camera to the location of the thing you are rotating around. Then rotate the camera here (if you allow free rotation use the mouse x/y or if you want it to match the thing you are rotating just get the y rotation of the thing you are following). Then use Move(0, 0, -dist) to move the camera backward by whatever distance you want. If doing this in Lua via entity scripts then make a script variable for the thing you are following to accept the camera entity and make the camera entity take a script variable to the entity it should be following. Now you can get anything between the 2 entities you want.

You don't. This was a debate some time ago and some still would want it, but the engine dev decided against it as he thought it didn't add much benefit as he deemed those scripts needed some kind of connection to make them specific and less generic which is the main benefit of multiple scripts. Some don't agree with that still, but attaching 1 script only does simplify things. What you can do is make your own lua "classes" that have functionality you want and add those to the script of an object. This is probably the best workaround to this. The best advice is that this isn't Unity and so even though that's your background it's best to not come in with that mentality to save yourself any frustration. The Leadwerks API is great and so easy to work with. Very little math is required to make a game which is nice and speeds development up. Focus on the good and note the bad and see which has more pros

I think the thing you are missing YouGroove is that these sub game players are in reality primarily for the people who use the engine in question to start with. This means you get more developers playing these games than non developers so they tend to forgive bugs and issues because they know what it's like. Yes, this will be open to everyone but I'd venture to say the majority of the users, to start with anyway, will be LE users themselves. People who think like you won't get this game player because they don't want to play buggy games. And that's fine.

This right here is truth I think. Gotta get the game looked at by the crowd that likes raw things to iron stuff out. By the time we're hearing hit songs on the radio they have redone and refined it to be that way by playing live and getting feedback.

I have a Lua table that has functions similar to the App table. I'm able to copy how App is called but I have extra params in my function and not sure how to add those. I'm really not all that familiar with stack type programming. My lua function is: function NoesisHelper:EventRaised(element, event, args) end where element and event are strings and args is a table. The way I call this without filling in those params is: int stacksize = Interpreter::GetStackSize(); Interpreter::GetGlobal("NoesisHelper"); Interpreter::PushString("EventRaised"); // push the Noesis table onto the stack as "self" Interpreter::GetTable(); Interpreter::PushValue(-2); Interpreter::Invoke(1, 1, 0); // restore the stack size Interpreter::SetStackSize(stacksize); What do I do to add 2 string and 1 table param to this function call?

Setting the pick's radius alone fixed the issue in the test project. Why would that be? Will test in our main project shortly.

Ah ok, read that wrong then. Will play around with that to see if it makes a difference. Thanks!

There should be a link in the first post at the bottom. Are you not able to get it?

You should put this on sourceforge so LE'ers can contribute to it and fill it out over time since it's pretty bare bones atm. Some of the most complicated pieces are still needed. Or you could fill it out and make it really solid and sell it as a Workshop item for extra revenue!

I can't see how we know when the button is clicked in your example. Where is the event handler for it's click event? If you go the Java route (which blows imho) we'd derive our own classes from a listener class that has virutal methods that gets called from the gui engine and inside we check what control fired them. Personally I think the .NET method is way better where we register C++ methods as callbacks to the events. In C++ this can get fairly complicated, but C++ people would know what's up. It should be really easy to define event callbacks in Lua though if you plan to bring it there. Does this handle different screen resolutions and aspect ratios? Anchoring, like Agror's GUI, seems to be the best way to handle control placements, and he has some calc's for control sizes based on a base resolution. This part is really the bread and butter of any GUI because this is the trickier part. Can't lock users into 1 resolution.

But we are talking about a community project. I guess we have to ask what defines a community project? If a person makes a skeleton of a game and asks for certain tasks and people from the community contribute does that still make it a community project? One could argue that makes it that persons project where some people from the community contributed vs a project where the community voted on the genre and some high level decisions as well as doing tasks. You have to ask yourself if you'd feel you are part of a community project if you made no decisions on it but just contributed a few piece of art (or code in my case) to some guys project. Or, would you feel you were just contributing to that persons project.