Rick

Since LEO is just a wrapper for LE, at it's core it's still uses LE's function to setup callbacks. It sucks, I know. I have a way to map these to class members but it's probably just as easy to use the C style. Even the mapping way is done with the normal C callback, but inside that callback you map it back to the class function to call. Would have been cooler if LEO did that automatically.

Is paddle->EntityCollisionCallbackdefined as static?

They do? Maybe he changed it. Last night when he shut the server down everything on my screen stopped. The oil drums weren't moving. He's most likely doing a million different tests.

I thought that's what he was doing. If that's the case there is no point in having bodies at all client side. Just SetPosition() on the meshes. Interpolation and extrapolation smooths things out. SetPosition() doesn't automatically equal jerkyness like Lumooja seems to think. Lumooja, you were talking about applying forces client side before. I don't think that would be the way to do it. I agree with CalcBodyVelocity though. By interpolating client side you can smooth out the movemnet, and my extrapolating client side you can send less data and predict where they are going.

Do you know for a fact that's how Josh is doing this or are you saying that's how you'd do it? If applying forces and such is how Josh is doing it then I'll buy it because I'm seeing it and it seems ok, but if that's not how he's doing it I'm not buying that applying forces would give the exact positions. If this isn't how Josh is doing it I'd love to see your idea Lumooja and see how it looks. I think I would just do extrapolation and interpolation on the meshes on the client side.

So you would set the oildrums position to where the server says they should be by applying forces to them? I wouldn't think that would be exact enough.

SetPosition() with interpolation would work the same way and I would assume be more precise than SetBodyForce(). What is being done when the server sends the update of where the body should be?

Well the character controller is just something I put on top for testing. It happens when it's just the 2 physics bodies as well. So when it's going down and it hits the point where it goes back up the distance between the child and parent is reduced slightly. The opposite when doing up and changing direction. It only happens when I change direction. It's not a huge deal just annoying.

If the physics objects are getting a new position from the server x times a second I assume on the client SetPosition() is called on these bodies? If that's the case then the physics is basically not happening on the client since SetPosition() basically kills physics from happening on bodies. My guess would be that reducing the physics updating and letting the client handle the physics more would probably result in some warping or scenes not being in sync. How you described is what I was doing for my MMO testing for player movement. The issue I had was that sometimes in the client I was able to get to places in the terrain from my local controller that the server wasn't able to get to with it's controller of my character. Sometimes when you have steep hills or valleys in the terrain. Since the server couldn't get to that place when it updated me every 5 seconds it would snap my client back.

I got this working btw, and it's freaking sweet. I made some supporting Thingoids to make it able to be more dynamic. I have a Cube Thingoid that has a physics body and you can apply a material to and resize. I have a Body Thingoid that does basically the same thing but is just a body. I have a Fixed Joint Thingoid that you assign 2 targets to. Target 0 is parent, target 1 is child. I have a Pivot Thingoid that creates a pivot at the location of the object in the editor. I have a MoveTo Thingoid. Target 0 is the body to call MoveEntity() on, and all the other targets will be the Pivot thingoid so it moves between pivots. It's really cool being able to just move the pivots around and see the cube move in any direction I make it, real-time!!! I'm excited.

That's called client side prediction, which is what I've been saying is required. That basically hides the lag. The problem is that opens up a can of more issues to handle. He tried updating the oildrums 2x a second and it didn't look right. Since the physics are being done server side, things on the client would sort of "snap" to a position sometimes.

No, that was network lag. Create yourself a server and then move around. Then join another person server and move around. As long as the key press is being sent to the server and the server is doing the moving there will be that lag. If it's a 300ms round trip and if that's how it's being done, you will visually notice that. As long as the server is doing the movement and sending that movement back to the client there isn't any way to get around the sluggish feeling of movement. I did just that, I think with version 15 or 14 and there was a difference and I only had a 110ms lag.

