1.13 particle enums problem

Discussion in 'Spigot Plugin Development' started by Nort721, Sep 16, 2018.

  1. so, I have decided to make an update to my plugin so it will work with 1.13 since all the sound enums have been changed (for no reason) so after updating all the sound enums I saw that the particle enums also have changed since I am using the cloud particle on my plugin so I have checked in a few websites for the new enums
    link: https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Particle.html
    you can see there that the cloud enum is still called could but when I run the plugin I get errors because of the enum, so I decided to swap the library to the 1.13 library to try and find the actual name but I found nothing that has the word cloud in the name or something that sounds like a cloud effect. can someone help me with that or tell me what's going on?
    how can I use the cloud particle in 1.13 maybe there is another way that i don't know about?
    also if a spigot staff see this can you tell us why do you change the sound enums all the time what benefit does it gives now if I want my plugin to work with 1.8 - .13 I need to do tons of if statements just to play one sound :(
    Code (Text):

                        if (p.isFlying()) {
                            if (version.contains("1.13"))
                                p.spigot().playEffect(p.getLocation().add(0, -0.6, 0), Effect.valueOf("???"), 0, 0, 0f, 0f, 0f, 0.1f, 14,
                                p.spigot().playEffect(p.getLocation().add(0, -0.6, 0), Effect.CLOUD, 0, 0, 0f, 0f, 0f, 0.1f, 14,
  2. Firestar311


    The issue is most likely from the fact that you have two different versions of Minecraft as dependencies in your IDE, From what I can tell, there is no Cloud effect in 1.13 or 1.13.1
  3. Firestar311


    Reflection won't actually help, as the field in that enum no longer exists, I have looked at the source code to find this information out (The one from BuildTools)
  4. I do not have two different versions on my IDE my plugin is made with the 1.8.8 build but my plugin will check what version is the server and make the enum changes
    stuff like that
    Code (Text):

    if (Bukkit.getVersion().contains("1.9")) {
         player.playSound(player.getEyeLocation(), Sound.valueOf("BLOCK_NOTE_PLING"), 1, 1);
    } else {
         player.playSound(player.getEyeLocation(), Sound.NOTE_PLING, 1, 1);
  5. How about your own enum?
    Cloud("1.8name", "1.12name", "1.13name")
    Than write your own send particle method and depending on the version do get1_13Particles or so and send them how each version wants it
  6. Firestar311


    Actually the playEffect method has been moved from spigot() to the actual interface.
    Code (Text):
    Instead of
    Code (Text):
  7. Firestar311


    Ah, there is the issue, the Cloud effect does not exist in 1.13, not sure if it exists above 1.8.8 even
  8. Fam there are a ton of more changed enums, and creating your own enum with the values from all versions will be the best and the easiest solution for anyone.
  9. wait so if they moved the method classes how can I make the plugin work for 1.8.8 - 1.12.2 which has the method of the spigot class and on 1.13 which has the method on the player class?
  10. cloud effect exist on 1.8.8 - 1.12.2 with
    p.spigot().playEffect(p.getLocation().add(0, -0.6, 0), Effect.CLOUD, 0, 0, 0f, 0f, 0f, 0.1f, 14,
    and in 1.13.1 its p.spawnParticle(Particle.CLOUD, p.getLocation().add(0, -0.6, 0), 0, 0, 0, 0);
  11. Particle and sound enigma change OFTEN, usually about every major update. With updates like 1.13 sooo much changed a lot of things broke and have to be done in very different ways. If you’re going to support ALL versions of Minecraft be prepared to write a lot of code over and over to do the same thing depending on the version.

    Sent from my iPhone using Tapatalk
  12. but I don't need only to import from different classes I need to use methods from different classes
  13. Not really, the only big change from 1.8 > higher are the sound enums and some particle enums, nothing more. 1.13 has a ton of new features and is basically an overhauled version of 1.12.
  14. Reflection is never your friend. It's an absolute last resort when everything else fails. In this case, any many others, there too many good alternatives to fall back to reflection (which is not only slower, it's also error prone)
  15. Reflection can be your friend Lol. It’s not a last resort. Reflection can be used for SO many things, and is super useful in general.
  16. well, guys, I am very confused, can someone show a code example so I can understand faster? because i really want to update this soon and i don't really got the time to get deep into this (not requesting to spoon feed just a code example of the idea)
  17. Choco

    Choco Previously 2008Choco
    Junior Mod

    No... darkseraphim is correct. Reflection should only be used as a last resort and the fact that developers rely on it to access NMS internals for "version-independent code" was the biggest mistake to be stumbled upon. This API is meant to dynamically access a class at runtime, but this is such an alien feature in programming languages. Java is one of the very few to include it. More mature languages such as C++ or C have opted to avoid such an API.

    An article from Oracle written in 1998 even states that it's meant to use for the sake of introspection rather than wherever you want.
    If you have a proper alternative (in such a case, interfaces and abstraction, a supported and encouraged feature of OOP languages such as Java), it should be used instead of a hacky functionality in the language. Do not use reflection. Use abstraction.
  18. Again, i said it could be your friend. And not a last resort. It is useful for many things, here among fancy annotations. Etc, just like how Aikar made ACF. That’s reflection magic.

    Sent from my iPhone using Tapatalk
  19. Choco

    Choco Previously 2008Choco
    Junior Mod

    That's because there's literally no other way to use annotations ._. You can use annotation processing, but that's more used to generate source files at compile-time. The only way to use annotations during runtime is with reflection. i.e. it's a last resort


Share This Page