Inventory issues

[Jammet]

Hello .. I'm not sure if it makes sense to just add this to the bug thingy, so I wanted to say it here. Since I updated the server binary from about a month ago, players and I have strange new problems with the inventory. Sometimes the server will just refuse to acknowledge that a player has taken something out of a chest.

It'll disappear from the player inventory and "still be" inside the chest, when trying to interact with the item, or place it.

This is happening every day now, and the server doesn't recover on it's own. The restart command doesn't fix it either, it seems, I have to really "stop" the server and relaunch it.

So yeah, this is kind of an issue, because if I'm not there, and this happens, people can't play anymore.

[fichdlmaa]

Since I updated the server binary from about a month ago, players and I have strange new problems with the inventory. ...

Nearly the same problem with actual MCServer-Release (for MC 1.8.3) for Raspberry (ARM hf) since Mojang-Update from 1.8.3 to 1.8.4

Network Game in Creative Mode:
- Moving Items between Inventory and chests still works, but copying items between (as well as duplicating within same storage) doesn't work anymore.
- Sometimes Items disappear or move to another position - awful!

I hope, update will follow soon. Workaround 'til then; howto temporarily downgrade client to 1.8.3?
For the future: Any Idea, how to block Mojang-Updates without killing internet route ?

Tnx

FichdlMaa

[Jammet]

I'm playing with 1.8.1 and Optifine HD in survival mode, and others may have used 1.8.3 or 1.8.4. If 1.8.4 does causes the problem, all other clients are be affected by it.

But now that you mention it, the only times when that happens is when other people are connected as well. And the player who was connected the first time this happened, a bit more than a day ago, she does all auto updates.

Downgrade: http://goo.gl/186E84

The problem is, I am not *sure* this is the cause for the problem, otherwise I'd type it in the bug tracker. Are you certain that this is the cause? Have you tested this?

[Jammet]

This is really becoming a very prominent problem fast. Players keep having this problem and I am constantly restarting the server. We can't say for sure if it's 1.8.4 and some people don't read the motd.

[xoft]

Does this happen reproducibly or is it random? Can you observe a pattern that we can follow in order to reproduce the bug on our machines?

[Jammet]

I'm trying to find it, but ... it only seems to happen to me (and them at the same time) when others are connected as well. I will keep trying -- in fact I'll just go and throw stuff in and out of a box for 10 minutes and see if the server stops cooperating at some point... nothing else I think I could do.

So yes, I did that, and switched to 1.8.4 also. Nothing. I don't get it. Either I don't know how to mess it up "properly", or it cannot be done locally, or this only happens with multiple people on. All I could do is wait until it happens again, and then invite someone in who can .. then look at the behavior and see if it's a problem. It looks like it's crazy lag, but I don't think it's that, because we had up to six people on the server before, with nothing like this ever being a problem, two weeks earlier.

:/

[Jammet]

Okay, it's happened again, the server is now officially not accepting proper interaction with chests <---> player inventory any longer.

Anyone wanna hop in and try it? Please, take a look... I'll disable the whitelist for now.

Server address: jammet.duckdns.org

The log shows miles of:
[15:41:50] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:41:51] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:41:51] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:41:52] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:41:53] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:41:53] Clicked: Wrong window ID (exp -1, got 255) received from "AtiKat"; ignoring click.
[15:42:00] *** Window lost sync at item 6 in SlotArea with 27 items ***
[15:42:00] My item: -1:0:0 * 0
[15:42:00] Their item: sign:0 * 9
[15:42:14] *** Window lost sync at item 4 in SlotArea with 27 items ***
[15:42:14] My item: -1:0:0 * 0
[15:42:14] Their item: oaklog:0 * 10
[15:42:16] *** Window lost sync at item 4 in SlotArea with 5 items ***
[15:42:16] My item: -1:0:0 * 0
[15:42:16] Their item: oaklog:0 * 10
[15:42:49] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.

[15:42:50] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:51] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:51] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:51] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:51] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:51] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:52] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:52] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:52] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:52] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.
[15:42:53] Clicked: Wrong window ID (exp -125, got 131) received from "AtiKat"; ignoring click.

[tigerw]

I think its because the protocol is now using an unsigned char, whilst we're using a signed one, to represent the window ID.

Code:

m_WindowID = (++m_WindowIDCounter) % 127
(assume the counter has incremented to 127)

signed Counter = 127 (0111 1111)
signed ID = 0
protocol unsigned ID = 0
okay

Counter++

signed Counter = -128 (1000 0000)
signed ID = -1
protocol unsigned ID = 255
mismatch!

...

signed Counter = -125 (1000 0011)
signed ID = -125 (C modulo operation on a negative number is negative: -125 % 127 = -125)
protocol unsigned ID = 131
mismatch!

Suggested to ➀ use an unsigned counter and ➁ avoid all the modulos?

[worktycho]

If we make the counter an unsigned char but keep it restricted to modulo 127, that should be a suitable hot-fix for now. We need to keep the modulo because of 1.7 protocol support. But there is the problem of what if we have more than 127 windows on a server? It could happen on a busy server, remember when Howener got 140 players on a server.

Also if we want to be truly portable what about architectures with non-octet bytes? My proposal will work on machines with >= 7 bits per bytes, but there are 4 bit per byte architectures out there.

[xoft]

The window ID is only per-player specific and isn't really used for any logic, so it would even be safe to use a constant window ID