Rick

I personally don't think the entities should have variables, just the scripts attached to them. Each script should be creating it's own "instance" for that entity. So for example the variables in a script that is attached to 4 different entities would have it's own instance of those variables per entity, essentially making those variables apart of the entity itself, but indirectly via the scripts. In my view entities should basically be dumb. They are just placeholders for scripts and other objects like a model or a sound object, or nothing but a script that runs game logic. You build on these things to an entity to make it smart but it's not the entity that is holding anything but the objects attached to it.

Are you thinking along the lines of letting artists do a kind of vert animation via an editor that could be saved to file and played back on the specific model via code? Like you move the verts to where you want (from some editor), snap a keyframe, then rinse and repeat and have the playback code interpolate between keyframes? I read somewhere about facial animations and how they predefined facial positions to spoken letters and then you would provide the text of the sound file and the code would read the text and build the facial positions required to speak what is in the text interpolating between the letter positions for the verts defined for each letter. The artist would just have to provide snapshots of the verts for each facial expressions one makes when saying letters (or groups of letters since some letters share facial expressions).

The GUI looks nice, but I would think the GUI of the tool to connect to a custom database system would be a task way down on the large mountain you are about to climb. You must be a GUI guy because if I recall correctly most of your posts are about GUI's

Perhaps you can give each script a name property which will be the script file name itself and we can access it like: FindScript("characterstats"):AddHealth(5) or somehow be able to prefix the script name directly like characterstats:AddHealth(5) Then require that you can't attach 2 scripts with the same name. This would help reduce confusion for newbies and pros both. I would suggest also a FindEntity("") that can be called from any entity to find another entity in the world. Then FindEntityTag("") to be able to group entity types in the case of dynamic entities.

Yeah, I agree. If you goal is to hit as many platforms as you game Lua is the way to go.

You could, you'd just need a better virtual machine that is optimized for gaming as opposed to using the default one. Bad for LE because of how it's take on Lua but not bad for everyone. C# can do anything Lua can, which is why engines like Unity use it for it's scripting language. C# is a scripting language.

Sorry I didn't say this, but I meant in the context of on the XBox but Mono makes C# cross platform too, it's just not MS official. I for sure agree that on mobile devices C# isn't the best way to go. For consoles and PC's that have more processing power to spare it's great, but for mobile devices where you are fighting for every single piece of processing power you can I agree it wouldn't be ideal at all.

I'd be shocked if you ran into something that C# can't do that C++ can actually. I'd venture to say .NET has more library support and functionality than C++, and it's easier to setup and use too. That's saying something for a framework that is a baby when compared to C++. That's why it' so popular though.

I can't imagine actually having the job to do that stuff. That would be strange to tell your spouse what you did at work all day. That was a very interesting article though, thanks for sharing.

That sounds more like you are just more comfortable with C than C++ so you are faster with it. If you would learn C++ more and use it more you would be converted, but you would have to approach it in such a way of learning instead of getting a project done. That's just making the learning and using part a priority instead of just getting a project done. vs what? 10 seconds? You remind me of a Saturday Night Live skit back in the day where they did an infomercial that will save you seconds in the day by shortening words when you talk.

I'm confused. Oh nvm, that's what I get for viewing new content and not looking at what forum it's in.

I prefer exceptions over error codes these days.

I think you can get away with just that though and leave it up to the programmers to handle the rest. Honestly LE's models are just another piece of data that describes "real" game objects. Nobody is going to make a big game like this without making their own game object objects that just have an LE model as another variable inside these objects. The behavior of the object belongs to the actual game object class and not on the model. The model is just a visual and nothing more. A model is not a game object like how LE seems to try to make it, it's just another piece that describes the game object. So the programmers can manage their own game objects and assign models to them if we have a way for LE to tell us what model has loaded and some properties tied to that model so we know what game object that model belongs to. The models that don't have any functionality, then it doesn't matter either way with those. Honestly if you just allow loading on another thread, and give us a callback to tell us when what model was loaded would give programmers what they need. You can leave it up to them to manage at that point then. Make us do null checks in our code to validate if a model gets released by the engine, that's fine. Maybe this is what phase 1 of this could be before you start worrying about how it all fits into the Lua stuff.

