mojira.dev

Rezzing (Adriana)

Assigned

No issues.

Reported

MC-52668 Player skulls UUID compatibility incomplete (NBT tag SkullOwner was of wrong type) Fixed MC-42179 Knocking zombie hordes, being after a Villager Meal, causing high CPU usage Duplicate

Comments

Something to tinker with for the devs: A copy of my affected vanilla game files (last time used with server 1.8.9 and not loaded into 1.9 so far) at https://www.dropbox.com/s/y3iqdvoryvi6fak/Cubystar_World_1_8_9_March2016.zip?dl=0

Just in case, a copy of my latest game files (from vanilla 1.8.9, not loaded into 1.9): https://www.dropbox.com/s/y3iqdvoryvi6fak/Cubystar_World_1_8_9_March2016.zip?dl=0

@Sealbudsman, 1.9.1-pre1 makes no difference. So please, to not discourage the devs to fix this ASAP: This remains a major issue for worlds generated prior to 1.9.

@Gorlov, ugh, this is basically affecting my entire 350MB region (which is completely vanilla btw.) There must be a better way but repopulating this by hand. That would take forever.

I've the same entity spam in my server logs, if I try to continue my 1.8.9 world on 1.9. No crashes but lag spikes and I'm afraid this could damage my game files. Can someone explain, please? Any workarounds?

While I play server-side (all vanilla), it doesn't seem to affect the server but my client log is spammed with "Item entity # has no item?!" every time I create a drop, either by mining or simply by dropping whatever. Maybe worth mentioning that I've made a clean install for 1.8, to see if it solves my lag issues. Well, it doesn't. Found out about this error instead.

Yes, apparently there is much more wrong. I still get java errors all over the world, same for very old and very recent locations. I just can't figure it out and I don't see anything missing either. The server window keeps saying stuff like: u: Saving entity NBT...blah blah...

Nevermind *blush*. My SethBling villagers (with custom made trades) weren't compatible anymore. Had to remove them, rolled out the flowers fix already and everything works fine now! At least so far anyway 😃

@Rickard, I'm using the 64-bit MCedit dev version 0.1.8build799. The release version is incredible outdated. Check the "MCEdit > Keys" menu for camera controls. And MCEdit takes a whole lot of RAM, so better do not edit very large worlds all at once or it might just crash on you.

How to:
1. After opening the world (level.dat), uncheck 'Record Undo' in the upper right corner. Undo takes a lot of time.
2. Expand a selection from sea level to the highest mountain (selecting whole chunks takes longer).
3. On the bottom toolbar, click the Fill and Replace button.
4. For the first tab, search for "Tall Plant Top" with the ID 175:9. Then click Replace and select 175:8.
5. Click the bold yellow Replace button to apply. Repeat this for 175:10 to 175:12 of course.

So, that's it. Saving takes a lot of time because it will relight all modified chunks. But that's nothing to worry about and will fix lighting bugs anyway.

PS: It's quite possible that MCEdit stops with a nasty error code saying something about malformed chunks. That's not a bug but indeed a corrupted chunk and MCEdit can't handle it. I'm mentioning it because I had this quite often at random. In such case, look for "Minecraft Region Fixer". It's a command line tool, so for example "region-fixer.exe --dc c:\your_gamefiles\world" would remove the broken chunks and the game files are accessible by MCEdit again.

I'm getting desperate about this, so I just took a look at it with MCEdit. MC 1.8 generates downright all top parts for tall flowers (including tall grass and fern) with an item ID of 175 and a data value of 8, while for some reason, MC 1.7 generates top parts with values between 8 and 12. Apparently, replacing all those flower tops with 175:8 does the trick. The java exceptions are gone from my server shell too.

But what now? Because that's an irreversible workaround. I can't tell really if that's a 1.7 or 1.8 bug. Although, the wiki says about value 8: "Top Half of any Large Plant; low three bits 0x7 are derived from the block below" (from http://minecraft.gamepedia.com/Data_values#Large_Flowers). So can someone confirm this before any of us is going to ruin their game files?

Uh.. common Mojang, how can you pre-release it with a showstopper like this? In case you need another world to reproduce it, here's a copy of my game files at db.tt/InrIbgNK with every garden and flower field getting ruined due to this. Plus, I get a lot of "Saving entity NBT... java.lang.NullPointerException" all over the world 😞

Alrighty! In this case, I'll look forward to the updated knowledge base. Thank you.

Not trying to get on somebody's nerves lol but bug #2 (summon mobs with skulls) still shows up with a Steve texture. Plus, placing a skull for the first time, still generated the server log "NBT tag SkullOwner was of wrong type; expected TAG_Compound, found TAG_String".

Reproduce like this:
1. /give @p 397 16 3 {SkullOwner:"Rezzing"}
2. Place one on ground and the server generates an exception.
3. Pick it up again and it creates a new stack, which is not prone to log exceptions.

This problem still exist with 1.7.6pre1. Placing player heads causes client crashes. And not sure if related but I also had a chunk corruption on my server while testing the pre-release. The affected chunk is carrying a whole lot of custom player heads (about 10 or more) since my 'head shop' is located there.

Ops.. that's why I hate JIRA. I couldn't find similar reports by search. Sorry for the inconvenience.