Rick

I'm curious to see what people would think about and if Josh is open to a more component based pricing system with LE3 since it seems like things can be attached pretty easily. I feel like a good example would be the OpenGL 4 renderer. Seems like that could be a separate component that we purchase with LE 3 if we want it? What would be cool is if Josh could do a Kickstarter like campaign for components like this to get some idea on what the people want more. I don't think Kickstarter itself would allow this but maybe there is another site or he could make a Kickstarter like process here on LE where people pre-order the thing they want and the money is only taken out if that component meets it's goal. He could put up 3 "Kickstarter" components and whatever hits it's goal he works on. I wonder if this component idea could apply to a game also. Not one big kickstarter for an entire game, but smaller kickstarter like goals for pieces of an overall game. hmmm

That's the point of a state machine system YouGroove. You get to define your own states to do what you want. State machine systems are just a framework for you to define the behaviors.

Yeah, for sure they do have more than just the navmesh and state machine. I was just saying if we built a state machine system to the already provided navmesh it would be close to the core of what EKI-One is. It won't be exact but those 2 systems seem to be the core from what I can see.

Yeah I think the navmesh in LE3 gives a certain % of the features EKI-One. I think the community could build the state machine to make it even closer or similar. Clearly it won't be exact but close to the same.

Those parameters are arrays. Well they are pointing to an array so position[0] = x, position[1] = y, position[2] = z I believe. I don't know why Josh did it this way instead of just making them Vec3 types instead.

You know I've seen people win the Powerball lottery and get 200+ million dollars too This is why I talked about the ODDS are that a small indie team won't be making massively complex games at the level of caring about C++ vs Lua speed. A good number of these teams that make it also have people on their team who were in the industry to start with for many years and have the experience. Dream big, set realistic goals. I still don't understand the harm in allowing multiple scripts. If someone only wants to use 1 script then the multiple script system still allows that. Best of both worlds. Let the community decide which is best for them.

The odds (read not impossible but very slim. do you play the lottery?) are small indie teams aren't going to make such a game. It's important to be realistic about your goals. You can dream big, but your goals need to be reachable. You wouldn't try out for a pro football team with having no experience right? So I'm not sure why people with little to no experience think they can compete with the big boys and make such large games.

This is a misconception in LE. It's like saying SQL Server isn't a serious database. It very much is these days, just like Lua in LE is very serious. I love C++ too, but we are indie programmers and I promise that 99% of us won't be taxing the computers enough to worry about the speed difference between C++ and Lua. So then it comes down to available libraries, but that's where it gets interesting because you can expose any C/C++ library to Lua. I made RakNet bindings before and had RakNet networking in Lua in LE. The gap between Lua and C++ is actually pretty small, and even more so in the indie world where we generally aren't taxing the computers.

I wish MS would have just stuck with C++ instead of inventing .NET. However their implementation with MFC was a nightmare, but it's not as if that was the only way to implement their framework with C++. They seem to be going back to C++ now though so that's good. I also use .NET at work and like the framework but 99% of the framework could have been made using normal C++ and looked the exact same. I'm not a fan of C++/CLI though. The one script thing is something Aggror and I were trying to fight against but I don't see any signs that it'll change. It's not the end of the world but just kinda sucks and limits us in programming styles some.

Looks like the columns have a lightmap texture assigned.

Every engine has it's problems. People engine switch all the time and then blame the engine for why they can't do something. You'll have to work around something that doesn't meet your needs in every engine you use because it's impossible to meet everyones exact requirements. It's easier to blame the engine though than to face the reality. Leaving for other reasons, like not agreeing with the company, or whatever is different though and IS a personal decision.

Adding more platforms leads to more potential customers so can't complain about that. Although it seems I'll have to get a Linux box for testing so thanks for that Josh! You owe me whatever a new Linux box will cost!

Great tutorial! You might want to use local in front of those variables because I believe they are global otherwise, which can be dangerous especially with generic variables like active or the like as many scripts probably would have those named variables.

Did you place the texture on the model in the model editor and then save it or are you placing the texture on the model in the world editor? If you place the material on the model in the world editor, then if you load manually through code you'd have to load material manually and put it on via code also because that's what's happening behind the scene in the world editor. The reason you see it work normal if you already have it loaded is because of instancing. Loading the same model will have the same material applied. About the physics it sounds like your model is offset to the actual character controller. Turn on physics to see the where the character controller is in relation to the model.

I don't think it's the setting of the mass to 1 at a later time that causes the slow down, I think it's having so many collisions. The question then is how many collisions should LE3 be able to handle without slowing down much?

What happens if you set position after you set physics mode?

I don't even use dds anymore because I noticed this on I believe power of 2 textures even. I use tga now and have never had an issue. I've had dds textures that worked in LE2, crash Leadwerks 3, then when I convert to tga they work. I use Paint.NET to do the conversions.

Nice, I wasn't sure about this either. beo6, I was able to make a level picker script that sets a value based on what button was picked and then triggers your script. It's working great so far!

+1. It's not logical the way it is. Whatever scene I have open, when I hit play I'd expect that scene to be loaded.

I like the second option you have for positioning the camera. Would be nice to get the editor camera where you want, and then be able to position the game camera to that. Even if only showing the position/rotation of the editor camera would help in that sense.

I don't see any variables declared at the top of app.cpp. Not sure what you mean, but window, context, world, & camera are part of the App class. They are not global.

You might have to build from VS? Can't remember if that's the same error or not, but get VS 2010 express (free), open up from the projects/windows folder the .sln file and build for both release and debug. Then you can run. For every new project you have to do this. Also when a new update comes out you have to do this also.

Yeah, we worked around this. I hate saying that because I don't want Josh to think it's not important then that he fix it asap because this is a pretty basic feature of the editor. Will need to test if getting the parent works as I'll need that.

I noticed this a while back also.

This is generally why I always use entity->SetUserData(this) when inside a class. Then I make a base class like GameObject, which has a pure virtual ToString() and my sub classes override it and return a string that describes that class. class Player { public: virtual string ToString() { return "player"; } }; Then in your loop you cast the object to GameObject* and if not null call ToString() and compare the value to what you are looking for. OR You set a key for each entity when loaded and get the key in your loop to compare.