[1.7.10 or 1.8][DROP IT] Side-mods (non-universal).

[Ernio]

Goal is simple: I want to have non-universal mod (client and server has other jars but they are one mod).

Purpose: Private server request

 

I haven't done much research yet so any info on doing it simply would be nice.

Main questions are:

 

To connect to server you need to have mods required - how does Forge compare them, can names or versions be different (there will be more server-side updates than client ones, thus versions will differ)?

 

Good thing would be nice workspace - the goal here is to have:

mypackage.server //Everything that loads custom configurations (where classes or quests are created)
mypackage.client //Data storage for data received from server IF playing on server, if NOT then some basic "demo" stuff (client won't have its own configuration to create e.g. quests which are on servers config side)
mypackage.common //all the common files, block registration and basic forge stuff that is shared

 

Basically after obfuscation I'd just need to remove either client or server package and .jar is ready.

To go with said above - I need to have 2 @Mod annotations, one in .server one in .client and when launched inside eclipse: If launching client - start ONLY @Mod from .client and other way around with server - is there some tool for writing this-kind-of-sided-mods?

 

P.S - I know about proxies (and I could do it all in one @Mod and then do shitload of Side-checks), but I want something even before that, the moment of adding mod to container. If not, well, prixy it is.

[Ernio]

The lords calling (request for "code safety" - you know, so the client can't make server using his client.jar).

I personally don't care.

[Ernio]

Thats not quite what I had in mind.

 

You see, as told in 1st post - there is .common package that handles everything related DIRECTLY to forge (just like any other forge mod), so packets, IEEP, GameRegistry are still on both sides.

 

The case here is about further related code (quests, classes, lore). Goal is to make client.jar unable to work for dedicated server. So if the client connects to dedicated server it will receive data (from packets) and save it to its virtual storage and use it, but if you would just go to singleplayer then the client will only use some static values, a "demo gameplay". On the server.jar there will be config-loader, that can load custom stuff that will be later sent to connected clients.

 

 

EDIT: (I was wrong about java imports crashing after class removal)

Oh. My. God... I mixed up two different languages... nevermind, it can be done *.*