Rick

Need way more details. Line 58 of what? You need to show us the code that is having the issue.

I think it's calling Release()

I guess I don't follow what you mean by "without entities being attached".

I wonder if LUA supports static types? If you define a variable local but outside of any functions it'll only be visible to that file. You can then make functions in that file that manipulate that variable. So to simulate C++ I generally make "classes" in Lua like Josh does with the AnimationManager.lua file. Then outside of all the function/class stuff I define the local variable and now it'll be accessible by all instances of that class inside that file but not outside just like static variables.

My preference is usually composition. class Knight { private: Entity* model; Animations* animations; }; I would examine if I need functions like Walk() and Fly(). They are basically just MoveTo() functions. Each type would just determine what animation to play when it moves

I assume the .entity part is a variable name in the script that is attached to the entity? If so the way you get script variables from a script attached to an entity is: theEntityInQuestion.script.variableName

Merry Christmas

It's less about scalability and more about readability and maintenance. I'm not offended as it's anyones nightmare to manage if they wish to go that route . I'm just trying to help. Post the global benefits over at gamedev.net and you will hear an earful from everyone over there and for good reason. They are more passionate about it than I. At the end of the day it's referred to as lazy programming because 99% of the time you just didn't spend the time to think about the system you are designing to know how things need to interact. Like anything else the more your practice design the better you get at it. It's not about that though Josh. It's about you being able to easily maintain that code later. Globals make that harder. Every software company needs to just get products out the door. It's how they make their money. MS is no different than you in that respect. These practices are followed for very valid reasons though even with needing to get product out the door. Namely because it's not that hard with practice to see that you don't need globals. The risk far outweighs the benefits. I mean having a global player variable I get, it's still not needed, but I get why a person would do that, but it's a slippery slope. Merry Christmas and Happy Holidays

Then I'd say you probably haven't written more than, say, 50k lines of code yet in a single project (which is small for most any game). Think of how many systems a game needs. Think of maintaining those systems that you haven't gone into for a few months. If you have more than a handful of globals in your game it's going to be a nightmare to manage those for you, and for sure for someone else. It's best to isolate each of your systems in your game and just pass variables around. Is it really that hard to pass a "player" object to functions that need it? This way each system is on it's own and doesn't have their outside reliance on certain things. This also means you can easily reuse these systems without modification. How many people here actually finish a game? Not many. How many people here start many different games? A lot. Reusing systems that are 100% isolated helps speed all that up. I had a bunch of other stuff here to respond to Josh and Hay but I don't want to start a war. I'm trying to give advice from my 13 years of working as a software developer has provided. Globals are a dangerous path that isn't even needed once you understand how to design systems. Programming isn't just about putting code in an editor. Programming is about design and you will NOT be wasting your time by reading up on some design patterns.

public variables? what do you mean with this? you mean globals? those are bad things and shouldn't be used.

Not 100%. 2 benefits to prefabs would be being able to save the assembly of something, which is still there. However, yes, the big benefit of changing the original prefab and having all those prefab instances getting those changes is gone. It's not complex to give us what we ask here. It just has to go up against is it worth Josh's time or not.

You have nested prefabs there too YouGrove so it wouldn't work. The Fridge prefab is a child of the Roof prefab and that's the issue at hand that LE can't handle correctly in multiple ways. I'm not sure what you are getting at with your comment here. With what you have listed 2 things will happen when you load the house: 1) The Fridge prefab won't have it's script's Start() function called (the work around currently is me doing what LE should be doing, which is looping over all children of the house prefab and if it has a script attached call it's Start() function) 2) The Fridge prefab won't be drawn. (the workaround currently is when we build the house prefab and add the fridge prefab we change 1 setting on it to break the prefab link which will then cause it to be draw). These both are things LE could easily do for us to save us time. That's the point we are trying to make here.

No problem. Just remember me when you get rich from your video game

Also make sure it's the Desktop edition and not the web edition.

I'm confused. What were you trying to open it with before? http://www.leadwerks.com/werkspace/page/documentation/_/user-guide/getting-started/programming-with-c-r58

So you are opening this with VS 2013 Express or Standard edition?

Yeah, give me a day or so.

Replied from the original PM

Oh come on man . It's just some recursion. This means when we build each house configuration for our game we have to break each prefab prop we place in the house for no real good reason.

Those are CSG I assume? The old mass or attached script on CSG strikes again . CSG gets collapsed if it doesn't have mass or an attached script which means they are no longer entities in LE's eyes.

@nick This was actually a hot topic a few months ago and the workaround at the time was the CSG hints. This library was suggested then but I guess a new version is out now that's better than the last.

Well I would disagree YouGroove. When you get into a pipeline of filling your game nested prefabs is efficient and allows for programmatic functionality. This is a bug because nothing should prevent this and this is NOT considered bad practice.

What did you link to parentObj in the editor? If it's csg then it needs a mass or script attached otherwise it won't be treated as a valid entity as it gets collapsed into nothingness (I don't know, I hear it gets collapsed and not sure what that means but I know it means it's not treated as an entity).

It's not an LE pivot (LE has an entity type named pivot). It can be thought of as a pivot point but because LE has an actual entity called a pivot that you can make, it's confusing to call it a pivot. Sounds like you did not make an LE pivot. You just made a csg box. So no, that center point of the box is NOT really considered an LE pivot. That center point is the center of mass. It's the point every model has, I guess, that LE uses to place the bottom of the character controller. As far as I know once you set the type as character controller, then those other settings don't do anything. The only exception being the rotation one (don't recall the name off the top of my head). That rotation one can be handy if the model you imported was facing in the "wrong" direction for LE (not facing down the positive z axis). You can use that rotation setting to adjust this, but it's best to just export the model facing correctly for LE if you run into that case.

What pivot? You said you made a csg box and made it a controller. If that's all you did then there is no pivot involved. Whatever you make the character controller will be where the character controller aligns it's bottom to the things center of mass. So I'm not sure where this pivot is involved?