Fix bugs when selecting an area #140
Conversation
| local function OnPlayerRightClick(a_Player, a_BlockX, a_BlockY, a_BlockZ, a_BlockFace) | ||
| local Succ, Message = GetPlayerState(a_Player).Selection:SetPos(a_BlockX, a_BlockY, a_BlockZ, a_BlockFace, "Second") | ||
| if (not Succ) then | ||
| return false | ||
| end | ||
|
|
||
| if ((os.clock() - LastRightClick) < 0.005) then |
There was a problem hiding this comment.
A comment here explaining why this is necessary would be useful (multiple packets come through in a single tick?)
There was a problem hiding this comment.
A comment here explaining why this is necessary would be useful (multiple packets come through in a single tick?)
In some cases, when the second position is indicated, the client sends 2 packets
There was a problem hiding this comment.
Could you check the a_BlockFace parameter? It's possible we can filter out the second packet if a_BlockFace is BLOCK_FACE_NONE.
Also, wouldn't it make more sense to put the check before setting the selection? Now the selection still gets set twice, but the second time the player isn't notified.
There was a problem hiding this comment.
Could you check the
a_BlockFaceparameter? It's possible we can filter out the second packet ifa_BlockFaceisBLOCK_FACE_NONE.Also, wouldn't it make more sense to put the check before setting the selection? Now the selection still gets set twice, but the second time the player isn't notified.
The problem is that we catch 3 packages, 2 of them are normal, and the third with BLOCK_FACE_NONE. Even with checking for BLOCK_FACE_NONE, 2 messages are displayed. Example:
- Normal
- BLOCK_FACE_NONE
- Normal
There was a problem hiding this comment.
I see. I guess the os.clock() method is the simplest way to avoid this. It's also somewhat forwards compatible if Mojang decide to change the number of packets again.
|
On Tue, 21 Apr 2020 01:49:03 -0700 Yaroshenko Yaroslav ***@***.***> wrote:
@YaroshenkoYaroslav commented on this pull request.
> local function OnPlayerRightClick(a_Player, a_BlockX,
> a_BlockY, a_BlockZ, a_BlockFace)
local Succ, Message =
GetPlayerState(a_Player).Selection:SetPos(a_BlockX, a_BlockY,
a_BlockZ, a_BlockFace, "Second") if (not Succ) then return false
end
+ if ((os.clock() - LastRightClick) < 0.005) then
> A comment here explaining why this is necessary would be useful
> (multiple packets come through in a single tick?)
In some cases, when the second position is indicated, the client
sends 2 packets
Add a comment in the code saying this then.
|
Classes/ToolRegistrator.lua
Outdated
| local function PlayerBrokeBlockHook(a_Player, a_BlockX, a_BlockY, a_BlockZ, a_BlockFace, a_BlockType, a_BlockMeta) | ||
| if a_Player:GetEquippedItem().m_ItemType == E_ITEM_WOODEN_AXE then | ||
| a_Player:GetWorld():SetBlock(a_BlockX, a_BlockY, a_BlockZ, a_BlockType, a_BlockMeta) | ||
| end |
There was a problem hiding this comment.
I don't think this will be enough for breaking multi-block structures, such as doors or beds.
There was a problem hiding this comment.
I don't think this will be enough for breaking multi-block structures, such as doors or beds.
PLAYER_LEFT_CLICK will not be enough for breaking multi-block structures too. But thanks to PLAYER_BROKEN_BLOCK we will not have friezes.
There was a problem hiding this comment.
I don't have any freezes with the original code, so I have no idea what you're trying to fix
There was a problem hiding this comment.
But if we care about multi-block structures, should we should use PLAYER_BREAKING_BLOCK?
There was a problem hiding this comment.
I don't have any freezes with the original code, so I have no idea what you're trying to fix
Oh, maybe i put it wrong. When you select the first point (left button of the mouse), the person stops abruptly (I think it is connected with the fact that all player actions in this packet are canceled). Friezes are not permanent, only when specifying a point
There was a problem hiding this comment.
Okay, now I see it too. When trying to select the first point while moving, the movement is stopped and the player is jerked back.
However, I think this needs a fix in Cuberite itself, rather than hacking the plugin - it seems the client doesn't like something Cuberite sends as a reaction to the rejected blockbreak.
There was a problem hiding this comment.
Well, you're right. I put everything back in place and left a bug fix when specifying the second point
There will be no friezes when selecting the first positionUse PLAYER_BREAKING_BLOCK then PLAYER_LEFT_CLICK (better when working with multi-block structures)