Fixed IndexOutOfBoundsException for ClientPlayerDigging, ClientClientStatus, and ClientInteractEntity

[DemonDxv]

No description provided.

[NoJokeFNA]

We now have the class 2 times, no?
https://github.com/retrooper/packetevents/pull/1371/files#diff-ea1bb08a8407de704db4ba3657b251d706d8cc19d1ad124504fd33e4fd6c5ef6R168

[NoJokeFNA]

I don’t get why these imports need to be in this class.
Why did you touch this class at all? Nothing’s really been added.
Also, your TODO comment should probably be an issue instead.

[booky10]

I'm not really a fan of adding yet more of these "UNKNOWN" enum states
Idk what @retrooper thinks, but in my opinion making them nullable seems like a more appropiate solution then adding an enum value which doesn't actually exist

[NoJokeFNA]

I actually like this approach. IMO it’s better to check if the enum is UNKNOWN than to handle nulls or exceptions. proto3 does something similar — it uses UNRECOGNIZED.

[DemonDxv]

I'm not really a fan of adding yet more of these "UNKNOWN" enum states Idk what @retrooper thinks, but in my opinion making them nullable seems like a more appropiate solution then adding an enum value which doesn't actually exist

I wouldn't of made this poll request if I didn't think it would benefit everyone, if you continue to leave it as is, people can just bot a server with pe 2.0 and send invalid packet data spamming the console with errors. I also noticed that even legit players get kicked and console error for these. One of the major ones was the TODO that i could not fix but since removed. Many legits kept erroring packetevents for index out of bounds based on the face value pe would read.

[retrooper]

Thanks for the PR.

[retrooper]

Instead of adding 'UNKNOWN' fields to every enum, let's have the methods that get an enum from an ID return null if the ID is invalid. I think this is the best move here.