What was smooth? The dropping of barrels was great, but the moving of the character controller wasn't "smooth", in that there was a delay when when you pressed the move key vs when you actually moved.

I didn't try 17 but if all you said is what changed from 16 above, there was a noticeable delay from when I pressed my move keys to when I saw the movement happen. As we talked about before I assume you are just sending the move key to the server and having the server do the physics and sending back the position to the client. My ping was 110 which is what it is for nearly every online game I play. I'm sure you are well aware but client side prediction will be required. It sucks to have to jump through that hoop, but it's a reality in online games today. Remember that post someone made about that box that was going to let you play any game online and it would stream the games to your tv/computer as you're playing them so you wouldn't need any local installs of the game? I can't remember the name, but this is the reason everyone said it was basically impossible to do it because there wouldn't be any client side prediction and there would be noticeable lag between when the player pressed an action button and saw the action being done. It's basically impossible to not have client side prediction because even when I created my own server (which you can't get faster than that) I noticed a slight lag between my key presses and movements and players just wouldn't accept that these days. I'm sure you are aware of this and I'm sure you'll figure it out. Baby steps first. Learning as you go I'm sure. I didn't enjoy trying client side prediction with the character controller. I ran into all sorts of syncing issues when trying to implement the player physics on the server and on the client. That's why I think it's just easier to have the physics run on the client for just their character controller. Then that sends the data to the server and on the server all characters are just doing SetPosition() to the position the clients said they were. Obviously there would need to be server checks to make sure the last position and current position of the players is reasonable and they aren't hacking. NPC's would have physics run on the server and position/rotation send to clients where the clients would just do SetPosition/SetRotation. The other issue with doing it this way is that I'm not sure how to cause physics interactions between objects and players. If I threw a barrel at a player but on my side the player is just getting SetPosition/SetRotation called, when it hits the player on my side there would be that noticeable lag between when I see the physics happen. Again though, this is most likely why nobody has good networked physics. There are just so many issues around it.

I'm loving it and I'm a C++ programmer. I try to do everything in lua. I like being able to get instant feedback when testing my objects.

I notice when I move up and down the distance between my child and parent changes when I change direction of the parent. Is there a way to make sure the distance between the child and parent stay exactly the same? I also notice that when going up, when it changes direction and it's going fast enough, my character controller "jumps" a little. Is there any way to stop that? Ideally the character controller would stay flat on the cube.

Is there an issue with fixed joints where the child slightly raises when the parent moves? I move the parent cube, and when it first moves the child cube slightly raises before it follows the parent. Not sure if it's on my side or something a fixed joint does for some reason. If the parent doesn't move the child doesn't do this.

Copy this link and just change the number of what josh says at the top post It should be http://www.leadwerks...post/chat12.zip

Looks like it's almost like setting a parent. Child moves relative with parent.

Found it. objecttable[] not classtable

So let's say I have object A. function class:CreateObject(model) local object=self.super:CreateObject(model) function object:MyFunction() return 1 end end Say I make object A a target to another object. So in the other object I do: local objectA = object.model:GetTarget(0) How can I call MyFunction() from object A? I tried: classtable[object.model:GetTarget(0)]:MyFunction() but that didn't work. I'm guessing that would work if MyFunction() was class:MyFunction().

So what does a fixed joint do?

How can I assign more than 1 target to an object? I drag object A into my scene. I drag from object A to another object and that makes a target which will be 0. I then drag from object A again to a different target, but it asks me to make target 0 again. if I do it overwrites the other target as 0. I need it to say make it target 1 because I already have target 0. nevermind I see I can press the number key to assign it.

Who has the Duke Nukem Forever server? It doesn't seem to connect me. I created my own server and I have to assume the controller is server side. I'd like to try it on a different server.

OK, then I'm guessing the controller was created in the current world. When you free the world it is freeing the controller. Which means you have no more controller. Recreate the controller after you load the new scene.