[SOLVED] [1.10] Player connect event ?

[DBLouis]

Hi,

 

I'm looking for an event that Forge is firing when a player connect to the server. Everything I found on Google is old stuffs ...

 

EDIT :

 

I found this : FMLServerAboutToStartEvent

It says "Called after FMLPostInitializationEvent on the dedicated server, and after the player has hit "Play Selected World" in the client", but I wanna be sure if this is also fired when connecting to a server.

 

[Matryoshika]

No, that is only fired when the server initially starts.

 

You can subscribe to

PlayerEvent.PlayerLoggedInEvent

alt either

FMLNetworkEvent.ClientConnectedToServerEvent

or

FMLNetworkEvent.ServerConnectionFromClientEvent

.

ClientConnectedToServerEvent

is only fired on the client, and

ServerConnectionFromClientEvent

is thus, only fired on the server.

 

I've also heard that the

PlayerEvent.PlayerLoggedInEvent

requires you to wait a tick before doing anything, as the event is fired before the player-entity is created.

[DBLouis]

How can I get the PlayerLoggedInEvent from ServerConnectionFromClientEvent ?

 

EDIT: Like this ?

 

@SubscribeEvent

public void onPlayerLoggedIn(PlayerLoggedInEvent event) {

    if (event.player.isServerWorld()) {

        EntityPlayerMP player = (EntityPlayerMP) event.player;

        ...

    }

}

[Matryoshika]

How can I get the PlayerLoggedInEvent from ServerConnectionFromClientEvent ?

Those are 2 different events altogether. They both fire when the player connects to the server, but in different places.

 

Don't cast the Player to EntityPlayerMP or EntityPlayerSP unless you really do have to. Most if not all you really need exist in EntityPlayer already, which is what the event#player is.

Entity->EntityLivingBase->EntityPlayer-> [EntityPlayerSp | EntityPlayerMP]. SP/MP are the same thing, just on the opposite sides of the server/client coin.

 

If you only want to do something server-side, check if

event#player#worldObj#isRemote

returns false, and then do something, instead of checking

isServerWorld()

.

[DBLouis]

I don't need ServerConnectionFromClientEvent then.

How can I check that the server is dedicated ? I want to exclude the integrated server case.

 

I need an EntityPlayerMP to call a method, so I have to cast, but I think it's safe if I checked on what side I am before.

[Matryoshika]

Aaaaah. My bad then.

You can simply skip checking what side you are on, and focus directly on the player instead.

Your previous code-snippet should be fine to run, however, it is not explicitly safe.

If you are on a server, the player should be EntityPlayerMP, yes, however, you never actually check if the player IS EntityPlayer first.

You can cast classes to equal or super classes. You cannot cast it to another forked class like EntityPlayerMP/SP are.

 

You can simply check:

if(event.player instanceof EntityPlayerMP){
   EntityplayerMP player = (EntityPlayerMP) event.player;
   //Rest of your code.
}

That is explicitly safe casting. Only cast to what you know you are casting to.

Who knows, with the power of Java, pigs can easily fly. A mod spawning an EntityPlayerSP on a server wouldn't be too hard to imagine, bar for what possible reason.

[DBLouis]

Ok so what you're saying is if the player is an EntityPlayerMP, then I'm on the server side of a dedicated server for sure, that's it ?

[Ernio]

No.

 

There are always 2 sides. There is one Entity for each side.

Client + Integrated (also integrated LAN)

Client + Dedicated (or other non-integrated, like outside LAN).

 

EntityPlayer is a special Entity where Client thread uses AbstractClientPlayer (for EntityPlayer you control, Minecraft#thePlayer, it's EntityPlayerSP), server thread uses EntityPlayerMP.

So to answer your question - "if (player instanceof EntityPlayerMP)" is almost same check as "if (!World#isRemote)" - where remote means that code is ran on client (so negative is server). you can sue Entity#worldObj to check logical side.

More here: http://mcforge.readthedocs.io/en/latest/concepts/sides/

 

Now - you shouldn't create mods that are physical-side specific (meaning they work differently on dedic and integrated). It will get messy for a novice. If you are planning on writing sided mods you should be writing two mods such as one for ONLY dedic, and one for ONLY client.

Otherwise you should write universal mod (and for real - dedic and integrated is the same thing, so it's easier this way).

 

To solve your problem in best possible way - please describe the goal you are after, including on what side what should happen. Some of code/events are reserved for specific sides so it's important to state end-goal (like e.g: checking if server is dedic looks different for server and different for client that connects to it).

[DBLouis]

I probably should have explain the purpose of this at the beginning 

The dedicated server must send some settings to the connected clients : recipes, block hardness and resistance ...

This is dedicated server behavior only, not integrated.

[Ernio]

If you want your mod to be "universal" (keep it in one .jar), this is step by step on how I'd do it:

 

Events part:

1. Create DedicatedServerEvents.class. Mark it with @SideOnly(Side.SERVER).

2. @SubscribeEvent to PlayerLoggedInEvent in class above.

3. Register class above from ServerProxy (call during preInit).

4. At this point whenever mod is ran on dedicated server (so ServerProxy is fired), you will be firing event for all players that log in on this server.

 

Dedicated part:

1. In ServerProxy load (during preInit) your data from files (using forge config or configs of your design).

2. Place loaded data in @SideOnly(Side.SERVER) static storage - it could be for example Map<Block, Double> for block hardness or other ways for different values.

3. Use loaded data to change vanilla values. In mod's init (ServerProxy) call Block#setHardness and other methods you want and use data you loaded from config.

4. At this point whenever mod is ran on dedicated server (so ServerProxy is fired), you will be modifying vanilla properties with stuff loaded from configs while storing this data in static maps. @SideOnly also prevents those classes/fields from existing on Client.jar, so there is that.

 

Syncing stuff:

1. Create SimpleNetworkWrapper and proper IMessages (remember about thread safety).

2. In PlayerLoggedInEvent send data from server's static maps to client (serialize them into something and deserialize on receiving client).

3. On receiver client modify proper Blocks by puling them from registry by names (So e.g: in your packet you send arrays of stuff like: "modid:blockname"=5.0D).

 

This should work assuming vanilla allows such hot-modifications to hardness values.

 

Note that similar effects (for only some of block properties) can be achieved with HarvestSpeed (or whetever the name was) and some other events.

 

BIG NOTE: Mind EVERY word I wrote - each one of them is important as they directly describe possible design approach.

 

Questions?

[DBLouis]

Thanks a lot