Add Roll EnchantmentOffer API

[I-am-ddang]

No description provided.

[lynxplay]

Welcome to paper 🥳

It appears you commit / generate a whole slew of completely unrelated and invalid changes.
Please make sure to remove them so we can review your PR change.

[electronicboy]

I would suggest rebasing this PR or creating a new one

[I-am-ddang]

I would suggest rebasing this PR or creating a new one

I don't want to create a new one because this is my first PR and its number is 12345. I will look into rebasing the codes

[I-am-ddang]

wait. it is not done. I will inform it is ready for review when I end all of rebase procedure

[I-am-ddang]

I did it. I am now the master of rebase. I am ready for review.

[I-am-ddang]

@lynxplay @electronicboy
I'd glad for you to take a look whenever you are not busy guys. thanks for your patient.

[I-am-ddang]

wait I will reopen PR right now. it was accident

[I-am-ddang]

I am not sure if I do it right. waiting for review.

[dashiellbenton]

THIS IS PULL REQEUST #12345 AND I LOVE IT (soory this might be off topic but i had to say it)

[Strokkur424]

What I find a bit unfortunate is that changing the bonus power in the event basically makes any changes in the offers redundant, as you reroll these anyways.

I don't know if there is a particularly clean way to fix this. I personally can also only think of one way to fix this, but I understand it is not very advantageous:

• The introduction of a new RetrieveItemEnchantPowerEvent, which allows for setting the enchantment bonus before the offers are even put into consideration.

Therefore, the actual PrepareItemEnchantEvent could stay unmodified and enchantment offer modifications would still work as intended.

Of course, before you make this change, I'd like a Paper developer to confirm that this is an acceptable step to take, because I am not sure myself either.

[I-am-ddang]

I will fix the build error as soon as possible.

[I-am-ddang]

@Strokkur424 your idea is previous my idea.

when I discussed this feature at Paper discord's paper-dev channel, I suggest that structure but lynxplay adviced me that, in his opinion, making the event just set value is not good idea

(the discord dialog link that starts to discuss this feature with lynxplay: https://discord.com/channels/289587909051416579/555462289851940864/1347917294382219417)

So I should change original PrepareItemEnchantEvent. Yeah. I also think it would be good if offers method have more role. and I think "why doesn't it process the values of offers member field at constructor point with considering the bonus value is changed? it would be easy way to handle the logic when making an event." but that is not really feasible. because paper-api package can not import the code from paper-src. (I don't know the principle why it should be like it.)

Finally my decision is making bonus member field non final instead of making new event to set the bonus value and to include the other fields of PrepareItemEnchantEvent, checking the value and refreshing the enchantment hint after PrepareItemEnchantEvent calls. (it is now structure.)

[Strokkur424]

Well, we still need some way to modify the new enchantment suggestions, because this is a valid thing a plugin would do:

• Add 5 to the bookshelf bonus.
• Replace smite and band of arthropods with sharpness.

Not entirely sure how this can be achieved cleanly though.

[I-am-ddang]

@Strokkur424
You are right. refreshing enchantment is needed hint when replacing one of offers to other enchantment. Because paper-src codes can not be imported to paper-api, we should process the entire refreshing logic at paper-src/.../PrepareItemEnchantEvent.java (like logics of my PR)

[lynxplay]

I am sorry I haven't managed to read through this for so long.
The suggestion I made on discord was

Yea, I think there might be a point in adding API. Tho I don't think I'd like an API that says "just set that value" of bookshelves around.
The more powerful API on e.g. the EnchantmentView or whereever would be
Construct me an EnchantmentOFfer for this slot with this amount of bookshelves around

which I still believe to hold true.
Allowing a plugin to reroll specific offers and then setting them via Event#getOffers would enable doing all of this without the need for a second event.