Rick

I seem to remember having the same issue if the physics update method wasn't being called over frames it would build up the force values still and when it was called apply all at once which resulted in some crazy stuff. I would think in rewind mode, that you would simply set position/rotation only. Would there really be a need to set the force when rewinding things?

It's not a bad design, but I don't think it's flexible enough. If someone wants to add rows on the fly this doesn't seem to account for that. I would drop the parameter which you seem to be using to tell how many are in the table. Use something like the below if you need to loop through the table: for index,value in ipairs(t) do print(index,value) end Then maybe make an AddButton() method that will add a button to the next index in the array (you can keep this count in a variable to the class if you like, although I would make they keys in the table a name of the button so people could retrieve the button from the table by name later if they so wish. So AddButton() would take a parameter which would be the string name to call the button in the table).

Is there a Vec3ToString function? Seems that would be handy to save some typing. [edit] Looks like there is. So he could use that to save some keystrokes I guess. [edit1] So I would think the fastest way (not much faster but less overhead) would be to directly set your default values to your object variables right after CreateObject instead of using SetKey(), but yeah either would work. You just would have caught this bug later when you tried to update from the properties window Aggro

Does that work? I assume you maybe meant .rows[0].SetImages()? instead of row1, or maybe that's a table feature I'm not aware of. Either way are you asking for other ideas than the idea you have there?

Yeah, as I loaded his model I realize I was wrong in my first statement. I always just assigned my variables directly after CreateObject instead of using SetKey, since it was just another layer to do the same thing. That would have worked, but you had a good catch in that when he changed values from the properties window he would have ran into issues.

seriously, your pot shots are getting old. but yes that way works best. you just don't have to be mean about it. [edit] and sorry, vec3 not 1. didn't see what you had there aggro Aggro, not that I want to convince you of a style, but the way you have it with object.model:SetKey("rotationspeed","0,1,0") is really just a longer way where you could set it directly with object.rotationspeed = Vec3(0, 1, 0) just inside the CreateObject class. Just a thought.

I'm just saying put object.rotationspeed = 1.0 under object.model:SetKey("rotationspeed","0,1,0") and it should work [edit] or not

You are using the lua variable rotationSpeed in Update(), but aren't setting it to a value until SetKey is called. You do object.model:SetKey("rotationspeed","0,1,0"), but that's not setting the lua variable rotationspeed, that's setting the model key variable, which is a different variable. According to your description even though you are using object.model:SetKey() doesn't call your lua classes SetKey method. below object.model:SetKey("rotationspeed","0,1,0"), set rotationspeed to 1.

hmm, that worked, but now when I select deserthighway sandbox I get a message box saying "Can't open Script/class". I see class.lua in there and the Scripts dir did get copied. I can open it up in the editor.

Sweet, thanks for this! Are you going to maintain both WinForm and WPF always, because I'm not a big fan of working with WPF. I'm newer to it but it just seems clumsy to work with when compared to WinForms and I'd hate for this to only work with WPF some day. [edit] This line doesn't seem to show the dialog for me. It just sits there doing nothing. It's strange that it doesn't error out and if I'm stepping through it it just never comes back after that. It's like it's opening the dialog but I can't visually see it. if (openDlg.ShowDialog() == DialogResult.OK)

Any progress on this? I could really use the fixes you made to this control.

5k? I know you said more serious users, but damn. Even Unity is only 1.2k. I don't think the 5k people were really ever considering LE to start with. Cost almost always equals quality (in tools and such not just graphics) so someone willing to spend 5k on quality tools most likely wouldn't even think twice about a $200 engine, because they would realize the tools are probably subpar to a 5k engine. Man I hate engines that use their own scripting language. Why would you do that and cost a learning curve when you can use Lua or .Net and get the same effects.

I'm willing to bet any sort of raycast system will be very very slow.

Thanks guys

Is there an existing solution to convert gmf files to other formats like .obj or .fbx?

