[MC-65532] Armor stand with invisible tag cannot be hit

When summoning ArmorStand with the Invisible tag, it can't be hit
Command used:
/summon ArmorStand ~ ~ ~ {Invisible:1}

Linked issues

duplicates 1

MC-66068 Invisible armor stands cannot be hit Resolved

Attachments

Comments 22

Samuel Shank 2014-08-06T20:59:47Z

confirmed

Skylinerw 2014-08-11T09:06:25Z

Still present in 14w32d. It should also be noted that not even players in creative mode can destroy it.

Itouch2 2014-08-23T16:23:50Z

Can confirm in 1.8pre1

onnowhere 2014-09-23T00:45:39Z

Still in 1.8. When shot at, arrows bounce off them without affecting them.

Dlawso the Really Lucky Rabbit 2014-09-25T20:18:21Z

WAI per Searge from MC-66068:

Invisible armor stand can't be destroyed by hitting them.

12 more comments

marcono1234 2014-09-27T17:15:57Z

And why? I mean I can still interact with them by rightclick, that makes no sense!

Confirmed for

1.8
Even if it is intended, because of MC-66068 it is probably then not intended, that they still "block" blockplacing and destroying

Connor Dabron 2015-01-25T10:33:39Z

Invisible and No Gravity on a Server. Ruined my Modern House.

Connor Dabron 2015-01-25T10:36:52Z

The 3D items trick works well, except I can't place my floor back... On a Server too.

Connor Dabron 2015-01-25T10:39:47Z

This is a serious bug for me. I really want to see this fixed now.

Meri Diana 2015-01-25T10:46:44Z

@ @unknown : In case you can use commands there, just use /setblock to place your floor.
Stand directly where the invisible ArmorStand is, then:
/entitydata @e[type=ArmorStand,r=1] {Invisible:0b}

Depending on where the ArmorStand is, it can be you need to raise the radius to "2" instead of "1".

Then it will be visible and you can interact with it, e.g. also punch/destroy it.

Hope you'll get it fixed }=)

Kind regards,
Meri

PS: Sorry for re-editing, I wanted to firstly suggest to use the tag
Marker:1
that is available ever since 1.8.1, but looking at your pictures, I guess you want to have an Armor Display, so Marker:1 would make not only the ArmorStand itself invisible.

So every version starting with 1.8 works };]

Connor Dabron 2015-01-25T11:00:40Z

@ Meri Diana

You have just made my day!

Your comment was quick and kind and I was able to get rid of the stand right away. At first i thought that /setblock was a smart idea and then you gave me just what i was looking for! Thank you very much!

P.S. People like you deserve to be noticed. You went out of your way to make some stranger on the internet happy. You're awesome!

P.S.S. I don't know how to use the Reply feature, if there even is one...

Meri Diana 2015-01-25T11:09:13Z

@unknown You're very welcome, I'm always happy if people are happy in MC };]

For formatting here inside Mojira, look at:
Text Formatting Notation Help

In order to tag someone, hover over their name and see their real Loginname.
For me, you get displayed as "Connor Dabron", so I have to hover over your name to see what your Loginname is.. and that loginname I have to insert like this:
@unknown

without any blanks, but including the Tilde and the square brackets.

I use /setblock for whenever an ArmorStand is in my way, but I have to change a block close to it, so just keep that command in mind, too ^^

Again: I'm very happy you're happy, and thank you very much for thanking me, that made my own day, as I'm feeling quite down at the moment.. so.. thanks again!

Have a nice Sunday and fun playing Minecraft.

Meri

Connor Dabron 2015-01-25T11:34:47Z

@unknown I have hopefully attached an image to this/above this comment.

I actually found that I needed both of the commands, as once i had set the Armor Stand, it was blocking the slab bench. As you said in your last comment, the Armor Stand was in the way and i used the setblock command.

I started to get a bit worried when i couldn't find quartz_slab, but then got a glimpse of my F3 Hud and saw that it was a variation of stone slab.

I just want to say, I was extremely amazed at how fast you returned my comment. I would just like to finally thank you (unnecessarily) for you have just saved me hours of being annoyed and frustrated. Now I can relax and show off to my mates who aren't moderators >😃

Connor Dabron 2015-01-25T11:40:31Z

Just cutting in on this topic and correcting myself for previously calling this a bug. It is quite fair that they cannot be destroyed. However when something cannot be destroyed in Creative mode, you start to get a bit worried. That is all.

Meri Diana 2015-01-25T11:42:44Z

@unknown Again: Very welcome.
That invisible ArmorStands cannot be destroyed is "works as intended", it's really important and useful ^^

In my opinion the entitydata change possibility is too few known still in the community.
You can do awesome things with it, not only changing some tags, but also even making scrolling ticker text };]

Anyways, again: Have fun, and spread the commands, both of them! }=)
Meri

