Paper API Addition - Block Break Speed

[kohlerpop1]

Is your feature request related to a problem?

I would like a small addition to the paper API to be able to edit the breaking speed of a specific block/material in the server. I am using blocks which are retextured from mushroom blocks but I am unable to change the breaking speed of the mushrooms to match the material that is being broken.

Describe the solution you'd like.

I know that it is possible to do this with NMS so I was wondering if it would be possible to add it to the api to be able to access/change the values. I have looked into this and have found a few ways of doing it. I am currently using NMS but would like to see an addition to the Paper API if possible.
Here are a few references and code examples.
Example 1
Example 2
Example 3

Describe alternatives you've considered.

I have tried all of these and it currently is working it is just a pain for it to be using NMS and I believe would be a nice addition to the API.
I have also tried using spell effects to slow down there breaking speed but that just throws off interactions and gameplay.

Other

No response

[electronicboy]

afaik we've generally decided agianst this because it creates many desync issues between the server and the client in some cases, I'm still not sure if this is something we'd want to commit to with how unstable it is/can be

[kohlerpop1]

afaik we've generally decided agianst this because it creates many desync issues between the server and the client in some cases, I'm still not sure if this is something we'd want to commit to with how unstable it is/can be

What about it makes it so unstable? I feel like it would be simple and have almost no effect on performance. Even if it is not the most ideal, I would very much find it useful and I am sure others would too. Obviously most people wont use it but for those who already do it would just be one more reason to use paper!

[electronicboy]

Because you introduce a desync between what the server and the client thing is the strength of the block, which is used for determining how fast blocks break, etc; the server does send progress back to the client but when there is too much latency is can create many issues, at least in the past, with how blocks can break

[kohlerpop1]

I see. I understand it can lead to issues due to latency but generally speaking if we did not account for potential internet problems, then it would be a viable and useful solution. CraftBukkit NMS already contains this method.
public float getBreakSpeed(org.bukkit.entity.Player player) { /* compiled code */ }
I am believe there could be a simple method added of setBreakSpeed but idk if this is for all blocks or just this specific CraftBlock.

[electronicboy]

viable and useful so long as you don't consider real world usage of the API is basically what you're saying there, latency is expected when people play on servers, idk if the client has changed since then but at least in the past this was basically untenable to support realistically in the real world without just telling people to "deal with it" when it induces the issues we expect to occur in somewhat normal states

[kohlerpop1]

So would this be something we can add anyway and allow server owners and developers to choose if it is a viable/useful or if it is not usable. I am already doing it anyway via NMS and have had no issues which is why I believe it should be added to the API. Every single thing that is required to use NMS would be nice to be added to the API even if it is useless or unhelpful regardless. It can always be used by someone and someone will always find a use for something.

[electronicboy]

I mean, as said, we where generally against it in the past, we've not hard decided but at the very least the caveats would need to be documented, we don't wanna provide support for people fighting against the client, etc; I'm not hard against it but I don't wanna be adding API we can't exactly support

[kohlerpop1]

I see. Well would you mind representing myself and others who may use/need it and see if it is something yall can do? I mean worst case scenario I fork paper and add it in myself and compile but I was hoping it could be done for others as well. Like in the javadoc of the method/call, it could warn that using it can cause potential desync but just still having it provided would be sweet.

[kohlerpop1]

Also adding onto this, when blocks are sitting in the same block as an itemframe, the frame and block is rendered super dark.

The one on top is an itemframe with the block rendered by the frame, the one on bottom is a transparent block, aka pink stained glass.
Would it also be possible to add to the api to set the light level of the current block so it is not rendered as a dark black block?

[aerulion]

Also adding onto this, when blocks are sitting in the same block as an itemframe, the frame and block is rendered super dark.

The one on top is an itemframe with the block rendered by the frame, the one on bottom is a transparent block, aka pink stained glass.
Would it also be possible to add to the api to set the light level of the current block so it is not rendered as a dark black block?

You could simply use a glow item frame, although that would render the block always fullbright, but still better than completely dark I guess. But that problem seems a bit off-topic in this issue.

[Happily-Coding]

I also agree think it'd be a nice feature, as long as its correctly docummented.
ps: added this comment because i saw the status was input wanted, is that what it means?

[kohlerpop1]

I know I posted this a while ago but I still believe it would be a nice feature to have and be able to use. Countless people try and come up with many ways to do it super inefficiently. Even if it does cause desync, I believe having a standard way to do this in the API would be extremely helpful.

[kohlerpop1]

I spoke with lots of people and we eventually concluded this is not entirely possible. The best way is honestly in the links I provided above. I will close this as all the leaders (Kenny, Spottedleaf, Machine-Maker, etc) said this cannot and will not be added.