Dan Midgett

so the bug is not that sharpness isn't applied but that the base damage of the sword is canceled. Ok. This is misleading as it does say +X damage and +X attackSpeed. Is there no way to write to another attribute without deleting everything that is already on the item? It seems like there should be...

Also, the other issue with writing all the damage of the sword into generic.attackDamage is that it is applied to other items when in the offhand, but I guess i can just disable the damage part for that slot and only apply it in mainhand. Thanks!

Just wanted to drop this here but:

I also noticed the "when in mainhand" tooltip that gives attack speed and damage for items disappears when any attribute is attached to it.

It may be a bit strange, but if you give minecraft too much memory this happens. My mod-maker friend told me that if you allocate 8G memory to minecraft using JVM arguments this will happen where JAVA will start using more and more memory due to garbage collection. You are better off using no more then 2G. That's what I do. Also, minecraft by default does not give the JAVA it uses more then 1G of memory unless you alter the JVM arguments or use mods, so there is no way unless you did that that it can eat up to 8G of memory by itself that I know of...

thank you! You probably already know this, but I am reading their nbt using this command after each hit: /entitydata @e[r=5] {}

And I checked bows and bow power is unaffected by attributes. Seems to be only enchants that deal direct damage. If I knew how the damage from enchants was calculated relative to attributes I might be able to say more but I always figured they were seperate systems.

*Update: *

Since this post I have done more testing. I have confirmed that sharpness damage doesn't appear to apply on any weapon that has ANY attribute applied even if it is not one that normally applies to players (like mob follow range), and this happens regardless of the mode of operation (addititive, multiplicative additive, or multiplicative) and whether or not I have a slot specified. Attributes other then attack damage always caused the weapon to do the damage that a similar weapon with no sharpness enchants did.

Could this be because sharpness has a hidden bonus to attack damage that is overwritten? I did not think it worked that way but it would explain why initializing the attributemodifiers list with some unrelated attribute might reset it. To test this hypothesis I threw down the sword with the attributes and removed the attribute list with commands with this command:

/entitydata @e[type=item,r=3] {Item:{tag:{AttributeModifiers:[]}}}

Sure enough, the sharpness damage still did not work although the tooltip info for attribute modifiers disappeared.

Also, I tested the effects of attributes on weapons with smite and bane of arthropods as well. The results were even more confusing:

attacking a zombie with a smite V sword always left them at Health:3.760f. However, attacking the zombie with the same smite V sword after applying an attribute caused the zombie to be left with Health:6.7159996f. So most of the smite damage bonus applied but a small portion of it was also added incorrectly. I got similar results for spiders and bane of arthropods: bane III sword left a spider at Health:4.5f, but bane III + 1 armor sword (or other attribute) left them at Health:7.5f. The incorrect damage seems to be related to the level of the enchant but that could be my imagination.

