Rick

So does that mean the angle between node to node has to be below a certain value? It won't automatically make a curved road no matter the angle?

If you follow the green line, that's where he wants his road to be, but it gets this broken look to it. I have the same issue.

Invisibility ability of the suit (gives an effect like the Predator when he went invisible). It would require some sort of draining of power or something so you can only do it for so long, and heat vision goggles that can see invisible players. I'm picturing an assaulter turning invisible to get into a zone, and the defenders having heat vision goggles on. Picturing cool knifing in the back as invisible. Maybe attacking takes you out of invisibility.

I'm excited for this, but I have to imagine if it's just Josh or maybe even Josh and 2-3 other people that it'll be 12 months before we have the final game. The best thing I think will come of this is that Josh will find all the gaps in the engine that we are all finding and fix them.

Very interesting. I think it's a good idea for you to build a game using your own engine. It'll help you find the holes in the engine and make it better. Did I not read his post correctly? I didn't see anywhere where he said it was a community project. By the sounds of it, he'll create it and just make it open source for the community to use it as an example for our own games.

How would you use the LoadScene() to only load terrain/vegetation but then load all the other things yourself? LoadScene() is going to load anything in the sbx file. So the only way I can see this happening is to parse out the terrain and vegetation from the sbx file you want to load, then use LoadScene() on the new sbx file which just has the terrain and vegetation, and then create our own loading function to parse out the original sbx file. That's a pretty big hack. It gets old having to hack stuff like this. By "big hack", I mean anytime you have to start manipulating files on disk like this it's a "big hack". Not in the amount of code it takes, but in how crappy of a solution it would be vs the engine just having it. This would be such an easy feature to put into the engine vs the time it would take for us to do it.

I agree. This would be a nice feature and probably pretty easy to implement.

I agree. For now I just turned off the console and I'll just look at the engine.log. I had like 10 console windows open. Very annoying.

Oh, well that sucks. It doesn't seem to be in C++. The way I have it works for this instance, so I guess I'll just use this. Thanks!

Is that undocumented? I don't see it on the wiki and doesn't seem to be in C++. What information does that return anyway? Like TCamera or TTerrain?

I'm not making mistakes, I just don't let the program exit fully. When I run I'm usually testing a specific spot in the middle of the code. Once I see it works I just press the stop button. But sometimes the windows go away and sometimes they don't.

What do you mean? I do wrap my mesh objects with user data of a class instance, but I don't for the terrain. I could check for null but wouldn't this basically mean I have to create a generic class that everything has SetEntityUserData in? Or are you talking a different kind of class?

Sadly that is the only way I was able to get them to go away. What really sucks is it seems I have to hard power it off. Start->Reboot doesn't seem to work. Not sure if they are still running and XP can't pull the rug out.

OK, seriously has anyone found a way to close these prompt windows? I have like 7 of them open but I can't close them.

I'm curious how other people determine if the terrain was picked vs other meshes. According to http://www.leadwerks.com/wiki/index.php?title=Raycasting#CameraPick the pick.surface will be null if it's not a mesh (ie. terrain). So I'm going off that, but is there a down side to that? Is this how we should tell if the terrain vs a mesh if being picked by the camera? Also, the way I had to tell that was by using strcmp() against pick.surface since a simple check against 0 (null) didn't work. It works and I get why it works since TEntity is just a char*, but it does seem strange when you read it in code. Is there another way that looks like it makes more sense? Seems like there should almost be a IsEntityNull() method or something in the engine.

It does look good. I have to wonder though, if this is only built in Lua (I thought I remember seeing you say that) I think you're going to have a lot of pissed off BMax & C++ people. What would really be nice is a GUI editor. I think Torque has something like this, even though I didn't enjoy working with theirs, but it would be cool to have something like Visual Studio does for their GUI editor.

Tell him about the shader options for changing textures that you made Nio. That was very helpful.

Don't you ever step through your code when debugging things? Yeah me too, but I do a ton of debugging before release, so it's kind of annoying to have these console windows open that I can't seem to close.

