[1.7.10] General guidelines for when code should run (server only or both)?

[abstruselyarcane]

I just started playing around with mods, and I was wondering what code should run on the server only, and what should run on both the server and the client. For example, what I have gathered is that entities will send packets to the clients about their internal state, so I will only need to summon an entity on the server, and put movement logic on the server. (Please correct me if I am wrong)

 

Since 1.7.* forge made tick handling into an event (TickEvent.*), I was also wondering about which events I should register to for some logic. Since TickEvent.ServerTickEvent is fired both on Phase.Start and Phase.End, and inspection of MinecraftServer shows that the Phase.Start is fired before everything else, and Phase.End is fired after everything else.

 

I am currently working on some stuff related to multiblocks, and I have a "controller" that controls the central logic of the entire multiblock. I figured that since there will be no packets send about the internal state of my multiblocks, and the code ran should produce the same results for everyone, I will handle both ServerTickEvent and ClientTickEvent. But, I am confused as to run the logic when it is on Phase.START or Phase.END. Is there a difference?

 

So, what I am asking are basically the following:

[*]What are the general guidelines for running code on either on the server only, or both the server on the client?

[*]Is intercepting TickEvent the correct solution, and if so, is there a difference between Phase.START and Phase.END?

[brandon3055]

First of all you almost never need to use a tick handler for anything like that. entities and tileEntitys have update methods that are called every tick use that.

 

As for what sine code should be run on well that depends on what you are trying to do but usually things like tile/entity logic run on the server and anything todo with rendering runs client side. 

[Draco18s]

Entities should totally run their movement code on the client side, as while the server will enforce what it believes is going on, if the client end isn't doing ANYTHING then the entity will jump around as it periodically gets packets from the server correcting its location.

[abstruselyarcane]

First of all you almost never need to use a tick handler for anything like that. entities and tileEntitys have update methods that are called every tick use that.

 

The problem with that is that a multiblock has, well, a lot of blocks, and I will have no way of determining if I have already ticked this tick with 100 tile entities all delegating their update methods to me.

[brandon3055]

The best way to deal with this is to use a "master" a single tile that manages everything could be ether a completely different block or the tile in a certain part of the structure e.g. the tile at the centre of the structure.

[TheGreyGhost]

Hi

 

>What are the general guidelines for running code on either on the server only, or both the server on the client?

 

Some general guidelines I use:

Client side only:

rendering and sound - anything that doesn't affect the "game state" - things other players don't need to know about - for example animations, local sound effects other players don't hear, etc

 

Server side only:

things that affect the "master" source of information on the state of the world, such as entity positions, block states, etc, interactions between players

 

Both:

It can be a big advantage to run the same code in parallel on both the client and the server, to reduce the amount of information they have to exchange and to reduce the apparent lag.  So for example as Draco said, your entity should run its movement code in parallel on both client and server .  The client makes a guess / extrapolation based on its current information and just corrects the movement occasionally when server packets arrive.  It's much less visually disturbing that way. 

 

-TGG

 

 

[Draco18s]

The client makes a guess / extrapolation based on its current information and just corrects the movement occasionally when server packets arrive.  It's much less visually disturbing that way. 

 

Note that the guess can be 100% accurate, as the client does know the full state of the world (plus or minus a second).

 

For example, I was messing with pushing ItemEntities around (similar to liquid flow) and if the code only ran on the server they'd move about a full block at a time, so it was pretty close to short-range teleportation.