Rick

Yeah I create them with: Actor* actor = new Assassin(pos, rot); Nothing is sticking out to me either. I've done stuff like this a hundred times. That's why I'm thinking it might be something with LE's TTexture or LoadTexture() is doing something funky. When I step through the code it's making it into each derived class so it's running each LoadTexture() correctly it seems. Interestingly enough the texture that it's showing for all of them is the Assassin's texture which is the first one loaded.

Actor::Actor(TEntity model, TTexture headShot, TVec3 position, TVec3 rotation) { _model = model; _headShot = headShot; PositionEntity(_model, position); RotateEntity(_model, rotation); } class Actor { private: bool _enabled; // if false they can't do an action TEntity _model; TTexture _headShot; };

I've been out of the LE programming for to long I think I have an Actor class that takes a TTexture in it's ctor and stores it in a variable to be drawn later. I then derive other classes from Actor like Knight, Assassin, etc. I then have something like: Knight::Knight(TVec3 position, TVec3 rotation) : Actor(LoadMesh("abstract::Knight.gmf"), LoadTexture("abstract::KnightHeadShot.dds"), position, rotation) { } So I call LoadTexture() and depending on the class what it loads is different. Then in the Actor::Draw() class I draw the texture. The problem I have is that every draw is drawing the same texture. That TTexture isn't defined as static in Actor so why would I be getting all the same textures being drawn even though I load different textures per class? It's not making sense. Note that I do the same thing with LoadMesh() and that works. I get the correct model loaded. So that's even more confusing as to what is happening.

Oh thank you! As soon as I looked at that code I was already typing in my head how much polling for events suck To comment on Mumbles comment, I would assume WaitEvent() is a blocking method, but it looks like it would just return an event in the event queue so it would return instantly because PeakEvent() is being used to tell if there is anything in the queue to start with. If you were creating just a GUI app that wouldn't need a main game loop, then we would probably just use WaitEvent() since blocking would be fine for such an app, but because this is a game app we have to peak for events before we pop them off the queue. I seem to remember doing that stuff in my Win 32 days (which I hated). On a side note, why would anyone program events like that. I mean even if you didn't allow callbacks, I would create my own callback system with what you have there and take away the nasty switch statement.

You should be able to add them there. We all have access to modify it. I added one event tutorial on there a few months back.

OK cool.

Yeah I was just using those as hardcoded examples. In the actual code those are variables that are from TextureWidth/Height functions. I casted them both to float and they work now. I could have sworn it used to know that.

Yep. Totally forgot to copy those over to my new location. Thanks.

I could have sworn at one point in C++ it would do the conversion for me, but maybe I've been using .NET to long. Thanks guys.

OK, feeling dumb. What am I missing with this. The following is setting ratio to 0.0 instead of 0.25. float ratio = 200 / 800;

Can seem to find the forum post that talks about how to setup in code the field of view. Also, does anyone know the default FOV by the engine?

That didn't seem to help. Maybe I'm doing something wrong in my Lua file. Here is what I have. When I find this entity in code and have: string cls = GetEntityKey(ent, "class", ""); it's returning "0" require("scripts/class") local class=CreateClass(...) function class:InitDialog(grid) self.super:InitDialog(grid) group=grid:FindGroup( "Class" ) group:AddProperty("class",PROPERTY_CHOICEEDIT,"Assassin,Paladin,Knight,Wizard","Class Type") end function class:CreateObject(model) local object=self.super:CreateObject(model) function object:SetKey(key,value) if key=="" then else return self.super:SetKey(key,value) end return 1 end function object:GetKey(key,value) if key=="" then else return self.super:GetKey(key,value) end return value end end

What is the PROPERTY_ constant that returns the string and not the index again? I've used PROPERTY_CHOICE and PROPERTY_CHOICEEDIT and they both seem to return "0" instead of the string that I put in the drop down list.

When I point the editor to my own game folder and then load a scene I made when it was pointed to the leadwerks folder the terrain shows up, but I had hills but the terrain is completely flat. What would cause that? I copied over the Scripts, Models, & Materials from the leadwerks dir to my game dir.

A bunch of the entries from the main page seem to be gone? What gives? I use some of that stuff for reference. Who is editing the wiki?

I am using VS 2010 pro on my PC and that's what's doing this. I downloaded 2008 express and it works fine. Very strange.

What VS version are you using? Are you using an Express version also?

Honestly all those systems can be done many different ways. Tutorials can be made on one way to do them but that doesn't mean it's the only way. Maybe a tutorial could be made to just describe how one could go about it, but not a detailed tutorial.

Does anyone else have issues making an LE project with vs 2010? It seems to just hang on Initialize() for me when I run it from the IDE. If I run it from the exe (which is what I kind of thought the IDE was doing) it works fine though.

That's been talked about many times and I think the outcome is always that it doesn't seem possible. I think this will prove to be a bigger hurdle than the terrain loading.

It's almost to hard to hold back against the Linux talk here, but then again reality is what it is.

The new version of LE, LE3, is currently in the works and is said to be able to run on Mac, PC, Linux, iPhone, Android, PS3, XBox, etc. You just have to wait probably another year or so for all that to be ironed out and solid. Some people might say less, but I'm just being realistic and not a fanboy by saying a year. Josh is making good headway on LE3 but there is still a ton of work to be done to support all those platforms and get all the tools to support LE3.

Honestly, just because a tool HAS all the needed features available, doesn't automatically make it more efficient to use than a combination of tools. If the said tools are hard to work with and/or don't follow standards it actually makes it less efficient because you have to retrain people to follow a non standard way of doing things that they can't use anywhere else. I have no doubt that Blender has all the features a game engine should have, but they aren't implemented in such a fashion that people think it's not efficient to use. Linux also has all the features an OS SHOULD have but it's not implemented in such a way that makes it efficient for your average person to use, which is why it's not the number 1 OS in the world. Blender is very similar to Linux in that way, and it seems like their mentality of, we are right and we don't care what you think our product should be. The reason for this is clearly money. When you don't charge for your product it's very easy to keep thinking you are doing something the right way and everyone else is wrong. As soon as you have to make a living with your product you start to listen to the majority of people and do things the standard way (the way everyone knows already). That's basically the difference between open source projects and for profit. For example Blender looks like it uses Phython for scripting. Why Phython? Most people who are into making games don't know Phython, they know C++, LUA, BMax (questionable). Then you come back with it's open source and you can bind any language, but yeah yeah yeah, Linux has been saying the same thing for years, but your average person doesn't want to do all that work. They want to use tools that are very standard across multiple engines, like C++, and LUA. Until you, and more importantly Blender, realize this, it'll be another Linux. Good for some, but not for the majority, even though a superior product to the competition in terms of features.

Easier to use would be highly debatable I think

That seems cool, but really what's the point? If it looks exactly the same and plays the same, then why would you need that?