I’ve played about with a sending a block description to a client when connection to a server. It worked, as in I could change the hardness of the custom block. I used JSON to send the block description and the client could register it. As blocks could only be loaded in the Init phase, it registered a stub block, which could have different properties depending on it’s metadata.
This is essentially what Forge Multipart does, so for block information I could try and serialize TileMultiparts into JSON.
@disconsented that’s all that’s being asked for - adding new blocks that are just reskinned normal blocks, etc. The client would have a mod that parses the information (texture + ID #) into a working block, the server would run a plugin that sends the information to the client mod. All that sponge has to do is provide a channel for server plugins to communicate with client mods, (and a method to add new block types / entity types / etc. to the server) - just look at the Carbon plugin for Spigot to see the serverside part of the plan in action under the severe restrictions of the Bukkit platform.
1 Like
I haven’t read this entire thread so forgive me if this has been mentioned. Would it not be possible to use something like lua to store info that the client needs to know then simply send that to the clients instead of some nasty java code that could be exploited? Lua has most if not all the features that would be required, you could use it to send models, then send the textures separately.
While lua hasn’t been specifically mentioned we never considered sending java code, we would send some serialized version of a java object or send it in a format such as JSON a client could easily interpret. Lua sounds interesting but couldn’t that still be exploited?
I would imagine it would be really hard to exploit it if it’s sandboxed and only certain methods are called.