I'm in the same position, but honestly I think people in our position that think they can code and make the art are kidding themselves. To get a full game up and running while doing it all would take years and by then it would be outdated and old. The reality is that people like us need to rely on others for either the code or the art needed in our games. If you're a coder your best bet is to use crappy programmer art but complete your game. Then you can showcase this for artist to see if anyone is interested. Ideally you should just have to plug and play the art assets and your game be complete, but it will be slightly more as you'll have animations to deal with. But at least the programmer knows you are serious about making a game if you have it complete with bad art. If you're an artist then I think your best bet is to make all the art you think you'll have. Build some levels to show your game idea. Then look for a programmer. Coming from the perspective of a programmer I can tell you that I would jump all over a game if the art assets were 99% finished, because then I know the person is serious about the game and the odds that it'll get complete are good.

Does anyone using VS 2008 have an issue with the console window sometimes staying open even when you have exited debugging? Every so many runs the console window stays up for me.

Ah I see. I'm entering the GetKey() method by calling it inside there. It's an endless loop. Duh!

The following results in a C stack overflow error. I wish to store these keys in the model object. I tried :GetKey() also with the same error. function class:CreateObject(model) local object=self.super:CreateObject(model) object.model = model function object:GetKey(key,value) if key == "color" then return GetEntityKey(object.model, "color", "") -- C stack overflow elseif key == "type" then return GetEntityKey(object.model, "type", "") -- C stack overflow else return self.super:GetKey(key,value) end return value end

I think I'll just hack around it with a pivot and just parent that to the object and set the cameras matrix to the pivots when in game mode.

This results in the notify telling me the camera parent is nil local p = fw.main.camera.parent if p == nil then Notify("camera parent is nil") end It's very strange. After I exit game mode when I right click the mouse acts like normal. It is hidden and when I unpress the right mouse it moves to the center of the screen just like normal camera in edit mode. I can't move with the keys and the camera doesn't rotate though.

This is the Thingoid. Basically what it does is allow rotating around target 0. I place an object in the middle of my map and place this Thingoid in the map also. Make the link on index 0, position this Thingoid where I want the camera to be and run it. It then allows me to rotate the camera around the object. When I escape game mode, I then can't move the camera at all in editor mode. require("scripts/class") require("scripts/hooks") --- create the class local class=CreateClass(...) function class:InitDialog(grid) self.super:InitDialog(grid) end function class:CreateObject(model) local object=self.super:CreateObject(model) object.model = model object.oneTime = false object.leftMouseDown = false object.mouseX = 0 object.mouseY = 0 object.camRotationX = 0 object.camRotationY = 0 Notify("Unparent camera") fw.main.camera:SetParent(nil, 1) -- unparent the camera. when we leave game mode this gets called and should free the camera from being parented function object:Free(model) self.super:Free() end 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 function object:Initialize() end function object:ReceiveMessage(message,extra) if message == "" then else self.super:ReceiveMessage(message,extra) end end function object:Update() if GetGlobalString("mode") == "GAME_MODE" then if object.oneTime == false then -- position the camera to the editor object fw.main.camera:SetPosition(object.model:GetPosition(1), 1) -- make the target the parent to the camera fw.main.camera:SetParent(object.model:GetTarget(0), 1) object.oneTime = true end if MouseHit(1) == 1 then object.mouseX = MouseX() object.mouseY = MouseY() MoveMouse(200, 200) -- 200 doesn't mean anything. It's just picked at random. It doesn't matter what it is since we are always finding the difference from where the mouse started HideMouse() end if MouseDown(1) == 1 then local mx local my mx = MouseX() - 200 my = MouseY() - 200 MoveMouse(200, 200) object.camRotationY = object.camRotationY + mx / 4.0 -- this is left and right --object.camRotationX = object.camRotationX - my / 4.0 -- this is up and down object.leftMouseDown = true object.model:GetTarget(0):SetRotation(Vec3(0, -object.camRotationY, 0), 1) elseif MouseDown(1) ~= 1 and object.leftMouseDown == true then MoveMouse(object.mouseX, object.mouseY) ShowMouse() object.leftMouseDown = false end --fw.main.camera:SetPosition(object.model:GetPosition(1), 1) object.model:SetPosition(fw.main.camera:GetPosition()) fw.main.camera:Point(object.model:GetTarget(0), 3, 1, 0) end end end