Rick

fw.main.camera:SetParent(nil, 1) didn't work

Anyone have any ideas on how I can unparent an object?

So after the main game loop in lua I try to unparent the camera with fw.main.camera:SetParent(0, 1) But I get an error: Value at index (2) is not an object. I thought passing 0 as the first parameter was how you removed a parent? I also tried 0 as the second parameter but the same error. Any ideas what I'm missing?

That's good stuff. Now the issue of us having to modify engine.h to rename your lua methods so we can use the real lua in our program without conflicts. From what I can see some of those methods you didn't create in engine.h, which would mean we need to bring in lua to our projects, which leads to the function name conflicts.

hmm, maybe that's something else he can look at because it doesn't do that for me.

Why do you say that? You don't want syntax highlighting for the specific language?

You would have to store the return of LoadSound() into a variable and pass that to PlaySound as the first parameter.

I'm not sure if you work on the forum part, but it would be nice to be able to select the language syntax in the code tags. Something like: or [code lang=c++] would be nice.

Yeah it does. image1 = new Bitmap(@"C:\Documents and Settings\All Users\" + @"Documents\My Music\music.bmp", true);

He wouldn't have to use physics forces. He could do what I posted above which doesn't directly use physics forces and it allows for more accurate movement of the physics object.

Unless you made the change of renaming your lua methods you made this can only be done with modifying engine.h. Even then, calling a lua object method from C++ hasn't been demonstrated yet.

hmm, I kind of did this same thing and the controller moved with the moving platform. The way I moved the platform was by making 2 bodies. 1 body was the platform itself, and the other body was just a small body under the first that was just a body and had no mesh to it. I then fixed pointed the 2 and would call SetPosition() on the bottom body. Now when the bottom body moves the platform body would also move with it, but the difference is that the platform body now can be collided with. If you call SetPosition() on a body it kills the physics on it and other bodies will fall through it. But by using the fixed joint I was able to get this working. I founds this easier than working with forces and torque and such. It also game me the ability to make a platform move to an exact location. I think some have found the force movement isn't as exact. Anyway, when I did this, the controller moved with the platform. It did however cause other effects like, when the platform changed direction the controller had momentum and would kind of jump on it's own. Or when going from up to down the controller would jump up slightly because of the platform moving direction. This is what you would expect in real life but not generally in a platform game. I didn't figure out how to stop that.

Like Nio said, it's probably best to team up. If you try to code and do the art you'll most likely never finish a game.

Welcome. You have a ton of assets there. Looks like you enjoy modeling and are pretty good at it.

Everything I've read says a NavMesh is the way to go.

Well then, problem solved!

Am I missing something? When did setting up a menu have anything to do with allowing users to configure keys? That didn't seem to have anything to do with the original post, so that's where I got confused. Original Post

What do you mean user-defined keys? If you want to build a truly simple menu like "New Game", "Option", etc. Just use 2D images. Draw them on the screen and note their location and size. Then check the mouse to see if the cursor is within each 2D image. If it is you know what the user selected and can act accordingly. That's basically the idea. Of course you can take that idea and really run with it to make things very advanced like an entire GUI system.

Just to put this out there, use it or not, I find it handy to be able to create event calling chains. So instead of just storing 1 event callback method you store a list (table) of them. Then when the onClick event is to fire, you loop through the list and call them in the order they were added. In C++ I do this so my control class can register for the event first and do something based on it before it goes to the user defined event handler. For example, in my Textbox class I have them register the onGotFocus and onLostFocus events that it exposes in the constructor. That way whenever the main gui manager fires these events, my Textbox control event functions get called first, which allows me to do certain things a textbox should do. Like when a textbox loses focus I have that instance stop showing the caret. When a textbox receives focus I have the textbox say it needs to start showing the caret. That way my gui manager that is looking for events doesn't have to worry about that kind of stuff. It just looks for the raw events that every control would have, and fires them. Then the controls are responsible for doing things that pertain to them and not some outside class. Then since these events are stored in a list, it'll then continue to call the function that the user defined for it's event handler. Another cool effect of this is that a user could define their click event handler for a button and do something inside that click event, but they could also define a different function that will fire also when the button is clicked. This is nice in C++ because the function can be from any class and it'll get called. So it allows for nice interclass communication via events.

"If you prefer modeling, then focus on that and join forces w/ someone like me who enjoys programming but sucks at the artistic stuff." Look at that sales pitch

I'm guessing you are thinking it accepts RGB values from range 0-255. There is some formula you can use to convert 0-255 values to what that method needs. I can't remember what it is. Lumooja knows though I'm sure.

Programming is just like everything else in the world. It's not for everyone. Some people just have a hard time with it and some just get it. My personal view is to specialize in an area. If you are an artist be the best artist you can be. If you are a programmer be the best programmer you can be. It's very rare to be able to be an expert in both areas. The people who are making AAA games are experts in their area. They don't spread around their time between all different areas because there wouldn't be enough time in the day, unless you have no friends, family, or full time job I guess. In the indie world they'll say you need to know everything, but I disagree. You will need to know some stuff, but generally you can contact out or get someone else to help that knows more about topic X. The more you know the more money you can save, but the better the odds are your game won't be anything special. In my situation I have basically accepted the fact that I don't have the time to work on models so I use all my time programming so I can be the best programmer I can be.

C++ has try/catch also, but the editor is written in BMax if I remember correctly.

I love gui programming! Sounds like you are missing key presses though. Also events like GotFocus and LostFocus can help with things. It sounds like you have just scratched the surface. Things get interesting when you let into parent/child relationships that controls can have. For example a control could be a child of a window. Or in the case of a combo box it has a textbox, button, and list box control that make it up. So basically you are making a control based on 3 other controls. GUI programming is really fun, but it can also get really involved. I think lua would be really easy for users to bind to the events because you can easily store functions with any signature as the same variable, where in C++ it gets a little trickier with that but still doable. I didn't see it mentioned but I would assume I define the event handler to a control? Something like: function mybutton_onClick(owner, args) -- this gets fired when mybutton is clicked end mybutton = button.create() mybutton.onClick = mybutton_onClick

OK, now that I draw some examples out I see that it would be the center point of the next mesh node in the path which is linked to the current node in the path. This will be interesting to see if I can get this working Seems like a cool idea.