Rick

Can't I call GetPosition() on a controller? I'm trying to make my model follow my controller, but I get an error saying pos1 is nil value when I do: local pos1 = object.controller:GetPosition() self.characterModel:SetPosition(Vec3(pos1.x, pos1.y, pos1.z)) My controller is there I can see it.

lol oh. Your original post was confusing I view that as meaning the function seems to be gone. As in the GetEntityKey() function, because that's the function. Really the function isn't gone, that specific key is. So what you are saying is the key name "classname" seems to be gone. OK, now I understand.

I can't try it atm from where I am, but I can't see how it would be gone. Keys are a big part of storing info in entities, and it works for lua.

Oh, this being in General Programming I was confused. Should probably put this in C# forum to avoid confusion.

Really? What kind of horrible thing is causing that? That seems very lame of a language to restrict that.

Maybe it's a different language you are talking about but don't you have to pass in the entity to GetEntityKey(ent, string)?

Looks clean and crisp. I like it. I really hope this C# version sticks around and has all the functionality of the other versions because I prefer working in .NET.

That's not a bad idea. Instead of a bool it could just be a file selector that lets you select the lua inventory file to use and it'll just run that lua file. The character would need to be the one to call all the functions though inside its functions that LE is calling. Like Update() and such. Plus that lua file might not be able to look the same as other objects because you'd have to recreate how LE does all that stuff. Something to think about though. I just love the idea of adding objects to a scene to make a game It's so easy and reusable.

I think it would just mean you couldn't have a scene with a large amount of the same model because it would take up so much memory compared to the way it is now. I would say things like tree's but I think he made that neat trick with vegetation where you can have a ton of trees and it doesn't take a big hit.

Where are the hackers at? I'm sure it can be figured out by some nice memory snooping tools. I wouldn't think that's a big deal to Josh.

You can take that 25% rebate and get UU3D to convert them to GMF.

I have to imagine this is possible. I mean if we know the way it's stored in memory and we have a pointer to that memory, there must be a way to copy that memory to a new memory location. That would essentially create a new instance of that model and allow you to do whatever to it. So we need to get the size of a load model object in memory. I guess I just don't know how to get the engine to see this new model memory though. It would have to be able to be added to the world somehow. LoadModel() must do this. If we knew how it does that we could make this work I think. Either way, this should 100% be added by Josh to the engine. It's such a basic thing to have.

Well the issue is, the character object is an object just like any other. When you make a new scene you have to drag that character object in again. But that's a good point that the character object would also need a sqlite file to store off it's attributes so it can go through multiple scenes. You could do what you are saying, but then for different inventory styles you would need different character types. Remember that the inventory object also does the 2D drawing of that inventory. So that can be very different between inventory styles. I'm trying to break this down to objects like I would in C++. In C++ I wouldn't include inventory code inside the character object. I would have a separate class to handle that because it becomes easier to plug and play different inventory styles and makes it more reusable.

Do we have any way to make a copy of the model/mesh from memory instead of from file? That would be way cooler and cleaner as this "could" cause files to get left behind if something happens between making the file copy and deleting it. Although it's unlikely it would just be cleaner to be able to copy the memory of a loaded object already. I have to imagine there is a way to do this. I mean if you have a pointer to the loaded model in memory, we should be able to copy that memory to another location and get a pointer to it. I'm not that handy with low level memory stuff though, but it would be much cleaner that way. Can't we do something with memcpy() in C/C++?

Either way, no biggie. By having the .Enabled and such as opposed to just making the effect name true/false it opens up for future expansion of new effects that have parameters or old effects to get parameters at some point and could save you time & consistency issues later. That's all I was thinking. Otherwise I like it.

So here is what I'm thinking for an inventory object that you can drag into your scene. The inventory object would check for an existence of a sqlite db file. If it's not there it creates it. You place an inventory object in your scene and assign it a target, making sure the target has a name assigned to it. In general you would only give inventory to the player character, BUT if you wanted to give inventory to other NPC's you could. You would drag another inventory object in your scene and assign it a target. This inventory object would be pretty specific. Because of this you'd have multiple kinds of inventory objects. Something like a FPS style like HL or a RGP style with bags. The inventory object would also provide the 2D HUD for it. The reason the target needs a name is because that's what the inventory object uses when it queries the sqlite db table to figure out what items that character has. The cool thing about this is it would persist through multiple scenes. To create a different scene you would just drag a character in your scene, give it the same name as the character in the last scene. Drag an inventory object to your scene and make the character it's target. Because the database would exists, the inventory object opens up the db and reads the table passing in the targets name, which because it's the same as the other scene it finds what it had from the other scene. Thoughts? Gaps? Anything? I'm at work bored out of my mind One of the cool reasons I like this is because it becomes very easy to test things out inventory wise. Let's say I'm creating a RPG dungeon scene. It becomes very easy to test out different inventory stuff. Each time I open my bags the inventory object would query the db and return the items. So if I'm inside an engine I can just have my sqlite client open and add inventory to the table that I can then use instantly for testing.

When I get home I could give you my 3rd person camera object for lua. It's not ready yet, but it will allow you to rotate the camera around any target you give it. It just doesn't do any collision checking so it goes through objects and such. It's really easy to use though. Just drag it onto your scene and give it a target and it works. Providing the game .lua file you use is one I provide which is easy to change also from the editor.

Just curious, why did you decide to stick with the old way of Foo.Load?

I was just thinking that from what Josh has said in the past that making things thread safe wasn't a huge priority for him. I just really doubt it'll be looked at anytime soon and I'd be nervous if he did it anyway because I'm guessing it would introduce all sorts of bugs at first and make us unhappy. I seem to recall more than just LoadScene() would need to be changed because if something was 1/2 loaded and you call the rendering method it would hose things up because it would try to render something that isn't fully loaded yet. Something like that. I'm not a big threaded guy. I have a couple threaded apps at work and they are a pain in the wonderful person to debug with VS's stepping through code. I'm having to freeze threads and all that ****.

Maybe he meant all items over $50 and not the entire order? I'm not sure if anything he has cost $50 or not.

So what is this all about? Are you saying if I run from engine.exe vs editor.exe the case is different? That's not cool.

Just throwing ideas out, but couldn't you simulate this without threading? By parsing the sbx file yourself you can store all things that need to be loaded in a container. Then over multiple cycles load a few things in the container. This would allow you to keep the main loop running to give you a better progress bar. You could also get a count of how many things need to be loaded to give an accurate progress bar. Sure while it's loading 1 model in the container it would be frozen for a second or so, but if you don't have anything moving around constantly the user wouldn't notice. For that game I'd put up a cool 2D drawing in the background (because the art style is very cool) and use a progress bar on top of it. That being said, yeah thread safe would be nice, but until then above is how I would handle it if I cared enough about that limitation.

That looks clean. The only thing that seems backwards is: Framework.Effects.Water = true; Framework.Effects.Parameters.Water.Height = 2.0f; I'd think it would be: Framework.Effects.Water.Enabled = true; Framework.Effects.Water.Parameters.Height = 2.0f; That seems more logical to me. Or really you wouldn't even need Parameters just Water.Height. That's the more .NET way of things

I agree. Having the same model but different textures is very common.

Bah. Duh. I just wrote it out in true or false and realized it. I swear when I get into a new language the most basic things escape me sometimes. I need to just go to sleep.