[1.8.9][Networking] Some questions about dedicated server and modded clients

[Major Squirrel]

Good evening,

 

I'd apologize in advance for the lack of visual code, my problem is purely based on concept understanding that I need to clarify in my mind.

It has been about one year that I have "forge modding times", all repressed by studies or a lack of understanding : I'd like to correct the latter.

 

Doing some research on google, I have found a good explanation of "how client and server sides" are separated in Minecraft thanks to The Grey Ghost. (This topic is dated on 2013 but it seems to be still valid)

 

From what I understood, a modder is able to create a mod with client side and server side for both dedications : when launched in singleplayer, the server side is still handled by the "client program" while in multiplayer, the server side is nicely handled by the "server program" but putting client code in it is kind of useless.

 

---

 

Let's say that a modder would like to open a forge modded server. Within, he would like to create a "quest system" where data are stored in a database. The modded clients can access to this server and use the quest system : the modded client asks for a quest (e.g pressing a button) and the servers responds using packets to the client.

 

In this hypothesis, the modded client just has to handle client input (button), packet requests (and responses obviously) and quest rendering (gui) while the modded server has to handle the research (specific quest in db), and packets req/res. In this case, all tasks are well distributed to their dedication.

 

The point that I don't understand very well is : how to achieve this, knowing client and server have to get the same mod so that the client can connect to the server.

 

I might be wrong for the last sentence, in which case I'd like some explanations on it, but I already encountered some errors where I couldn't connect to the server due to mods difference. For maintainability and common sense reasons, it would be obvious to not put all the database system in the modded client. Furthermore, I would like to clarify that modded clients cannot play in singleplayer (which is a little bit obvious, without database system it would be pointless).

 

I think I have a clue but I'm not sure : the solution would be to implement the packets differently in both client and server, so that client and server would be compatible and the quest system would be well done at packets implementation.

 

I would thank you in advance for any help or clarification on this, that would be valuable to me, to better understand this principle. 

[Failender]

Im not sure if I get ur quesiton right.

Forge already ensures that clients can only join if they got the exact same version (of course u need to change the version of the mod when making a new release)

[Major Squirrel]

Im not sure if I get ur quesiton right.

Forge already ensures that clients can only join if they got the exact same version (of course u need to change the version of the mod when making a new release)

 

Hello @Failender,

 

Is this the only constraint to connect a modded client to a modded server ?

 

For TL;DR, I'd like to make a mod that handles client stuff for modded client, and a mod that handles server stuff (including quest system and database system) for the modded server : in itself, it is the same mod but separated in two versions: one for the client and one for the server. The thing that I would like to achieve is to separate the tasks so that the dedicated server hasn't the client code and the modded client haven't the server part.

 

The client shouldn't have the packet handling that the dedicated server do. The server aswell shouldn't have the client handling (like input or gui rendering) that is reserved for clients.

 

I don't know if I can make myself understood in fact. 

 

EDIT : is there any documentation that explains the forge versioning/compatibility that you point out ?

[Failender]

why do you want to separate? its a fkn whole ton of extra work to do, but yes it is possible

[Ernio]

I am not sure what exacly you want to know because 1st you claim that you found good explanation for sides and then you seem to think that server and client mod is something different.

 

