Jump to content

Should I separate the server from a heavily client-side mod?


TheNuclearDuck

Recommended Posts

I'm working on updating a very heavily client-sided mod. The only part of the mod that needs to run on the server side is a couple of event handlers, which only send IMessage packets back to the client for the main part of the mod to handle. Since a server-only JAR of this mod would be tiny, be very easy to debug and update and not cause problems with @SideOnly, would it be a good idea to cut the server stuff completely from the client mod and create a new, server-only mod for the event handlers? Is there a better way to handle this situation?

 

Edit: Does using

@SideOnly(Side.CLIENT)

on classes and fields which are guaranteed to be accessed only on the client side make any difference to performance? I don't know too much about Java class loading so I'm not sure if those classes would ever be loaded regardless, or even read from the JAR file.

Edited by TheNuclearDuck
Link to comment
Share on other sites

29 minutes ago, TheNuclearDuck said:

would it be a good idea to cut the server stuff completely from the client mod and create a new, server-only mod for the event handlers?

No that only makes it more confusing for players to install.

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 hour ago, TheNuclearDuck said:

Edit: Does using


@SideOnly(Side.CLIENT)

on classes and fields which are guaranteed to be accessed only on the client side make any difference to performance? I don't know too much about Java class loading so I'm not sure if those classes would ever be loaded regardless, or even read from the JAR file.

 

The annotation culls out the annotated stuff at build time. So the server JAR won't include anything annotated that way.

 

Your client-side code is probably accessing Side.CLIENT annotated vanilla classes (rendering and such) so probably a lot of your client-side mod code will need to be similarly annotated -- if you have call any sided code, then your code that calls it has to also be sided.

 

So it will mostly work itself out. You will have to annotate some of your stuff and that won't be included in the server JAR when you build your mod.

 

You can go further and annotate other things that you're sure are on a single side, but many people say you shouldn't (I don't really understand the concern).

 

I would not create two separate mods though (one client-side and one server-side) if they are needed to work together. That would be annoying and confusing to people using it as Draco pointed out.

Edited by jabelar

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

12 minutes ago, jabelar said:

I would not create two separate mods though (one client-side and one server-side) if they are needed to work together. That would be annoying and confusing to people using it as Draco pointed out.

In this particular case, the server-side of the mod isn't always needed. The mod will run without the server-side, just with some of its features disabled (I have the server-side send a packet to notify the client that it's there and turn those features on). I don't want to spam @SideOnlys everywhere so I'll stick to only invoking those classes that refer to client-only stuff from the client.

Link to comment
Share on other sites

5 minutes ago, TheNuclearDuck said:

In this particular case, the server-side of the mod isn't always needed. The mod will run without the server-side, just with some of its features disabled (I have the server-side send a packet to notify the client that it's there and turn those features on). I don't want to spam @SideOnlys everywhere so I'll stick to only invoking those classes that refer to client-only stuff from the client.

If the functionality really is separate or not dependent, then yeah it can make sense to make them separate mods. It's really a style thing, with pros and cons. I would organize it based on the way the users will think about it. Will they be thinking that it is essentially the same mod or will they think of it as separate functionality? Would anyone ever want to install the server side without the client? If not, I would probably let the sided annotation do its job -- the server JAR will be nice and compact without making it a separate mod.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

14 minutes ago, jabelar said:

The annotation culls out the annotated stuff at build time. So the server JAR won't include anything annotated that way.

 

This is incorrect. There's nothing in the Forge build system that removes @SideOnly classes from the JAR, since Forge mods are universal (i.e. required on both sides) by default.

 

You may be thinking of Mojang's build system for Minecraft, which doesn't include client-only classes in the server JAR or server-only classes in the client JAR.

 

ForgeGradle adds @SideOnly to client- or server-only classes, fields and methods when it merges the client and server JARs for the development environment.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

49 minutes ago, Choonster said:

 

This is incorrect. There's nothing in the Forge build system that removes @SideOnly classes from the JAR, since Forge mods are universal (i.e. required on both sides) by default.

 

You may be thinking of Mojang's build system for Minecraft, which doesn't include client-only classes in the server JAR or server-only classes in the client JAR.

 

ForgeGradle adds @SideOnly to client- or server-only classes, fields and methods when it merges the client and server JARs for the development environment.

Yeah, it sounds confusing because I'm talking about build time when there are two "build time" points. But my point was that @Side.CLIENT "vanilla" classes are not even in the server JAR (when they are built) so they are fully inaccessible (can't be loaded) and therefore if you extend them you also need to annotate so at ForgeGradle build time things work out. Is that correct? Or do the mod side-annotated classes exist in the JAR and it gets sorted out during class loading or run-time?  

Edited by jabelar

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

1 minute ago, jabelar said:

and therefore if you extend them you also need to annotate so at ForgeGradle build time things work out. Is that correct? Or do the mod side-annotated classes exist in the JAR and it gets sorted out during class loading or run-time?  

This is wrong.

If you extend a class that uses the Side Only annotation you can annotate your override if you wish, but you don't have to.

What Choonster is saying is that the annotation does nothing as far as a mod developer is concerned. It's there to let you know that the method/class/whatever won't be available on the other side.

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

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...

×   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.