Rick

Oddly enough so did I above. Maybe it was hiding.

I agree that would be ideal. If he would give Lua the ability to have bodies created from Lua to have collision callbacks this could be simulated without CSG, but he hasn't done that yet. I wouldn't think it we be that hard to expose the set collision callback method to Lua and instead of a C++ function we define a Lua function as the collision callback. We can do AABB manually too I guess with the bodies, although most likely inefficient.

If you google for something like Lua encryption I'm sure someone has created some encryption library for Lua that you can use.

Yeah, sadly the best we have from within the editor is to have predefined model's and their physics attached to them. It's kind of cumbersome if you want tons of triggers of all varying size but sadly it's all we have right now

So does the above work for you because I notice you now have test = a value instead of just test. I would think test = value would be valid. You might be better off making a lua file by hand to be how you think you want it, then try compiling manually with luac to see what errors you get. Once you get that worked out, then you can make the file with code. But you can't just do "luac -o save.lua save.luac" inside a lua file. luac is an exe and to kick off an exe from lua you need to use os.execute("c:\\temp\\program.exe"). This is Windows specific I think, but that shouldn't be an issue right now.

Oh yeah. Looks like he's trying to save out saved game data if I had to guess with his lua filename. I was thinking of something that had functionality instead of just data, but yeah same idea. ESP gives a good point. I assume you can only compile a lua file that is valid lua syntax.

Just curious, why are you opening, writing, then closing the file? Have you tried just running the luac command you have there at the end against a lua file you already have? This gives me a cool idea though. Would be pretty cool to dynamically create lua files on the fly in a game.

I haven't seen Nio around here is a long time?

It is strange how it does kind of change how you program. When you know it takes no time at all to test something small you are more prone to run after every little small change you make it seems. At least I've seen that happen with me. That can be good and bad I guess.

It allows for faster development since you don't have to compile. Just hit the run button and see your code at work. Press the stop button, make a tweak, and press play again. Your code is now running again and it only took about 2 seconds. Plus it allows for some kind of structure of objects. In C++/BMax generally people don't create things to be reused even though it's ideal for reusability. I'm not really a fan of Lua, but I do prefer not having to recompile every time I want to test a change. Although I miss being able to step through code. Ideal situation would be a scripting language where I could step through it line by line like I can in an IDE. Lua can do that in certain editors, but not with how it's implemented into LE.

I get it, but I can't understand why you guys thought that way. Leadwerks just can't stay as an API. That seemed obvious to me after trying out other engines. If it wants to survive it has to go beyond the API, and there is no doubt in my mind that at some point, even though Josh says otherwise, it'll be all about the scripting structure for Leadwerks much like it's all about scripting for UDK, Unity, and Torque. I think it's the evolution of a game engine. It just seems inevitable. I thought Torque's scripting structure was horrible (although it's been 3 years since I've playing with my version I bought). I know I hear that often on these boards too when a comparison thread pops up. The way Unity does it's scripting structure seems to flow much better.

I agree the scripting side will be nice and clean and structured. I'm saying trying to manage both the C++ api and the scripting stuff can get messy for Josh to do. It probably would have just been better if he just had the scripting stuff to start with and the API supported that and that's what he exposed to people. Kind of like most the engines do today. Generally they only expose the scripting side of things you their users. Leadwerks is unique that way, but I have to wonder if most engines do that for a reason.

And spend a good chuck of time waiting on compiling and making tweaks and recompiling, etc, etc. It's just faster to get things just right with scripts than compiling. Really the cool thing about the C# scripting way is that it compiles on the fly right after you save the script. It does it in the background in a few seconds so it's transparent. I agree, there is no need. There is a want.

3.0 will do that. It'll just take time I know he had this other stuff in there, but sometimes it not just as easy as dropping it back in. He might have changed things behind the scenes to make implementing some of these a little different and time consuming.

I don't disagree with you, but it's my view that the reason isn't the API. It's the lack of tools around it, and honestly you can look at the other engines to prove that statement. The other engines that have AAA games made, have many tools that complement the engine. So since UDK hasn't produced a game without their tools to aid in that production, it seems logical that the toolsets could be the reason for that engines ability to produce complete games. Nobody is programming games from scratch with a core api anymore. They build tools first, like I think you have done, around api's, OR you use something like UDK that did all that already for you. Leadwerks's API is a state of having to build tools to help aid your game dev, but that's the stuff that Josh should be doing. He should be making the tools to help us make the games. I want what you want. I want the tools to make a finished game. It just sucks that Josh's vision to do this started out differently than the way most every modern engine that games are made with do it. It seems the issue you have is that you were told LE was one thing, and now it's changing and you don't like that. That's no doubt what will happen to the existing customers of LE. I know Josh says all 3 aspects will be equal, but there will be points where he works on one, where the coding people will get pissed, then the other where the scripts get pissed. Having these 2 ways of doing something is a task that I don't think can stand. It gets messy that way. Just look at Torque. C++ vs scripting and it's just a messy system.