Are we able to still get to the old forums at all?

Does Move and Turn interpolate or use the time or something like that though? I thought there was something done inside these methods and it wasn't really just a straight addition or subtraction. Or maybe I was dreaming that.

The physics water would be sweet!

It's good for converting between file types. There is a gmf plugin for it so you can convert from things like fbx to gmf. It's very cheap and very handy to have if you purchase models that only come in other formats.

Yeah, good point. I will be studying the code release to see if I can make a component with it. This seems perfect in that it generates for you around your map automatically and would be a good fit for such a component.

Yeah, I'm not trying to argue really. Just trying to get an explanation of his method and why he thinks it's better than another method. I've been looking at navmeshes since that's the buzz word in the game industry for pathfinding these days. So when NA comes out with this and it's not quad navmesh oriented I was just trying to get information about it to see if this would be an option vs trying to get my own quad navmesh going. I love that he's done this for the community, but that shouldn't mean someone can't ask questions about it or challenge it to get more information about it. That should be a healthy thing for any of us to do with anything as long as it's not done in a negative manor. That's my view on it anyway. When my component editor comes out I expect tons of questions and challenges about why I think people should use it. Like NA said, and I love his attitude on this, it might help one find any holes or suggestions. Keep up the good work NA!

Thanks for taking the time to explain this. Your 1 line example seems to be in BMax. Did you say if you were going to release this for C++ too? I would be interested in checking this out. Also that one line of code you have showed how to create the grid. I assume we just pass in 2 points (start/end) and we'd get back a list of pivots/points to travel along?

Is there a way to handle walking weights? For example moving through a swamp type land would be slower than just going around it? Are we able to select an individual waypoint and modify some kind of settings for it? Or maybe but some kind of special meshes in our scene that when the grid is generated it automatically does this, but the mesh would be invisible at game runtime. Just curious on the flexibility this has. In the 3rd picture on your first post, what's the crazy zig zag going on there? I assume the dark blue is the path that was found, and in that 3rd picture it looks like a few straight lines would be desired instead. I guess I still don't get how waypoints would be faster than navmesh when it comes to running A* against it. Less nodes to cycle through should equal faster right? I would think, everything I've read and seen, shows you would have less quads than waypoints. Don't get me wrong I'm interesting in trying to figure out why you say this would be faster than navmesh, but all the literature I've read state that using quad navmesh is the way to go over waypoints, so it'll just take erasing all that for me to understand where you are coming from. [EDIT] NA, I hope you don't take my questions in a negative way. I'm simply trying to understand your method and your reasoning for it. I don't mean any disrespect.

Nice explanation. That's kind of what I was looking for. I still can't understand how using something like A* would be faster with waypoints than navmeshes though. Generally you have less quads in a navmesh than you do waypoints which means less data to go through to find the path. The room you constructed has 15 quads, but it would most likely have way more waypoints, which means more points to check against right? It does seem that navmeshes require additional work like dynamic object avoidance for dynamic scenes and spline movement to make moving look more natural. I would think the spline would still be desired for waypoints, but waypoints does have the benefit of being a build in dynamic scene avoider. Do you think combining navmesh with waypoints would yield even better results? The first check could be just the quads to find the quad path. Then the next check would be only the waypoints within the quad path. That seems like it might help break down very large areas. [edit] Did you mention if the path is returned in one call or can it be spread out over a few cycles to ease the burden on the cpu? I've always read that's how some of the RTS games did this. I remember games like Age of Empires where when you told a unit where to go there was a 1 second animation of the unit saying "OK" before he actually moved. I read somewhere that was to hide the fact that the pathfinding was spread out over a few cycles so as to not have any noticeable fps hit.

I was just curious as to why he didn't use navmeshes as that seems to be what games are going to these days. I said this is good, was just curious. Seems we can't question anything these days without getting people all bent out of shape.