How will Sponge seperate ClientSide and ServerSide code?

How will Sponge seperate ClientSide and ServerSide code? Forge uses an @ClientSideOnly or something like that. Will Sponge use this too? Thanks.

So far I know there is no client side API code yet. So yeah, I would not worry much about the client yet.

1 Like

Thanks thomas15v. Gawd you are hyperactive on this forum :frog:.

Not really, I just clicked “load new topics” :blush:.

^^^ this button to be precisely.

1 Like

Rofl :laughing:.

Currently, sponge doesn’t have a Client-Side. They want to, but not at the current time.

How would it separate? I don’t think it would, actually. Based on what sponge says in their FAQ’s, they plan on having the Multiplayer-plugins work ON SINGLEPLAYER!

This would be extremely cool - imagine having WorldEdit in those Lan Worlds!

1 Like

When it’s done, it will probably be similar to the FML / Forge way of doing it, annotating classes / methods / fields with the @SideOnly(Side.CLIENT) annotation and if there is rendering envolved, there will be things similar to proxys. I doubt they’ll reinvent the wheel.

1 Like

Just a note I’m pretty sure @SideOnly is trying to be phased out, unless the Forge documentation is outdated/wrong.

I myself wish for a system with a common/server jar (since the client will be a server in SP) and a client rendering jar, possibly loaded as a single zip. That would allow one to be updated asynchronously and force better practices by decoupling rendering from logic. Just a thought/opinion.

3 Likes

that would be awesome

I would love that, but that would require some changes to MC itsself. (Although for mods my opinion on this is different…)