Block placement/digging quirks

[huin]

To reproduce:

• Place a torch (or use an existing placed torch)
• Place a block against the torch

Expected:

• The block should not be placeable against the torch

This might be a simple case of making the torch non-attachable (if it isn't already), but there seems to be some quirks around how the placed block acts after being placed when it is subsequently dug. The client acts as if the server has told it that the block has been placed, but upon digging, the server acts as if it has not.

[huin]

It might be worth getting the server to send a packet after an illegal placement to tell the client that no items have been taken and the block which would have changed has not.

[jnwhiteh]

I am unable to reproduce this issue, but I do have some information on your follow-up. This is the intercept logs when you try to place a block against/next to a torch:

2011/06/21 12:26:27.140151 2 PacketPlayerBlockInteract(itemId=35, blockLoc=&{-202 64 -604}, face=1, amount=8, data=0)
2011/06/21 12:26:27.140214 2 PacketPlayerBlockInteract(itemId=35, blockLoc=&{-1 -1 -1}, face=-1, amount=8, data=0)

There is no response from the server, it simply makes no changes. The client sends the block interact packet and then sends another (invalid one) with the same item count (8). In chunkymonkey, trying to perform an invalid place like this causes the player to consume one of the items they are holding. I've not been able to 100% track that issue down yet, but I'm looking at it.

[huin]

I think I understand some of the problem, so I'll explain a bit of my
understanding to help avoid you investigating possible knowns...

Both the client and the server model changes to the inventory, so for
the case where the item is consumed - it's only consumed on the
client's view of the inventory. The server can rectify this by sending
an update for the slot. (Although this can be tricky - as the player
connection code doesn't perform a syncronous check to see if the item
can actually be placed, there's a bit of a conversation between the
player connection code and the chunk shard).

The client and server also model changes to blocks in the world, so
if the client thinks that it's placed a block and the server
disagrees, the server currently just doesn't send an update to say
"actually, no, the block is still air (or whatever)". The client
eventually gives up waiting for this notification and puts the block
back as it was. Again, a fix can be for the server to immediately
reply and say "hey, this block is still air". This should be a
slightly simpler fix than the inventory problem.

[jnwhiteh]

On Tue, Jun 21, 2011 at 4:18 PM, huin
reply@reply.github.com
wrote:

I think I understand some of the problem, so I'll explain a bit of my
understanding to help avoid you investigating possible knowns...

Both the client and the server model changes to the inventory, so for
the case where the item is consumed - it's only consumed on the
client's view of the inventory. The server can rectify this by sending
an update for the slot. (Although this can be tricky - as the player
connection code doesn't perform a syncronous check to see if the item
can actually be placed, there's a bit of a conversation between the
player connection code and the chunk shard).

I understand this, but that's not what I'm observing in the inspect
logs. The entire exchange consists of the two packets I posted above
and the server does not appear to respond in any way. Admittedly, I'm
not entirely sure of everything that's going on, but that's what I'm
seeing.

The client and server also model changes to blocks in the world, so
if the client thinks that it's placed a block and the server
disagrees, the server currently just doesn't send an update to say
"actually, no, the block is still air (or whatever)". The client
eventually gives up waiting for this notification and puts the block
back as it was. Again, a fix can be for the server to immediately
reply and say "hey, this block is still air". This should be a
slightly simpler fix than the inventory problem.

Yes, this is something I've seen as well. Is it worth me looking at
the chunk storage so state is persistent across server invocations?
That may help with some of my testing.

Reply to this email directly or view it on GitHub:
#27 (comment)

[huin]

I understand this, but that's not what I'm observing in the inspect
logs. The entire exchange consists of the two packets I posted above
and the server does not appear to respond in any way. Admittedly, I'm
not entirely sure of everything that's going on, but that's what I'm
seeing.

Tsk, I should have read your comment better, sorry.

http://mc.kev009.com/Protocol#Player_Block_Placement_.280x0F.29
mentions a "special" packet like the second that you see. It is
certainly very odd that the client decides to consume an item when it
potentially has the knowledge that this is a special case (as
evidenced by the -1 values). You might well be looking at the original
problem that I saw but was never too clear on and had started to
disbelieve its existence.

Yes, this is something I've seen as well. Is it worth me looking at
the chunk storage so state is persistent across server invocations?
That may help with some of my testing.

It could be useful. I was vaguely thinking of starting some work in
that regard myself, but if you fancy doing the storage work then I'm
quite happy to let you :) - note that the chunk generation code API
will likely implement the IChunkStore and IChunkReader interfaces (my
intent there was to have an IChunkStore that contains a sequence of
IChunkStore objects to read a chunk from, eventually falling back to
chunk generation, but preferentially storing changed chunks to the
first - I should mention that in another issue, however).

[jnwhiteh]

Very interesting, I'll have to investigate further. If you have any consumable items that might be good for me to look at, feel free to tag me in those issues. I'm fairly good at getting things done in my spare time.

The mod issue is very very complicated given the current structure and what has been requested, I"ll respond accordingly once I have a chance to craft a reasonable response.