[1.7.10] SideOnly vs FMLCommonHandler.getSide

[target.san]

Hi!

 

I've noticed in my mod that I have too much stuff like if (worldObj.isRemote).

So I decided to move to some more unified client/server logic decoupling. With this, I came to two possible solutions

1. Use FMLCommonHandler.getSide, which effectively returns side. Then have some private var in my TE's or blocks which would reference client or server implementation, then delegate all calls there.

2. Use SideOnly annotation. The problem is, it's said to be used for Forge's internal use only.

 

So, which way is considered more convenient? Aside from fact that approach 1 allows for different logic on the same actions, where approach 2 doesn't.

 

Thanks.

[Eternaldoom]

Read this: http://www.minecraftforge.net/forum/index.php/topic,22764.msg115304.html#msg115304

[target.san]

...

Conclusion:

World.isRemote

is the way to go.

 

Ok, thanks, got it.

Though I have another stupid question. Do we always have 2 instances of tile entities, normal entities, block flyweights etc. for logical client and server? Or there's one instance in case of integrated server? What I need to know is, can I have some kind of central dispatch point for 'client' or 'server' methods? Or do I need to check for World#isRemote every time, and there's no other way? Because, TBH, it's annoying to have "if (worldObj.isRemote) return;" in each method.

[target.san]

Yes, indeed. Although I am not sure why you mean by "block flyweights".

Block classes. They're essentially 'flyweight' pattern.

How do you mean?

By having some kind of

private lazy val dispatcher = if (worldObj.isRemote) ClientDispatcher else ServerDispatcher

then delegating all methods through that dispatcher

Usually you have to check, there is no other way. Some methods are only called on the server or on the client though, checking would be unneeded there.

I mostly mean methods like onNeighborBlockChange, which are called both on logical server and logical client. Though I'll have no other option for blocks anyway, as I can't check whether specific block instance construction happens on client or on server.

[TheGreyGhost]

By having some kind of

private lazy val dispatcher = if (worldObj.isRemote) ClientDispatcher else ServerDispatcher

then delegating all methods through that dispatcher

You can achieve this to some extent using your proxy class;

http://greyminecraftcoder.blogspot.com.au/2013/11/how-forge-starts-up-your-code.html

this can sometimes be very useful especially for packet handlers where any references to vanilla client code, even if you never execute that code path on the server, will cause a crash.

 

Personally I think .isRemote is the easiest to understand and debug.  I think that if I need to worry about whether my Class is being instantiated twice or only once, then I'm probably overcomplicating things and increasing the chances of logical vs physical server bugs.

 

-TGG