[1.6.2]Separating the code on client and server sides?

[Naiten]

So, i have an entity with tons of different code in it's onUpdate(). And i know i can use if(worldObj.isRemote) to check if the code is run on server or client side. Now i want to understand which parts should i run on every side. For example, which side should i use when operating motion variables or moveEntity()?

[Mew]

Well, I would like to think that would be simple logic problem, but oh well... ( I apologise if this is taken insultingly, I am not intending it to be that way. )

 

I also apologise if this seems extremely childish to you, and seems insulting. I am not trying to be.

 

 

 

Think about this logically. What is a client? A client takes the data from the server, and displays that data in some way. The server handles the data, and sends it to the client to be displayed.

 

So, going by what I have just said ( if it was unclear, please say so, I am still trying to get the hang of explaining things and your input would be helpful ), anything that deals with visuals, so your entity movement and stuff like that, is done client side. The server handles the information like the placement of the entity on the map, the locations of blocks etc. Once again, the server handles the data, the client displays the data.

 

I hope that helps If it doesn't, I am sorry.

[Naiten]

I can't get why server would store position, but not motion. And how is movement or collision (physics, in more general terms) dealing with visuals? And if every client process movements by itself, can't they (clients) run with different frequency and desync?

[Mew]

I can't get why server would store position, but not motion. And how is movement or collision (physics, in more general terms) dealing with visuals? And if every client process movements by itself, can't they (clients) run with different frequency and desync?

 

Like I said.. It has flaws. Thanks for pointing that out. And I did leave room for expansion in my explanation didn't I? So that means the rotation could be kept on the server, but I doubt that myself.

[GotoLink]

It doesn't really matter if clients don't see exactly the same entity animation at the same time.

Just look at the vanilla "flying" player animation to see how senseless animations are.

What matters is collision and positions, which are handled by the server.

 

As for the question at hand, it is not needed to separate client and server sides in most cases.

Of course, client-side only methods (rendering, animation...) should only be called client-side.

And if there is any chance of desync between client and server (say, you add a bit of random in the logic), stay on server side.

This is what i would say in general.

[shadowmage4513]

In my vehicle implementation, my onClientUpdate is pretty small -- it just applies any motion that it had received from the server.  Thats it--little/no calculation, no collision checks, just blindly/dumbly apply what the server sent.  My server-side calculates motion, applies collision, applies rotation, applies user input, and sends update-packets to client side with the intended positioning.  Client side takes that information and figures out how to be where the server says it should be within the allotted time (3-5 ticks generally) (very similar to the vanilla boat rotation-delta updating methods). 

 

How much needs to be done client side will mostly depend on how you are calculating motion, and where you are doing collision checking at.  At the minimum-- you will need to update any movement/animation variables -- e.g. leg position, wheel rotation, as well as applying any motion you had calculated (you can techincally do motion calculations client side as well and use position synch packets to keep things lined up...but I figured...why calculate something twice?).

 

Mew has the correct approach though -- think exactly what is needed client side?  You need to know where it is at, how it is moving (both how it is rotating and moving in the world), possibly the health value (for health bars), and any other information needed for client-rendering.  Pretty much everything else can be server-side only.

 

(I can provide links to source examples if needed)

[Mew]

In my vehicle implementation, my onClientUpdate is pretty small -- it just applies any motion that it had received from the server.  Thats it--little/no calculation, no collision checks, just blindly/dumbly apply what the server sent.  My server-side calculates motion, applies collision, applies rotation, applies user input, and sends update-packets to client side with the intended positioning.  Client side takes that information and figures out how to be where the server says it should be within the allotted time (3-5 ticks generally) (very similar to the vanilla boat rotation-delta updating methods). 

 

How much needs to be done client side will mostly depend on how you are calculating motion, and where you are doing collision checking at.  At the minimum-- you will need to update any movement/animation variables -- e.g. leg position, wheel rotation, as well as applying any motion you had calculated (you can techincally do motion calculations client side as well and use position synch packets to keep things lined up...but I figured...why calculate something twice?).

 

Mew has the correct approach though -- think exactly what is needed client side?  You need to know where it is at, how it is moving (both how it is rotating and moving in the world), possibly the health value (for health bars), and any other information needed for client-rendering.  Pretty much everything else can be server-side only.

 

