Spigot & BungeeCord 1.17 & 1.17.1

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

  1. @md_5 Sorry to bother you, when you have an item you're placing in an inventory and you even ever so slightly move your mouse, it should trigger InventoryDragEvent right? Has this changed, I see it mentioned in the javadoc, but it doesn't seem to trigger the event in some situations.

    If you drag one item (it seems fine when it is 2 or more) in same slot then you have this bug(?), But if you drag it across multiple fields then its fine. At same time click event ignores this action as player did dragged item just not across multiple fields, it seems. This only a bug with single item in your hand while performing drag in same field, everything else seems to be fine

    I've asked around but so far the response from people that know more about this than me has been 'yeah, I do not know.. seems like that isnt working or something'.
     
    #161 mrfloris, Jun 12, 2021
    Last edited: Jun 12, 2021
  2. And: will the obfuscated names stay the same in new/next versions?
     
  3. md_5

    Administrator Developer

    I've fixed this but in future please open a bug report, it's much easier to track even if it doesn't end up being a bug.
    No, they're obfuscated.
     
  4. I was afraid I was simply doing things wrong and looking at the wrong stuff. I didn't feel comfortable filing 'false' bug reports. But in a way I am glad to hear this wasn't on me for once and actually a bug. I'll go for a bug report next time, thank you for the swift response md_5. I appreciate it.
     
  5. @md_5 Special Source fails at remapping certain method names for plugins. For example the

    PlayerConnection#send(Packet<?> packet)
    is remapped to
    PlayerConnection#a(Packet<?> packet)

    but is named in the server

    PlayerConnection#sendPacket(Packet<?> packet)

    I expect it to be named like the method of the server.
     
    #166 ysl3000, Jun 12, 2021
    Last edited: Jun 12, 2021
  6. Thank you for the swift update to 1.17. I was curious about the following "It is intended that this API be used for common and large non-Minecraft dependencies (...). Specialised libraries should continue to be shaded+relocated or packaged in a separate plugin." What is the reason that smaller, specialised libraries should continue shading and relocating manually, instead of using the new libraries section? Is it only because the smaller size doesn't put a strain on the final JAR size and including it directly makes it so the library does not need to be downloaded at startup? Or are there other reasons as well for not using this for specialised libraries?
     
  7. [21:38:20] [Server thread/ERROR]: Cause of unexpected exception was
    java.lang.IllegalStateException: Unhandled damage of EntitySpider['Spider'/797, l='ServerLevel[world]', x=3237.68, y=30.00, z=311.38] from stalagmite
     
  8. This pretty much killed my plugin API. I need to re-write the API. RIP.
     
  9. Having to use multiple modules to implement multiple versions increases complexity dramatically.
    The way it was done until now was having every supported version of NMS as a dependency. Then you could create classes using a specific version, that were instantiated based on the server. Of course this has the drawback of preventing static checks on the imports, but I think it is a fair trade-off to keep a way simpler project structure.

    While the Spigot API has been greatly improved over the years to cover most use cases, there're still valid reasons to use NMS, for example directly accessing packets and modifying vanilla behaviour of entities...
    The way around having multiple modules is using reflection, but reflection is generally slower than direct access.

    @md_5 Everyone working with NMS would greatly appreciate moving the classes inside net.minecraft inside a version package just like it was in older versions, to keep having multiple version compatibility. I fully understand and support your decision of keeping obfuscated fields, but the removal of the "versioned" packages really doesn't make much sense I think.
     
    • Like Like x 3
    • Agree Agree x 3
    • Optimistic Optimistic x 2
  10. Just use the bukkit.getServer().getClass() and get your version there. Craftbukkit is relocate to a versioned package.
     
    • Agree Agree x 2
  11. Sooo, anyone has gotten the mojang mappings to work yet?
    I used the remapped-mojang dependency and build the jar using the remapping maven plugin.

    Everything compiles just fine but upon running the plugin I get errors like `Caused by: java.lang.ClassNotFoundException: os`

    Seems like he can't resolve the obfuscated classes, so I am just wondering if I am doing something wrong here?
     
  12. Nope, didn't work for me as well. Using the provided commands as I'm not using maven anymore.
    Similar problem.
     
  13. Good to know I'm not alone :)
     
  14. I have a question: How often should I run BuildTools to get up-to-date spigot? And where to check if there any new builds?
     
  15. At this point, I would say at least once per day. You can check the following link. Most, but not all, changes will be listed here:
    https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits

    Right now it's the middle of the night in Sydney, Australia, so there probably won't be any changes for the next few hours.
     
  16. The only reason not to have a module per-revision is if you weren't using some sort of dependency management system. You can't use multiple versions of the same artifact with any sane build system for the very reason that you're complaining about. CB's versioned packaging just made it easier to be lazy and skip the maybe 5 additional minutes it takes to properly set up a project.
     
  17. There is basically no valid reason to remove the version from the package name.
    Of course we would have no problems with making it compatible with every coming version, but it increases our work unnecessary.
    Adding server version into NMS package is no effort and give us the best benefits.
     
    • Agree Agree x 3
  18. And a small question: When running BuildTools should I turn off my server? Or it can run in the background and then just restart?
     
  19. During this test period I've put my buildtools.sh script in front of the start script. So if there's a restart or i start the server, it just checks if there's a new buildtools and/or spigot and makes it, replaces the jar and continues starting it up.

    In live situations i wouldn't do this, but with the state of 1.17 right now, it's too early to say it's okay to run live.