Jump to content

[1.12.2] Problem getting world with ClientPacketHandler


Meldexun

Recommended Posts

So i want to send a packet from the server the the client and when receiving the message i need the client world. But when starting a server the server crashes because the Minecraft class does not exist on the server. But the message should just be received on the client side. Now i don't really know how to solve the problem.

MessageHandler:

public class CPacketSyncEntitySpawnerHandler implements IMessageHandler<PacketSyncEntitySpawner, IMessage> {

	@Override
	public IMessage onMessage(PacketSyncEntitySpawner message, MessageContext ctx) {
		World world = Minecraft.getMinecraft().world;
		
		TileEntity tileEntity = world.getTileEntity(new BlockPos(message.getX(), message.getY(), message.getZ()));
		if (tileEntity instanceof TileEntityEntitySpawner) {
			TileEntityEntitySpawner t = (TileEntityEntitySpawner) tileEntity;
			t.setEntityID(message.getEntityID());
		}
		return null;
	}
	
}

 

And that is how i registered my Message:

CrystalicVoid.CONNECTION.registerMessage(CPacketSyncEntitySpawnerHandler.class, PacketSyncEntitySpawner.class, 0, Side.CLIENT);

 

Link to comment
Share on other sites

The problem is that i want to send a packet from the client to the server and then when the packet is received on the server in need the world of the server. But when i send the packet in singleplayer it always picks the world of the client and not of the server when using SidedProxy. It seems logical but doesn't achieve what i want.

My MessageHandler:

Spoiler

public class PacketSyncEntitySpawnerHandler implements IMessageHandler<PacketSyncEntitySpawner, IMessage> {

	@Override
	public IMessage onMessage(PacketSyncEntitySpawner message, MessageContext ctx) {
		World world = CrystalicVoid.proxy.getWorld(message, ctx);
		
		//do stuff
		return null;
	}
	
}

 

 

My ClientProxy:

Spoiler

public class ClientProxy implements IProxy {
	
	@Override
	public World getWorld(PacketSyncEntitySpawner message, MessageContext ctx) {
		return Minecraft.getMinecraft().world;
	}
	
}

 

 

My ServerProxy:

Spoiler

public class ServerProxy implements IProxy {
	
	@Override
	public World getWorld(PacketSyncEntitySpawner message, MessageContext ctx) {
		return ctx.getServerHandler().player.world;
	}
	
}

 

 

This should work with a dedicated server and a dedicated client. But in singleplayer it always gives the world of the client side and not of the logical server side.

Edited by Meldexun
Link to comment
Share on other sites

So now i got this:

Spoiler

	@Override
	public IMessage onMessage(PacketSyncEntitySpawner message, MessageContext ctx) {
		World world = null;
		if (ctx.side.isClient()) {
			world = CrystalicVoid.proxy.getWorld(message, ctx);
		} else if (ctx.side.isServer()) {
			world = ctx.getServerHandler().player.world;
		}
		
		//do stuff
		return null;
	}

 

And now it's working.

When received on a client side it now uses @SidedProxy because using Minecraft#getMinecraft()#world directly would obviously crash the server.

And when received on a server side i doesn't use @SidedProxy because in singleplayer it would give me the the world of the client and not of the logical server.

Maybe there is a better solution?

Edited by Meldexun
Link to comment
Share on other sites

@SidedProxy distinguished between physical sides. You seem to want to distinguish between logical sides. Also, any interaction with minecraft objects from a packet thread needs to be done inside of a scheduled task.

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

11 hours ago, Cadiboo said:

@SidedProxy distinguished between physical sides. You seem to want to distinguish between logical sides. Also, any interaction with minecraft objects from a packet thread needs to be done inside of a scheduled task.

That's why i asked for help. And i will look at scheduled tasks. Thanks.

 

40 minutes ago, diesieben07 said:

Your message handler knows the side it is received on. Just access the server world directly, do not use your proxy for that. Your proxy should have a getClientWorld method, which throws an exception on the server.

