Jump to content

1.16.3 -- Best way to keep track of players across the network boundary?


Xan the Dragon

Recommended Posts

This thread serves as a means of cross-checking my work more than anything. I want to ensure that I am using the best method possible to achieve my goals, as I am not particularly comfortable with my skills in data replication quite yet.

 

 The mod I am making is a sort of "trimmed" version of iChun's Morph mod. This mod simply allows players to alter their displayed model. The desired behavior of my network replication system should meet four goals in total:

On the client...

  1. Provide a means of requesting a model change from the server.
  2. Provide a means of requesting which model a specific player is using from the server.

On the server...

  1. Provide a means of propagating changes to a player's desired display model to all connected clients, so that the clients may render them appropriately.
  2. Provide a means of responding to requests asking for which model a specific player is using.

 

To synchronize this data across the network boundary, I am using the following packet class. My main concern is my choice of tracking players. Is there a system in place that can more easily keep a reference to a player that is common for the client and server alike? This player is not necessarily associated with the packet handler, of course. Additionally, is there a more optimal setup than what I have now? My method right now is to simply use UUIDs to identify players, as should be obvious. Apologies if the pascal case drives anyone mad, I've been doing a lot of C# work and prefer things to be in that style :P

 

public static class ReplicationPacket {
	
	/** The type of event that this is. */
	public EventType Type;
	
	/** The ID of the player this event pertains to. */
	public UUID PlayerID;
	
	/** The target entity that the associated player wants to become, should become, or currently is. */
	@Nullable
	public ResourceLocation TargetEntity = null;
	
	/**
	 * Represents a type of morph replication packet, which describes the behavior that this packet should have on the associated side.
	 * @author Eti
	 */
	public static enum EventType {
		
		/** A player has changed their model or joined with a model on.<br/>
		 * Update the client registry to the packet's defined data to determine how to render this player.
		 * Additionally, the player that requested this morph should actually morph at this point.<br/><br/>
		 * TODO: Provide means of client-feedback for slower connections / long processing time on the serverside to prevent people from getting confused at the lack of any immediate changes.
		 * */
		UpdatePlayerModel,
		
		/** A player wants to change their model, and is asking the server to propagate said change. */
		ChangePlayerModel,
		
		/** A player is asking the server what someone's model is. */
		GetPlayerModel,
		
		/** A response to GetPlayerModel. If the target entity is null, the player is using their stock player model. */
		IsPlayerModel,
		
	}
}

 

Thanks for your time.

Edited by Xan the Dragon
Grammar change

Check out my website!

Link to comment
Share on other sites

That would be done via a capability. You would store the entity type of the model the player is using and whenever that value changes, sync it to all players tracking and self. You will need to sync whenever a new player starts tracking the entity. From there, the rest is just handling the client rendering such that it uses the entity provided in probably RenderLivingEvent$Pre and not the stored instance of your player.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.