The use of proxies

[Kenta1561]

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

[larsgerrits]

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.

[Guest]

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.

[Draco18s]

  On 2/14/2017 at 8:55 PM, diesieben07 said:

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

Expand  

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.

[larsgerrits]

  On 2/14/2017 at 10:13 PM, Draco18s said:

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

Expand  

 

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.

 

  On 2/14/2017 at 10:13 PM, Draco18s said:

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

Expand  

 

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

[jeffryfisher]

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.