Good NMS is here to stay?!

Discussion in 'Spigot Discussion' started by DMan16, Jul 2, 2021.

?

Will the NMS be consistent between versions from now on (or will Mojang pull a Mojang)?

  1. Yes

    1 vote(s)
    5.0%
  2. No

    3 vote(s)
    15.0%
  3. It's Mojang...

    10 vote(s)
    50.0%
  4. Don't talk to me or my son ever again

    6 vote(s)
    30.0%
Thread Status:
Not open for further replies.
  1. So I've been using Reflection for all my NMS needs for a long time, but I just checked out 1.17's NMS and there are no numbers anymore...
    Does this mean that from now on NMS classes will be consistent between versions?! (And if so, when is it coming for CraftBukkit?!)
    I GOTS TO KNOW!!!!
     
  2. if you're using reflection, it should not matter whether NMS has version/release number or not, right? unless you're hardcoding version/release number in your reflection invocations.
     
    • Agree Agree x 2
  3. Maybe the classes will be consistent, but all the methods, variables name etc. still change every version
     
    • Agree Agree x 1
  4. What do you mean by hardocing? The whole point of Reflection is to use the version name to get the class...
    What I meant is changing something like "net.minecraft.server.<version>.ItemStack" to "net.minecraft.world.item.ItemStack" (there's no longer any numbers so there's no need for Refelection...) - will this remain like this in future versions as well?

    Haven't seen any changes yet, but I see what you mean... I guess I should stick to Reflection for NMS after all...
     
  5. well, you're explicitly (hardcoded) using net.minecraft.server.<version>.ItemStack
     
  6. How else would I use Reflection on NMS?
     
  7. using reflection to auto-discover which package name style you would need to use for your reflection.. that's what I did in my plugins.
     
  8. Can you please give an example? I'm serious - I really want to know, it sounds like a better way.
     
  9. there are a number of ways to do it.

    *) a method that allows you to keep your current NMS class retrieval code,
    *) a method that requires the change of your current NMS class retrieval code but reflection code can be very short.
     
  10. But what about the new 1.17 NMS? Each class was put into a different package and sub-package and you'd have have to check each one or "hardcode" it - any solution to that?
     
  11. If you use the mojang mappings it'll likely stay consistent, but there could be some breaking changes as the game evolves.
     
  12. Any idea how I should use reflection on the new NMS? Each type was put into its own package and sub-package...
    I tried searching for ways how to get all sub-packages of a package (of the main package "net.minecarft"), but they all require accessing the file (especially the Reflections library) which I prefer to avoid - any ideas?
     
  13. My take on this is that you shouldn't use reflection when it's not necessary. It's much better to have compile time errors than runtime errors.
     
    • Agree Agree x 2
  14. Basically split all NMS uses to pre-1.17 and post-1.17...
    Oh well, at least post-1.17 plugins will have an easier time...
     
    • Agree Agree x 1
  15. Here is an example of how Im handling reflection across multiple versions in a plugin of mine
    (its a Skript addon, so just ignore the Skript methods)

    Code (Java):
        private static final String VERSION = Bukkit.getServer().getClass().getPackage().getName().replace(".", ",").split(",")[3] + ".";
        private static final boolean NEW_NMS = Skript.isRunningMinecraft(1, 17);

        public static Class<?> getOBCClass(String obcClassString) {
            String name = "org.bukkit.craftbukkit." + VERSION + obcClassString;
            try {
                return Class.forName(name);
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
                return null;
            }
        }

        public static Class<?> getNMSClass(String nmsClass, String nmsPackage) {
            try {
                if (NEW_NMS) {
                    return Class.forName(nmsPackage + "." + nmsClass);
                } else {
                    return Class.forName("net.minecraft.server." + VERSION + nmsClass);
                }
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
                return null;
            }
        }
    This method allows me to use the class name and the new NMS package.
    If its 1.17+ it uses the class with the new package, else it uses the old NMS packaging.

    Example usage:
    Code (Java):
        private static final Class<?> ICHAT_BASE_COMPONENT_CLASS = ReflectionUtils.getNMSClass("IChatBaseComponent", "net.minecraft.network.chat");
        private static final Class<?> NBT_BASE_CLASS = ReflectionUtils.getNMSClass("NBTBase", "net.minecraft.nbt");
     
    • Winner Winner x 3
    • Informative Informative x 1
  16. Yeah, that was my idea.
    No really other option if I wanna use pure Reflection...
     
    • Like Like x 1
  17. However, title , actionbar , particle , boss bar etc. can be created without nms
     
    • Optimistic Optimistic x 1
  18. OK... I knew that... Why specify? Never asked about them
     
    • Agree Agree x 1
  19. if you're handling invocation through static handling, I can show you 20 lines solutions without needing to worry about version differences. (join my discord)

    This is the 2nd option of my previous post.
     
Thread Status:
Not open for further replies.