I think the idea is that it doesn't rule out making certain types of games like it does today. I know the talk will go to what's realistic for indies to make but it still does rule out certain types of games no matter if people thinks it realistic or not for an indie shop. I also apologize as I was the one in another thread who said we were getting this. From some of the talks that happened around this area it seemed like you were making this feature. Again, I apologize for reading into that incorrectly.

I don't mind an Open() method. It's how the .NET database stuff works and I'm fine with that.

That seems like it would still require code to look up this value and play the right footstep noise. In that case couldn't you just do the same thing where you raycast down to see what surface you hit and get the material and play the sound based on that? Seems you'd basically have to do the same thing anyway.

I've never heard Josh talk about giving us more control over the scene graph, but he does plan on letting us load models on another thread. It would be another parameter to the LoadModel() method. We are hoping for some kind of callback then that let's us know when the model was fully loaded.

LE is not thread safe. It will crash. Do a search and you will see a bunch of posts on this topic.

The short answer is no, but you can preloading that model before hand. The models are instanced so once you load 1 specific model, loading others will be close to instant and not cause any slowdown. So the idea is to load a model you know you'll need to load at the start and just hide that one. That preload model doesn't have to be used in the game really but just used to get the model from file so other loads are "instant". Hope that makes sense.

I guess the question would then be is a function call (to get the keys) and an if statement (to check the keys) for every loaded entity more expensive than storing your own list that probably has just a handful of entities in it for the selection list more costly or not? I would venture to say looping through 5 or so entities in a separate list is cheaper than checking every loaded entity for a specific key value. Of course the more entities you have loaded the better the separate list way is.

Your second statement is why your first statement doesn't make sense. The reason he wants to add selections to a list is so he can loop through them quickly. Dozz, an stl list works just fine.

That may be the case, but it's still officially supported by Josh and he has made changes to it given user feedback and bugs. Also, if Josh leaves the LE community, LE basically dies which means you don't have to worry about support because it'll be dead. If Joe Blow leaves who was supporting C# from a community standpoint, LE still continues with the other languages but the .NET community suffers.

Lua is officially supported by Josh though. He is the Lua leader and even worked with external people at points (I believe) to get some things working with Lua. That's the difference between officially supported and not.

Or, instead of doing all that, we could meet Josh's requirements (which aren't unreasonable) and have a better chance of Josh putting the official support to it.

That's basically what we have today Lum and it's not working. The people in step 4 always leave. In LE 3 it sounds like the procedural concerns won't be there and instead mimic the C++ OO version in C#. Which should be very doable, but requires not being tied to the C# mentality to a T. I disagree with your number 3 point. This is no way the same as GameLib. GameLib has specific game oriented and additional functionality that compliments the LE library. C#'s goal would be to provide the exact same functionality of LE so it can be used in another language. Just like the Lua port Josh did. C++, Lua, BMax, & C# would all be identical in functionality and look and feel. I know you would ask why anyone would want to not just use C++ but there are people out there and Josh is trying to mass appeal. 1) There are slight differences mostly due to callbacks and the extra parameter that Josh has. 2) I don't believe there is such a thing currently. 3) People don't want to work with unsupported languages and deal with the community drama and lack of response that comes with it. 4) Hasn't work and I would argue rarely does. There is little to no motivation for someone to stick around and deal with all the bugs that will come up and answer all these questions and deal with support stuff. Unless they are getting paid that is The fundamental problem for people using C# in LE, is that there is a bug and the person who wrote the port is no longer around and you find out your support is basically zero, and you don't want to spend your time messing around with the C# port code but instead make video games. Within the last 3 years I think we've had 4-5 different versions of a community driven C# port library. That tends to discourage the C# user base.