Spigot & BungeeCord 1.17 & 1.17.1

Discussion in 'News and Announcements' started by md_5, Jun 11, 2021.

  1. You can, I was just showing this as the "External Library"
    I'm just not sure why its not working for you, I've not really used Gradle much, mostly maven.
     
  2. I'll play around with it more when I get some time later. Thanks for the information! I am only slightly familiar with Gradle and not at all familiar with Maven, so I'm finding all of this very confusing.

    Perhaps @md_5 can offer some direction?

    Also, I have one other question: since we are only supposed to use the deobfuscated version for development, does that mean that when it's time for a release, we'll have to go through our code and manually change everything to use the obfuscated variation?
     
  3. That is not correct. Dinnerbone himself says otherwise: "You may use the names in mods, you may reference them in source code and compiled code, you just can't redistribute the mapping file verbatim."
    https://twitter.com/Dinnerbone/status/1294314025807945729

    Plugins are considered mods, so you may use the names in plugins.
     
    • Like Like x 1
  4. While this is true, in the case of Spigot, you have to compile back to the obfuscated names so your plugin will run on Spigot.

    You dont have to manually do it yourself, md_5 added a tool to automate the process.
    For maven, you can just add a build profile (or plugin I think) which will do this when you build/package the resource.
    For Gradle I think you need to run the tool manually. See #2 of this thread, all the info should be there.
     
  5. While the question is, why doesn't Spigot use the deobfuscated names then...(anymore) ...?
    And users that don't use any of those? You can use Eclipse without the need for maven or gradle!
     
  6. from what I gather, md_5 didn't/doesn't fully understand the copyright around the mappings, therefor decided not to use them.
    I'm not totally sure on his decisions but if you go back a few pages you can see his convo about it.
    Based on his responses, others responses, the copyright on the mappings, and dinnerbone's explanation of it ... theres a lot of confusion around the mappings and who/how they can be used.

    see #2 of this thread, theres a tool you can manually use on your built jar to re-obfuscate it
     
  7. I think, as long as it's not 100% safe to use the deobfuscated mappings, he will keep it the way it is now...
    Yes, maybe i'll try that one, too.
    Atm i don't need to, as i'm fine with the obfuscated version in my code...
     
  8. Sorry for the beginner question here, but I haven't updated our server (1.16.1) at all yet (not even to 1.16.2). What does md_5 mean by using --forceUpgrade option? Is that meant to update to the latest 1.16.x version so the jump to 1.17 is easier?

    Could someone give me a line or two of code for updating? It's much appreciated.
     
  9. Microsoft/Mojang has released the mappings under three different licenses. The original license was quite restrictive ("You may copy and use this information for your internal, reference purposes."), but the current license is more permissive ("You may copy and use the mappings for development purposes, but you may not redistribute the mappings complete and unmodified."). So if someone was unaware of the changes to the license, they may draw the wrong conclusions.
     
  10. --forceUpgrade upgrades the region files to format used by whatever version you're running. So:
    1. Shutdown and backup your server.
    2. Put in the 1.17 Spigot .jar file.
    3. Put --forceUpgrade at the END of whatever command line you use to start your server.
    4. Start the server and wait for the upgrade to complete. It may take a few hours (yes, hours).
    5. When it's done, stop your server and remove the --forceUpgrade.
    6. Start your server and enjoy playing on 1.17.
    Remember, there is no way to go backwards in versions!!
     

  11. You rock. I appreciate you! Should I bother updating to 1.16.5 first?
     
  12. It's probably not necessary. I would suggest creating a test server because you'll probably have to update plugins.

    MAKE A BACKUP FIRST!
     
  13. Will do!
     
  14. Has anyone figured out how to configure Gradle for this?
     
  15. Shaggy67

    Benefactor

    An additional point of confusion is that apparently Mojang doesn't agree with what the current license says either. Some people are basing their conclusions on "unofficial" posts by Mojang employees regarding what their intent was. That's "probably" fine, but twitter posts are not legal statements. From a purely legal/strict perspective, the only thing you can go on is the license itself. md_5 is being cautious and going by what the license says.

    It's highly doubtful that Mojang would attempt to sue someone over something that they said was OK on Twitter, but is not technically OK in the license. However, would Microsoft?
     
  16. Shaggy67

    Benefactor

    I would, that should make things a lot easier in the future. I've been working on removing as much NMS dependencies as I can. It only helps make things simpler moving forward.
     
  17. Don't forget about eraseCache with that forceupgrade.
     
  18. Maximvdw

    Benefactor

    There was this company that once said on Twitter that Windows 10 would be the last windows ever. We all know how that turned out.
     
    • Funny Funny x 1
  19. For someone who is maintaining a codebase that they did not initially develop (as in, me), and does not have extensive knowledge of when it is and is not appropriate to use NMS, do you have any advice?
     
  20. Don't use NMS if there is API that can do what you need. If there isn't, open an issue/pull request and try to get the required API. If what you're trying to do does not have an API equivalent and is not suited for inclusion into the API, only then use NMS.
     
    • Agree Agree x 1