Employ fix for headless Armor Stand

[PikaMug]

What feature do you want to see added?

Redirected from GeyserMC/Hurricane#7 (edit: formerly known as GeyserHacks)

From the wiki:

The following things cannot be fixed without changes to Bedrock or the Java protocol in general...

    - Blocks (excluding jack-o-lantern) on entity heads (E.G. armor stands, players)

If the head of an Armor Stand uses an unsupported block, have Geyser display it as Carved Pumpkin on Bedrock clients instead of naught. Particularly useful for Spigot plugins such as GPS.

Are there any alternatives?

Some (but not all) plugins allow setting the block type, however this typically affects Java clients, as well.

[Konicai]

How exactly does this affect the GPS plugin?

[Kas-tle]

Assuming that you only need it to work with a specific block or set of blocks, you could easily accomplish this with a resource pack. Simply define an attachable with the same identifier as the block you wish to use. You can refer to the vanilla resources, specifically the helmet armor attachables. See https://aka.ms/resourcepacktemplate.

[PikaMug]

How exactly does this affect the GPS plugin?

GPS uses blocks on Armor Stands for its navigation arrows. Quartz Block is default, which causes it not to appear for Bedrock users. While it can be configured to use Carved Pumpkin instead, this is less desirable. Suggested feature would prevent confusion in the former and spare Java edition users in the latter.

Assuming that you only need it to work with a specific block or set of blocks, you could easily accomplish this with a resource pack. Simply define an attachable with the same identifier as the block you wish to use. You can refer to the vanilla resources, specifically the helmet armor attachables. See https://aka.ms/resourcepacktemplate.

That sounds like it could work in this instance, but there are numerous plugins which do not—or don't wish to—use a texture pack. My argument is that, when an Armor Stand has a block head, showing a Carved Pumpkin is better than showing nothing at all. Maybe not all will agree, hence why I first submitted to GeyserHacks.

[Kas-tle]

GeyserHacks is only applicable when server side changes are required, which is not the case here. We can tell the client whatever we want is in the slot.

I'm confused what you mean by "numerous plugins which do not, or do not wish to use a texture pack". What bearing does the will of the plugin developer have on this...? Any server owner can easily create such a resource pack. In my opinion, if server owners choose not to use the tools available to them for no good reason other than not wanting to, that's on them.

[Konicai]

We put together this pack with a single attachable that will render the quartz block. Its not perfect because the geometry hasn't been customized, so the texture looks a bit zoomed in. It should look fine for a GPS arrow though.
quartz_block.zip

Rendering any non-pumpkin block on heads as a pumpkin is kind of problematic because it could interfere with people wanting to actually render the block (like with the pack above). We could implement a config option, but I'm not sure what the decision regarding that is.

[PikaMug]

GeyserHacks is only applicable when server side changes are required, which is not the case here. We can tell the client whatever we want is in the slot.

Yes, I realize that now. What I meant to imply was that the reasoning behind submitting to GH was uncertainty that all Geyser users would appreciate the new behavior; it would preferably be optional.

I'm confused what you mean by "numerous plugins which do not, or do not wish to use a texture pack". What bearing does the will of the plugin developer have on this...? Any server owner can easily create such a resource pack. In my opinion, if server owners choose not to use the tools available to them for no good reason other than not wanting to, that's on them.

Plugin developers may insist that it's outside the scope of their project, or simply be unaware of Geyser's existence, this limitation, and/or the texture pack workaround. I concur the problem should ideally fall on server owners, then, but this request would save developers the headaches from those owners who merely see a broken/invisible plugin feature.

We put together this pack with a single attachable that will render the quartz block. Its not perfect because the geometry hasn't been customized, so the texture looks a bit zoomed in. It should look fine for a GPS arrow though. quartz_block.zip

Rendering any non-pumpkin block on heads as a pumpkin is kind of problematic because it could interfere with people wanting to actually render the block (like with the pack above). We could implement a config option, but I'm not sure what the decision regarding that is.

Thank you both for doing that. As mentioned, that only affects this particular instance/example. I agree that a config option seems essential. Given packs must be made for the task, it is my opinion that pumpkins would be the default behavior.

[BobtheBob123456]

Wait, couldn't you do this with ever block, like Jack o lanterns as well?

[Kas-tle]

Yes, but there are consequences in terms of pack loading times to do this so it will not be done for GeyserOptionalPack. If you need certain blocks to show you should make attachables for those blocks.

[PikaMug]

We could implement a config option, but I'm not sure what the decision regarding that is.

Just want to follow up and see if any decision has been reached on this matter? As a refresher, the config option would signify whether or not to display invalid blocks on entity heads as Carved Pumpkin.