I am not sure how to update my plugin after the NMS changes that occurred recently, could use help.

Discussion in 'Plugin Development' started by zombies601, Dec 12, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    zombies601

    I am having a lot of trouble updating my plugin "StormAnnounce" with the NMS changes, please if anyone could help me it would be greatly appreciated, just send me a PM, thanks!
     
  2. Offline

    Cammy_the_block

    You might wanna say what isn't working and post your code.
     
  3. Offline

    Ne0nx3r0

    A lot of people are in the same boat; just give it some time. Bukkit staff probably wont make a recommended/beta build without providing good information on how to update, and even if they do, someone will come along and provide something to clean up their mess.

    For now I'd recommend just keeping your plugin up to date with the revisions before the NMS madness.
     
  4. Offline

    fireblast709

    afaik (besides the obfuscation changes) the only change is that the version is behind it (something like net.minecraft_1_4_5.server, could not find the posts/commits instantly)
     
  5. Offline

    Ne0nx3r0

    I think he's referring to that if you were to update your NMS plugins to the dev build imports now, then it would break users who use the recommended Bukkit build, and vice versa.

    I'm not sure how you would support both with one jar.
     
  6. Offline

    Tirelessly

    You can simply reimport everything... Right click the package, source, organize imports.
     
  7. Offline

    Ne0nx3r0

    You're saying someone using the recommended build will still be able to use the current recommended build after you setup the new imports and compile again?
     
  8. Offline

    Tirelessly

    Right, that might be a problem. Not sure.
     
  9. Offline

    NinjaW0lf

    look at tagAPI or nocheatplus dev builds.
     
  10. NoCheatPlus uses Maven though, and it is not fun to set up the source code editing (i am using a cheap trick currently), it just works for compiling with our jenkins. With a few adaptions it will work "nicely" i assume, but i am completely new to maven.

    Shortly before i used a similar layout to the nested sub projects without maven, just with jar exporting (jardesc) in eclipse for a quick adaption. But instead of the nested structure i was using top level eclipse projects for each of them, referencing the needed ones. The NCPCompat and NCPPlugin parts had the bukkit api as dependency, the MCAccessCB... had the cb versions as dependencies. So i could use jar export saving the jardesc to the NCPPlugin project, i just have to select exporting the other projects parts too. Saving the jardesc made the export simple. Drawback is having multiple projects and that it does not run under maven directly (mind jenkins), advantage is clear separation of dependencies and not too much tech fuzz for starters.

    Another alternative is to put all in one project and add multiple cb versions as depencies, keeping a separate design for the access API implementations. That of course may be confusing after some time and not a very clean way for debugging etc.
    ....
    Edit: The backwards compatibility is not really better than before, Bukkit API also changes and one would have to start adding wrappers for that too after some time. For time critical stuff this will hardly be a good option. Not sure how much Minecraft will change in contrast to the Bukkit API, but one should not expect to have an easier go than before for backwards compatibility. Main point is to put the access for version specific API into some module to be used with that version.
     
    MyPictures likes this.
  11. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

Thread Status:
Not open for further replies.

Share This Page