Instead of having a complex sentence like "jeb was shot off a ladder by Skeleton and withered away" which is hard to split in a way that's compatible with all languages, why not simply split it into as many sentences as required?
"jeb was shot off a ladder by Skeleton. He then withered away."
"jeb fell from a ladder. Then a zombie ate him."
This should be translatable easily, and doesn't lose any details. It'd only really need additional "then.." type equivalents for the follow-on sentences.
Why not just let a "full layered-snow block" actually produce a "normal" snow block instead?
If it's for balance with the recipe or drops of the old snow block, that could be rebalanced to fit with the new system.
Unless there's an advantage to having a second, less-functional, "full" snow block, wouldn't having just one be more sensible?
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".
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?
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?
@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.
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.
^ 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.
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.
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).
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.
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.
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...
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.
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...
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.
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.
"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.
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.
Moo
MC-33065
Instead of having a complex sentence like "jeb was shot off a ladder by Skeleton and withered away" which is hard to split in a way that's compatible with all languages, why not simply split it into as many sentences as required?
"jeb was shot off a ladder by Skeleton. He then withered away."
"jeb fell from a ladder. Then a zombie ate him."
This should be translatable easily, and doesn't lose any details. It'd only really need additional "then.." type equivalents for the follow-on sentences.
Why not just let a "full layered-snow block" actually produce a "normal" snow block instead?
If it's for balance with the recipe or drops of the old snow block, that could be rebalanced to fit with the new system.
Unless there's an advantage to having a second, less-functional, "full" snow block, wouldn't having just one be more sensible?
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".
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?
In the real world, chickens wouldn't be able to swim forever, whether baby or adult
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?
@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.
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.
Related to
MC-17203?That's the middle of the 0,0 chunk. A default or fallback value that is becoming active unintentionally?
^ 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.
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.
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).
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.
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.
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...
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.
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...
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.
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.
"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.
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.