Jump to content
View in the app

A better way to browse. Learn more.

Forge Forums

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Posted

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.

  • Author

...

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.

  • Author

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.

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

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.