Can a mod please run these commands I posted and confirm so mojang can respond to this? This bug makes it impossible to make a weapon with attribute modifiers properly. Unless you want the weapon to be really bad at least. Damage modifier can be replaced by a few extra levels of sharpness but this is still a little annoying as it reduces flexibility (you can't use it as an offhand attribute booster)

The creeper taking a tick to render as invisible is normal behavior. It annoys me too but there is no way around it without rewriting a basic part of the game. This happens because the entity is created and rendered based on data, but only the next tick will the effect of any status on him be applied. You will note status particles also take a tick or two to start being visible as well. This works well for all potion effects but invisibility. Note that this only happens if you are summoning with commands as there isn't a built-in check to see if the creature is invisible before it is created. In spawners, they are rendered as invisible in the spawner and appear invisible on the first tick so consider using spawners if it really matters to you.

Your other report of the black particles with showparticles off seems like a legitimate bug though you should check that it does that with creepers that aren't summoned with such a short fuse. Even if the original creature was summoned without particles visible its explosion areEffectCloud should still have normal-colored particles.

Oh I didn't think of that. Well thanks guys!

thanks, that isn't as easy to use as name=unknown, but I'm happy to know there is an actual workaround for other languages. I thought I was stuck there! Thanks skyliner.

Note: I haven't been using the direct names for items much but I did note it worked (for english players at least). The main thing I found it useful for was for command blocks targeting modded entities. I found several modded mobs for which I couldn't get a type argument to work (maybe they didn't assign a unique one?) but for which their extended name did, such as entity.imp.name. This same issue means if players load many mods with my map the workaround you described above doesn't work anymore since bobbers are no longer the only excluded entity. However, in that case it is an unfortunate incompatibility. The grappling hook is the only device I've had so many issues with with mods and language settings so it may just be dropped in the future...

Oh really? I had heard a rumor this was a bug and that all games, even SP servers would be running english in the background and only change what was displayed as it was displayed. I did not realize the language wasn't implemented this way and thought it was a new bug.

That is a real shame. Just some clarification on what you said there about bobbers. So if I select ALL entity types except something like players, they will be missed because they have no "type" id? I know if I have no type argument they are tagged too because I tried that. They show up on the testfor list as "unknown" in english.

I would love to hear from Mojang if this is really not worth fixing as it seems uneccessary to do it that way. One last example of the usefulness of the name tag:

little known to most creators you can also use it to manually select a specific TYPE of item in one command. The main way I've seen most people detect items is to use a scoreboard searching if a particular id type in the datag and then tagging it. Then they operate on items with that type of tag. However, I have learned you can just search for the extended default name in a single selector and find it immediately without use of scoreboards. It is the name it displays back to you from testfor: item.X.X.

I disagree. The purpose of barrier blocks is to make an invisible barrier, ceiling, etc. Torches and other things can't be placed on them so snow shouldn't be either. At the very least snowfall should not accumulate on them as if a custom map uses them in a snowy area it looks incredibly weird to see snow layers accumulating on what appears to be air.

I have also stumbled upon this bug while creating a custom map. It would be nice if this could be fixed as you can't currently tell without it with command blocks if the player used a name tag. And there are a lot of useful features that could be added if this was possible. For instance, the ability to keep custom mob combinations intact if one of the stack is named. Also to recognize if a player named entities and how many in a puzzle game using the mechanic. As it is I'm going to have to create a custom item for a player to toss or hold to indicate they renamed an entity which is a pain. Or just replace name tags with my own custom items.

It relates but I wouldn't say duplicates. As drinkable saturation potions worked in 1.10. I could not find a thread about this particular issue appearing in 1.11. I've edited my original description for clarity. Thanks for your attention

Never mind. This was a product of the fact that I was setting the Age of the clouds back to zero when they were near their carrier so they would remain persistant only until it died. Apparently AreaEffectClouds will not apply effects when their age is zero regardless of other data. I put the age reset on a once a second cycle and the effects applied perfectly at ages above 1. So it's just a built-in cooldown I think after creation.

Issue resolved--at least for my purposes. I assume this is intended behavior?

yes I opened a seperate ticket and uploaded the crash report. This is still the first snapshot of the new AI changes so I won't discuss it much here but here's the link if you're curious: MC-93655

this is the crash report from where I made a blaze shoot a fireball that hit a pigman. The game immediately crashed. This also happens, but less reliably, with Ghast fireballs.

The nature of this bug has changed in the latest snapshot. I just ran tests after seeing that it was a major mob AI update.

the results:

When hit by skeleton arrows pigmen now properly target and kill the skeleton in question. But afterward they still went after me and killed me too since they were still angry. Seems they still default to aggroing on the player if the anger tag is still nonzero but only after the primary target has been eliminated. Is this intended?

Ghasts/Blazes they did not seem to get angry at all which is nice. Hit multiple times with fireballs and no reaction. they used to target the player after getting struck. But, strangely enough shortly after getting hit by the projectiles from them the game crashed. This happened repeatably many times. It think it is because the pigman is targeting the projectile instead of the ghast/blaze and the game crashes when the projectile disappears. In the error log the crash happened because of a null pointer in a fireball. I'm not sure what that means. Let me know if you want more details.

I will Sun, did not realize that. thank you

I have something to add about this bug. I designed a difficult survival nether-based map and many players complained about the severity of this bug on hard difficulty. Also you no longer have to kill the mob for them to target you. They now appear to target the player immediately when hit by any projectile.

I ran some tests and found the following:

• Pigmen immediately aggro on a player if their Anger tag becomes nonzero. This is why if any mob hits them other then the player they target the player immediately. It appears to be the closest player at the time. If you wish to quickly replicate the bug just type this command with pigmen close by: /entitydata @e[type=PigZombie] {Anger:500}

• The reason this happens is the HurtBy:"" tag no longer appears to work. The pigmen do not understand the new 1.8 UUID system for entities and I've only seen the player UUID in this spot, never that of the mob that launched the projectile.

• On hard difficulty this is especially annoying due to pigman density. Pigmen never seem to be able to become unangry in 1.8. I ran some tests and found that this is because when the anger on one pigman falls to zero it is seen as a recruitable pigman again and the hostile pigman make it angry again. the result is if more then a few pigmen are angry at you it no longer wears off like it used to in 1.7 they are literally angry forever.

• You also can't really run away, especially on hard, because you can't get far enough away before the anger is passed to newly spawning pigmen.

• The ONLY way I found to reliably fix it on hard mode survival is to force a despawn with distance. aka have a bridge out over a large lava lake where you can get far enough from all of them to force despawn before anger is passed to new pigman groups or to get above the bedrock into the void. However, this is way too much trouble to be a practical way to end this nightmare. Killing them also will not work as they have a recruit and follow distance greater than the 24 blocks and so in many situations will never stop spawning new angry pigmen. this is especially true as the angry pigmen below you in closed caverns will not come and will continue to anger new groups.

I have a quick fix suggestion for this bug that I'm begging you to implement as this bug is extremely annoying for any player spending a small amount of time in the nether: Please, code it so that the pigmen's anger tag does not become nonzero if they are hurt by a projectile not fired by the player. My tests show as long as the anger tag does not change the pigmen will no longer aggro at the player when struck by projectiles of other mobs. this should be fairly easy to do as skeleton arrows, blaze fireballs, and ghast shots are coded differently then player-fired projectiles. This is my suggestion to fix the issue in the meantime until you can fix the targeting bug and make them fight other nether mobs again. For my map I provide a custom item to deal with the pigmen when the bug occurs. ( A book with imbedded command) but I'd prefer to see it fixed in the main game. This bug is discouraging players from spending a lot of time in the nether at present.

Come on Mojang! Fix this issue already! This really messes up player's saves when it happens.

You know why this happens right? It is because minecraft has a real-time autosaving feature. It's saving all the time. If anything interferes or interrupts that process in midsave then you get a corrupted chunk from saving. But there is a solution to real-time saving errors! It's the same solution as the one for handling noise corruption in cell phone transmissions, namely: REDUNDANCY. When you try to save over a perfectly good old save for a chunk DON'T overwrite it directly. Instead back up the working old save for that chunk. Hold onto these backups for about 5 minutes backwards. Then, if the game detects a missing/relocated/corrupt chunk replace it with the most recent backup and inform the player a chunk error has been detected and it was restored from a backup. This is the smart way to do it. It would mean that you don't need to back up your whole game, just carry backups for a few minutes in the past and only for the chunks that have been recently updated. This wouldn't even up file-sizes much. When you log out and close the game permanently only carry the latest backup so the game can run a check for errors when you log back in and restore if it detects this problem. Since you usually only have made changes to a few chunks in the minute before you logged out this would not increase file-sizes nearly as much as even a single backup of the whole save. They back up level.dat so they really should do the same for recently updated chunks.

Hey guys,

the bug is ongoing and is worse in multiplayer (though happens some in singleplayer) due to the more complex terrain loading states.

However, you can get around it and prevent escaping animals AND suffocation death with some clever pen construction. I will share with you my workaround for the bug and the reason why I haven't griped about this bug in 2 years:

First, I did a test a while back in beta, the problem is less commmon now, but back then I'd lose all my animals. Even doubling walls, etc. did not work. So I finally decided there was no way to pen them efficiently with walls/fences above ground.

Step 1: dig your pens into the ground. I make all of mine 2 deep and inset into the ground like a shallow bowl. This keeps any animal from escaping because over the 1-2 seconds even if they wander through the walls there is no unoccupied blocks so the code snaps them back into the pen as the closest safe area.

Step: Dig out the bottom wall edge of all around the dug out pen and replace it with glass. This does 2 things: 1 it prevents animals pushed into walls by a crowded pen from suffocating as glass is non-opaque and they can breathe in it. It also allows them to move back out later when they can. 2 for sheep it is a nearby source of grass they can't eat and therefore they can't defoliate their entire pen so you can keep colored herds more compact.

I've been building these pens for the past 2 years and no animal has escaped or died since. I'd recommend spacing dugout pens 2-3 blocks this ensures they won't mix via the glitch.