KingSupernova 2015-03-07T21:13:24Z

I think this should be reopened. On MC-66068, Searge said that this was so you couldn't destroy them by hitting them. But as it is, they are completely invincible, which doesn't make sense. I would like it if Mojang at least confirmed that this was supposed to happen, as it makes the "Invulnerable" tag redundant and is a real pain for mapmakers.

voforan 2020-07-07T14:14:22Z

This shouldn't be marked as resolved, it still exists and is a problem in 1.16.1 .

I could understand by default, if no Invulnerable tag is specified, the game automatically makes the invisible armor stand invulnerable. But if I go out of my way and apply the tag: Invulnerable:0b to an invisible armor stand, it shouldn't be invulnerable, since I'm manually specifying that I don't want it to be invulnerable.

Meri Diana 2020-07-07T15:43:49Z

@unknown Could you please elaborate why this poses an issue for you?

1) Does setting the Invisibility-tag back to true to see (and thus punch/destroy) Marker-false-AS not suffice?
2) Or is it Marker-true-AS where you want a change, that even Invisible-true-Marker-true-AS can be punched?
If 2), only Creative gamemode, or also Survival?

This bugpost here is a duplicate, but depending on what your exact issue is, is where people here could point you, be it Mojira Reddit, Suggestion Reddit, or, if it'd be a true issue for mapmakers, potentially then a new bugpost.

voforan 2020-07-07T17:11:33Z

1. Setting Invisible:1b automatically makes the AS invulnerable regardless of any other tag put on it, even Invulnerable:0b . It is immune to all damage, and creative & survival players can't damage them.

2. Invulnerable:0b should make the AS able to take damage.

Meri Diana 2020-07-07T19:47:54Z

As long as that AS has its Marker set to false, but is invisible, I agree that it should be hypothetically damageable, as this would be an easy way how mapmakers could use them to create e.g. some form of mob without the AS showing optically, or the need to somehow cover the exterior of the AS with models, or a retexture of the AS texture PNG (= using only Vanilla pack).

"Invisible" is used a lot in the code (various things depend on it), so there might be a good reason it behaves like that for AS, and it could also be that mapmakers rely on the as-is-behaviour, and changing this would break some of what they created.

If you can think of extremely good reasons to have Mojang touch that code, so they would consider revising it, then you could give it a shot and open a new bugpost. But no promises it won't be closed as WaI.

Imo it should not be closed at least as Invalid/suggestion, as it seems like an inconsistency, considering AS are entities (imo they should not be part of EntityLiving at all though), and you can also hit e.g. an invisible spider; however, AS have always been quite funky and special, and up to this day there might be a fair amount of mapmakers relying on them, in one way or another, so changing anything about them would imo have to outweigh by a lot the problems that change could in theory cause.

If you open a new bugpost for this, I'd emphasize on the apparent inconsistency with other invisible entities, and also make it clear it's solely about AS with Marker false, or else it might be closed rightaway as Invalid/suggestion, but I have no idea how the Mojira mods here will handle this case.
Good luck!

Torabi 2020-07-08T11:50:13Z

@unknown marked MC-66068, which this report is resolved as a duplicate of, as Works as Intended. Any new reports would also be resolved as duplicates of MC-66068. The bug tracker is simply not the correct avenue to convince Mojang to change this, and I would recommend pursuing other means of building support for such a change, such as the feedback site or the suggestions subreddit.

Meri Diana 2020-07-08T12:39:29Z

@unknown I can see where you're coming from, and usually I'd fully agree, but I learnt from an insightful comment-reply of yours here on the bugtracker years ago that not everything that gets resolved as "WaI" won't hypothetically ever be fixed - sometimes it can be that at that point in time it couldn't be fixed due to the state of the code for example, but that it could be revisited later, which is also what I've read from Devs. We all know that things can change in Minecraft over the years, and that "WaI" or "Won't Fix" is not set into stone, and if this change would benefit mapmakers, this should be taken into consideration, even more so considering this seems to be an inconsistency as I tried to explain in my previous comment, and Mojang seems to not be adverse towards fixing inconsistencies.

On the other hand, I can see how changing this could potentially affect other parts negatively, and thus I won't continue to argue 🙂

Just trying to explain a different perspective on this, and that others, who'd bump into this bugpost would not potentially be aggravated towards a decision Mojang or you Mojira-mods did, or at least can understand the reasons, why. Uncertainty and assumptions often lead to disappointment and sometimes even hate, toxic criticism, more or less hidden from public, which can accumulate, whereas knowledge, background intel, can hypothetically lead to an understanding and may lead to constructive criticism as well as input (e.g. on the suggestion website).

If you truly can't see hope for such a bugpost due to the aforementioned reasons (potential benefit, apparent inconsistency, changes of the code and potential new fixes over time), then, of course, the only way remaining for @unknown would be to make a suggestion.