MC-65532Armor stand with invisible tag cannot be hit
When summoning ArmorStand with the Invisible tag, it can't be hit
Command used:
/summon ArmorStand ~ ~ ~
Linked Issues
Created Issue:
Armor stand with invisible tag cannot be hit
When summoning ArmorStand with the Invisible tag, it can't be hit
{Invisible:1}
Command used:
/summon ArmorStand ~ ~ ~
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
duplicates
is duplicated by
Duplicate of MC-65532
Dupe of MC-65532.
Dupe of MC-65532.
Like a lot of Mojang's decisions, there is absolutely no use for this one. They have a tag specifically for preventing damage, and then they ignore it. And they only ignore it for the one entity, other entities can be damaged perfectly well while invisible. This sort of decision making is what makes me worried about Minecraft's future.
By the way mods, this is a dupe of MC-65532. Although since Searge commented on this report, maybe it should be the main one.
confirmed
Still present in 14w32d. It should also be noted that not even players in creative mode can destroy it.
Can confirm in 1.8pre1
Still in 1.8. When shot at, arrows bounce off them without affecting them.
WAI per Searge from
MC-66068:And why? I mean I can still interact with them by rightclick, that makes no sense!
Confirmed for
Even if it is intended, because of
MC-66068it is probably then not intended, that they still "block" blockplacing and destroyingInvisible and No Gravity on a Server. Ruined my Modern House.
The 3D items trick works well, except I can't place my floor back... On a Server too.
This is a serious bug for me. I really want to see this fixed now.
@ Connor Dabron : 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 };]
@ 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...
Connor Dabron 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:
[ ~ LOGINNAME ]
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 ^^
Have a nice Sunday and fun playing Minecraft.
Meri
Meri Diana 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 >
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.
Connor Dabron 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
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.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.
voforan 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.
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.
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!
[Mojang] Searge (Michael Stoyke) 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 ofMC-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.[Mod] Torabi 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 voforan would be to make a suggestion.