Guidance on when to check world.isRemote

[Drakmyth]

I know world.isRemote indicates whether the code is running on the logical server or the logical client. I further know that in most cases interacting with the world from the logical client causes desync/ghost entities/etc and so it is important to only interact with the world from the logical server. Finally, although I haven't learned much about GUIs yet, I know those are one of the primary places where logical client-specific code exists.

 

What I'm wondering is if there is any guidance on what scenarios world.isRemote needs to be checked, or how to tell if any particular method should include that check?

 

My current impression is that with the exception of registration code (which I'm doing through DeferredRegister and thus is registered on each side according to how Forge knows how to do it) there generally should not be any logic that should run on both sides and so world.isRemote should be checked in pretty much every method. Further, unless there is logic that is specifically known that it should only be executed client-side, generally all logic should be logical server-side only. Obviously this may differ wildly depending on the particular mods goals, but as a general-case implementing vanilla-like items and blocks mod goes that seems to be the case.

 

For instance: I believe I should check (!isRemote) in Item#onItemUse, but not in Block#createTileEntity (because tile entities *should* be created in the client?) but what about in Block#getShape or TileEntity#tick?

 

If there's not a general rule-of-thumb (such as "never execute on the client unless you know you have to"), what kinds of properties or scenarios should I be looking for to understand when I do need to check? How do I tell which sides a particular method will even be executed on?

[ChampionAsh5357]

I would say read the statements on the different kinds of sides prior to me explaining my reasoning. Even though all logic should be executed on the server side, sometimes it's less computationally heavy to execute the logic on both sides. For example, if your TE changes it's texture based on the amount of liquid it has, you might just want to send a boolean to client saying whether to increase the liquid or decrease it. It more or less depends on what information gets synchronized between the two sides. NBT data on an ItemStack is synchronized to the client when changed, so it should be logically sided within Item#onItemUse. Alternatively, Block#createTileEntity is called on both sides if we want to change how something like a TileEntityRenderer appears based on the stored data on the server. Same thing with entities except their spawning is sent through a packet to keep the same id.

So, generally, all logic should be on the logical server unless you want to display something. Then, that information should be synced to the logical client. However, if it's sending a multitude of information every single tick, then the logic should be handled on both sides and synced via some value that switches both of their states. At least, this is my opinion.