Isn't that what i'm doing in my latest post? When the packet is received client side (what i check with ctx#side#isClient()) then i use my proxy and when recieved on server side i directly access the world.

Link to comment
Share on other sites

I have a block with a tileentity and a gui that opens when the block is right clicked. When the tileentity is loaded on client side it sends a packet to the server which requests that the data from the server tileentity is send with a packet to the client.

And then when pressing DONE in the gui it sends a packet with the data from the gui to the server.

That seemed to be the most efficient way.

Link to comment
Share on other sites

8 minutes ago, Meldexun said:

tileentity is loaded on client side

Why do you need to send a packet when the tile entity is loaded? Please elaborate.

If you only want to get data from the server whenever the GUI is opened, you probably wouldn’t need two packets (depending on your needs, you might not even need packets at all).

 

If you need to send data to both sides, use two packets.

Edited by DavidM

Some tips:

Spoiler

Modder Support:

Spoiler

1. Do not follow tutorials on YouTube, especially TechnoVision (previously called Loremaster) and HarryTalks, due to their promotion of bad practice and usage of outdated code.

2. Always post your code.

3. Never copy and paste code. You won't learn anything from doing that.

4. 

Quote

Programming via Eclipse's hotfixes will get you nowhere

5. Learn to use your IDE, especially the debugger.

6.

Quote

The "picture that's worth 1000 words" only works if there's an obvious problem or a freehand red circle around it.

Support & Bug Reports:

Spoiler

1. Read the EAQ before asking for help. Remember to provide the appropriate log(s).

2. Versions below 1.11 are no longer supported due to their age. Update to a modern version of Minecraft to receive support.

 

 

Link to comment
Share on other sites

23 minutes ago, DavidM said:

Please elaborate. 

I need the data for opening the gui. It should display the data from the server.

21 minutes ago, diesieben07 said:

Vanilla already has a perfectly adequate data-syncing mechanism for tile entities.

I have read that i should create my own packet and handler to sync my tile entity most efficiently. And my tile entity should just sync when someone interactes with it. I think vanilla always syncs the tile entities and that would create much network traffic (i just think so. Correct me when i'm wrong)

 

21 minutes ago, diesieben07 said:

If you treat them the same, you enable cheating.

It should be kind of cheating. The block is creative only and the client should say "This is the new data, use it from now on"

Edited by Meldexun
Link to comment
Share on other sites

1 hour ago, diesieben07 said:

Okay. So then: When the TE is right clicked (or whatever the interaction is), send a packet from server to client which contains the data. The client can then open the GUI. 

But then it always sends a packet from server to the client when the block is right clicked. When you right click the block it 3 times in a short period of time it sends 3 packets.

Currently it sends only a packet when the tile entity is loaded. So it sends just 1 packet.

1 hour ago, diesieben07 said:

Except if you use the same packet the packet can be sent by survival clients as well. For blocks that are thousands of blocks away. 

I don't understand how a new second packet solves this issue.

I could check when the packet is received server side if the sender is in creative mode.

Link to comment
Share on other sites

1 hour ago, diesieben07 said:

that is the same as vanilla syncing then.

I thought vanilla sends more packets. But that doesn't matter. You are right. I will change it so it only sends a packet from server to client when the block is right clicked. Often opening the gui will cause much traffic but when not opening the gui it causes zero traffic. Seems the best option.

Link to comment
Share on other sites

It looks like i have to open the GUI server side. I'm using a GuiHandler and when calling player#openGui at the end of my packet handler on the client side it seems to create a broken gui.

So what i now try to do is:

When the block is right clicked on server side it will send a packet to the client which tells him to update the tile entity with the data sent from the server. As an answer the client then sends a packet which requests the server to open the gui. When received on the server it checks if the player is in creative mode and then opens the gui.

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.

Announcements



×
×
  • Create New...

Important Information

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