![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg)
[Mojang] Jeb (Jens Bergensten)
- jeb
- jeb
- Europe/Stockholm
- Yes
- No
MC-1574
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)duplicates
Connecting to a server using a slow or less reliable network and suffocating in a block.Falling out of the world
[Mojang] Jeb (Jens Bergensten)is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
duplicates
duplicates
duplicates
duplicates
is duplicated by
duplicates
duplicates
duplicates
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)duplicates
is duplicated by
duplicates
[Mojang] Jeb (Jens Bergensten)is duplicated by
is duplicated by
duplicates
duplicates
[Mojang] Jeb (Jens Bergensten)is duplicated by
duplicates
is duplicated by
duplicates
relates to
relates to
relates to
duplicates
is duplicated by
MinecraftCrashing ConstantlyMinecraft crashes if connection is lost when editing signs
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)duplicates
Lowis duplicated by
duplicates
[Mojang] Jeb (Jens Bergensten)is duplicated by
[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)duplicates
[Mojang] Jeb (Jens Bergensten)is duplicated by
[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)[Mojang] Jeb (Jens Bergensten)![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams[Mojang] Nathan Adams[Mojang] Jeb (Jens Bergensten) resolved this report as "Works As Intended". He also commented roughly one year later as response to the following:
Panda4994 (source):
I always viewed the breaking of the sticky piston connection as inertia, and taking away the block teleportation part, I don't think this behaviour is buggy at all.
Jeb (source):
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense.
The bug
When a sticky piston is powered with a very short pulse ("0-tick pulse"), it will push the block, but not retract it.
To reproduce
Build the contraption in this screenshot:
The redstone block will not be pulled back.
After 1.14, it is also possible to reproduce this by placing a button on the side of a sticky piston, and press the button to move a block.
While under the effects of Mining Fatigue 5 or higher, it becomes impossible to break anything. Even with Haste 100 and Eff 100 you still can't even break tall grass.
[Mojang] Jeb (Jens Bergensten) added a comment - 04/Mar/13 11:22 AM
I dunno why Dinnerbone removed the limit to the effect command I don't want to chase "bugs" like these..
Big Oak Trees completely fail to generate in Forest, Flower Forest, etc ...
This bug seems worse than MC-11208 since big trees doesn't even attempt to generate, instead of being generated weirdly
In jungle biomes, however, they are replaced by trees with generical spherical foliage
Steps to reproduce :
_Find a Biome in which Oak Trees can spawn naturally
_Notice how Big Oak Trees are missing
Alternate way :
_Create a superflat world of a Forest for exemple with decorations enabled
_Notice how Big Oak Trees are missing
Turns out it's a so-called "FPS fix" by [Mojang] Jeb (Jens Bergensten)
http://www.reddit.com/r/Minecraft/comments/1m97cw/while_you_are_all_crying_over_the_name_change_of/
The reason they got removed was because they don't follow the leaf decay rules, and thus caused a LOT of chunk updates. I basically doubled my FPS in forests by removing these.
My intention was not to remove them completely, though, but rather "fix them later". The problem now is that the code for those trees is super-complex, and not the easiest thing to work with.
Problem description: Leaves must be placed so they are connected via other leaves to a tree trunk, max 4 steps away. Where's the bug?
...
BigTree source code from Jeb: big_tree.java
Paul Spooner, original maker of Forester Filter and gave the Big Tree generation code to Notch, says:
The stuff you're looking for is in the "foliageShape" function. I suggest replacing the line:
else if ((y == 0) || (y == (foliageHeight - 1))) return (float) 2;with the following two lines
else if ((y == 0) || (y == (foliageHeight - 2))) return (float) 2; else if (y == (foliageHeight - 1)) return (float) 1.5;The change should reduce the size of the foliage clusters and prevent decay.
EDIT: It appears that the cause leads to the New AI. Wolves already had the New AI before Pigmen did and the bug was only for wolves when this was created, because the anger tag for Pigmen still worked. Since 14w06, the anger tag no longer works for Pigmen, which leads it to the New AI because Jeb made all mobs have the new AI now.
Steps to Reproduce:
1.8/1.7 - type
/summon Wolf ~ ~ ~ {Angry:1}
/summon PigZombie ~ ~ ~ {Anger:1}
[Mojang] Jeb (Jens Bergensten) added a comment - 30/Jul/14 2:08 PM
This has been fixed, but differently for wolves and zombies:
Wolves will only remain angry as long as they have something to attack. Summoning an angry wolf will immediately make it non-angry since it doesn't have a target.
Pig Zombies will actively try to find targets for as long as they're angry, even if they can't find / don't know the source of the anger.
Downgrading from newer versions to older versions may have undesired behavior, please back up your worlds before testing snapshots.
Upgrading to a snapshot may also corrupt worlds, please back up your world before testing.
Enabling Development Builds Warning in the Launcher:
Are you sure you want to enable development builds?
They are not guaranteed to be stable and may corrupt your world.
You are advised to run this in a seperate directory or run regular backups.
Downgrading is not, was never and will never be officially supported!
Definition of downgrading: Going from a version with a higher number (example: 1.12.2) to a version with a lower number (example: 1.11)
[Mojang] Jeb (Jens Bergensten) in https://twitter.com/jeb_/status/507193706781614080
... Don't open a 1.8 world in 1.7 unless you have a backup ...
https://twitter.com/jeb_/status/507198150474727424
Since you ask: 1.7 doesn't know how to handle 1.8 saves, but tries its best not to crash. This means it ignores data, which is lost forever.
14w03a came up today and I noticed the transparancy bug with glass panes, so I switched back to 14w02c to verify that was working correctly there. All items everywhere vanished. Everything in my inventory, equipped gear, even everything in chests and furnaces are gone. Switching back to 14w03a did not bring it back.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
I would personally prefer if stone stairs were renamed to cobblestone stairs, for consistency and ease of searching, as you've brought up. I suspect they're named this way partially to deflect the frequent requests for actual "smooth" stone stairs, which [Mojang] Jeb (Jens Bergensten) is strongly opposed to adding.
[Mojang] Grum (Erik Broes) has taken interest in some naming or spelling tickets before (such as MC-19032 or MC-2453), so I'll reopen MC-3100 and see if someone from Mojang will be willing to address it. Don't be too surprised if they mark it "Working As Intended", however.
Affects 1.8-pre1. (I wonder if anyone at Mojang reads these, it's been over a year since [Mojang] Jeb (Jens Bergensten) last commented on this issue)
KingSupernova, even if "Won't Fix" was a more appropriate resolution, it was [Mojang] Grum (Erik Broes) who resolved it as "Works As Intended", and thus we won't be changing it unless directed to do so by Mojang. Beyond that, while [Mojang] Grum (Erik Broes) has stated that he shares the opinion that this is a bug, it would appear that [Mojang] Jeb (Jens Bergensten) and [Mojang] Nathan Adams both consider it to be intentional behavior.
I think [Mojang] Jeb (Jens Bergensten) probably saw it as a feature request, rather than a bug. He may not have understood the report, may not have realized that the behavior was ever implemented, or may have deliberately removed it. Considering Notch's coding style, it was probably an inflexible special-case bit of code, and it may have conflicted with some other issue. Regardless of the reason at the time, a substantial portion of the code has been replaced since then, and any broken remnants of this have probably long been factored out of the codebase – in other words, there's nothing to "fix", and it would have to be re-implemented entirely. As such, it probably won't be addressed through the bug tracker here, and this should be pursued elsewhere, such as the suggestions subreddit.
It's the result of a suggestion on reddit, which [Mojang] Jeb (Jens Bergensten) and [Mojang] Nathan Adams both liked and decided to implement.
Dead bushes now drop sticks when broken. They can't be placed on grass, so when the dirt changes to grass, it breaks them. That was true before the snapshot.
[Mojang] Jeb (Jens Bergensten) added a comment - 01/Mar/13 10:14 AM
I've decided that this is the expected behavior. If I "fix" it, people will complain that it's much harder to do double-length piston extenders.
That's why MC-9342 is resolved
@[Mojang] Jeb (Jens Bergensten):
I reopened this because not the whole issue was fixed. Here's a tl;dr of the issues this ticket is about:
- Redstone doesn't render going up the side of non-solid blocks like hoppers, slabs, stairs or redstone blocks
- Redstone doesn't point towards the side of non-solid blocks like hoppers, slabs, stairs or redstone blocks if they have a piece of redstone dust on top (even though they transmit power that direction)
- Redstone is visually cut off (both in direction and in going up blocks) by non-solid full blocks like TNT, glowstone, sea lanterns or leaves but functions exactly as if the non-solid full block wasn't there
I won't go into the issues caused by your fix, see DicoTheRedstoner's comment for that. In short, it's even more confusing now.
For the future: If you only fix part of an issue, leave a comment explaining that so tickets aren't reopened even if you consider them done. I will leave this one open so you can decide what to do with it. In my opinion it'd be best if the whole fix was undone and the ticket marked "Won't Fix".
@[Mojang] Jeb (Jens Bergensten): Villages in void/empty maps is MC-87522... which I mistakenly marked WAI. Reopening now.
The bug
The sword "special attack" will work, even when moving, as long as the attack meter is full.
[Mojang] Jeb (Jens Bergensten):
More MC combat shenanigans... Crit and knockback attack types are now separate, and there will be a third type if you move slowly
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The method net.minecraft.entity.player.EntityPlayer.attackTargetEntityWithCurrentItem(Entity) has besides other ones the following condition to perform a sweep attack:
this.distanceWalkedModified - this.prevDistanceWalkedModified < this.getAIMoveSpeed()
The problem seems to be that for the server most of the time this.distanceWalkedModified and this.prevDistanceWalkedModified have the same value. Maybe because the client sends packets with its position instead of its motion and therefor this method is not called when the player walks server-side.
most likely not, that's how [Mojang] Jeb (Jens Bergensten) decided to fix this, by just keeping the hitbox smaller until there's space for the full hitbox
[Mojang] Jeb (Jens Bergensten) added a comment - 27/Nov/15 1:05 PM
The Wither and the Ender Dragon will now ignore all effects.
Again:
[Mojang] Jeb (Jens Bergensten):
F3 is a debug mode, turn off debugging
So, not for player use, that there's options/gamerules for it, is for people who use it, but don't want a overload of info, yet, it's only there for debugging.
[Mojang] Jeb (Jens Bergensten) you need to make the Minecraft window as large as possible and then look a little bit tilted at the sun. There is eventually one line above it that jitters.
ItsPlantseed [Mojang] Jeb (Jens Bergensten) already got assigned by [Mojang] Grum (Erik Broes), so I doubt it's intended.
Wild neutral wolves cannot be put on leashes. I do not normally keep dogs but some spawned near my house. I didn't have any bones yet and wanted to prevent them from wandering and killing sheep.
Following MC-15707 this is unexpected.
[Mojang] Jeb (Jens Bergensten) added a comment - 30/Jul/14 11:24 AM
Wild wolves should be able to be leashed, but not angry ones. Fixed in future updates
Not especially inconvenient for me but please check more common environments.
[Mojang] Jeb (Jens Bergensten) Is fixing the oldest open bug a hint that 1.11 will be a bugfix update? 
Marcono1234 For me the given command from the description reproduces the bug. I'll check again probably in 5 hours and then either change the description or correct you. 
[Mojang] Jeb (Jens Bergensten) I've seen a few fix notes by now from you (also on Reddit), not only I do very much appreciate these, thank you very much!
Although it steals a few minutes of your time, I know from own experience that in some bugfixcases the community was asking themself what exactly was the issue now, or how it was fixed/what to expect now as new behaviour, which is also a good thing to know how the game is supposed to work from Mojang's view, so we can look out for anything out of the normal (= bugs).
Thank you again }=)
[Mojang] Jeb (Jens Bergensten) Personally I think "clean code" should be preferred over a "hack" (if you mean a temporary "ugly" fix with it).
Also to not make people unhappy if a "hack" gets fixed at some point with "clean code" (which then maybe would "break" that "hack/feature").
As you guys and gals want to have everything the same across all platforms, it'd be interesting to know about this behaviour on platforms other than Java-PC though.
I don't own any of the others, so I can't check on that myself.
If this bug does not occur on other platforms and you're sure it's fixable sometime on Java-PC via "clean code", I wouldn't use a temporary fix/"hack" but rather work towards clean code.
Even if that means that Java-PC will have that bug persisting until then.
Unless a "temporary hack" would not cause other bugs or interfere with you guys' and gals' code-cleaning and code-adding work in any way and make things harder or so.
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
[Mojang] Jeb (Jens Bergensten) Thank you a lot for the fix notes! Really helpful 
As you said there are a few side effects with aligning hoppers with the game tick.
Since hoppers can interact with components that can change in every tick, hoppers will appear to have a bit more or less delay dependent on the time they were triggered.
Many designs that use hoppers for timing will now have 5,6,7 or 8 ticks delay at random and considering random factors in redstone designs is always tricky for the player.
@_Eta740_ pointed out some of these cases on Twitter: https://twitter.com/_Eta740_/status/763452453303967745
The issue comes from the way the hoppers cooldown is reset when another hopper places an item in it.
It only resets the cooldown if it was ready to transfer items already. If the cooldown was almost done before it stays there.
Which can lead to neighbouring hoppers having almost the same cooldown (see Jeb's comment).
Resetting the cooldown each time an item is placed inside the hopper is not really an option, because then hoppers that get fed from two sides would just not transfer anything out.
Potentially an alternative hack-solution for this issue could be to also reset the cooldown to 4 if the hopper was empty before and the cooldown was not done yet.
It's such a specific case that it probably wouldn't affect too many other cases (even though it probably would allow for some kind of "super charged hopper line").
More generally I think that the cooldown is used for two things here:
1. Limiting the hopper to one action every 8 ticks
2. Making sure each item stays for some ticks inside the hopper
Handling the second case on a per stack basis instead would make the timings more predictable (e.g. when a stack was added to an empty slot it can't be moved out for 4 ticks).
Tricky as always with redstone changes.
Thanks again for the fix notes!
Please link from the description to this comment again until MCP is released for the snapshots or 1.11
[Mojang] Jeb (Jens Bergensten), please have a look at that comment, I assume the packets I mentioned there are causing this
[Mojang] Jeb (Jens Bergensten) It indeed seems like the client preferred the rounded positions over the exact ones, even when it had access to it.
I made the following changes on the client side to better this: https://gist.github.com/Panda4994/741bde1d58054513e3d44c4ba7c7f660/revisions
This does fix the issue for the command:
summon Item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}
However it does not fix it in cases in which an entity was moved by a relative teleport after the last forced teleport since the client can't possible know the exact location in these cases.
So throwing an item down and triggering a command block with this command will still produce the issue (the item needs to be within 8 blocks):
teleport @e[type=Item] ~ ~1 ~-0.6249
To fix this as well the server would have to tell the client the exact position when ever the entity stopped moving in one axis. Even just sending an absolute teleport when the entity stopped moving at all would solve most cases (except this one).
Either way, even though it would not be sending a teleport on each position update, it certainly would need to send more and be a bit more expensive on the network.
While looking at the server side code I noticed that the relative movement packets are send every 3 seconds, even if the entity didn't move at all.
So each movable, but currently not moving entity sends a relative movement package containing three zeros each three seconds.
The client resets the entities position to the last one it got from the server when receiving these packages, but the only information these packages convey is that 60 ticks have passed on the server side.
So instead of sending these “empty” packages the client could just make an assumption about the server running at the same time and update the entity position if it didn't receive a position update for more than 60+n ticks.
Alternatively the client maybe could use the received keep alive packages to tell how many ticks passed for the server.
Since most entities are stationary a lot of the time, I think that this would greatly reduce the traffic and possibly outdo extra teleport packages that would be needed to fix this issue.
Also I think MC-7809 may be seen as related to this issue as it likely is caused by network rounding errors of the rotation pitch.
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
Works As Intended. [Mojang] Jeb (Jens Bergensten) say: comment
It has been resolved by 2 devs already, 1 of which is [Mojang] Jeb (Jens Bergensten), so mojang is very unlikely to change their mind.
That was already said by [Mojang] Jeb (Jens Bergensten):
You can't keep hoppers the same while providing a fix for them getting stuck, the current way is not perfect, but it can't get better without undoing that fix.[Mojang] Jeb (Jens Bergensten) added a comment - 30/Aug/16 10:50 AM
Fixed while maintaining the fix forMC-105560, so behavior for hopper-to-hopper love may still act differently compared to 1.10
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
[Mojang] Jeb (Jens Bergensten) marked MC-5726 as "Works as Intended" himself. If you really want this to be changed, you can submit a feature suggestion/change at Minecraft Suggestions on Reddit.
When [Mojang] Jeb (Jens Bergensten) announced the locate command at MineCon 2016, he mentioned that it takes arguments to determine where to start the search from (e.g. @p, <x> <y> <z> etc.). However this doesn't appear to be working.
I've tried the following commands, all of which fail.
/locate Mansion @p
/locate Mansion 1000 100 1000
/locate Mansion ~ ~ ~
/locate @p Mansion
/locate 1000 100 1000 Mansion
/locate ~ ~ ~ Mansion
[Mojang] Jeb (Jens Bergensten) What problem? Farms or performance?
Your answer seems very vague and doesn't answer the question of those asking why this decision has been made in the first place.
I'm curious how you'll re-evaluate the design of weighted pressure plates, given the maximum of entities of 24 in one spot, so they can be used in a technical way like before.
(Of course I'm not going to use this bugpost anymore to discuss that decision, I just felt I had to reply to it one last time.)
[Mojang] Jeb (Jens Bergensten) I'll try to collect the community's input about the weighted pressure plates, maybe you'd want to have a look at it in a few days, unless you already got an idea yourself about their future design: https://www.reddit.com/r/Minecraft/comments/56y4nv/maxentitycramming_gamerule_remains_defaulton
One thing I always thought was "expensive" in terms of performance was to have stacked items countable, because it changed at some point when items stacked together; turns out, after I asked a coder, it apparently wouldn't be a strain on performance, so that'd be one of the things that would be great if it could be re-added to the game, after the change that stacked same items couldn't be counted individually anymore.
Maybe that's how the plates could be different: One that counts stacked items and maybe even mobs of the same type, and the other plate doesn't, or the plates weigh different types of entities on them, e.g. items, mobs, XP orbs; but I'll wait for the input of the tech community, they might come up with more sophisticated ideas.
You can't use weighted pressure plates with mobs because of entity cramming
They check for too many mobs, more than entity cramming allows in one space
—
In MC-108301 [Mojang] Jeb (Jens Bergensten) mentioned that weighted plates should be re-evaluated, now that they have gotten basically useless or at least quite restricted in the function they had before due to his implementation of the default-on and set to a value of 24 maxEntityCramming gamerule in 1.11.
After some testing in 1.11 release, this doesn't seem to have been done yet though, thus this bugpost.
In this post on Minecraft Reddit I collected input by the community how to redesign those weighted plates so they'd be useful for the tech community again: https://www.reddit.com/r/Minecraft/comments/56y4nv/maxentitycramming_gamerule_remains_defaulton and more suggestions have been added and more might still be added, as I asked again for participation in this older Redditpost.
It'd be very kind if Mr. Bergensten could have a look into the suggestions that were and will be made in said Redditpost and maybe also give some feedback and spread the word, as his community reach is by far bigger, and people would be more likely to make suggestions if he participates in this discussion and makes people aware of it, as not everyone seems to know about it yet.
Unless, of course, he already got own plans how to re-evaluate weighted plates and doesn't need or want community input.
I might insert a redux of the suggestions in this bugpost here if I find the time.
An argument that it still detects non-living entities such as items is fair, but not satisfying, as it would deprive us from old functionality which, again, was not voiced publicly by Mr. Bergensten or Mojang generally that this would be a wanted change for 1.11.
I have not read a single word about this anywhere on Reddit (or the Mojang website/their blog in the snapshots, prerelease or release post), but in case I missed it, it'd be kind if anyone could get me a link.
The only public statement that I'm currently aware of was what Mr. Bergensten said in MC-108301, that the argument of weighted plates being rendered useless is a valid point and thus their design should be re-evaluated.
As there could be a Redstone overhaul-in-one-go planned to get rid of old bugs (not bit by bit/redstone component by redstone component as this would confuse the tech community too much and aggravate them as we could see during the 1.11 snapshots), I could live with this bugpost being resolved as "Postponed", as the weighted pressure plates would be part of a complete overhaul as well, but I definitely don't consider this bugpost a feature request or suggestion, due to the aforementioned reason.
From MC-108301:
An iron/heavyweighted pressure plate changes the signal strength it gives off depending on the number of entities on it.
Signal strength of 15 is reached with 141+ entities.
The default of 24 entities with the "maxentityCramming" gamerule renders them pretty much useless, even more so as golden/lightweighted pressure plates detect only up to 15 entities.
There was the argument that at least those pressure plates would work as intended for those people who use commands to turn off that gamerule.
As the technical community is the main target group to use these pressure plates, and as those who really can make use of those pressure plates are nearly all "decidedly Vanilla" players who would never use commands for their Vanilla worlds, it makes no sense to deprive them from making use of those pressure plates, as they are nearly the only ones using them in the first place, as highly technical players with "many entities being crammed in one spot intentionally".
I'm not a native English speaker so I cannot word it so well like Skylinerw can, whose comment over on Mojira-Reddit I will thus mostly quote, as he mentioned many things I and some of my technical-player-friends I showed it agree to:
Regardless of if the gamerule's primary objective is to boost performance or affect gameplay, it's not taking into consideration that it's blocking another feature that already existed.
Why have weighted iron plates in the game if, by default, 12 of its 15 states cannot be used without cheating?
Not to mention that gold plates already encompass some of the remaining available states for iron, even further reducing the usefulness.
A singleplayer-playing, cheats-off player taking notice of the useless weighted plate feature has no way of fixing it without using a third-party tool, which does not mean that that player knows that such tools exist and how to use them. Nor does that necessarily mean they are even aware that there is a way of fixing it.
Driving the player to using a third-party tool to fix a feature (that was previously fully available and could otherwise have been defaulted to fully available) is not something that should happen.
That also does not mean that players should "learn" to enable cheats on world creation.
Enabling cheats is optional, not a requirement for being able to fully access all survival features.
Weighted pressure plates were not cheating, after all.
The primary issue I have with it is that a cheat, by default and with no recourse for some, blocks a survival feature that was previously accessible, and requires cheating or (for some) requires third-party tools to access it again.
Keep in mind that weighted plates are not restricted to the technical community.
Everybody has access to this feature, not just a single sub-community, so it does impact everybody (including non-technical players following a tutorial that makes use of weighted iron plates).
An existing and intended feature (weighted iron pressure plates) is being hindered by default for everybody and requires cheats to access them fully again.
Possible solutions to this issue are to change the default value of the gamerule up to the highest value that iron plates can detect.
The popular solution is to change the default of the gamerule to 0 and let players/server admins decide when to use it, while iron plates become fully accessible again.
However, none of those solutions work when the gamerule is changed.
What would probably be an unpopular solution is to remove iron plates entirely, since in their current state, they are near-useless.
I'd like to add to SkylinerW's last sentence here that a removal of weighted pressure plates in favour of the "maxentityCramming" as default-on-gamerule would not only make all technical contraptions which make use of them with living entities void, but I'm sure that the reaction of the community would be even more negative than it already is towards the maxEntityCramming gamerule.
In latest snapshot the color palette for maps has changed.
See the picture attached for comparison: (PRE snapshot | Snapshot)
Comment from [Mojang] Jeb (Jens Bergensten) on reddit:
I think the problem here is that one brown shade changed, but not the other? Your gradients have disappeared, which is a shame. It would be helpful if you filed this as a bug.
[Mojang] Jeb (Jens Bergensten) added a comment - 4 days ago
This should be fixed for 1.11 worlds. There is no upgrade path for worlds created (or already saved in) one of the 1.12 snapshots.
@[Mojang] Jeb (Jens Bergensten) why exactly is this intended? Only because the current way you fixed MC-113380 does not allow differentiating between liquid types or is this really intended in a way that it could only work for water but you decided it should work for lava as well?
Timothy Miller - Every bug is a bug and it should be fixed, (unless [Mojang] Jeb (Jens Bergensten) says its a won't fix), it doesn't matter how important or hard it is to fix.The more game-breaking ones are of course prioritised (like MC-111645), but for most issues the votes count is the way to sort them.
About the resolution of the bug itself - it's a little more complicated then that, go watch Panda's video if you haven't.
sorry for the unnecessary bug updates, the syntaxes never work the first time
Then [Mojang] Jeb (Jens Bergensten) should come close the ticket himself, if that is really true and discussed with him. We (moderators and helpers) have had no message whatsoever to close this.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Works as intended, see MC-83174 and this comment from [Mojang] Jeb (Jens Bergensten).
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
user-f2760 This is the full comment of what [Mojang] Jeb (Jens Bergensten) said when the discussion was over (https://www.reddit.com/r/Minecraft/comments/5c752g/help_us_decide_should_observers_update_at_1_or_2/d9zmv4l/)
Thanks for the input, you bring up very good points.
The reason why the piston behavior "technically a bug" is because the block in front of the sticky piston is supposed to act as if fixated to the piston. Your interpretation as "it's inertia" actually makes sense. In any case it doesn't look like we can fix it without making other major changes to the system.
So, it sounds like "piston leaving block behind" is intended behavior because of its inertia, it is not strictly supported, that a block moves in the new position immediately, tho.
The last sentence is just hypothetically what if they wanted to fix it.
frank the frank [Mojang] Jeb (Jens Bergensten) himself resolved this as intentional, so it is intentional.
@[Mojang] Jeb (Jens Bergensten):
They're supposed to "pop" into an item entity if you can't catch it
Previously happened to this person: https://www.reddit.com/r/Minecraft/comments/7xk1he/in_the_last_snapshot_be_careful_with_your_legs/
And also this person (@[Mojang] Jeb (Jens Bergensten)): https://www.reddit.com/r/Minecraft/comments/7veimo/turtle_shoutout_to_billyk_as_suspected_theres_a/
![[Helper] Michał](../../../data/avatars/users/43368.png){kind=small}
[Mojang] Jeb (Jens Bergensten): "If you put a stair on flowing water, the flow will be blocked, just like it is now in today's Minecraft, but you can put it in a source block and you will have both a stair and a source block."
cource: https://www.reddit.com/r/Minecraft/comments/7yj559/recap_of_jebs_talk_at_the_pc_gamer_weekender_on/
Based on this source can this bugreport be reopened?
also 18w08a affected
For now, this is intended. As [Mojang] Jeb (Jens Bergensten) explained here, this is to prevent contraptions from being flooded.
Seems to be fixed as of 18w20!
As [Mojang] Jeb (Jens Bergensten) said, the tridents now drop into items when you can't pick them up- i.e. when you die when it's coming back, it drops into an item. Also, same thing for when you throw it then go into spectator mode.
Thank you for your report!
However, this issue is Invalid.
Ilager_beast currently doesn't have a official name as told by [Mojang] Jeb (Jens Bergensten) on Minecon Earth (source), you can suggest names!, visit https://feedback.minecraft.net to suggest one!
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
This works as intended as per [Mojang] Jeb (Jens Bergensten)'s comment in MC-83271:
The Wither and the Ender Dragon will now ignore all effects.
This is working as intended, see [Mojang] Jeb (Jens Bergensten)'s comment in MC-28424.
As per [Mojang] Jeb (Jens Bergensten)'s comment on MC-1, this is what's supposed to happen:
Block animation now disappears after 20 seconds
However, perhaps the breaking animation should disappear when the block is broken, too.
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Hello! This looks to be a duplicate of MC-151512, which has been marked as Works as Intended based on a comment by [Mojang] Jeb (Jens Bergensten) on MC-83271.
What [Mojang] Jeb (Jens Bergensten) said. Thay can't reproduce.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Can confirm. May be relevant to this comment by [Mojang] Jeb (Jens Bergensten) in MC-1149:
"The duration is less the farther you are from the impact point. I just verified that if you are directly hit by the splash potion, you get the full duration."
Despite the entities being in the same block position, the game may not be handling it as such, and could consider some entities to be further away somehow.
Please submit crash report
This is probably because of little/big-endianess of the CPU. We don't plan to fix this, but it's possible we accidentally fix it one day...
Problem with client-side prediction
Block animation now disappears after 20 seconds
Fixed by making the client fall slower if the chunk hasn't loaded
I can't reproduce either...
The problem is that the game isn't able to read the file. I've contacted C418 to see if he knows why.
First part of bug report is a duplicate.
Noticed that this bug was occurring when music was turned off, fixed.
Because of scaling problems, we've only re-enabled this feature when shooting other players
Redstone power will always open doors, not switch
The offset is to prevent z-fighting when wearing multi-layer armor (at the moment leather). It looks bad on the default Steve skin because the insides of the legs and torso have a bad choice in color.
DarkWolff: Can you check the performance graph (Shift+F3) and tell us if you see a big difference on the "Sound" section when it's raining?
Please verify that this still occurs in 1.4.2, thanks.
I can't reproduce this bug, but I added some debug messages that may help us find it in the future... if it still exists =)
Fences and cobblestone walls work like this, no current plan to change it.
Matti: Unfortunately, allowing players to float client-side will trigger the anti-flight hack check. The server isn't aware of the client's chunk-loading state, so we can't consistently know when to allow floating without also making it easier for people to fly-hack.
Made noises slightly deeper in pitch.
Made bats less noisy when sitting still.
Decreased number of bats that are spawned.
Stopped bats from pushing other mobs (they're too light anyway)
Have you tried opening the server's world in single-player?
The song will now be included with the game, but called "wait", not "where are we now"
Although not exactly the same problem description as
MC-15, the fix forMC-15should cover this bug too. Otherwise, re-open it after the release of 1.4.3Temples and huts are now more strictly placed in correct biomes. I haven't looked at placement of villages, please create a separate bug report for that.
The duration is less the farther you are from the impact point. I just verified that if you are directly hit by the splash potion, you get the full duration.
The local player will now play its own sounds, to skip sound lag.
With the debug info I added previously, I was actually able to reproduce this bug! Now it's fixed!
The bug was caused by the old "suffocation when touching walls" fix. We've fixed both bugs now.
DiEvAl: The chunk update and sign update packets sometimes came in incorrect order, so the sign didn't exist client-side when the packet arrived (and was thrown away).
This error is due to old LWJGL version. We are aware of this and will update LWJGL "as soon as possible". Until then, please try to update LWJGL manually.
My investigation of this bug has lead me to believe that it's the same bug as
MC-100, so I'm closing it as a duplicate now. Re-open the bug report if the problem still occurs in future versions (1.4.3).The timer you see in the GUI is only client-side and may mismatch the "real" timer server-side. I've added a method that resends effects every 30 seconds in order to synchronize the timers more often.
Can you please give us more information, such as what the map looks like?
Don't link to a 20-minute video clip without telling us when in the clip the bug occurs.
Closing this as invalid because there are several bug reports in one. Also, the item frame glitch was fixed in 1.4.1, so I don't believe it's still relevant.
Can't reproduce, what kind of tree are you planting?
Aha, thanks for the video clip and test world. It's fixed now
Please make sure you aren't playing on "easy" difficulty.
kumasasa: In his defense, this was a different bug. Fixed now!
Thanks for the help!
The bug was that the pressure plate would trigger the teleport command immediately, so the server's thread would still be inside the movement method for the player's position before being teleported. We are not 100% sure why the false pressure plate was triggered, but we fixed by delaying the command block by 1 tick.
Stop wasting our time...
Swords can't have silk touch and shears can't be enchanted, so at the moment this is a feature request and not a bug report.
Thanks for the detailed bug report! I was able to reproduce and fix it, turned out the client responded with a "close container" packet when it received one, so the server would close two containers when the client only closed one.
Can't reproduce
Added info: This only seems to happen when activated directly from a button, and not if the button is connected via additional redstone dust.
Added better error handling when encountering unknown statistics. Should help most problem cases.
Updated again... Fixed the issue when it gets stuck in open state if the GUI is closed server-side.
I think this is a duplicate of
MC-4024, please re-open if I'm incorrect.Seán: Can you please provide more death message examples, so I can see how to change the message form? For example, translate "jeb fell off a ladder" and "jeb fell off a ladder and was slain by Zombie", for starters.
Bastian: Yes, I tried to figure out a way to keep the dynamic feeling of the death messages, but I couldn't find one. I've simplifed the death messages and made them full sentences. I'll upload a new translation sheet to crowdin tomorrow.
It's fine to change the order of parameters, that's why they are numbered. Ie you can change "blah %1$s bleh %2$s" to "blah %2$s bleh %1$s" if you want, though it's difficult to know what they are replaced with.
The %1$s was removed from the death reasons because they were used as fragments as either "jeb withered away" and "jeb was shot off a ladder by Skeleton and withered away". That sentence was a combination of the following fragments:
It's probably very difficult to find a fragment system that works in all languages, as you say, so I had to simplify the system. It's no longer possible to get falling+death combinations, and all different ways of being pushed by someone has been removed. In the example above, if I had been killed by the Skeleton's arrow it would've been "jeb was shot by Skeleton", if I had been killed by the fall "jeb was doomed to fall by Skeleton", and if I had been killed by the wither effect after the fall "jeb withered away" (as previously).
Sigh...
Comparators were being updated all the time, even if you couldn't see it. So this was a huge performance bug, beyond the weird/unintentional tick builds.
Chad: Yes, but I think that's more a bug with dispensers/droppers. They fire on neighbor updates if there is power around them (and the tile that was updated counts as a "signal source", as comparators do), regardless if the power was turned off or not. I think we still have a bit of metadata remaining, so we could use that to prevent repeated updates for the same signal.
The fix was to revert to how clouds were rendered before beacons. Clouds will now look funny when seen through a beacon beam, but I suppose that's a worthwhile tradeoff to fix this problem.
Tim: Yeah... I kind of thought it looked better that way. The top/bottom edges were intended to hide that the panes are infinitely thin, but that's not necessary when there are blocking blocks above/below.
Confirmed, it happens when you have the "survival inventory" tab in creative mode. Looking for a fix.
The entry is on crowdin, even if it hasn't been included in the game yet
This bug has been "sort-of fixed". What seems to be the problem is that your game is unable to read and/or access the ".minecraft/saves" folder. The game is unable to get around this error on its own, so we made it display the error instead of crashing, but you will still have the same problem.
Uhm... Fixed this, but probably not the way you hoped for =) I've made it impossible to create items with negative damage values, because the behavior is undefined. Will compensate by adding some kind of "indestructible" enchantment for this purpose in the future.
It works like this for performance reasons
The wither effects disintegrates creatures over time, so undead are not immune (although the Wither itself is immune).
Although the wither skeletons can't burn, they want to stay out of sunlight.
Please use the search function before posting duplicates...
Fixed for real this time. I was lazy when I "fixed" it yesterday, sorry.
I managed to reproduce it and then I managed to change stuff so I no longer was able to reproduce it... I don't know any other way to properly verify that the bug is gone, or that I haven't added new bugs =( Please re-open this in future snapshots if you're able to find it again.
Can't reproduce
Can't reproduce
Although crazy behavior, it's intentional that you lose hunger when harmed
Players now dismount if they are teleported
I think this is fixed now, will check tomorrow.
I've decided that this is the expected behavior. If I "fix" it, people will complain that it's much harder to do double-length piston extenders.
Marking this as fixed now. This example is stable: http://imgur.com/a/9FMnX
Fixed as suggested.
Fixed as suggested, data value 15 is now smooth quartz
I think you have to have a good reason to scale down the windows that much. And if there is such a reason, why prevent it...
The debug tools are intended for internal use. I have other things to spend my time on.
Can't reproduce, it's possible I fixed this yesterday =)
Fixed, but client-side the piston will flicker into its closed state for an instant. I don't think I can avoid this. It's more noticeable when you have lag, but at least the piston itself doesn't move (no sound effect either).
Thanks, hadn't noticed this. The comparators will not give off any light, though, due to the "on" state is stored in meta data instead of switching blocks.
Didn't know about this, but it's funny so let's keep it.
Weird! I can't reproduce, though. What kind of objectives did you add?
I've already commented on this. Negative damage values are undefined, but we haven't bothered to change it because nobody's complained about them. Now there is a bug, and the proper fix is to remove the undefined values (otherwise we'll just keep on hunting bugs like these in the future). I've already said that this can be compensated with an enchantment, but it can also be compensated with some kind of tag data (such as a boolean tag stating "indestructible"), but our focus now is to fix bugs and not add new features.
Please also provide the texture pack you are using.
@p is case sensitive, maybe that's the problem?
I dunno why Dinnerbone removed the limit to the effect command
I don't want to chase "bugs" like these...
Was hard to see since the client-side bounding boxes were correct. Should be fixed now, though.
As far as I can see, my fix to
MC-10889also fixed thisThanks for this bug report!
I can't reproduce this. Tried both SMP and SSP, building those examples with command blocks within a chunk. The order of the say commands is unpredictable, but that's because the order in which repeaters are triggered is undefined if they all get the power at the same tick.
Let's keep this open for the 10a snapshot.
Thanks for the help. I was able to use The.Modificator's world and stop the random behavior. Problem turned out to be that when ticks are scheduled, they are thrown away if the neighboring chunks haven't been loaded yet. Removing this check fixed the problem, and I couldn't discover any new errors.
I'm marking this as resolved, please reopen it if the bug occurs again in the next snapshot.
Thanks for the updated bug report, I was able to locate and fix the error!
This is because sounds are loaded asynchronously in the background. We may change this in the future, but it will require a new launcher.
I'm unable to reproduce, but I think it's because I indirectly fixed this when I fixed
MC-11019, so I'm marking it as resolved.Can't reproduce
Reverted this fix because of performance issues. In the future we can fix this again, but with more specific cloud options in the video settings menu.
We can't really find why this is happening, so please continue adding reports and information for this bug. However, in 1.5.1 this error will be ignored by the game so at least the game doesn't crash when it happens.
I've attempted a number of optimizations and created a temporary snapshot. You can get it here:
http://assets.minecraft.net/13w12_/minecraft.jar
Please compare this to both 1.5 and 1.4.7. The snapshot should be compatible with 1.5 servers.
Dranitsin, Raphael: Oups sorry, my bad, I forgot to unlock security settings. Please try again.
Ok thanks... I can't really understand the FPS difference. There must be something else causing it, possibly the new texture stitching (but on our computers the stitching actually improved FPS).
Thanks for the info. I've uploaded a new version of the debug snapshot that is even more optimized. Please let me know how it works.
Not sure how to reproduce this
Yes, unlike player movement, horse movement is server-controlled. This may cause desynchs because of lag (which often happens when you ride into new territory).
This works as intended. The bug is that you can't remove armor from horses, but that has been fixed.
Can't reproduce, it's possible Dinnerbone has fixed this for snapshot w21
I'm not sure how you dismounted with the inventory open, but since you don't need to ride to access the inventory, I don't consider this as a bug.
Can you upload your results to pastebin or something instead of an Excel sheet?
Also, I've double-checked the math and I don't see any errors. The offspring get (Pa+Pb+New)/3 in its attributes. Should be able to produce both higher and lower values than its parents.
I've made it so that wolves will ignore tame horses when the player hits them
I removed the "no armor" requirement on breeding
Translation errors should be fixed on the crowdin project. From the game's perspective this is working as intended, as formatting errors should display an error message (previously the game would crash).
Can't reproduce
I think this is fixed now, but can't confirm.
Yeah, it's about getting leather. The achievement name is a joke.
The horse armors are not rendered as an extra layer, so giving them the enchantment glow is a bit difficult.
Fixed the horse sounds. Donkeys are not supposed to play the galloping sound, so that's working as intended.
No they're stored as floats, and health is rounded up to the nearest full heart in the GUI.
I think these bugs are fixed via the horse-in-water desynch bug fix
Can't reproduce
Wolves can only deal damage to what they're targeting, so in this case the wolf was trying to kill your wife, not your wife's horse.
Yes, if you attack her or she attacks you.
The rules for fortress mob spawns have been changed to make them work better on old worlds, without breaking current worlds.
I've done some changes now (for 1.6.2). First of all, wolves weren't able to hurt horses at all previously, which they can do now. However, in order to stop accidental kills of family members, you can now tell wolves to stop attacking by sitting them down (previously they would still remember the target and continue the attack).
Fix your redstone wiring so you're sure which block gets activated first
Is this bug still valid?
Thanks for the research. I actually found the same problem while I was investigating how the noise patterns worked. Should be fixed in the 1.7 snapshots.
Villagers plant whatever they want to plant.
The local difficulty is a derivative of global difficulty settings and total world time, but it's still the local value that is displayed in the debug screen.
The guardians were not intended to be fire immune, however they are not supposed to suffocate on land either, so that works as intended.
The knockback is more accurate now, the old way gave a false impression that the mob was farther away than it actually was.
Not enough information
Sponges can not soak up 5x3x5 blocks of water (75 blocks), because the maximum is 64 blocks.
You see better underwater with both these effects than you did before. It's intentional.
Needs more information.
Stop re-opening this issue. Sponges can only soak up to 64 blocks. The bug report is for 5x3x5 blocks, in other words 75 blocks, so it's not a surprise you get different results depending on where you place the sponge.
Fixed by adding an inverted state for daylight sensors
Wild wolves should be able to be leashed, but not angry ones. Fixed in future updates
This has been fixed, but differently for wolves and zombies:
Wolves will only remain angry as long as they have something to attack. Summoning an angry wolf will immediately make it non-angry since it doesn't have a target.
Pig Zombies will actively try to find targets for as long as they're angry, even if they can't find / don't know the source of the anger.
Fixing this would create a whole bunch of special-case code, as the saddle and armor are baked into the horses' textures. After making a few stabs at the code, I decided it was not worth the effort / complexity. I will remember this when/if we add other mobs with armor in the future.
Can't reproduce, update the bug report with an example of a failure.
Fixed in next update. You were correct, the sponge behavior was interrupted by water updates while removing water. Thank you for clarifying the bug report.
You need legs to jump!
You can upload your own skin at http://www.minecraft.net/profile if you have bought the game.
I'm unable to reproduce this bug, maybe it already has been fixed? Please test again in the upcoming snapshot (15w46a)
Won't fix because the risk is too high that something else changes behavior.
"Fixed" as in "fixed for redstone blocks". Other signal sources have not been changed
I couldn't reproduce the birch tree bug as in the description, but the "bonus chest being destroyed in jungles" part is now fixed
Grum pointed out that this bug may have been fixed when we corrected some blocks' bounding box calculations. Please update the report to include the latest snapshot if you are sure it still happens in the latest snapshot.
Sorry, I hadn't pushed to master for this week's snapshot
Sorry, I hadn't pushed to master for this week's snapshot
Why was this reopened? I fixed the old report and this is a new problem that should be "won't fix", but I don't want to change this report to "won't fix" because it was fixed!
Redstone dust should not float in the air, but dust on the ground should point to connections.
Sorry, I hadn't pushed to master for this week's snapshot
Shears will make cobweb drop cobweb
Slimes now act as you would expect when they're levitating.
First of all, I'll do another round of balancing before 1.9 is done.
Secondly, this works as intended. The idea is that axes are strong and slow, and better materials make the axes faster. Swords are always faster, so better materials make them stronger.
In many combat situations the stone axe is as effective as a diamond sword, but the sword has the sweep attack, better combat durability, and better combat enchantments.
F3 is a debug mode, turn off debugging
This works as intended
"Works as intended" may be an exaggeration, but they're not supposed to be able to teleport great distances, and if they can't find a spot they simply give up and stay where they are.
Increased damage
There would simply be too much code to fix this (each effect would need to keep track of its source, its coordinates, and its range)
I decided to ignore ghasts, because it just looks jittery when they try to float back to where they want to be. Fixed it for squids out of water though.
I don't want to add a special case check for this. Consider it to be a badass life hack!
The Wither and the Ender Dragon will now ignore all effects.
Note: Guardians and Ghasts work as intended
I'm not sure what to say about this... if your body is gone, how can you still see???
First I fixed it as you suggested (0.5 points of damage), but it was really fun so I bumped it to half a heart instead (1 point of damage)
In my opinion this bug should be fixed by changing level.dat into something that can be read and edited by human eyes. What happens here is actually that the server will prioritize the level settings (in level.dat) over the server properties. I feel that the server properties shouldn't control level settings in that way, so it's a structural problem.
My suggestion to you, if you still have this problem, is to edit your level.dat with a NBT editor and change the setting there.
So... status: to be determined
Searge fixed this while fixing
MC-91543Aha, I didn't read the description properly. You should've posted two different bug reports instead of describing two bugs in one report
In adventure mode you are allowed to "use" blocks
It's hard for me to try to find every single instance of tricking the game to destroy and drop bedrock, so I "fixed" this by simply preventing bedrock from dropping a bedrock item. This way it may still be possible to remove bedrock in certain ways, but at least you shouldn't receive it as an item
Chorus plant will treat max build height as a ceiling
Fix note: This has only been fixed for wolves as they spawn as friendlies. Ocelots spawn as monsters (i.e. continously) and need to be despawned when inactive.
Unable to reproduce
Fix note: Grass is not replaced with grass paths if there's something above it. This is the new intended behavior, so don't report it as a bug when tallgrass prevents paths
Fix note: Replaced with cobblestone
Fix note: Zombie villagers spawned with villages are now persistent
Can't reproduce. When I test it the husks they get the same follow range as normal zombies (around 35 blocks)
Can't find the said village for seed -8920838275269013217
This bug report is about various different things so I'm not marking it as fixed, but the horses should now have proper names in their inventories etc
It's fixed to the point that I can't reproduce it any more. Please update the bug report after the first 1.11 snapshot if you find a way to reproduce it. Obviously the items will jitter slightly depending on client-server lag issues, but items should no longer appear in the wrong locations.
As mentioned in the description, still doesn't work perfectly for downwards-facing dispensers. Mainly a bit tricky to know how much to offset the entity, since there may be a floor below the dispenser as well
Fixed as according to the description. Thanks!
The bug was that arrows add effects with 0 duration, so they're never activated on the target
Thanks for the help Marcono1234, though I fixed it by making sure that the endermite/silverfish updates all rotations
Fixed as suggested by Marcono1234
The bug in this particular case was that the two neighboring hoppers would get almost exactly the same cooldown tick. This meant that instead of hopping the item every ~4 ticks, the item would stay in either hopper 7 or 8 ticks and in the other one 1 or 0 ticks. The comparator is not updated frequently enough to notice this, so it looked stuck.
I've fixed this issue by aligning all hopper ticks to the level's game tick, at a rate equal to half of the hopper's interval (i.e. 4 ticks). Obviously this may have new side effects that I'm sure the community will discover. Especially if a redstone contraption relies on hoppers to update more frequently than every 4 ticks.
:sadface: At least that command gives an identifiable rounding error in the network code. Could do a hack to fix it for items, but not sure that's the correct approach
Yes, the entity move packet is indeed the problem. The relative movement is truncated into integers to save 12 bytes of data for each update, and in certain cases this is not granular enough to achieve correct movement physics.
The "hack" I had in mind was to simply let the server tell clients when an item has become stationary. When that happens the client should no longer predict the physics until the server says the item is moving again. Just feels like an awfully awkward workaround.
Fixed according to Neko's suggestion
Fixed while maintaining the fix for
MC-105560, so behavior for hopper-to-hopper love may still act differently compared to 1.10This is how the Minecraft engine works
We've been talking about this problem for several years, so my only regret is that we didn't add this sooner.
The pressure plate issue is a valid point and their design should be re-evaluated.
Yes, I created all the mansion pieces. The reason why they don't have "jeb_" as the author is because when I run the game in development mode I don't bother loading my real profile, so I'm assigned a random player name.
I've marked this as "wont fix" since it's a hassle to fix it and little is gained.
This is by design.
The Eye of Ender still finds the stronghold, just not the portal room. The behavior changed in order to support more than 3 strongholds.
This is intentional and part of that specific room's layout
Assigning to Grum instead, because he was talking about getting rid of the template room.
Ben: I think the problem here is that the model itself is inverted, right? If you just modelled it to face the other way, the 'fixed' transform shouldn't need a rotation at all, or am I missing something?
Sorry I made you write that long response, I realized my mistake while at a meeting =)
In the end I discovered that the problem was not for the token itself, but rather in the item frame renderer. The item frame has a hard-coded 180 degree rotation on all non-3d item models. This was easily fixed by remove the hard-coded rotation and replacing it with a json definition for 'fixed' transform in "generated.json". There's a similar bug regarding mob skulls.
I've fixed this but it will not be in this week's snapshot because I was too late to commit to the branch.
Also: I discovered that the item which is used to activate the animation is ignored. The game is supposed to be able to play the totem animation with any kind of item, but there was still a hard-coded totem item instance in the renderer, which I fixed thanks to this bug report.
Restored the fix that we added a couple of snapshots ago. The conflicting bug was
MC-108127, so in order to make them co-exist there is a special rule for custom cooldown times that are longer than the default (8 ticks).