Plugin idea, is it ok to make?

Discussion in 'Spigot Plugin Help' started by TeamBergerhealer, Aug 6, 2018.


Good idea, bad idea

  1. Good Idea!

    3 vote(s)
  2. Bad Idea!

    3 vote(s)
  3. I like Animaniacs too

    1 vote(s)
  1. TeamBergerhealer


    With the fuss about the new 1.13 Block data api, I have a dumb but obvious solution to all the quabbles: what if I write a plugin that packages the Spigot BlockData API with support for Minecraft 1.8 ... 1.12.2? People can ditch the outdated MaterialData API and use the (much better imho) BlockData API, avoiding magic values in their code altogether.

    BlockData has been inside the server since Minecraft 1.8.

    But is this ok to do? It would involve copying a lot of source code from the Spigot project, or in other ways, forking the Spigot project to build an additional artifact. Licensing and ethics. Plugins will likely have to depend on the plugin, because there is no BlockData getters for blocks and others on versions of Minecraft before 1.13.

    Option A: Add a plugin that injects new code into the server's ClassLoader, perhaps also modify CraftBlock/Block to introduce the missing API's it needs for BlockData.

    Option B: fork the server and add the BlockData api retroactively this way. Its cleaner, but also more difficult for the user because it would have to be done to all forks of the server as well.

    Option C: write a tool that patches a spigot or spigot fork jar file, inserting the missing API that way. One extra step for the user, but can be kept separate from BuildTools which is convenient.

  2. I understand that many people out there want to run their server on Spigot 1.8, and many plugins are now incompatible due to API changes. So it would be neat to have a backport of new features for some older Spigot versions. Undoubtedly, that would encourage plugin developers to adopt the new API and thus make their plugins compatible with all versions.

    Having said that, I have my doubts that backporting the BlockData API alone will get the job done. Among the more significant changes are the name changes in the Material enum, along with Sound and Biome. Unless you find a solution for that as well, the utility of this is rather minimal; old plugins still won't run on newer versions, and vice versa. I doubt that anyone will update an old plugin which is working perfectly well just to get rid of some magic values, unless there is that additional benefit.

    So, while I find the project in itself exciting, from a mere technical, problem-solving standpoint, I am not convinced that the effort of making it will ever pay off.
    #2 StarTux, Aug 6, 2018
    Last edited: Aug 6, 2018
  3. TeamBergerhealer


    Luckily plugins arent incompatible entirely, thanks to the hard work of spigot devs in writing a compatibility layer with old plugins. The problem is, though, that people are starting to depend on this layer also for new plugins. I'm one of them 50% of the way there. I've heard @md_5 mutter his annoyances with this before.

    It might be possible to do the same remapping in reverse for older versions of Spigot. I have to admit though, that that is an awful lot harder to accomplish.