Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[SOLVED] Adding tasks for different side than original(CLIENT-SERVER) by using NetworkEvent.Context


Mr Bonobo
 Share

Recommended Posts

What is the new way of adding task to work queue?

What i want to do in old way:

public static void handle(Packet message, Supplier<NetworkEvent.Context> contextSupplier) {
FMLCommonHandler.instance().getWorldThread(contextSupplier.netHandler).addScheduledTask(() ->

New way:

public static void handle(Packetmessage, Supplier<NetworkEvent.Context> contextSupplier) {
      contextSupplier.get().enqueueWork(() -> {

If contexSupplier is CLIENT, it will add task on CLIENT. So what should i do to add task on DEDICATED_SERVER, even though contextSupplier is CLIENT?

Edited by Mr Bonobo
Link to comment
Share on other sites

Ok, I somewhat managed to make it work in different way by accessing capability values with:

 

public static void handle(PacketTriggerElectricGen message, Supplier<NetworkEvent.Context> contextSupplier) {
contextSupplier.get().enqueueWork(() -> {
    contextSupplier.get().getSender().getServerWorld().getTileEntity(message.blockPos).
            getCapability(new UtilCapabilities().UTIL_CAP).ifPresent(st -> {

And context shouldnt be in CLIENT-side, because this packet is triggered by sendToServer(new etc...) from CLIENTside, only sender should be a CLIENT. Even though i tested with DistExecutor which side it is, and it shows its always a CLIENT, but maybe its SERVER after all if I managed to access SERVER side capability values.

Link to comment
Share on other sites

You are the confusing the concepts of distribution (dedicated server vs the client launched from the launcher, this is what DistExecutor checks) vs logical side (server, including integrated server used in singleplayer, vs client, the thing that renders the game and accepts inputs).

What matters here is the logical side, which is usually accessible using World#isRemote (true on the client). The context also tells you the direction (it is on the network thread, this is why you need to "enqueueWork" and also why you don't have a world here) using NetworkEvent.Context#getDirection.

  • Thanks 1
Link to comment
Share on other sites

3 minutes ago, diesieben07 said:

You are the confusing the concepts of distribution (dedicated server vs the client launched from the launcher, this is what DistExecutor checks) vs logical side (server, including integrated server used in singleplayer, vs client, the thing that renders the game and accepts inputs).

What matters here is the logical side, which is usually accessible using World#isRemote (true on the client). The context also tells you the direction (it is on the network thread, this is why you need to "enqueueWork" and also why you don't have a world here) using NetworkEvent.Context#getDirection.

Wow! Very good and full-explanitory post. It solved probably all my questions. Only one question came from it: if i create packet, which is sent from a SERVER and handled by a CLIENT, I dont need to use enqueueWork then, or I should add this scheduled task always to prevent bugs/overlapping even on CLIENT side??

Link to comment
Share on other sites

Just now, Mr Bonobo said:

if i create packet, which is sent from a SERVER and handled by a CLIENT, I dont need to use enqueueWork

Yes, you do. Packets are received on the network thread always, that's why you need enqueueWork (you can read the name as "doThisOnMainThread"). Most of Minecraft is not thread-safe, which is why you need to schedule your code to run on the main thread if you want to do anything meaningful from your packet.

  • Thanks 1
Link to comment
Share on other sites

1 minute ago, diesieben07 said:

Yes, you do. Packets are received on the network thread always, that's why you need enqueueWork (you can read the name as "doThisOnMainThread"). Most of Minecraft is not thread-safe, which is why you need to schedule your code to run on the main thread if you want to do anything meaningful from your packet.

A many thanks to you! :)

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
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.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.