The game checks to see if there is a chest to the right of any given chest, and connects them accordingly. If there was a third chest in a row, the last two would both look like the right side of the chest and the combined inventory would be 9 rows tall. The code for checking for adjacent chests is not configured to support directly adjacent double chests, and it would be extremely difficult to change it to support this. The code only checks on the XZ plane so vertically stacked chests are no issue.
With further testing, it appears as if this only occurs when "docking" the window (Windows 7 and up). To reproduce, drag the title bar of the window to the very left or right side of the screen until rings appear around the cursor and let go of the mouse. The window will resize to occupy half the screen horizontally and will be vertically maximized. Upon losing focus, the window will reset to however it was before it was docked. This did not occur in 1.6.2 or earlier.
I wouldn't say that this is a feature request, as most people who don't know the innerworkings of the game will expect the maps to update while on walls. They don't know what causes lag and what doesn't, so they will expect what's natural. If it will for sure create lag to constantly update the maps on the walls, then maybe allow a server command to "flush" a certain map, or force-update it? Then for servers (or players) who wish to have a constantly-updating map, they can use a command block or run the command from the game. This is just one idea, there are obviously more solutions.
I understand your point of view, and this is working correctly as the code specifies, but it is not "working as intended" in the long-run. Maps should update automatically no matter where they are (inventory, in the world, etc.) as to not be confusing to players who do not understand game mechanics. I'll let Mojang make the final decision though.
Brian R.
MC-2040
Retested with unmodded 1.4.2 client on unmodded 1.4.2 server. Issue still persists. Users unable to activate buttons in spawn.
The game checks to see if there is a chest to the right of any given chest, and connects them accordingly. If there was a third chest in a row, the last two would both look like the right side of the chest and the combined inventory would be 9 rows tall. The code for checking for adjacent chests is not configured to support directly adjacent double chests, and it would be extremely difficult to change it to support this. The code only checks on the XZ plane so vertically stacked chests are no issue.
With further testing, it appears as if this only occurs when "docking" the window (Windows 7 and up). To reproduce, drag the title bar of the window to the very left or right side of the screen until rings appear around the cursor and let go of the mouse. The window will resize to occupy half the screen horizontally and will be vertically maximized. Upon losing focus, the window will reset to however it was before it was docked. This did not occur in 1.6.2 or earlier.
I wouldn't say that this is a feature request, as most people who don't know the innerworkings of the game will expect the maps to update while on walls. They don't know what causes lag and what doesn't, so they will expect what's natural. If it will for sure create lag to constantly update the maps on the walls, then maybe allow a server command to "flush" a certain map, or force-update it? Then for servers (or players) who wish to have a constantly-updating map, they can use a command block or run the command from the game. This is just one idea, there are obviously more solutions.
@Th3F4114n0n3:
I understand your point of view, and this is working correctly as the code specifies, but it is not "working as intended" in the long-run. Maps should update automatically no matter where they are (inventory, in the world, etc.) as to not be confusing to players who do not understand game mechanics. I'll let Mojang make the final decision though.