-
-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup of enchantments #1687
Cleanup of enchantments #1687
Conversation
// Item Enchantment | ||
public static final DataQuery ENCHANTMENT_ID = of("Enchantment"); | ||
// Item EnchantmentType | ||
public static final DataQuery ENCHANTMENT_ID = of("EnchantmentType"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was done automatically by IntelliJ. Should I keep I revert this change to not cause compatibility issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyone have input here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
undo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do. 👍
@@ -25,7 +25,7 @@ | |||
package org.spongepowered.api.block.tileentity; | |||
|
|||
/** | |||
* Represents an Enchantment Table. | |||
* Represents an EnchantmentType Table. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is absolutely wrong.
@@ -114,7 +114,7 @@ | |||
*/ | |||
public static final Class<DyeableData> DYEABLE_DATA = DyeableData.class; | |||
/** | |||
* Signifies that an item has {@link Enchantment}s applied to it. | |||
* Signifies that an item has {@link EnchantmentType}s applied to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably should revert this one.
@@ -169,7 +169,7 @@ | |||
*/ | |||
public static final Class<SpawnableData> SPAWNABLE_DATA = SpawnableData.class; | |||
/** | |||
* Signifies that there are stored {@link Enchantment}s available on the | |||
* Signifies that there are stored {@link EnchantmentType}s available on the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same?
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN | ||
* THE SOFTWARE. | ||
*/ | ||
package org.spongepowered.api.data.meta; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should move the package of this class. It is not really a meta any more, since it has been converted into an interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you feel about moving Enchantment
, EnchantmentType
, and EnchantmentTypes
to a new enchantment
package inside of the effect
package?
* with a level. | ||
* | ||
* <p>The contract of enchantments is that their level will | ||
* never be below 1.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p>The contract of enchantments is that their level will
be in the range of {@code getType().getMinimumLevel()}
and {@code getType().getMinimumLevel()}.</p>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhh yes, it can be any natural number as long as the number can be stored in data.
Does this hurt items with empty enchantment tags? Those tags may give item stacks an effect while not having a valid enchantment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we only check when building if it is above 0 or below Short.MAX_VALUE. There are issues if the level is below 0 if I recall correctly but in reality it can be 0(I think?). I just changed it to 1 since I didn't see a reason why an enchantment would ever need to be 0 and Minecraft doesn't really expect it with all of theirs having a minimum level of 0. Do you think I should switch back to 0 or greater?
Also to your suggestion. I don't think that is a great idea as we return the vanilla max and min which are not necessarily as high as they could be set.
I'm heavily open to feedback relating to our lower limit and how to specify it.
* Increases damages to arthropod mobs. In vanilla this includes spiders, | ||
* cave spiders, silverfish, and endermites. | ||
* | ||
* <p>In vanilla the maximum level is 5.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At high level, the enchantment will slow down the arthropod hit for few seconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, never knew this.
// SORTFIELDS:ON | ||
|
||
/** | ||
* Increases underwater mining rate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should say it just increase the speed to the regular mining speed.
|
||
/** | ||
* Reduces all damage, outside of a few sources, such as the void, | ||
* the kill command, and hunger damage in vanilla. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably mention that it doesn't reduce damage that bypasses armor.
public static final EnchantmentType THORNS = DummyObjectProvider.createFor(EnchantmentType.class, "THORNS"); | ||
|
||
/** | ||
* RIncreases effective durability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove that R I guess
|
||
public static final TypeToken<ListValue<ItemEnchantment>> LIST_ITEM_ENCHANTMENT_VALUE_TOKEN = new TypeToken<ListValue<ItemEnchantment>>() {private static final long serialVersionUID = -1;}; | ||
public static final TypeToken<ListValue<Enchantment>> LIST_ITEM_ENCHANTMENT_VALUE_TOKEN = new TypeToken<ListValue<Enchantment>>() {private static final long serialVersionUID = -1;}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should rename these 2 fields.
Could we also use a custom ListValue and extra methods in the enchantment data manipulator to turn in some kind of mapped data? So you don't have to loop through all the enchantments to get the level, this could also be optimized internally. import org.spongepowered.api.data.value.mutable.ListValue;
import org.spongepowered.api.item.EnchantmentType;
import org.spongepowered.api.item.Enchantment;
import java.util.OptionalInt;
public interface EnchantmentListValue extends ListValue<Enchantment> {
OptionalInt getLevel(EnchantmentType enchantment);
void add(EnchantmentType enchantment, int level);
} |
No we can not @Cybermaxke :( Vanilla very occasionally will generate with multiple enchants of the same type on an item. |
What are people's opinions on the minimum enchantment value? Should we allow it to be 0 or above, or 1 and above to match vanilla's enchantments and to avoid possible issues. |
@Meronat We should probably allow only positive levels, no zero. The glowing effects some items have is from an empty enchantment tag list (so the list can exist and be empty, a different concept) so level 0 enchantments are useless |
These 4 PRs should be ready for more testing and review. 🥂 |
@Meronat are we exposing the 'natural maximum' enchantment level of each item anywhere? Is it even plausible? |
https://gaming.stackexchange.com/questions/262999/what-is-the-highest-effective-enchantment-level/263013#263013 States that some out of band negative values may have some effect. Not sure if we should handle them, or reject them outright. How do other parts of the API behave with out of band values? Also don't know if any mods do anything outrageous. |
* | ||
* @param level The desired level | ||
* @return The modified builder for chaining | ||
* @throws IllegalArgumentException If the level is below 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This contradicts the argument in the java doc for the class of Enchantment
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I'm somewhat concerned about mod compatibility here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There I said their level will always be larger than 0, which equates to the same thing as never below 1, but I can clean up the wording and add the max as well.
How do you propose I handle the concern? Should we simply allow them to use the full range of Short.MIN_VALUE
to Short.MAX_VALUE
, specifying that unintentional issues may arise if you go outside of EnchantmentType#getMinumumLevel
and EnchantmentType#getMaxmimumLevel
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we simply allow them to use the full range of Short.MIN_VALUE to Short.MAX_VALUE, specifying that unintentional issues may arise if you go outside of EnchantmentType#getMinumumLevel and EnchantmentType#getMaxmimumLevel?
I am going to have to say "yes" because we cannot 100% control the possibilities of enchantments. If developers choose to make unworkable enchantments, that's more on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will make this change and the necessary changes to the docs later tomorrow.
Edit: Sorry haven't had a chance to get around to this yet, will do soon!
Any final reviews on API or implementation? Changes work for me. |
662934f
to
9719f9f
Compare
9719f9f
to
a26b454
Compare
SpongeAPI | SpongeCommon | SpongeVanilla | SpongeForge
I will finish what I need to tomorrow, but for now looking for any feedback and also where I undoubtedly made mistakes as I haven't really tested much and some stuff was done automatically through IntelliJ refactoring and I may have missed mistakes.
Closes #1684