* Update player list gamemode on world change
* Fix invisibility for spectators, use entity metadata
* Populate m_World for cPlayers on load
- Remove SendPlayerMaxSpeed, a duplicate of SendEntityProperties
* Flush out all pending, buffered changes at the end of each tick, after every chunk is ticked. This makes every block update client-side in unison, instead of unlucky ones only being sent 1 tick later.
* Re-add buffer for outgoing network data; IOCP async WSASend has higher overhead than expected... Fixes regression introduced in 054a89dd9
+ A cPlayer, once created, has a strong pointer to the cClientHandle. The player ticks the clienthandle. If he finds the handle destroyed, he destroys himself in turn. Nothing else can kill the player.
* The client handle has a pointer to the player. Once a player is created, the client handle never outlasts the player, nor does it manage the player's lifetime. The pointer is always safe to use after FinishAuthenticate, which is also the point where cProtocol is put into the Game state that allows player manipulation.
+ Entities are once again never lost by constructing a chunk when they try to move into one that doesn't exist.
* Fixed a forgotten Super invocation in cPlayer::OnRemoveFromWorld.
* Fix SaveToDisk usage in destructor by only saving things cPlayer owns, instead of accessing cWorld.
- Removed RemoveFromAllChunks. On destruction cWorld::RemovePlayer calls RemoveClientFromChunks already, and there's no need to manually clear the chunk lists.
* Turn off global-constructors warning. These are needed to implement cRoot signal handler functionality
* Add Clang flags based on version lookup instead of a compile test. The CMake config process is single threaded and slow enough already
* Reduced GetStackValue verbosity
+ Clarify EnchantmentLevel, StayCount, AlwaysTicked, ViewDistance signedness
+ Give SettingsRepositoryInterface a move constructor to simplify main.cpp code
- Remove do {} while (false) construction in redstone handler
* Tried to fix a small issue...
Ended up rewriting a bunch of god awful, opaque code with no source
and no sense. Who names a function GetPlayerRelativeBlockHardness???
It's gone now. We're safe again.
* Testing anti-cheat.
* Tidy up debug logging.
* Remove empty member declaration.
* Rewrite GetDigSpeed slightly for better readability.
* GetMiningProgressPerTick now returns 1 when instantly mined. Fixed hasily written typo.
* Comment style and typo fixes.
* TNT: Implement tracing algorithm
+ Add intensity tracing
* Fix iterating over all players to SendExplosion, even those not in range
* Implemented TNT entity interaction
* Fixed misaligned destruction tracing
* Finalise TNT algorithm
- Remove BlockArea and just use chunks
Using SetBlock makes it so that we can update everything properly, and does appear to be faster.
* BlockInfo learns about explosion attentuation
* Rename Explodinator parameters
* TNT: pull block destruction into common function
Co-authored-by: Alexander Harkness <me@bearbin.net>
* Introduce recipe book functionality
The recipe book helps especially new players. Missing it gives the
impression that cuberite is not as advanced as it is.
The handling of the recipe book uses the following functions:
- Unlock Recipes
(https://wiki.vg/index.php?title=Protocol&oldid=14204#Unlock_Recipes) to
make recipes available and show the notification for new recipes.
Initialization is done on player login for known ones, the update is done
when new items are discovered.
- Craft Recipe Request
(https://wiki.vg/index.php?title=Protocol&oldid=14204#Craft_Recipe_Request)
when the user selects a recipe from the recipe book to fill the slots.
Known recipes are initialized on player login via `Unlock Recipes` with
`Action` 0.
As soon as a new recipe is discovered this is added via `Unlock Recipes`
with `Action` 1.
To be able to know and recognize new recipes the player class is
extended with `KnownItems` and `KnownRecipes`. As soon as a player
touches an item this is compared to the list of `KnownItems`, if the
item is unknown the recipes are checked for this item and the other
ingredients are checked with the list of `KnownItems`. If a full match
is discovered the recipe is unlocked with the client and stored in the
`KnownRecipes`.
To unlock recipes the recipe ID is sent to the client. A mapping file
(for protocol 1.12.2) translated the minecraft recipe names to ids. The
crafting.txt is extended with and minecraft recipe names is possible.
Limitations:
Only a single recipe is added to the crafting area. Multiple clicks or
shift click does not increase the number of builds.
Co-authored-by: peterbell10 <peterbell10@live.co.uk>
* Address first issues mentioned by @peterbell10
- Some linting
- Extract loading of recipe specific protocol mapping into a function
- Build `RecipeNameMap` only once
- Use `std::optional`
- Extract `LoadRecipe` from `Window`
* Start to implement new suggestions
* Update with suggestions from @peterbell10
* Some minor cleanup
* Update protocol packet IDs
* Remove unused include
* Include header in cmake
* Change a vector to integer counter
* Change dromedaryCase method names to PascalCase
* Address suggestions from @madmaxoft
* Read Protocol subdirectories to load recipe books
To load all recipebooks iterate over the `Protocol` subdirectories
to find mapping files.
Co-authored-by: peterbell10 <peterbell10@live.co.uk>
* Avoid inefficient AString -> c_str() -> AString round trip
* Avoid redundant string init expressions
* Avoid unnecessary return, continue, etc.
* Add .clang-format to help with clang-tidy fix-its
* Avoid unnecessary passing by value
* Avoid unnecessary local copying
* Avoid copying in range-for loops
* Avoid over-complicated boolean expressions
* Some violations missed by my local clang-tidy
* Allow unnecessary continue statements
* Add brackets
* Another expression missed locally
* Move BindingsProcessor call into clang-tidy.sh and add space
* Fix pushd not found error
* Different grouping of CheckBlockInteractionRate
* Make puking pickups fly nicer
* Improve entity position updates
* Move determination of whether a delta is too big for a packet into the protocol handlers
+ Less jittery movement
+ Generalise CollectEntity to take any entity
1. implement protocol message SendHeldItemChange
2. add save / load inventory equipped item slot in JSON
3. send held item slot message after player connect to server
Fixes#4189
* Add hand parameter to distinguish main hand/off hand.
* Add a new function cClientHandle::HandleUseItem to separate the functionality of using an item without a target block. This matches the protocol with client version >= 1.9
* Always actively update the status of a block if the placement fails (by out of reach or rejected by plugin).
* Do not call plugin callback CallHookPlayerRightClick(-1, 255, -1, -1, 0, 0, 0) when using item.
The CallHookPlayerUsingItem will still be called.
Now at most one of CallHookPlayerRightClick, CallHookPlayerUsingBlock,
CallHookPlayerUsingItem and CallHookPlayerEating will be called based on
the type of action (not including the used version of callbacks).
* Do not count using item as BlockInteractionsRate check (Using item takes time).
* Now we can open chests(etc.) when sneaking as long as the player's hand is empty.
This is what vanilla server does.
* Made BroadcastSoundEffect take vector parameters.
* Added docs for new vectored methods
* Removed old code
* Fixed lua warnings
* Made old BroadcastSoundEffect not an override.
* m_Block to m_BlockPos, used Vector3d constructor where prettier.
* a_Block to a_BlockPos
* Changed thunderbolt a_Block to a_BlockPos
Tiger Wang
Damián Imrich
12xx12
mathiascode
KingCol13
Tobias Wilken
peterbell10
Mattes D
Alexander Harkness
changyong guo
9caihezi
Lane Kolbly
Lukas Pioch
satoshinm
Pablo Beltrán
Tiger Wang