(I can provide links to source examples if needed)

 

Thanks for the support But I would be inclined to follow GotoLink on this, why would you calculate motion/rotation on the server? That is just extra resources used on the server and it does't really matter if the clients are out of sync... Does it? Please correct me if I am wrong in this!

[shadowmage4513]

Well, for my scenario, ALL of my motion is calculated server side.  It needs to calculate rotation because the forward motion/direction depends on the rotation.  You don't necessarily need to calc rotation server side (can interpolate from the motion vector on the client side), but in my case, my vehicles have forward and reverse, which necessitated using rotation in the basic motion calculations, and synching this rotation to clients (they don't calculate based on it, merely display whatever the server tells them)

 

As to the other...how do you _not_ calculate motion server side?  If the entity on the server doesn't calculate motion (and move), the client side entities certainly won't move (or will be out of position client side, and then collision detection wont work properly).

 

Essentially I moved over to a completely server-authenticated/calculated vehicle movement system, though it is probably overkill for most peoples purposes (I required smooth and (mostly) synched motion between server/clients, and that is the most reliable way I found to achieve it).

 

Anyway, I'm not meaning to argue on it, there are lots of ways to handle motion/synching depending upon your needs (dead reckoning, predictive, checked, lots of others) -- I was merely wanting to point out that you can indeed separate the code for client/server, for both easier reading of code, and possibly increased performance -- after all, why calculate something twice (or more, in the case of multiple clients), when once will do.

 

 

[Mew]

Well, for my scenario, ALL of my motion is calculated server side.  It needs to calculate rotation because the forward motion/direction depends on the rotation.  You don't necessarily need to calc rotation server side (can interpolate from the motion vector on the client side), but in my case, my vehicles have forward and reverse, which necessitated using rotation in the basic motion calculations, and synching this rotation to clients (they don't calculate based on it, merely display whatever the server tells them)

 

As to the other...how do you _not_ calculate motion server side?  If the entity on the server doesn't calculate motion (and move), the client side entities certainly won't move (or will be out of position client side, and then collision detection wont work properly).

 

Essentially I moved over to a completely server-authenticated/calculated vehicle movement system, though it is probably overkill for most peoples purposes (I required smooth and (mostly) synched motion between server/clients, and that is the most reliable way I found to achieve it).

 

Anyway, I'm not meaning to argue on it, there are lots of ways to handle motion/synching depending upon your needs (dead reckoning, predictive, checked, lots of others) -- I was merely wanting to point out that you can indeed separate the code for client/server, for both easier reading of code, and possibly increased performance -- after all, why calculate something twice (or more, in the case of multiple clients), when once will do.

 

I see your point.. That makes sense now Thanks for clearing that up. As I also had said, please point out where I am wrong And you did. So thank you for extending my knowledge in this area

[Naiten]

Well, this is what i have come to:

    public void onEntityUpdate(){
        /* 
         * Code that is not concerned to motion
         * <...>
         */
        if(this.worldObj.isRemote){
            this.setPositionAndRotation(this.posX, this.posY, this.posZ, this.rotationYaw, this.rotationPitch);
            this.moveEntity(this.motionX, this.motionY, this.motionZ);
            this.correctCartPositionOnRail();
            this.motionX *= 0.95;
            this.motionY *= 0.95;
            this.motionZ *= 0.95;
        }else{
            /*
             * Code that does something with motion
             * <...>
             */
            this.moveEntity(this.motionX, this.motionY, this.motionZ);
            this.correctCartPositionOnRail();
            this.motionX *= 0.95;
            this.motionY *= 0.95;
            this.motionZ *= 0.95;
        }
    }

And, what i got:

http://www.youtube.com/watch?v=WA5JJtbYoNc

Not really bad, but still kinda desynced, as i see.

[GotoLink]

Why don't you put the common code out of the if/else ?

It would be easier to read.

I would put moveEntity(...) after all motion calculation too.

[Naiten]

Damn. I lost the sight of that.

Tried what you've said, and the engine wasn't glitching. But wheel rotation broke, so i started messing with the code, and now i can't get «non-glitchy motion» state again -.- Facepalm.