cBlockArea:Write() quasi-randomly triggering assertion
#1
So, it seems that cBlockArea:Write()'s assertion line
ASSERT((a_DataTypes & GetDataTypes()) == a_DataTypes);
is randomly triggering, Russian Roulette style.

For instance, for a simple plugin I wrote to test some changes:

function OnPlayerUsedItem(Player, BlockX, BlockY, BlockZ, BlockFace, CursorX, CursorY, CursorZ, BlockType, BlockMeta)

local Area = cBlockArea();
Area:Read(Player:GetWorld(),
        BlockX - MOVER_SIZE_X, BlockX + MOVER_SIZE_X,
        BlockY - MOVER_SIZE_Y, BlockY + MOVER_SIZE_Y,
        BlockZ - MOVER_SIZE_Z, BlockZ + MOVER_SIZE_Z,
        cBlockArea().baMetas + cBlockArea().baTypes
    );
    --[[
if (Player:GetEquippedItem().m_ItemType == E_ITEM_EMERALD) then
    print("RotateCW Test\n");
    Area:RotateCW();
elseif (Player:GetEquippedItem().m_ItemType == E_ITEM_DIAMOND) then
    print("RotateCCW Test\n");
    Area:RotateCCW();
    end
    ]]
    Area:Write(
        Player:GetWorld(),
        BlockX - MOVER_SIZE_X,
        BlockY - MOVER_SIZE_Y,
        BlockZ - MOVER_SIZE_Z,
        cBlockArea().baMetas + cBlockArea().baTypes
    );
    return false;
end

I will enter the game and right-click a block. The first time everything works fine and I've set a break point up to check this; Both the passed datatype and the datatype of the object are the same.

I will then click a second time. The Write function will run correctly at first, but then it runs a second time immediately afterwards and this time the object has a datatype of "0," so the assertion triggers.

I don't know why it's doing this, and it's getting in the way of fixing an unrelated issue (Implementing Rotation functions for the block handlers.)
Reply
Thanks given by:
#2
The server is trolling you?
Reply
Thanks given by:
#3
There's a slight bug in your code:
cBlockArea().baMetas
should be
cBlockArea.baMetas
No idea why that would be the cause for this weird behavior, though.
Reply
Thanks given by:
#4
(02-22-2014, 09:05 AM)xoft Wrote: There's a slight bug in your code:
cBlockArea().baMetas
should be
cBlockArea.baMetas
No idea why that would be the cause for this weird behavior, though.

It's not. I get the same issues even if I leave off or hard code the numbers in. Also, I've checked and those expressions give the right results anyways.

I've been getting these bug alerts ever since I started trying to use BlockArea.

Something else I've noticed, when I write to the console from my plugin, is that my plugin tends to be called twice whenever a right click. Is that normal?
Reply
Thanks given by:
#5
But with the parenthesized code you are actually creating a new cBlockArea object instance just to read its static constant, that's why it's bad.

Two rightclick hooks may be normal for some instances - when rightclicking with something that the client doesn't think should ever be converted to a block (such as with a diamond), the client sends two rclk packets; one with all fields set to -1. At the start of your rclk handler you should check if a_BlockFace == BLOCK_FACE_NONE.

Is your plugin code short enough? Maybe it'd be best if you posted it full, so that we can have a look and try it ourselves.
Reply
Thanks given by:
#6
Okay, there we go, that fixes everything.

Is this Minecraft, and not MCServer, specific behavior, right? Is there a technical reference on how Minecraft works, for the sake of modding/development, or are these things more "you learn as you go?" I can't find anything like a manual and the minecraft Wiki isn't comprehensive in this regard.
Reply
Thanks given by:
#7
I don't think there's any such "technical compendium", mainly because the behavior changes from time to time, between MC versions. The closest you can get is in the protocol wiki, which says that "such a packet (BLOCK_FACE_NONE) exists": http://wiki.vg/Protocol#Player_Block_Placement
Reply
Thanks given by:
#8
This is helpful! (I couldn't find anything like this before.)
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)