mojira.dev

Liam Scott

Assigned

No issues.

Reported

MC-99905 Villagers spawned with no buy option breaks NBT data. Entitydata commands targeting said villager prevents chunks from saving. Duplicate MC-86460 World Crashes Upon Loading Incomplete MC-53416 Minecarts do not stop on unpowered rails/brakes, speed back up after passing over Incomplete MC-18789 Sound effects in resource packs/playsound command get cut off by other sounds Incomplete

Comments

That makes sense actually. On my map, we have a lot of Villagers permanently, essentially trapped in their respective business locations, and below those areas often exist large open caverns, (man made, essentially underground cities) with more empty space than anything else. We essentially have villages on top of villages, and the only thing that makes the lower ones work at all is precisely placed skylights to the surface. In hindsight, I don't doubt something would eventually go wrong with that setup.

OH I think I see what you mean. Whoops. My apologies, I have not slept in some time. But yeah, as far as I know, that won't output anything until the chunk tries to save. I never realized it was an issue on my server until I noticed the console spam from my entitydata command. But yes, you are right, it's not necessary to be targeted I suppose. Still kind of a game breaking bug though. Reminds me of the invalid Json in signs bug from the snapshots.

I.. could make several points as to why an entity would need to be targeted after summoning. Besides, that's not the issue at hand. As for your latter point, that's purely just false. For many months, redundant and heavy handed as it may be, I nonetheless have had a repeating command block updating the entitydata of any villager on the server to invulnerable. It is only when one is summoned with the aforementioned broken trade that the command fails, and that specific chunk loses the ability to save.

Yep, it pretty well never left our server either, though I've yet to narrow it down to any specific cause. The snapshots and 1.9 releases have definitely LESSENED it, but I've yet to see a smoothly rolling sky pass over, and potions take ridiculously long to use. It's playable, but only just. Sometimes.

Currently, it gets a great number of "Can't keep up!" warnings, and skips anywhere between 100 and 2100 ticks depending on what we're doing. This results in Elytra being basically useless, and players moving around any faster than standard walking, (this includes just dropping from the sky...) will result in "Moved too quickly!" followed by a prompt teleportation back to the last location they were picked up by the server. I also constantly still get console spam about keeping entities with duplicate UUIDs, which is something that, at least on a redstone and command level, is know to cause issues, and I know for a fact that I never duplicated anything myself.

Third confirmation there. Though on my end, it's still present to such a minor extent that it's almost not even noticeable any further. Night and day difference.

Unfortunately I don't have that option short of having my server host do it for me. Locally however, it made no difference for me, so I can't really be bothered asking.

If the game isn't skipping ticks, then this might actually be an unrelated bug from that which the rest of us are having. As far as I know, at least two users have posted logs indicating that the server, local or otherwise, is skipping a lot of ticks.

Be that as it may, because of this, in other duplicates, people have come to the conclusion that liquids play some part in the issue. As far as I can tell, they do not.

I don't believe water has any part of it, as setting up a multi-path system to a villager on land will work all the same. The only thing water does is force mobs to constantly attempt to recalculate which path to take, which seems to be the heart of the problem.

I also believe this issue is unrelated to MC-94684, as the command provided does not effect the test world on my end. To the extent of my current research, it only seems to be commands that target or effect entities that triggers it with command blocks. Though why /execute doesn't do it is beyond me...

Here is the same world provided by Jay with my findings added to it. Simply use the zombie spawner with the button, and activate any of the redstone clocks in the area, or turn the repeating command block to the always active state to see the effect:

https://dl.dropboxusercontent.com/u/47112247/SnapshotTest2.zip

From the looks of things, that will also do it. I just tested on the same world, and essentially any form of redstone clock will cause the issue. In addition, while repeating command blocks do not appear to be a cause on their own, any command that pings a large area, or updates a large amount of data will trigger it. (Eg: testfor, entitydata) Curiously however, executing a simple command like /say from all entities doesn't have any effect, despite the nature of execute being just as broad as the other two.

Unfortunately, because of the way this bug seems to work, this means I can't actually test whether or not the old repeating command methods will work, (impulse block hooked up to a clock circuit) as I would not be able to tell whether the lag is caused by the command, the clock, or both. >->

OKAY, I think I've found another possible culprit! Using Jay's test world, and a repeating command block set to always active to constantly update entitydata, causes the lag to resurface just the same as using the clock circuit. Curiously however, it ONLY happens in this case when a Zombie decides to recalculate it's path. They'll make a B-line for the Villager no problem, but if they decide to regroup and take the stairs, the lag will start.

