Thomas Rohloff
- v10lator
- v10lator
- Europe/Stockholm
- Yes
- No
MC-3987
Added Attachments:
Changed Description:
I manipulated NBT data a bit to spawn anvils with mob spawners. Problem is they always miss one row on X and Z axis.
As english isn't my native language I made a video showing the issue. It's to large to upload as attachment, so here's a link: https://vimeo.com/55709238
Also I try to explain: Let's say the spawner is at x 6 and z 6. spawn range is 5. The expected output is to add 5 to all sides, so spawn from 0 to 11 on x and z (5 + 1 (the mob spawner) + 5). The given result is 5 + 1 + 4, so from 0 to 10.
BTW: This happens with all entities, anvils are just good to show it. This note is important as it says that this happens with vanilla gameplay, too.
I also think this should get fixed. As James Wright told a easy solution would be to add/extend data values of affected blocks. Of course this requires work, but every fix/feature does that, so that isn't a excuse (nobody says fix it RIGHT NOW. We say: Take your time to fix...).
@Dinnerbone telling that this is a "design choice" sounds very lazy and I don't believe it, but even if so it was a bad choice. Technical limitation: Yes, that's what I believe, but that can be changed.
//EDIT: Also I don't even think all blocks would need this, you could just destroy some (telling they where washed away) if they are placed in water. For lava I think most blocks won't need it, just destroy them.
Actually I have to correct this, it only happens if the FOV setted in the client + the FOV from the packet is higher then the maximum FOV. Sorry for not being clear in the report.
Actually this seems to be the case for all solid blocks.
Not true. Flowers (non solid blocks) are flat, also Lava/Water (non solid, too) is flat, for example.
And "Work as Intended" ? Really? Item frames look like images to me. A image should be 2D all the time.
Yes, I also think this is the cause.
The problem with this is that Packet202Abilities is able to do it, no matter if vanilla uses it for that or not. Mojang coded this for a reason. Also as it's a client bug you can't tell it's bukkits fault.
"The stuff is put in the items frame with the exact same model as in your inventory."
why do pressure plates and stuff like that look completely different in my inventory then?
Are you sure the server is able to see the clients FOV settings? I never saw any code nor any packet for that.
//EDIT: Also the packet sets the walk speed, not the FOV. The client maps speed to FOV. Do you really think it would be an option to reduce walk speed just to fix the FOV? What if the client has max. FOV? Then the packet couldn't modify the speed at all.
Alright. Have a nice time getting the same report again when official API is released then just because you decided to not inform Mojang coders soon enough...
There it is (left: Inventory, right: Frame).
@Kumasasa Well, I see we have different views on this. So I started a discussion at the forums to stop wasting your time.
For reference: http://www.minecraftforum.net/topic/1584037-solid-blocks-on-item-frames-should-be-rendered-2d/
@George Gates:
1) Then the water would flow through it like it would flow through air.
2) If it has holes water flows through it.
3) Designs which use signs/ladders/... to keep water away would break, yes, but to quote myself: "do you try to hold water back with signs and ladders in real-life?"
Look also here: http://www.minecraftforum.net/topic/1583885-blocks-like-ladders-and-water/
Everybody here should read: http://www.minecraftforum.net/topic/1583885-blocks-like-ladders-and-water/ - Making fences covered by water is as simple as extending their data value. These data value would then be used by the client to render the water and by the server for its water flowing code (to see the block as water (or air if no extended data values are there) instead of fence in that codepath so water will flow through it). The most complicate thing would be to tell the water flow code that it doesn't have to give water data values to the fence but extend the fence data value, but that shouldn't be a big deal and when done it should be easily extendable for other blocks.