Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

The use of proxies


Kenta1561
 Share

Recommended Posts

Hello,

 

I just read the Forge docs about proxies but it is too simple and general for me to understand. What I understood so far is: Proxies can be used to tell Minecraft which code should be executed on the server or the client. Besides that, I know that for instance texture rendering must be done on the ClientProxy side as otherwise it would crash the server.

 

But here are my questions:

  1. What are examples of processes that should be only done on the server side but not on the client side?
  2. When I look at the source code of some famous mod projects I see that the ClientProxy class inherits from a super class, which is the Proxy class. But then they define this super class also as the server side proxy: Does this mean that all the things that happens on the server side should also happen on the client side as it is inherited? Why is the server side proxy then even required?

 

These might be really stupid questions but I am relatively new to Forge and I would be really glad if someone could explain this to me.

 

Kenta1561

Link to comment
Share on other sites

1) There are almost no things you have to do server-side. I haven't encountered anything that had to be server-only.

2) You mean the server proxy as "CommonProxy" and the client proxy extending that. In the old days, a lot of tutorials did it that way, and that is just how it stayed in popular mods, as it was just how they learned it. I prefer the proxy interface with 2 classes extending it. For me, it makes more sense, as the client and server proxy should only have code for that side, and not "common" code, as that defeats the purpose of proxies.

Don't PM me with questions. They will be ignored! Make a thread on the appropriate board for support.

 

1.12 -> 1.13 primer by williewillus.

 

1.7.10 and older versions of Minecraft are no longer supported due to it's age! Update to the latest version for support.

 

http://www.howoldisminecraft1710.today/

Link to comment
Share on other sites

Well, for question number two I know that some mod authors do either or. Some have a client proxy, server proxy, and common proxy, while some only have the client and common, in which case the client inherits the common.

 

The client code would in this case be the only code that would need to be executed separate, so there would be no point in having a separate server proxy class I think.

Link to comment
Share on other sites

1 hour ago, diesieben07 said:

The concept of a "CommonProxy" makes no sense. The "CommonProxy" is your main mod class.

That said, I personally prefer the "ClientProxy extends CommonProxy" (where Common == Server, just all the methods are blank) setup over the IProxy method (where I'd still need a server side implementation to avoid NPE, where all the methods are, again, blank).

 

The thing that I really hate is the Main Mod hands off the init event to the Proxy which then hands off the init event to ModBlocks and everything is done there (and the event object goes untouched).  Like, seriously, WHY DID YOU BOTHER PASSING IT ALONG.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

1 minute ago, Draco18s said:

(where I'd still need a server side implementation to avoid NPE, where all the methods are, again, blank).

 

I use Java 8 default methods for that, so I only have to implement the methods I need and no need for blank ones. But yeah, you still need a separate server proxy for that.

 

3 minutes ago, Draco18s said:

Like, seriously, WHY DID YOU BOTHER PASSING IT ALONG.

 

"Because some copy-paste tutorial I copied without thinking about it told me to."

Don't PM me with questions. They will be ignored! Make a thread on the appropriate board for support.

 

1.12 -> 1.13 primer by williewillus.

 

1.7.10 and older versions of Minecraft are no longer supported due to it's age! Update to the latest version for support.

 

http://www.howoldisminecraft1710.today/

Link to comment
Share on other sites

I think that there are many methods that should only run on the server (where world is not remote). However, I do not think that there are any classes that are loaded only on the server, and that's what proxies guard against: The mere mention of an undefined class can blow mod injection sky high even if execution would never have tried to call anything in the missing class.

 

So, the client proxy is needed to contain all references to classes loaded only client-side. The server can use the common proxy because it doesn't need anything but its trivial method stubs as placeholders. There is no server proxy because there's no need to contain any toxic reference on the server.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

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
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.