Kavukamari

I want to confirm this for 1.20.2. I'm trying to make a tnt launcher that pushes tnt up with bubble column, and had to do a very weird workaround to make sure the tnt isn't touching the soul sand when it enters the bubble column, else it gets stuck inside the soul sand and destroys the machine

it seems to me that, as most other entities, TNT should be pushed up if it enters the bubble column, even if it's sliding along the ground, and I probably shouldn't have to do this workaround

(had to add a gap under where the tnt enters so it doesn't ever touch the soulsand)

I had to think a little bit about this one, but I understand the question now. I would assume an upward facing command block would have a position/rotation of ~ ~ ~ 0 -90 and a downwards facing command block to be ~ ~ ~ 0 90 so we assume it's "facing" south and looking upwards/downwards. ^x follows the old x axis, ^y follows the old z axis, and ^z follows forwards on the old y axis. similarly down is the same way but ^y and ^z are inverted because of the view angle

That is a good question though, and I can see why that might cause confusion for users on first encounter

and it definitely throws a wrench into the "non-directionality" of the idea. I guess I was only thinking about it in the case of using the forward vector (^z) so I didn't see that problem before

Confirmed for 1.8.2-pre1

just checked in both 1.8.1 and 1.8.2 pre 1 and they both still have this issue; tested with boats in particular, can also try with other entities if needed.

I have to agree with stephen here, I imagine the reason mojang wanted to make the mob tags only viewable when the player hovers over them is probably so you can't pseudo-wallhack and see monsters through walls

The problem with this is that for cases where map makers want the mobs to show their names anyway, they have to use workarounds like the one stephen outlined here which adds another entity for every named mob you want. This can get incredibly detrimental to framerate if someone wants a large number of named mobs, for instance in a large battle/warzone.

I think the tag CustomNameVisible should be changed so that it has three options, using "magic numbers" isn't usually a good idea in programming, so I've given alternatives to the numbers as a suggestion:

0 for invisible (this could be the default for if the game doesn't understand what somebody wrote in the tag)
Alternatives could be: no, hidden, never

1 For ALWAYS visible
Alternatives could be: yes, force, always

2 for visible on hover/look
Alternatives could be: hover, look

I imagine the numbers would still have to be programmed in to protect backwards compatibility, but I'm sure people are also used to updating their maps with updates of the game.

ah thanks for reminding me, I had thought it was merged to somebody else's and I couldn't modify that, but apparently I could

Still a problem in 1.8.1, just tested it.

Yes, it is still an issue in 1.8.1

the problem isn't that mojang chooses to make it work like this, it's more like it doesn't work as is first expected for someone who wants to use the feature. It's a consequence of the way mojang wrote the code that it does this, and it's considered broken when people are surprised by it. I'm sure if enough people comment and agree that it should be fixed, they could change their minds and fix the apparent problem.

If enough people agree that this is a bug, I think it makes sense for mojang to modify the way that mobs work so that their names work more reliably and congruently to the way the rest of the entities work.

I agree completely, BratrilliantGamer7, It seems to me like CustomNameVisible should override any other name rendering and force CustomName to be continuously visible instead of any other nametag behavior. Even in item frames, I think it should ignore the contained item name it has inside and force this behavior instead with CustomName, because I feel like CustomNameVisible should just be more important than the natural behavior of the entities since you have to explicitly set it by hand

Sorry to double-post, but I just tried it in 14w34d as well, and the render glitch still happens there too

Still present in 14w34d

Still an issue in 14w34d

it would be very convenient if this were to work as expected

I would assume team dynamics would automatically be applied to anything that happens to be on a team, isn't that the basis of how object oriented programming works? it's fairly unfortunate and unexpected that this isn't the case.

Confirmed in 14w33c as well, still broken

I'm noticing the same thing, it seems really unfortunate that CustomNameVisible works like this for both values. I'd greatly prefer if 0 worked like this, and 1 made it visible always as is expected of other entities as well

I hope that's not the case for the ItemFrames, because it would be useful if I could see the things I name my item frames.

As for the Minecarts, entities with custom names are already allowed to ride each other without problems with the Riding{} tag, so I don't see how that should interfere, but you might be right and maybe minecarts do work differently or something..

I don't think so, even after reloading, the name is still properly inside the NBT data, I think it's just something weird with how carts and frames work, maybe