Jump to content

@SidedProxy for server not created in single-player mode


Recommended Posts

Ok, so my problem is, that the serverSide object defined by @SidedProxy, when playing in single-player mode, does not get created. I most likely understand why, as the field has to be static, and only one (client) would exist in the JVM. Therefore, I'd like to know, how can I have a common method, preferably defined in an interface, that has different logic executed on the server and on the client? Or, in case of single player mode, execute the server logic.


What I'm trying to achieve is the following:

- server stores some information in files on the server and allows access to this information internally to the mod running on server, via direct method access,

- mod when the information is requested, while running on the client, sends the request to server using a packet and returns a "pending" response to the caller, and after the response is returned from the server (via a packet) stores it locally in a cache, so any call done for the same information later on, is returned from cache.


So, what I did was the following:

- the serverSide proxy has an implementation for the getInformation() method that returns the information by reading it from file,

- the clientSide proxy has a Map that was used for cache, and if the getInformation() method was called, and the information was not in cache, was sending a packet to server to request the information to be sent to it,

- I've defined a PacketHandler on the server that when a packet was received, it used the getInformation() method of the server proxy and was sending the information to client in a packet,

- I've defined a PacketHandler on the client that when a packet was received, it stored the information in the client proxy's cache.


All great, and clean, however when I run this in single player, there is no server proxy, and the clientSide sends the packet to server PacketHandler, packet handler then goes to the proxy class and invokes the getInformation() method to send the response to client, however the proxy class is not the server flavor, but the client one.


I have a feeling that either the @SidedProxy was not really designed well for the single player mode, or I'm using it incorrectly. Please advise on how to solve this problem and maybe explain what is the purpose of the @SidedProxy.

Link to comment
Share on other sites

SideProxy is used for the environments, not the actually connection side.

The Client side has a lot more classes and functions then the server side.

Mainly because the obfusicator Mojang uses trips unused classes/functions from minecraft when they ship it.

So the client have a ton more stuff related to rendering, and languages, and the like.

There is no clean way to detect these differences, so, SideProxy was born to help modders keep a cohesive codebase. Basically anything that doesn't exist on both sides should be gated through the SideProxy.


As for your situation, you need to detect which side of the connection you're on. Typically you're given a world reference. Using world.isRemote will tell you which side you're on. If it's true, then you're in the client thread, if its false then you're in the server thread.


If that doesn't work, Somewhere, I think in SideCommonHandler there is a function to attempt to guess the current thread context.


As for how people use SideProxy, most cases i've seen people have a 'CommonProxy' class where they define there defualt functionality for what happens when they are in the dedicated server environment. And then a ClientProxy which extends CommonProxy to deal with the ClientEnvironment.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Thank you for your answer, however when I check using World, if I'm on client or server, in case of single-player mode, it will tell me I'm on client, but in this case, I have to actually call the server routine to look into the file, rather than sending the packet to server.


So, I guess my question becomes, how can I differentiate that I'm on client running against remote server, or on client running in single-player mode?

Link to comment
Share on other sites

You don't and you shouldn't, though its not the most optimal performance to do network negotiations on a local system, it's the best way to do it as 1) it emulates the dedicated server environment and 2) It does the delicate process of cross thread communication that is needed in a standard way.


So basically.. there is no difference between a client on localhost and a client of a dedicated server and you shouldn't treat it as different.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

I guess in the server PacketHandler I'll make a call to a static method in my main Mod class getServerProxy() which will check if the static proxy injected by Forge is instanceof the Server Proxy I want to use, and if not, just create and store an instance of it.


That way, on the real server, it will be injected by the Forge, on the single-player mode "server" it will be lazily created by this method, and all the calls that are done specifically on the server side, will use that method to get the proxy they require.



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.

Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

  • Create New...

Important Information

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