closes#5554
This is called just before the packet is decoded, allowing the event to be used to drop packets from clients without wasting CPU time decoding them. This can be particularly useful for mitigating denial-of-service attacks.
we want it to be included in receive timings, but not handler timings. Handler timings should reflect the time spent in the actual session PacketHandler, not in the event.
In refactors during PM4, I stripped out packet buffer caching, as it was problematic when events alter packets in undetectable ways.
However, I never cleaned this part of the code up properly after enabling DataPacketSendEvent to include multiple packets and multiple targets, so we were still individually encoding the packet(s) for every single session if the sum total of the sizes was below 256 bytes.
This change encodes packets once in the StandardPacketBroadcaster and retains their buffers to post to the session's send buffer directly if the resulting batch is below compression threshold.
This code is still not optimal (see ##5589), but fixing this brings broadcasting performance back to PM3 levels, without any of PM3's problems.
we don't translate raw string parameters anywhere else these days, so there's no reason to do so here either. The parameters array is already reduced to string[] by this point anyway.
the theoretical limit for transactions in this case is 64x9 (inputs) + 64x9 (output on crafting grid) + 64 (outputs to main slot) + 64 CraftingEventPackets = 1280.
This is an extreme case which assumes that a recipe could generate up to 64x10 (640) output items per iteration, filling every slot of the output grid, which should never occur in any reasonable circumstances.
I'm not quite sure this is the best way to enable such functionality, but it's already used for some other stuff, so I'm not too worried for now.
This allows the following commands to have their usage limited to self or others:
- /effect
- /enchant
- /gamemode
- /give
- /spawnpoint
- /teleport
- /title
I envision this being useful for creative mode servers, and test servers such as test.pmmp.io.
getName() essentially serves as an ID for the command for CommandExecutors. It has no other sane use case.
Since it's not unique (multiple commands with the same name may be registered, and the fallback alias will be used on conflict), it cannot be used for array indexing. It's also not correct to use it for any display purpose, since the command may not be able to be invoked by its 'name' if there was a conflict.
There is an open debate about what to do with getName() and the wider CommandExecutor ecosystem, but that's a topic for another discussion.
closes#5344
