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

[Mr Bonobo]

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 June 27, 2020 by Mr Bonobo

[Mr Bonobo]

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.

[Mr Bonobo]

Btw im new here, so have no idea how to mark thread as solved

[Mr Bonobo]

Btw im new here, so have no idea how to mark thread as solved

[Mr Bonobo]

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

[Mr Bonobo]

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!