Rick

Yeah, I'll encapsulate all that into my unit class I guess so it's transparent, no pun intended.

This unit goes from non transparent to transparent any number of times. In fact all the units can be like this. I could probably create all my units in the transparency world and don't make them transparent until I need to, but since they would all be in the transparent world, doesn't that effect picking and/or physics? Would I have to change worlds when I'm expecting a unit to be picked vs say the terrain? Also, I actually was wondering if I could get the other image. The one that doesn't really look correct because you can't see through the bottom part of the object, but that one looks better because the bottom part doesn't get overwhelmed by the yellow selection piece under it.

OK I fixed it but not following why it mattered. I took the code in the oneTime check in Update() and put it inside the Initialize() method. This is a method I created and call before the main loop in the main lua game file. I guess I don't know why that would make a difference.

So with the below code I'm trying to figure out why the controller gets positioned at the origin when I run in game mode? I set it's position to the editor model position. So why is it that no matter where I drag the editor model, and I see the controller follow it, that when once I go to game mode the controller goes right to 0,0,0. I'm pretty sure this used to work where it would start the controller at the position of the editor model. require("scripts/class") require("Scripts/hooks") local class=CreateClass(...) function class:InitDialog(grid) self.super:InitDialog(grid) group = grid:AddGroup("Character") group:AddProperty("model", PROPERTY_FILE, "GMF Files (*.gmf):gmf", "", "Model Files") group:AddProperty("controller_height", PROPERTY_FLOAT, "Controller Height") group:AddProperty("controller_radius", PROPERTY_FLOAT, "Controller Radius") group:AddProperty("controller_step_height", PROPERTY_FLOAT, "Controller Step Height") group:AddProperty("controller_max_slope", PROPERTY_FLOAT, "Controller Max Slope") group:AddProperty("model_scale", PROPERTY_VEC3, "Model Scale") group:Expand(1) end function class:CreateObject(model) local object=self.super:CreateObject(model) object.model = model object.height = tonumber(object:GetKey("controller_height", "1.8")) local radius = tonumber(object:GetKey("controller_radius", "0.4")) local step = tonumber(object:GetKey("controller_step_height", "0.5")) local slope = tonumber(object:GetKey("controller_max_slope", "45.0")) object.oneTime = false object.controller = CreateController(object.height, radius, step, slope) -- set the position of the controller to the editor object local pos = object.model:GetPosition() object.controller:SetPosition(Vec3(pos.x, pos.y + (object.height/2), pos.z)) object.characterModel = nil object.move = 0 object.strafe = 0 object.rotate = 0 object.jump = 0 object.moveSpeed = 2 object.strafeSpeed = 2 function object:SetKey(key,value) if key=="model" then local pos = self.model:GetPosition() object.characterModel = LoadMesh("abstract::"..value) object.characterModel:SetPosition(Vec3(pos.x, pos.y, pos.z)) elseif key == "controller_height" then object.controller:Free() object.controller = nil object.height = value object.controller = CreateController(value, radius, step, slope) elseif key == "controller_radius" then object.controller:Free() object.controller = nil object.controller = CreateController(object.height, value, step, slope) elseif key == "model_scale" then if object.characterModel ~= nil then object.characterModel:SetScale(StringToVec3(value)) end 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 function object:Initialize() --object.controller:SetMass(1.0) --EntityType(object.controller, 1) end function object:Update() if GetGlobalString("mode") == "GAME_MODE" then if self.characterModel ~= nil then if object.oneTime == false then object.oneTime = true object.controller:SetMass(1.0) EntityType(object.controller, 1) object.controller:SetPosition(object.model:GetPosition(), 1) end if KeyHit(KEY_T) == 1 then Notify(object.model:GetPosition().x..","..object.model:GetPosition().y..","..object.model:GetPosition().z) end self.controller:Update(self.rotation, self.move, self.strafe, self.jump, 5000, 10, 0) self.jump = 0 -- reset each frame -- the character model must follow the controller -- for the 3rd person camera to work we must also move the object model, which is stupid self.model:SetPosition(Vec3(object.controller.position.x, object.controller.position.y, object.controller.position.z)) self.characterModel:SetPosition(Vec3(object.controller.position.x, object.controller.position.y, object.controller.position.z)) end else -- constantly update the controller to the object in the editor object.controller:SetPosition(object.model:GetPosition()) -- make the model follow if self.characterModel ~= nil then self.characterModel:SetPosition(object.model:GetPosition()) end end end function object:ReceiveMessage(message,extra) if message == "move" then object.move = tonumber(extra) * self.moveSpeed elseif message == "jump" and object.controller:IsAirborne() == 0 then object.jump = tonumber(extra) elseif message == "strafe" then object.strafe = tonumber(extra) * self.strafeSpeed else self.super:ReceiveMessage(message,extra) end end function object:Free(model) object.controller:Free() if object.characterModel ~= nil then object.characterModel:Free() end self.super:Free() end end

Because there is no other way of thinking than the Linux way of thinking? You assume that the kernel would be identical working for any OS OR you assume Linux has the end all be all kernel in existence and there could be no possible other way than to do something different than the way Linux does it as far as the kernel is concerned. That's just not true. You of all people, someone who thinks outside the box, should know that at any point in time someone can come along and change how people think in terms of anything on this planet. Including an OS kernel.