It would make sense in my case that this was at least part of the issue, as I have at least two of these commands constantly making any Villager or item frame invulnerable, which on my server, accounts for at LEAST 500 entities.

Well I just did some experimenting on my own world. Best I can tell, the problem in my case starts at 15w35e. Or in other words, the build where the "always active" function was introduced for command blocks. In 15w34d and prior, the lag does not occur. Furthermore, reintroducing the world into post 15w35e snapshots fails to reproduce the issue, but also resets all command blocks to the "needs redstone" state.

@Jay: I just tested your provided world, and I can also confirm this working on my own system. I will do an experiment with MCEdit on my own world and see if that fixes things. Since most of my active contraptions have been converted to repeating command blocks instead of active clock circuits, this should pinpoint the issue without breaking anything else that might be causing it on my end.

If the problem is not limited to redstone, and also happens with command blocks, then we might just have a cause and effect. I can conform that deleting BOTH all my command blocks AND mobs will alleviate the issue entirely, but neither individually will do so. It's also worth noting that as of the snapshots, I replaced most redstone clock operated command block contraptions with repeating command blocks, which would significantly increase the amount of updates to at least a once per tick timing.

Oh no, I'm not complaining, just getting a little worried is all. To the best of my understanding, the bug won't be assigned until it's replicated and confirmed, right? Cause at this point, nobody can seem to pinpoint the exact cause. As for the theme, I know it's mostly a joke, but it seems to be a trend that the bugs fixed are related to the theme. Maybe I'm just misreading things.

@Early Reflections: It got so bad for me last week that the sun wouldn't even come up, and just trying to walk would trigger Dinnerbone's new anti-cheat system, and TP me backwards. I had just got done essentially refreshing the server map even more than usual. (I completely erased all command blocks and entities outside the shores of the main continent) and it responded by lagging worse than ever. O-o

From the looks of things, Mojang is fixing bugs in two sets of order; categorically, and numerically. Unless it's just their way of listing fixed bugs on the blog, they pick a theme for the snapshot, and fix each applicable bug in numerical order. Furthermore, for whatever reason they seem to keep the more severe bugs for last. At this point, I'm honestly not even expecting a fix anymore until pre-release. I just hope it gets assigned to somebody before then, because despite what I'm assuming should amount to "community consensus", this bug hasn't even been officially CONFIRMED yet..

@Pixie: I tried your JVM arguments with Java 9 x64, and my game, (along with my entire PC) pretty much froze, so I couldn't confirm or deny your findings. Weird since while we share the same amount of ram and OS, my CPU is three times as powerful as yours. o-O

Well I'm glad somebody with more debug knowledge than I has had a chance to look at it! You've definitely pinpointed more than I could, so that's a step in the right direction. On a semi-related note, I can probably say for certain that it's not an issue with it being an old map. While it IS true that the terrain here is absolutely ancient by Minecraft standards, (This was the first world I ever generated in beta 1.5_01!) in the interest of keeping it clean, corruption, and border-free, I have many times completely regenerated the map with MCEdit, including one time recently under the assumption that this issue was a corrupted chunk. It was not.

Essentially, the world itself is a 3008x3008 box covered on all sides by a stone wall, and 40 chunks of barrier blocks replacing air going inwards from there to prevent the wall being visible. Players can still get to the outside via the rail system, but not by land. ANYWAYS, the point of all of this, is that from time to time, I use MCEdit to prune the outlying chunks, and copy the entire map as a schematic, only to reimport it into a blank world. So while the map itself is technically very old, from a real world standpoint, the data that makes it up has been completely regenerated at least 10 times since then.

In my case, I can assure you that it's definitely not liquids or anything to do with them. or at the very least, they aren't the major cause of lag. Using the same effected region file I provided in my Minecraft Forum post, I replace all liquids with solid blocks, and the problem still persisted. In addition, deleting all mobs that have complex pathfinding, custom or otherwise, also did not help. It's really beginning to get on my nerves how ethereal this bug seems to be. _

I can also confirm this issue on my server, and in single player. It's been there for months, and has no specific cause, but CAN be pinpointed at least to a specific area. You can see my findings here: http://www.minecraftforum.net/forums/support/unmodified-minecraft-client/2603466-profuse-lag-extreme-ram-usage-and-console-error