Adding custom data to the client

[Tomalla]

The problem is simple: I need to store some data on the client side, i.e.: the "mode" the player is in, maybe registered actions etc. It doesn't really matter. What does matter is, that every client would have its own instance of this data, separate from other clients and the server. Also, if it's possible, I'd like the server to be able to read this data from the particular, specified player.

 

I don't quite know where to start. Where should I initialize the object? Do I need to register it somehow? I'd appreciate some hints on this.

 

Cheers

[grabie2]

First you need to create class that would store the data for you.

 

Then you'll need to use packets to sync data with server, I'll recommend keeping instances of all client data objects on server and only syncing data changes.

On forge wiki you can find packet tutorial.

[Tomalla]

Then you'll need to use packets to sync data with server, I'll recommend keeping instances of all client data objects on server and only syncing data changes.

 

That's the thing - I don't want to keep these instances on the server for every client. My idea was to keep them on the client side. If server wanted this data for a specified player, he would query the player and get from him the data he wants ( not necessarily using packets - maybe one simple function deriving from a player class? I don't know if it's possible ).

 

This client - server communication part seems to cover the main problem, which is storing the data for a client. If we dumped the need for client-server communication - can player hold any custom data on his own? Something like the Minecraft instance, which reassembles the client, really generally speaking.

[mnn]

can player hold any custom data on his own? Something like the Minecraft instance, which reassembles the client, really generally speaking.

I'm not sure I understand what you want. Your mod is being executed on a client side as well, you can check where you're running using e.g. FMLCommonHandler or proxy. For holding data you just create some fields in your mod's class and use them. Is it that simple or you're want something more? Saving stuff on a client side is also possible, simple example is the config file (more complex stuff you would probably have to write on your own, I don't know about anything in forge/fml that would allow this type of thing. java's serialization is not bad, you could use that. or simple property file).

 

Synchronization of not many data could be done via datawatchers, but they're quite limited and also your mod could conflict with other mods. Custom packets are the best way imho.

[Tomalla]

Alright, since it seems I've got problems with describing the problem, I'll try to explain what I want to achieve.

 

I've registered a custom entity. When a player right-clicks on it, it does something. This depends on the editing mode the player is in. The player can change the mode by pressing a Tab key for example. When a player interacts with my custom entity, I want it to check what editing mode this player is in and do something with it.

 

Every player can have different editing modes. Imagine this situation: there are two players in different "editing mode" each. They right click the custom entity and it either executes action A or action B, depending on the editing mode.

 

Now the question is: where should I store the information about the "editing mode"? And to generalize the problem, how can I store entire class with custom data which I can attach to each player?

 

I hope everything is clearer now.

[mnn]

Alright, since it seems I've got problems with describing the problem, I'll try to explain what I want to achieve.

It's entirely possible that's my fault, my english is not great.

 

Now the question is: where should I store the information about the "editing mode"? And to generalize the problem, how can I store entire class with custom data which I can attach to each player?

On a server side you can use NBT and the persistent tag. It's not common to hold data only on a client side. Usually this kind of things is done like this: client wants to change a mode, sends packet to a server, server changes mode sends updating packet to the client, client changes mode. This way you can at any moment access mode on a server and when using NBT in a player entity it's automaticly saved.

 

If you want to save your class on a client you can use the java serialization and save it to the config folder, or serialize your class manualy using forge config class, or use separate NBTs and serialize it to file (haven't done that, but it's possible).

 

I'm not in a modding for a long time, imho this should be answered by someone more experienced...

[Tomalla]

Yes I know the client is evil, the client cannot be trusted. But the server does not have to know everything. The editing mode is just the client's business. Once my custom entity on the client side is being interacted with, it sends the packet to the server with the type of the edit ( the client's editing mode ) and other data associated with it describing what has changed. The server doesn't have to know beforehand what the editing mode actually is.

 

Another example, which is something I'm planning to implement as well:

 

I want to make a SoundManager wrapper class, responsible for the sounds being played on the client. The SoundManager instance is on the client side and is accessible via Minecraft instance ( Minecraft.getMinecraft().sndManager ). The question is: where should I initialize the wrapper to be instanced and accessible by each client, the way the SoundManager is? If I initialize it in one of the methods of the mod itself ( i.e. as a field in the mod class ), it's being shared between all clients. I'm hopeless.

[Tomalla]

I'm surprised nobody has ever had such a problem before. Having some data on the client side is essential for my plans and it's going to be a core mod anyways.

 

I'm thinking of putting a custom client manager of sort either in Minecraft class or FMLClientHandler class ( and so the initialization problem would be a goner ). Any thoughts which one's a better option? Maybe other ideas? I'd really appreciate it.