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
closes#5154
this hack sends only the bare essential data to create the tiles in LevelChunkPacket,
and then separately sending the full tile data using BlockActorDataPacket afterwards.
This is necessary because the client doesn't handle items correctly in NBT when chunks are sent without using the SubChunkRequest system.
In 4.6 this is observed with incorrect items shown in item frames; in 5.0 it's seen with items simply not showing up at all (difference due to modernization of the serialization format in 5.0).
the current data management system uses case-insensitive names, so we can't allow different players with the same name in different cases to join, or we will have duplication exploits.
This typically only applies to offline servers, since Xbox Live doesn't permit reuse of a username, same case or otherwise.
closes#4965
- Added the following API methods:
- `Player::hasBlockCollision()`
- `Player::setHasBlockCollision()`
This enables spectator-like noclip behaviour in other gamemodes (could be useful for builders).
This reverts commit 866020dfdb.
For some fucking reason this broke resending chunks in some cases (and
sending chunks at all in others). I don't have time to debug this right
now, so it's going to have to remain broken, infuriatingly enough.
in the normal case, all sessions will share the same PacketSerializerContext and Compressor, so this code will be the same as before
However, for the multi-protocol hackers out there, this should reduce the maintenance burden (@Driesboy) since now only the PacketSerializerContext needs to be maintained. I recommend a separate PacketSerializerContext for each protocol (perhaps put the protocol version in the serializer context too, if you need it for some reason).
