Moo
Assigned
Reported
Comments
"Just one rider" is the obvious situation, for when you're riding on a pig or horse. I don't see how one extra block vertically could make that much difference.
Alternatively, allow the collision but prevent the suffocation. Maybe when you're riding something, check the "head height" of the animal rather than the rider.
Check wiki for correct functionality before assuming incorrect functionality.
Map starts off as small area, you need to craft it with more paper to increase the area it shows.
It would help if the doors actually had proper texture for the "outsides", rather than just using a section from the "sides"... Even without this bug, that part doesn't look right.
Look at the third and fourth line in his screenshot. The ---- in the third line is more "bold" than the other.
I can confirm it too... It only happens when editing a sign, not on the completed sign, so not a big problem.
The text on the third line is stretched vertically at a certain point, causing the effect he saw. Try + a e or s on line 3 and another line to see what I mean. A similar effect happens vertically too.. Try entering a line of ls (lowercase L) and see how sometimes some appear thicker. The stretched places are different when editing a signpost than a wall sign, try @s to see it.
I think it must be due to drawing the text at a low resolution and a non-exact size then scaling it up...
For multiplayer, why not simply have the server always send the distance set in the server.properties, and the client display either that, or whatever they have set in their client settings, whichever is lower. This way, client settings don't affect the server, but can still be lowered to increase performance.
I thought this is how it had always worked... Seems simple enough to implement though, and doesn't require any new settings or anything.
Yes, a rationale for it being an intended feature would help...
Hopefully the new /setworldspawn command changes the area that is kept loaded, allowing it to be moved to a location that is helpful, or at least less unhelpful...
I would say the new (mipmapping) issue should perhaps be a separate ticket from the old pixels in texture one. New one is apparent gaps between blocks in distance.
One solution, I think, would be for the server to periodically update the client with the server's idea of the boat position, while in the boat. This may cause "jumps" where the boat and player reappear in a different position, but this would be much preferable, I feel at least, to the current situation.
Yes it is! Happens with 13w38c. Horrible bug, suffocation is very quick. Either pig/horse+rider needs to not fit in too-small space (sensible) or suffocation of rider when this happens needs to be prevented (workaround).
No, it's for both. There's a separate cap for hostiles and friendlies, but the cap still works the same way. Just like having enough hostiles loaded in a mob farm prevents hostiles generating anywhere else, having enough animals loaded in an animal farm prevents them spawning anywhere else. And the cap for animals is lower to begin with.
^ is incorrect. The cap is per-world. See http://www.minecraftwiki.net/wiki/Spawn#Mob_spawning. Animals in any loaded chunk would count against this limit.
Also, that the spawn chunks always being loaded is well known and utilised by people doesn't mean it's sensible or intended.
IMHO the spawn chunks remaining loaded only makes sense on a true multiplayer server, where quick load times for new players would be an advantage. On single player where you're likely to be off somewhere far from "spawn" (if not taking advantage of the spawn-loaded-chunks, anyway), it doesn't seem to have a purpose, and is probably just byproduct of the internal-server system.
That's the middle of the 0,0 chunk. A default or fallback value that is becoming active unintentionally?
With hoppers you should be able to make an even more "automatic" egg/chicken farm than before, and without having to use the ridiculous floating method. I say there's far more important bugs for them to look at.
@Jesper: The dropped-item being created at all is sent by the server, I think, so any velocity involved there should be sent by the server too. But as the items can be completely still, and still appear to fall when they shouldn't, I don't think it can just be related to spawn velocity.
@Thue: Yes, exactly what I was getting at. The server and client should both "think" the same way, and "talk" accurately enough that such problems are avoided.
Chickens eating nether warts would seem strange to me... I'd also say they're only "seeds" for implementation reasons.
Maybe instead of changing the luring to match the breeding, the opposite would be more sensible?
In the real world, chickens wouldn't be able to swim forever, whether baby or adult 😛
If the server and the client both have the same data about the entity, state of other things in the world, and "physics system", how can they get different results?
If they don't, isn't it just a case of altering whichever part is "wrong" in order that they do?
I would say failing to check/maintain surrounding blocks when generating the world can be considered a bug...
At least, resolution would be "works as intended" if that is indeed the case, rather than "invalid".
All the strange "features" of the world generation, like this, could be fixed, but maybe not worth it...
But it can be cool to find strange things like this in the world, so would make the world less interesting if the generation was made "sane".
Yeah, for me, the real bug is that they can be bred using these other things, not that they don't follow them.
That netherwart is considered a seed by the chickens (for breeding) is a side-effect of how they are implemented, not any kind of logic.
For the other real seeds, that they can be bred is also a side-effect, but it's more reasonable, so it's up to them as to whether they should work or not. But it should still be consistent between following and breeding.