Well, since about 1.2 (around, I don't remember) modding has been redesigned to be compiled as one universal mod for both client and server.

Before going further:

Client = client.jar

Dedic = dedicated.jar

client-side = logical server side

server-side = logical server side

 

When:

1. Dedic is running - it runs server-side.

2. Client it running - it runs client-side and:

2.1. Nothing else on MP (server-side is handled by Dedic).

2.2. server-side on SP (integrated server-side)

2.3. When in LAN - one client will run integrated server, other clients will connect to LAN server like to Dedic.

 

Having Mod written as an universal jar - it doesn't matter where you run it. Data should be always handled on server-side, thus if you have any database it will always be loaded on server-side, which is Dedic OR integrated server.

Packets are still being "sent", even when you are on SP connected to your integrated server.

[Ernio]

Im not sure if I get ur quesiton right.

Forge already ensures that clients can only join if they got the exact same version (of course u need to change the version of the mod when making a new release)

I'd like to make a mod that handles client stuff for modded client, and a mod that handles server stuff (including quest system and database system) for the modded server : in itself, it is the same mod but separated in two versions: one for the client and one for the server. The thing that I would like to achieve is to separate the tasks so that the dedicated server hasn't the client code and the modded client haven't the server part.

 

The client shouldn't have the packet handling that the dedicated server do. The server aswell shouldn't have the client handling (like input or gui rendering) that is reserved for clients.

 

Hell, well you gave your explanation, my prev post is quite irrelevand aside from fact that modding has been made SIDE-UNIVERSAL.

 

Do tell - do you want to achieve what you want to achieve because:

1. Privatization of code (e.g coding for private server).

2. Lowering size of files for players to download.

3. Don't know why and you think that it will be better, when in reality - it really won't.

4. When you say "database" you actually mean embedded DB engine that you think is useless for clients, thus you go back to point 2. with addition of "useless code".

 

[jeffryfisher]

You might have a "mod" that has such distinct client and server tasks that you'd provide separate jar files for each (but have them depend on each other). You could build separate client and server versions of the "same" mod, or you might be able to use version and dependency annotations (or parameters to the MOD annotation).

[Major Squirrel]

Im not sure if I get ur quesiton right.

Forge already ensures that clients can only join if they got the exact same version (of course u need to change the version of the mod when making a new release)

I'd like to make a mod that handles client stuff for modded client, and a mod that handles server stuff (including quest system and database system) for the modded server : in itself, it is the same mod but separated in two versions: one for the client and one for the server. The thing that I would like to achieve is to separate the tasks so that the dedicated server hasn't the client code and the modded client haven't the server part.

 

The client shouldn't have the packet handling that the dedicated server do. The server aswell shouldn't have the client handling (like input or gui rendering) that is reserved for clients.

 

Hell, well you gave your explanation, my prev post is quite irrelevand aside from fact that modding has been made SIDE-UNIVERSAL.

 

Do tell - do you want to achieve what you want to achieve because:

1. Privatization of code (e.g coding for private server).

2. Lowering size of files for players to download.

3. Don't know why and you think that it will be better, when in reality - it really won't.

4. When you say "database" you actually mean embedded DB engine that you think is useless for clients, thus you go back to point 2. with addition of "useless code".

 

Good morning,

 

The first thing you point out is exactly what I would like to accomplish : privatize the code so that the client can't be aware of the embedded DB engine. (and yes, by database I meant embedded DB engine) This is really easy for a player to be aware of the code by opening the jar file and exploring some classes. That is why I absolutely wanted to separate client and server tasks into two different jars.

 

Unless you know a cleaner way to achieve this, do you think it is still possible to do this ?

 

EDIT:

 

You might have a "mod" that has such distinct client and server tasks that you'd provide separate jar files for each (but have them depend on each other). You could build separate client and server versions of the "same" mod, or you might be able to use version and dependency annotations (or parameters to the MOD annotation).

 

That is, you understand where I was getting !

[Failender]

Lets be honest this will be a lot more work, but it is totally doable.

 

I dont know how to use that annotation stuff so maybe jerry can explain more there.

 

What you could do would be create to different workspaces (server / client) and work independant. On the client side do only client stuff (rendering /networking / blocks / items)

and on the server side do all the server stuff (most of the event handling/ networking / blocks / items)

It is just REALLY important that when you register your items / blocks / whatever via GameRegistry.register...() that you use the same names ( if im not mistaken)

[Ernio]

You are making your life harder but whatever.

 

I can only suggest this approach:

Setup normal dev environment.

Create 2 mods - server and client one.

Proxify EVERYTHING - Client mod will fire everything it has in ClientProxy, Server will setup everything (databases, engines) in ServerProxy.

Write 2 different mods. that will somehow correspond to each other.

 

Why 2 mods, one workspace - well, easier to maintain - you can launch Dedic and Client at once and connect to test it.

 

Now where are main problems:

- You still need a lot of common code, since most stuff needs to be handled on both sides (e.g you send quest data, you recreate object on client, thus you need all quest classes).

- Client will NOT work on SP - since you don't have server's code (integrated), you need to take care of your shit when playing on SP (when using some client-event, you need to make if(sp) and then proceed with acting).

- Packets are "the shit" - your problem is with implementations that Forge alredy provides. SimpleNetworkWrapper and actually whole system requires you to have IMessage and MessageHandler. What you want to do is to make:

Dedic only have IMessage and Client only have MessageHandler or other way around.

Problem is actually that when you receive message, it will be recreated and passed to MessageHandler (that's why packts need empty constructor).

How to pass this? Well, you can't (if you want to use forge). You will need sided implementation of packets.

Next: SimpleNetworkWrapper allows you to register packets in PACKET<->HANDLER manner. You want to have INCOMING<->OUTGOING.

To resolve this you need to either write your own implementations (of networking) or "inject" your packets without pairing (meaning you register PACKET but not HANDLER).

You can do this like this:

SimpleIndexedCodec codec = ReflectionHelper.getPrivateValue(SimpleNetworkWrapper.class, this.getInstance(), "packetCodec"); // instance is ofc of your SNW
codec.addDiscriminator(packetId, message);

This way you can have OUTGOING packet with some ID. Now on receiving side you need to have both HANDLER and PACKET to receive (you also need to have same ID as incoming packet). That you register like any other packet.

 

Seriously, don't do that, just proxify your code and make one mod.

 

Oh and mark EVERYTHING (that is not common code) in your code with SideOnly:

http://www.minecraftforge.net/forum/index.php/topic,22764.0.html

 

EDIT

Additional shit: if you started modding/this is your first. DON'T do that. Without proper understanding of MC, you will most likely have a lot of problems.

[Major Squirrel]

Thank you Ernio for your answer !

 

Yup, the client has not to work in singleplayer on purpose, it is for a private server. I will do some extensive researches about Minecraft/Forge networking.

 

Why do I want to do this way ? This is a goal I set myself and that I would like to accomplish.

 

Thank you guys for your answers, I will keep you informed and surely will need your help later.

[ZeroNoRyouki]

If I ever need to do something like this, I will go with 2 mods:

 

modA: a server-side only mod to deal with the database engine and all the bits and pieces you want to keep off the client

 

modB: the actual mod you want to make

 

The logical server-side of modB will delegate all database-related jobs to modA, if modA is actually present

 

Z

 

 

 

 

[jeffryfisher]

And finally, the client mod depends on the presence of the server mod and/or the server mod requires a client to log in with the client mod.

 

BTW, You might not be able to stop code exposure. A player could still download the client mod for examination... unless you keep it all to yourself (only your servers and private correspondents would have it). Then you're doing something like public/private keys in encryption. Release one version of a mod publicly for players, and hold a private version of the same mod for yourself and your server(s).

[ZeroNoRyouki]

If he goes with the 2-mods structure I suggested he can keep all the private logic in the server-only mod and just release the public mod without need (and headaches) of having multiple versions of it

 

Z

[Major Squirrel]

And finally, the client mod depends on the presence of the server mod and/or the server mod requires a client to log in with the client mod.

 

BTW, You might not be able to stop code exposure. A player could still download the client mod for examination... unless you keep it all to yourself (only your servers and private correspondents would have it). Then you're doing something like public/private keys in encryption. Release one version of a mod publicly for players, and hold a private version of the same mod for yourself and your server(s).

 

If he goes with the 2-mods structure I suggested he can keep all the private logic in the server-only mod and just release the public mod without need (and headaches) of having multiple versions of it

 

Z

 

Hey guys,

 

Exactly, I don't really mind if clients want to take a look at the client mod code. I just don't want to expose the server part publicly.

 

For the moment (just for infos), I'm adding a connection pool for the server part but I'm having problems adding the lib to the jar using Forge Gradle. In fact, I don't really know how to create my own gradle tasks so that I can generate client build and server build at the same time (or separately), using Forge Gradle.

[jeffryfisher]

Wow, you might finally have created a use-case for @SideOnly server files and a serverProxy to ref them. If you set them up right, you should be able to build your project twice, first with all pieces in place for yourself, and then with the server-only pieces deleted from your src tree to produce a version for public release. To that end, you might want to organize your files to place all server-only classes into a separate package for quick removal or replacement. Make sure to keep a master elsewhere.

 

I do a similar thing with resources in my alt paintings mod, deleting the rather large graphics files before building a lightweight version of the mod for dedicated servers.

[Major Squirrel]

Wow, you might finally have created a use-case for @SideOnly server files and a serverProxy to ref them. If you set them up right, you should be able to build your project twice, first with all pieces in place for yourself, and then with the server-only pieces deleted from your src tree to produce a version for public release. To that end, you might want to organize your files to place all server-only classes into a separate package for quick removal or replacement. Make sure to keep a master elsewhere.

 

I do a similar thing with resources in my alt paintings mod, deleting the rather large graphics files before building a lightweight version of the mod for dedicated servers.

 

Hello jeffry,

 

Thank you for you tip, I'll try to organize my code there are two separated packages, client and server.

However, I don't really understand well what are you meaning by "use-case for @SideOnly server files and a serverProxy to ref them" ?

[ZeroNoRyouki]

Wow, you might finally have created a use-case for @SideOnly server files and a serverProxy to ref them. If you set them up right, you should be able to build your project twice, first with all pieces in place for yourself, and then with the server-only pieces deleted from your src tree to produce a version for public release. To that end, you might want to organize your files to place all server-only classes into a separate package for quick removal or replacement. Make sure to keep a master elsewhere.

 

@SideOnly=Server will not keep the annotated code out of the compiled jar, so it will not work for the public version of the mod and it's not needed for the private version

 

@Major Squirrel: I don't know how much code you will actually have in common between the "public" and "private" version of the mod but, again, I'll suggest to go with 2 distinct and separate mods (and 2 separate projects) to keep things clean and separate and to define an API to let the 2 mods interact with each other (if you end up with more than a couple of interfaces see the @API annotation)

 

Z

 

 

[jeffryfisher]

@SideOnly=Server will prove that a section of code can be left out of the public version (before it's actually removed from the src tree).

 

"Use case" is geek speak for "an example that shows how this feature could be useful". Use cases often drive product design, but they also help students to cement lessons about the features of complex tools (such as Minecraft + Forge).

[Major Squirrel]

Wow, you might finally have created a use-case for @SideOnly server files and a serverProxy to ref them. If you set them up right, you should be able to build your project twice, first with all pieces in place for yourself, and then with the server-only pieces deleted from your src tree to produce a version for public release. To that end, you might want to organize your files to place all server-only classes into a separate package for quick removal or replacement. Make sure to keep a master elsewhere.

 

@SideOnly=Server will not keep the annotated code out of the compiled jar, so it will not work for the public version of the mod and it's not needed for the private version

 

@Major Squirrel: I don't know how much code you will actually have in common between the "public" and "private" version of the mod but, again, I'll suggest to go with 2 distinct and separate mods (and 2 separate projects) to keep things clean and separate and to define an API to let the 2 mods interact with each other (if you end up with more than a couple of interfaces see the @API annotation)

 

Z

 

@SideOnly=Server will prove that a section of code can be left out of the public version (before it's actually removed from the src tree).

 

"Use case" is geek speak for "an example that shows how this feature could be useful". Use cases often drive product design, but they also help students to cement lessons about the features of complex tools (such as Minecraft + Forge).

 

Hey guys,

 

Thank you for you replies. It helps me to understand better the way Minecraft Forge works. I think I'll go for 2 separated projects for now because of the lack of knowledge. But if I had to create two separated jars from the same project, how could I accomplish this ? I thought about two maven tasks but I suppose this isn't the best way to do this here...

[jeffryfisher]

if I had to create two separated jars from the same project, how could I accomplish this?

 

I make mine the old-fashioned way: I build a jar, move it to another folder, then delete bulky resources, then build the "lightweight" jar, then rename it and move it too. I get 2 versions in 2 minutes without needing to learn advanced gradle/maven mechanics. It works for my simple situation. My project switching (from one mod to another) is similarly primitive.

[Major Squirrel]

Hey guys,

 

Good news, it works ! I decided to create two projects separately using the same "mod" infos : version, modid, etc... For now, I have a client project and a server one. I have the same packet class in both projects, but each project has its own implementation of the packet. Registering the same packet to the same discriminator, it works like a charm !

 

However, I still have some questions about client/server side exercices : how can I check if my packets are leaking ? Furthermore, I decided to give a try sending player nickname through packets, here is the code :

 

    @Override
    public void             handleServerSide(MessageQuest message, EntityPlayer player) {
        ChatComponentText   text;

        text = new ChatComponentText("Currently, your singleplayer nickname is : " + message.playerName);
        player.addChatMessage(text);
        text = new ChatComponentText("However, here is your multiplayer nickname : " + player.getName());
        player.addChatMessage(text);
    }

 

Here, I am sending the player nickname through the packet. The message.playername is obtained by Minecraft.getMinecraft().thePlayer which is an EntityPlayerSP. The player.getName() is obtained through context.getServerHandler().playerEntity which is an EntityPlayerMP. Informations such as player nickname are "obtainable" by both client and server mechanics. Actually, I'm wondering how could I know when to get informations from server side or client side : I assume that the right method is to always get infos from server side, but I'd like your point of view about that

[BusyBeever]

The thing is if you think about it you ALWAYS know at which side you are at the moment.

If you are sending a packet always make sure that you define where your packet is going (client->server / server->client) that way you always know how to access the information when handling the packet.

e.g. a packet to sync tileentity data is supposed to go from server to client, so you know you can always access Minecraft.getMinecraft if needed etc