I'm saying remove it from the "core api" and instead bring it to Leadwerks via the toolsets which are created from the Leadwerks core api. Clearly it's needed, but where it resides is the question. Should decent looking water really be part of the core api? We clearly differ here. I think it shouldn't be part of the C++ api. Water is a game specific thing. Putting it in the api wouldn't make sense, since the api is used to build game specific things. It belongs in the toolsets because water would be created from the api. Same with pathfinding.

If C++ had the ability to be loaded at runtime from just source files, I'd prefer using that but no such luck. So C# wins. Lua is just messy. It's old and crappy. It needs to be brought up to current times.

I'm confused as to how that flow you just gave should be part of the API. The ability to make bullet hole decals is there with the existing API. This is where the tools come into play. I agree. I'm just saying it's there. Most don't like it but there is something. Water is also one of those things that are kind of specific. Because of the bad system Leadwerks has today, he feels like he has to create the one true all water. Instead, if he had a more flexible system, he could play with making 5 different water types on top of what other people make and everyone can pick their own. That's why I'm saying it doesn't have to be core API stuff but addons with tools. Water is just a plane & shader system, which the Leadwerks API has functionality around.

One has to wonder how much is core API vs tools in UDK. I mean you have to use unreal script with UDK don't ya? The free version of it anyway. So really, much of what we might consider core API could be the tools around an API giving that functionality. So it's not really an apples to apples comparison. Leadwerks is trying to get to a place where UDK is. Having lots of tools around it to support it so a game can be made faster. This is my argument. If one considers Leadwerks API to be 95% complete, that last 5% isn't stopping anyone from making a game with it. At that point, it's the lack of tools to support it as a game engine and not just a graphics library. The tools wouldn't be part of the core engine, but they can fill the holes (one person might call them) that the core API has. Examples would be water. Water doesn't need to be a core API feature in Leadwerks. It can be extended on top of the core API. The core API has everything there to make water. Decals can be viewed the same. These types of things are just game features that can be built with the Leadwerks API and therefore can be created with tools. Really only true bugs would be considered core API issues. I'm sure there are a few of those that probably need being cleaned up.

But the reason he took some of that out was because he wasn't happy with it or it wasn't working right. He hated his old water but some people liked it more than what is there today. I think water is one of those things that you just can't make everyone happy. People will want different things. Technically water is complete because there is a water system in place today. You may not like it, but there is one. I also thought decals was in the engine already? Are they not working? Pathfinding is a big can of worms.

Having both is actually the ideal, (because why limit yourself) but it does add complexity if doing it with Lua. It doesn't have to, mind you, with something like C# as the scripting language though I really need to get my little example up and running with this. I need to take like a week vacation and get it going. It'll help show how cool this is in action.

I don't think that would have fit on the poll Let's play within the bounds of the poll. [edited] That's what he doing now. Just with Lua instead of C++ because I think I remember Josh saying Lua is easier for non programmers to work with in case they need to make changes or even try coding themselves. Plus the whole no compiling step is big. But I did agree with that 100% until I tried Unity. The power of scripting can't be denied. It makes for a much faster experience. Recompiling C++/BMax every time compared to scripts running isn't even a close contest in how much time is saved. The thing is if you want the code functionality running in the editor, it takes a system in place get that to work. It's easier to do that with a scripting language than with C++. This was all talked about though when he decided on Lua. I'm pretty sure I was in your camp with the C++/BMax object thing. I was very against scripting as well, but more against Lua because it's typeless and I think that leads to crappy coding. I'd still like the scripts to be in C++, but .NET is close enough and provides so much more functionality than Lua.

Just out of curiosity what other engines would you include in this and what API features would you consider core?

Very cool man! You are coming along nicely with this. Keep it up.

That's the problem though. Everyone has a different list and so the list gets bigger and bigger and would be enough to last Josh 2 years of work. Knowing the water perfectionist he is he could spend 6 months on water alone. All I'm saying is give the community better tools and a better structure and they will create those things or it'll even make it easier for Josh to create. It'll make it easier for us to plug and play different water. Decals can be game objects. Hell, if he allows C++ plugins someone can put RakNet into the editor to give already testing and reliable networking code functionality. Pathfinding is also something that can be a game object. I've seen it done and it works well. That is why I'm pushing for this. For some reason everyone thinks Josh has to be the one to make these. He doesn't. If he gives us the tools and interfaces we can make this and distribute them without any fear of compatibility. With a structure like this in place, we will stop relying on Josh for everything and more rely on the community. I think if mods have taught us anything it's that a community can really drive things. Now instead of just Josh having to make something, others can make it and if he likes it he can even take it and make it "official". It's like a bunch of free employees. Hell, we even paid him for the system.