Labels don't have an alternative for non-carpet clients
altrisi opened this issue · 5 comments
Makes some app's features quite useless without it, and also some look weird (mainly ai_tracker's villager things and box labels).
Probably blocks replacing /track
with ai_tracker
.
Idea: Named fake (packet only?) armorstands.
With the tags {CustomName:(name),CustomNameVisible:1,Invisible:1,Marker:1}
it makes them completely invisible to the player, floating, and with the label at their feet so it is (exactly?) at their coords. Those also have interaction disabled, so they don't obstruct the player click/right click actions.
CustomName
-> Specifies the name (label) of the armorstand. It is saved/retrieved in JSON, but AFAIK it's a Text
CustomNameVisible:1
-> Makes their nametag/label visible.
Invisible:1
-> Makes them invisible.
Marker:1
-> Auto-disables gravity, sets their label at their feet and prevents most interactions with them (there are a few bugs where if present in server could interact with some things, but not if only in the client).
Vanilla command to preview:
/summon armor_stand ~ ~ ~ {CustomName:'{"text":"I want to be in Carpet!"}',CustomNameVisible:1,Invisible:1,Marker:1b}
Scarpet script to preview:
spawn('armor_stand',pos(player()),'{CustomName:\'{"text":"I wanna be in Carpet!"}\',CustomNameVisible:1,Invisible:1,Marker:1b}')
/summon minecraft:area_effect_cloud ~ ~ ~ {Age:-10000000,Particle:"dust 0 0 0 0",CustomName:"\"233\"",CustomNameVisible:1b}
maybe using area_effect_cloud is a better solution? as they are invisible to even spectator mode player.
By the way, you may have noticed that the background biome boundary of this picture is straight. If you are interested, this is a carpet rule I wrote.
News on this: I currently have working per-player armorstands that don't (seem to) interact with the world and aren't saved.
Now I need to wrap them in some kind of handler to make sure they are removed/replaced correctly. And dispatch them so it's not like a shape per player.
Also things like follow
don't work
Edit: I've just seen it does interact with command selector. Not sure how bad is that.
problem is - with labels - its only visible to the provided player. Shapes in general can be sent to specific players, not to all. Use of particles as a replacement does exactly that.
Armorstand not only is an entity, floating text for all players (carpets would see double), and need to be cleared. That's what markers are for (via create_marker
).
Also - text can be rendered with appropriate offsets, layouts etc. For armorstands its just its nametag.
So the app dev may decide to use armorstand markers instead of labels, and that's perfectly fine (instead of labels).
I would say its fine as it is unless you have a better idea. I wish there were more practical particles (client shaped entities and sprites). Maybe just send 'somothing' to the players, like a single barrier particle, or the enchanting table letters, just to indicate they are missing out on something. Thoughts?
Yeah, I understand that, that's why I specified "fake (packet only)".
My idea would (probably) be a complex thing to do, and probably for long term if viable at all. It would basically consist in sending a "fake" (non-existing in the world) entity only to carpet-less players (via the magic of packets) that would therefore only be visible for those. It would probably need to be managed somehow by Carpet (not sure if you can create entities without assigning them a world, that would probably make it easier?) to allow things like moving (follow
) labels, removing them when expired, etc. They still wouldn't be as good as having the client (full customization) but just like particle lines, better than nothing.
I know it's possible to do that, but (may) be a pain (not tested, yet). Would probably require further investigation.
I definitely didn't mean spawning a regular armorstand into the world, that would be quite bad, not only in the visuals regard, but also in that they can interact with pressure plates and other components (MC-135809), breaking lots of things unwillingly.