There are several setup events I can hande:

• FMLCommonSetupEvent - called for both client and server.
• FMLClientSetupEvent - client only.
• FMLDedicatedServerSetupEvent - dedicated server only, NOT single player/LAN game server.

 

Where is the FMLServerSetupEvent that runs for both single player/LAN game servers and dedicated servers?

 

I have read https://docs.minecraftforge.net/en/1.19.x/concepts/sides/ extensively. A DistExecutor seems overkill. In the common setup event handler I just want to check the side and do client/server specific stuff.

 

How do I do setup for a logical server that may be running as a single player game or may be running as a dedicated server?

import net.minecraftforge.fml.LogicalSide;
import net.minecraftforge.fml.util.thread.EffectiveSide;


...
    private void commonSetup(final FMLCommonSetupEvent event)
    {
        if (LogicalSide.SERVER == EffectiveSide.get())
        {
...
        }
    }

 

The above code compiles (when you fill in the missing bits). It does not work for a single player game. I am not sure if it works for a dedicated server.

Maybe if FMLCommonSetupEvent was called FMLLogicalServerSetupEvent you would understand what it is for? 🙂 

If you are checking isClient() in the common setup you are doing it wrong.

The DistExecutor is for runtime when you might not know which side you are on. Or you do know but want to safely switch to the other logical side.

The DistExecutor is just a different form of control statement. e.g. the java if control statement could be used in a similar way

static void If(boolean predicate, Supplier<Runnable> Then, Supplier<Runnable> Else) 
    if (predicate) {
       Then.get().run();
    } else {
       Else.get().run();
    }
}

My understanding is that FMLCommonSetupEvent() triggers for both client and local server and dedicated server, which is why it has "Common" in the name, so calling it FMLLogicalServerSetup() would be incorrect.

 

I have found that my snippet above works for other events, such as PlayerEvent.PlayerLoggedInEvent.

 

The LogicalServer is present everywhere, it is "common".

So yes it will trigger on the PHYSCIAL client.

If Mojang ever release a "thin client" that doesn't include single player mode things will be different.

 

PlayerLoggedInEvent is a runtime event not a mod event.

The correct way to do it there is as mentioned in the document you link 

if (player.level.isClientSide) ...

You can find literally hundreds of examples in the vanilla code.

Quote

The LogicalServer is present everywhere, it is "common".

This contradicts both the documentation and my own experience. In the single player version there is a separate server thread. According to the documentation, and I agree based on over two decades as a professional software engineer, the code needs to distinguish between the server thread and the client (render) thread when doing anything server based so that when the mod is used on a dedicated server, everything works as expected. There are explicit warnings in the documentation to the effect that failing to do this correctly leads to crashes when a mod that works perfectly as a single player/LAN game is used with a dedicated server with multiplayer clients connecting to it.

 

The documentation talks about Level#isClientSide(), yes, but the information I was missing was that I didn't know where to get an instance of Level from. I didn't realise that it was a member of the Entity class until I read your post and searched for "level" in the documentation of the "Player" class.

Quote

if (player.level.isClientSide) ...

Thank you very much for helping me figure this out.

 

Quote

This contradicts both the documentation and my own experience. In the single player version there is a separate server thread. According to the documentation, and I agree based on over two decades as a professional software engineer, the code needs to distinguish between the server thread and the client (render) thread 

We are talking about very different things.

There are the mod event bus events that run at game startup to do one time initialisation.

 

Then there are the runtime events for when the actual server/runtime is starting (ServerLifecycleEvents + others).

Which do things that need to change things based on which save is loaded.