So because I use SetPosition() when not in game mode and the mass and everything is already set, the force just builds up the longer the controller is created and not run in game mode. That explains why my controller was shooting all over the place. That's interesting. I guess I'll save setting the mass on the controller until right before I get into game mode.

nvm, I forgot I was recreating the controller if properties were changed and forgot to set mass and entity type after the recreation. Now it's goes all over the place . Need to figure that out.

Any ideas why my Update for my controller isn't moving even when I hardcode the move value to 2? self.controller:Update(self.rotation, 2, self.strafe, self.jump, 5000, 10, 0)

If this works can we make it part of the default shaders that come with LE?

Well now I'm really confused. Now when I open my scene it's there. grrr, I hate stuff like that.

That's what it originally was It seems LoadMesh() or LoadModel() aren't working on this model or for some reason it can't find it.

It's abstract::character.gmf The model does load in the model viewer.

What am I missing here? I load the mesh, but when I try to SetPosition() it says object.characterModel is nil. So the mesh isn't getting loaded, but the Notify I have shows the correct filename and the model is under the Model directory on the LE SDK. Is there a typo I'm not seeing? function object:SetKey(key,value) if key=="model" then local pos = self.model:GetPosition() object.characterModel = LoadMesh("abstract::"..value) Notify("abstract::"..value) object.characterModel:SetPosition(Vec3(pos.x, pos.y, pos.z)) else return self.super:SetKey(key,value) end return 1 end

A small market share is one valid reason. This is the reason why almost nobody makes games that run on "pure" mac. I realize this sucks for the mac users, but supply/demand rules all.

I think any programmer at one point wanted to build their own OS. Without knowing about how it works and what goes into it, you might think you are good at programming so why not right? Then you start reading up about it and it's like a punch in the face. It's like the difference between being a good airplane passenger and an astronaut.

I would agree it's a waste of time to develop for older system, but what I would do is when upgrading the engine for newer features in the future, to make it so we can pick and choose the features we wish to support. In other words, keep the existing stuff so it works on todays/yesterdays hardware, but also develop the new stuff for tomorrows hardware. That way, 5 years from now we still would have the option to have it run on the hardware of today so we can hit even more people. What would be considered "casual" 5 years from now.

What Lum is saying is sort of like: I want to make a game, so I'll buy HL and make a few changes to the code and call it a game. We give that a different name. We call it a mod at that point because you modified the HL game. So when he suggests to use Linux for what basically could be classified as the heart of the OS, then I wouldn't classify it as your own OS. It would be a variation of the Linux OS.

Not to my knowledge. I know others have done it with .NET or the Win 32 API, but not MFC. Another GUI library might be able to be easier though. Maybe something like wxWidgets or Qt.

I don't know how, but I can't imagine why anyone would want to. Do you know and enjoy using MFC? Maybe there is an alternative that we can help you with? Did you try creating an MFC project and include LE in it? If so what kind of errors you are getting?

Basically you have to create C++ and OpenGL and everything else for your OS. Google how to make an operating system and you'll soon find out what we mean.

That's not an OS then. An OS doesn't run on another OS. Didn't we go through this already? If an OS requires another OS to run, then it's not a true OS. An here comes the Chrome argument. Say what you want but if we go down this road the word OS starts meaning nothing.

And in the mean time games that have made billions of dollars have been made using DX. I don't anyone really cares what John Carmack told Bill Gates. Bill ignored it for good reason. Are you honestly telling us you put more worth into John Carmack's request to stop DX than Bill's idea to make it what it is?

I think maybe this is where the confusion is. I don't agree with that statement since some people are still using older version to make games. If this is where you and Josh as coming from, then I get your point, but the new version just need time for the users to catch up OS wise. I should also say that I was specifically talking PC gaming and not console. To many parameters need to be defined when talking about this stuff. The iPhone and PS3 would be the only things to be concerned about that don't use DX. The others are so small that it wouldn't even be worth your time to port. Even in that the iPhone would need to basically be a cut down version, which Josh doesn't even seem to want to support lower end graphics cards, much less a phone. So really the PS3 would be the only legit concern. But like I said, I really care personally. As long as it works on Windows I'm happy.

I think Josh has been drinking Lumooja juice. I really don't care either way because they both suck to work directly with but how can you make a comment saying DirectX isn't widely used or supported? DX is highly used and highly supported in the game world. Otherwise I agree with everything you said, but that comment was just silly. And we aren't suggesting you use DX, we are suggesting that the comment wasn't accurate. And if running on the Windows platform it would use DX correct? Since 99% of gamers use Windows, it's save to basically say it uses DX. I know some games let you pick if you want to use DX or OGL. The compatibility thing was a risk MS was willing to take. They want to push their OS forward and with that comes things like this. Once the dust settles DX will still be the more popular because you have a real company backing it. A company who makes money when others succeed so they do more to support it (for a price that is)

1 ray cast works just fine. You can determine what entity types would effect the raycast so you could make some things not be affected by this raycast. This is why you don't parent the camera to the player, but instead create a pivot that follows the player. You offset the pivot from the player to determine where you want the camera pointing (the head most likely). Then you do entity visible between the player pivot and the camera or camera pivot. The other reason to do this is that most 3rd person games allow you to rotate the camera freely from the player rotating. By having a player pivot that follows the player, you can just rotate that and the camera will follow since it's parented to that player pivot. This will rotate the camera independently from the player very easily. Note that when you do the entity visible between the 2 pivots you'll have to worry about the actual player model. I generally just hide the player model, do the entity visible check, then unhide the player model.