WooHoo! Craftbukkit 1.5 (alpha) is available! Speaking of lots of stuff for the runecraft devs to do, y'all can now start working on the 1.5 compatible version of runecraft.
Speaking of which, it IS possible to use the official bukkit API to determine what the names of the minecraft internals are, and automatically be forward-compatible. This is, of course in precise opposition to the reason the devs introduced this "feature" to begin with, and would get you resented by the bukkit devs.
Maybe if you made it a optional feature, that automatically gets turned off when bukkit/minecraft gets upgraded, and must be manually enabled each time?
Anyway, some virtualization to get around this "feature" is obviously needed, if only to make it so we can use latest runecraft stuff with older server versions. More importantly though I want to try out the new features (hoppers especially) but can't. My players are putting on the pressure, and I can understand it, because requiring versions to move in lockstep is frustrating.
I won't upgrade minecraft until bukkit upgrades, and I won't upgrade bukkit until runecraft upgrades. I humbly, if impatiently, await your response...
Got to be honest, I'm at peace with this feature at this point. I know why they did it, I understand the motivations behind it, and I would rather spend effort adjusting RC so that it doesn't interact with this feature at all, rather than circumnavigating their protection mechanism. (I have a rather lengthy post earlier in the thread concerning this protection mechanism. Long story short: the mechanism is to clear out a ton of bukkit support requests that are plugin problems in the short term, and to do the same to Mojang support in the long term when the mod API comes out.)
If you dislike the lockstep of certain plugins, instead of advocating for bypassing the security mech. (which, yes, will get the bukkit dev's annoyed at us) I would ask those developers to look into removing any references to NMS and CB if at all possible. In most cases, a reference into either is completely unnecessary at worst, and simply more complicated to do via only the bukkit interface, not impossible. Removing these references from RC is actually on my todo list of things to fix if possible, as this would make that version of RC compatible with all bukkit builds, rather than locked to the current version.
Got to be honest, I'm at peace with this feature at this point. I know why they did it, I understand the motivations behind it, and I would rather spend effort adjusting RC so that it doesn't interact with this feature at all, rather than circumnavigating their protection mechanism. (I have a rather lengthy post earlier in the thread concerning this protection mechanism. Long story short: the mechanism is to clear out a ton of bukkit support requests that are plugin problems in the short term, and to do the same to Mojang support in the long term when the mod API comes out.)
If you dislike the lockstep of certain plugins, instead of advocating for bypassing the security mech. (which, yes, will get the bukkit dev's annoyed at us) I would ask those developers to look into removing any references to NMS and CB if at all possible. In most cases, a reference into either is completely unnecessary at worst, and simply more complicated to do via only the bukkit interface, not impossible. Removing these references from RC is actually on my todo list of things to fix if possible, as this would make that version of RC compatible with all bukkit builds, rather than locked to the current version.
Oh one of the developers is on! Could you perhaps direct me to the proper permission node for the personal teleporter?
Oh one of the developers is on! Could you perhaps direct me to the proper permission node for the personal teleporter?
Sadly, I can't be much more help than Merii. I haven't quite untangled exactly how our permissions nodes are setup (other than I know the name is derived from that list Merii linked you too, so try a few variations on that) and I definitely don't know exactly how it will behave if you use permissions nodes and disabled_runes.txt, so no promises there. Ctri may know more, but I don't think either of us wrote the current permissions setup, so neither of us are immediately familiar
Edit: OKAY, I have good news! I know why everyone is failing when I tell them how to do permissions!
So. Right now our permissions nodes do *not* remove spaces. So, the correct node for personal teleport should be, at least according to our code...
runecraft.runes.personal teleporter
Please let us know if this format is invalid. It will be pretty trivial to adjust it to remove spaces, and then it will work as I kept telling everyone it would work
Note to self, learn how to use permissions so I can test some of this myself...
I'm confused as to why permissions are an issue at all.
Couldn't the permissions plugin just collect a list of permissions nodes that are checked, as they are checked, and make that list available to the server admin?
Seems like it would be extremely straightforward to do, simple to implement, and horribly useful. So why isn't it done already?
If it where, it would be immediately apparent when code is inconsistent with which nodes have to be activated for what. Like the whole "runecraft removes the spaces sometimes, but leaves them in at other times" thing.
I'm confused as to why permissions are an issue at all.
Couldn't the permissions plugin just collect a list of permissions nodes that are checked, as they are checked, and make that list available to the server admin?
Seems like it would be extremely straightforward to do, simple to implement, and horribly useful. So why isn't it done already?
If it where, it would be immediately apparent when code is inconsistent with which nodes have to be activated for what. Like the whole "runecraft removes the spaces sometimes, but leaves them in at other times" thing.
I'm not sure the permission systems really have a way to tell, unless we tell them. That being the problem. We have so many permissions nodes that we only register a handful of the simplest default ones with the permissions manager, which makes it pretty much impossible for them to figure out what permissions we use. This will probably be something I attempt to fix when I take a pass through the permissions system.
I'm not sure the permission systems really have a way to tell, unless we tell them. That being the problem. We have so many permissions nodes that we only register a handful of the simplest default ones with the permissions manager, which makes it pretty much impossible for them to figure out what permissions we use. This will probably be something I attempt to fix when I take a pass through the permissions system.
There must be SOME method that plugins use to ask "does player X have permission to Y?" I think it's something like
Not being familiar enough with java, I'm unable to locate in percisely. If I understand how things work, it should be possible to write a generic plugin to intercept these sorts of checks or tests, and generate a text file listing all the permissions that were tested for by any plugin, while passing the actual call through to the original permissions plugin. And thus we'd have a list of permissions, which would make all sorts of things simpler to administer.
Point being that it should not (in theory) be neccessary to "register" permissions, or to do a proper .yml listing, or anything special or deliberate in the way of documentation at all. The mere fact that for a permission to actually DO anything it MUST be checked against should be sufficient. I.E. Let the actual code itself tell us what it needs. Of course, if a plugin friviously checks permissions then there will be meaningless permissions in our list. But that's a obvious bug in the plugin, I'd say. And if no player actually TRIED to do it, the plugin wouldn't check it, and we'd be missing things from our lists. But it'd still be light-years better than what we have now, and obviously if a player complains that they don't have permissions to do X then at least that one would be gaurenteed to be on the list, and we'd just have to hope that the name is descriptive enough for us poor abused admins to figure out which one to grant.
Not being familiar enough with java, I'm unable to locate in percisely. If I understand how things work, it should be possible to write a generic plugin to intercept these sorts of checks or tests, and generate a text file listing all the permissions that were tested for by any plugin, while passing the actual call through to the original permissions plugin. And thus we'd have a list of permissions, which would make all sorts of things simpler to administer.
Point being that it should not (in theory) be neccessary to "register" permissions, or to do a proper .yml listing, or anything special or deliberate in the way of documentation at all. The mere fact that for a permission to actually DO anything it MUST be checked against should be sufficient. I.E. Let the actual code itself tell us what it needs. Of course, if a plugin friviously checks permissions then there will be meaningless permissions in our list. But that's a obvious bug in the plugin, I'd say. And if no player actually TRIED to do it, the plugin wouldn't check it, and we'd be missing things from our lists. But it'd still be light-years better than what we have now, and obviously if a player complains that they don't have permissions to do X then at least that one would be gaurenteed to be on the list, and we'd just have to hope that the name is descriptive enough for us poor abused admins to figure out which one to grant.
No no, here's the thing. We, the plugin, can tell what permissions a player has at any time. We just ask the permissions manager about it. However, this does not work the other way. Unless we tell the permissions manager what permissions we're using (via the plugin.yml, or an in-code registration of nodes) it has no way of knowing what permissions we care about, so it's up to the admin to figure out what permissions we're going to check for.
This is something I plan to take a pass at later to fix. Part of the problem is that if we listed all the permissions nodes we check exactly, our plugin.yml file would be well over 10 times as long XD
(there is at least one and in most cases 2 permissions nodes for every rune)
No no, here's the thing. We, the plugin, can tell what permissions a player has at any time. We just ask the permissions manager about it. However, this does not work the other way. Unless we tell the permissions manager what permissions we're using (via the plugin.yml, or an in-code registration of nodes) it has no way of knowing what permissions we care about, so it's up to the admin to figure out what permissions we're going to check for.
This is something I plan to take a pass at later to fix. Part of the problem is that if we listed all the permissions nodes we check exactly, our plugin.yml file would be well over 10 times as long XD
(there is at least one and in most cases 2 permissions nodes for every rune)
Yeah it would be huge. But if you've looked at any other plugin.yml you'll see that many of them have large plugin.yml files. Specifically chestshop. Good god there plugin.yml is long.
Der_Niabs, I think you've missed my point? Either that or I fundamentally misunderstand things.
We, being random plugin #37, ASK the permissions plugin, via the permisionHandler.has() method, "Does user X have permission Y?" And based on that we either do nothing or create some effect.
Since we're asking the permissions plugin, THAT plugin knows that we asked about permission Y, and could (in theory) make a note of it and compile some sort of statistical report "User X tried 27 times to user permission Y, mostly between midnight and 2AM, and was denied" But of course all we're interested in is "permission Y was checked" which means that: "granting (or denying) user X permission Y would have some sort of gameplay impact" Which is the actual piece of information that I, as a server admin, am interested in.
Specifically, derive a class that inherits from permissionsHandler, which mostly does nothing, allowing all calls except the "has" method to be handled by the parent class. In the "has" method, referance a global list of "checked permissions" and each time "has" is called, check the permissions list, add an entry if it's a new one, and then call the parent method.
Then make sure that all instances of permissionsHandler use your derived class instead of the original. (this is one of the bits that I have NO idea how to do...)
And when some server command is issued, dump the permissions list to a text file. Maybe also call the logger.getlogger.info() method each time a new permissions existance is noted.
Der_Niabs, I think you've missed my point? Either that or I fundamentally misunderstand things.
We, being random plugin #37, ASK the permissions plugin, via the permisionHandler.has() method, "Does user X have permission Y?" And based on that we either do nothing or create some effect.
Since we're asking the permissions plugin, THAT plugin knows that we asked about permission Y, and could (in theory) make a note of it and compile some sort of statistical report "User X tried 27 times to user permission Y, mostly between midnight and 2AM, and was denied" But of course all we're interested in is "permission Y was checked" which means that: "granting (or denying) user X permission Y would have some sort of gameplay impact" Which is the actual piece of information that I, as a server admin, am interested in.
Specifically, derive a class that inherits from permissionsHandler, which mostly does nothing, allowing all calls except the "has" method to be handled by the parent class. In the "has" method, referance a global list of "checked permissions" and each time "has" is called, check the permissions list, add an entry if it's a new one, and then call the parent method.
Then make sure that all instances of permissionsHandler use your derived class instead of the original. (this is one of the bits that I have NO idea how to do...)
And when some server command is issued, dump the permissions list to a text file. Maybe also call the logger.getlogger.info() method each time a new permissions existance is noted.
It's not possible with the current permissions system that most servers use. You can't intercept permissions checks without writing it into the permissions plugin itself or making all the other plugins shake hands with a permissions checker, eg: vault or register.
You can't intercept permissions checks without writing it into the permissions plugin itself or making all the other plugins shake hands with a permissions checker, eg: vault or register.
Yah, just looked over the code for "permissionsBukkit" and it looks like it can't be done without modifying craftbukkit. Looks like the actual method that needs to be overridden is "org.bukkit.entity.Player.hasPermission(<str node>)" and I'm not sure how to do that, as it would require replacing the player object with our own derived class. Probably have to mess with bukkit internals? I don't know.
<hours of research later>
I'm done with this, unfortuneately. I know it CAN be done, and I've gotten to the point where I'm certain it can be done as a plugin (probably a modified PermissionsBukkit). But I don't know enough about the source code, how it's organized, etc. to figure it out in a reasonable amount of time. I also HATE java - it's a stupid language for lots of reasons and I don't like having to work with it. Permissions aren't that big of an issue on my server, so I don't itch enough to scratch this one.
I still think it's worth doing, it's just not worth it to me.
Riv is correct. In fact, there are lots of things you can do on our dev bukkit page, like post bug reports, suggestions, etc. As well, we have a build of RC for 1.5, along with several new features for you to explore, if you can find the pattern. It's marked as beta, as there are still several outstanding bugs (bow's broke. Again.) but the code is overall stable.
Hm... I wonder if hoppers store direction information the same way furnaces and dispensers do...
I get a "java.lang.NoClassDefFoundError: net/minecraft/server/v1_5_R1/World" error. Obviously because I'm running the wrong version of craftbukkit. However, there is no obvious way for me to discover what the right version IS.
Craftbukkit (apparently) doesn't always accurately reflect the version reported internally by dev builds on their downloads page, so even though I KNOW that it's a wrong version, and the right version is "1.5-R01" there isn't any way for me to find a dev build that reports that version internally.
So which specific artifact (version, essentially) of craftbukkit should I download? Or where do I find that information?
Hrm.. Well, the version of runecraft was uploaded on the 17th. So... I'll try the fifteenth. OK, that worked. Artifact #2646 didn't get that error (though it does complain about an invalid plugin.yml) Checking compass....Compass accepted! Huston, we have liftoff!
I have a really dumb issue that I just don't get. I have been using Runecraft for about 2 years (was my server's first bukkit plugin) and now with 2.17 it simply says 'Invalid plugin.yml'. I deleted the whole runecraft folder from the plugins, expecting runecraft to recreate it on restart - no, same error. I assume it is referring to the config.yml in runecraft folder... I have seen something about the pugin.yml in ref to permissions, nothing about this in the startup of the server. The following is what the console generates...
18:13:08 [SEVERE] Could not load 'plugins\runecraft.jar' in folder 'plugins'
org.bukkit.plugin.InvalidDescriptionException: Invalid plugin.yml
at org.bukkit.plugin.java.JavaPluginLoader.getPluginDescription(JavaPlug
inLoader.java:255)
at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager
.java:132)
at org.bukkit.craftbukkit.v1_5_R2.CraftServer.loadPlugins(CraftServer.ja
va:239)
at org.bukkit.craftbukkit.v1_5_R2.CraftServer.<init>(CraftServer.java:21
7)
at net.minecraft.server.v1_5_R2.PlayerList.<init>(PlayerList.java:55)
at net.minecraft.server.v1_5_R2.DedicatedPlayerList.<init>(SourceFile:11
)
at net.minecraft.server.v1_5_R2.DedicatedServer.init(DedicatedServer.jav
a:105)
at net.minecraft.server.v1_5_R2.MinecraftServer.run(MinecraftServer.java
:379)
at net.minecraft.server.v1_5_R2.ThreadServerApplication.run(SourceFile:5
73)
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at org.bukkit.plugin.java.JavaPluginLoader.getPluginDescription(JavaPlug
inLoader.java:243)
... 8 more
Pretty sure this is just something stupid on my behalf that I've missed but any advise would be appreciated. Thanks.
I believe my bukkit version is 2723 if that helps.
I have a really dumb issue that I just don't get. I have been using Runecraft for about 2 years (was my server's first bukkit plugin) and now with 2.17 it simply says 'Invalid plugin.yml'. I deleted the whole runecraft folder from the plugins, expecting runecraft to recreate it on restart - no, same error. I assume it is referring to the config.yml in runecraft folder... I have seen something about the pugin.yml in ref to permissions, nothing about this in the startup of the server.
Hmm... A question and a suggestion. The question: exactly which version of RC are you running? RC 2.17 is a semi-beta build, as we needed to get something out for 1.5, but everything isn't tested yet, so we have several versions of it available at the moment. Which build might affect what is wrong.
Buuut, it sounds like something has gone wrong with the RC jar itself. Try re-downloading it entirely from our dev bukkit page and let me know if it works. You might also want to update your bukkit build to the 1.5.1 beta at the same time, because why not
Speaking of which, it IS possible to use the official bukkit API to determine what the names of the minecraft internals are, and automatically be forward-compatible. This is, of course in precise opposition to the reason the devs introduced this "feature" to begin with, and would get you resented by the bukkit devs.
Maybe if you made it a optional feature, that automatically gets turned off when bukkit/minecraft gets upgraded, and must be manually enabled each time?
Anyway, some virtualization to get around this "feature" is obviously needed, if only to make it so we can use latest runecraft stuff with older server versions. More importantly though I want to try out the new features (hoppers especially) but can't. My players are putting on the pressure, and I can understand it, because requiring versions to move in lockstep is frustrating.
I won't upgrade minecraft until bukkit upgrades, and I won't upgrade bukkit until runecraft upgrades. I humbly, if impatiently, await your response...
If you dislike the lockstep of certain plugins, instead of advocating for bypassing the security mech. (which, yes, will get the bukkit dev's annoyed at us) I would ask those developers to look into removing any references to NMS and CB if at all possible. In most cases, a reference into either is completely unnecessary at worst, and simply more complicated to do via only the bukkit interface, not impossible. Removing these references from RC is actually on my todo list of things to fix if possible, as this would make that version of RC compatible with all bukkit builds, rather than locked to the current version.
Oh one of the developers is on! Could you perhaps direct me to the proper permission node for the personal teleporter?
Sadly, I can't be much more help than Merii. I haven't quite untangled exactly how our permissions nodes are setup (other than I know the name is derived from that list Merii linked you too, so try a few variations on that) and I definitely don't know exactly how it will behave if you use permissions nodes and disabled_runes.txt, so no promises there. Ctri may know more, but I don't think either of us wrote the current permissions setup, so neither of us are immediately familiar
Edit: OKAY, I have good news! I know why everyone is failing when I tell them how to do permissions!
So. Right now our permissions nodes do *not* remove spaces. So, the correct node for personal teleport should be, at least according to our code...
runecraft.runes.personal teleporter
Please let us know if this format is invalid. It will be pretty trivial to adjust it to remove spaces, and then it will work as I kept telling everyone it would work
Note to self, learn how to use permissions so I can test some of this myself...
Couldn't the permissions plugin just collect a list of permissions nodes that are checked, as they are checked, and make that list available to the server admin?
Seems like it would be extremely straightforward to do, simple to implement, and horribly useful. So why isn't it done already?
If it where, it would be immediately apparent when code is inconsistent with which nodes have to be activated for what. Like the whole "runecraft removes the spaces sometimes, but leaves them in at other times" thing.
I'm not sure the permission systems really have a way to tell, unless we tell them. That being the problem. We have so many permissions nodes that we only register a handful of the simplest default ones with the permissions manager, which makes it pretty much impossible for them to figure out what permissions we use. This will probably be something I attempt to fix when I take a pass through the permissions system.
There must be SOME method that plugins use to ask "does player X have permission to Y?" I think it's something like
com.nijikokun.bukkit.Permissions.PermissionHandler.has(...)
or maybe
this.getServer().getPluginManager().getPlugin("Permissions").getHandler.has(<player>,<str permission node>)
Not being familiar enough with java, I'm unable to locate in percisely. If I understand how things work, it should be possible to write a generic plugin to intercept these sorts of checks or tests, and generate a text file listing all the permissions that were tested for by any plugin, while passing the actual call through to the original permissions plugin. And thus we'd have a list of permissions, which would make all sorts of things simpler to administer.
Point being that it should not (in theory) be neccessary to "register" permissions, or to do a proper .yml listing, or anything special or deliberate in the way of documentation at all. The mere fact that for a permission to actually DO anything it MUST be checked against should be sufficient. I.E. Let the actual code itself tell us what it needs. Of course, if a plugin friviously checks permissions then there will be meaningless permissions in our list. But that's a obvious bug in the plugin, I'd say. And if no player actually TRIED to do it, the plugin wouldn't check it, and we'd be missing things from our lists. But it'd still be light-years better than what we have now, and obviously if a player complains that they don't have permissions to do X then at least that one would be gaurenteed to be on the list, and we'd just have to hope that the name is descriptive enough for us poor abused admins to figure out which one to grant.
No no, here's the thing. We, the plugin, can tell what permissions a player has at any time. We just ask the permissions manager about it. However, this does not work the other way. Unless we tell the permissions manager what permissions we're using (via the plugin.yml, or an in-code registration of nodes) it has no way of knowing what permissions we care about, so it's up to the admin to figure out what permissions we're going to check for.
This is something I plan to take a pass at later to fix. Part of the problem is that if we listed all the permissions nodes we check exactly, our plugin.yml file would be well over 10 times as long XD
(there is at least one and in most cases 2 permissions nodes for every rune)
Yeah it would be huge. But if you've looked at any other plugin.yml you'll see that many of them have large plugin.yml files. Specifically chestshop. Good god there plugin.yml is long.
We, being random plugin #37, ASK the permissions plugin, via the permisionHandler.has() method, "Does user X have permission Y?" And based on that we either do nothing or create some effect.
Since we're asking the permissions plugin, THAT plugin knows that we asked about permission Y, and could (in theory) make a note of it and compile some sort of statistical report "User X tried 27 times to user permission Y, mostly between midnight and 2AM, and was denied" But of course all we're interested in is "permission Y was checked" which means that: "granting (or denying) user X permission Y would have some sort of gameplay impact" Which is the actual piece of information that I, as a server admin, am interested in.
Specifically, derive a class that inherits from permissionsHandler, which mostly does nothing, allowing all calls except the "has" method to be handled by the parent class. In the "has" method, referance a global list of "checked permissions" and each time "has" is called, check the permissions list, add an entry if it's a new one, and then call the parent method.
Then make sure that all instances of permissionsHandler use your derived class instead of the original. (this is one of the bits that I have NO idea how to do...)
And when some server command is issued, dump the permissions list to a text file. Maybe also call the logger.getlogger.info() method each time a new permissions existance is noted.
It's not possible with the current permissions system that most servers use. You can't intercept permissions checks without writing it into the permissions plugin itself or making all the other plugins shake hands with a permissions checker, eg: vault or register.
Yah, just looked over the code for "permissionsBukkit" and it looks like it can't be done without modifying craftbukkit. Looks like the actual method that needs to be overridden is "org.bukkit.entity.Player.hasPermission(<str node>)" and I'm not sure how to do that, as it would require replacing the player object with our own derived class. Probably have to mess with bukkit internals? I don't know.
<hours of research later>
I'm done with this, unfortuneately. I know it CAN be done, and I've gotten to the point where I'm certain it can be done as a plugin (probably a modified PermissionsBukkit). But I don't know enough about the source code, how it's organized, etc. to figure it out in a reasonable amount of time. I also HATE java - it's a stupid language for lots of reasons and I don't like having to work with it. Permissions aren't that big of an issue on my server, so I don't itch enough to scratch this one.
I still think it's worth doing, it's just not worth it to me.
I do not know when it will be updated but I will talk to Ctri about it tonight, but for now here is where you can get it for 1.5:
http://dev.bukkit.org/server-mods/runecraft/
Enjoy and have fun!
-Rivkiin Shadows
May The Arcane Shadows Guide You.
Hm... I wonder if hoppers store direction information the same way furnaces and dispensers do...
I get a "java.lang.NoClassDefFoundError: net/minecraft/server/v1_5_R1/World" error. Obviously because I'm running the wrong version of craftbukkit. However, there is no obvious way for me to discover what the right version IS.
Craftbukkit (apparently) doesn't always accurately reflect the version reported internally by dev builds on their downloads page, so even though I KNOW that it's a wrong version, and the right version is "1.5-R01" there isn't any way for me to find a dev build that reports that version internally.
So which specific artifact (version, essentially) of craftbukkit should I download? Or where do I find that information?
Hrm.. Well, the version of runecraft was uploaded on the 17th. So... I'll try the fifteenth. OK, that worked. Artifact #2646 didn't get that error (though it does complain about an invalid plugin.yml) Checking compass....Compass accepted! Huston, we have liftoff!
Ok, I figured it out.
18:13:08 [SEVERE] Could not load 'plugins\runecraft.jar' in folder 'plugins'
org.bukkit.plugin.InvalidDescriptionException: Invalid plugin.yml
at org.bukkit.plugin.java.JavaPluginLoader.getPluginDescription(JavaPlug
inLoader.java:255)
at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager
.java:132)
at org.bukkit.craftbukkit.v1_5_R2.CraftServer.loadPlugins(CraftServer.ja
va:239)
at org.bukkit.craftbukkit.v1_5_R2.CraftServer.<init>(CraftServer.java:21
7)
at net.minecraft.server.v1_5_R2.PlayerList.<init>(PlayerList.java:55)
at net.minecraft.server.v1_5_R2.DedicatedPlayerList.<init>(SourceFile:11
)
at net.minecraft.server.v1_5_R2.DedicatedServer.init(DedicatedServer.jav
a:105)
at net.minecraft.server.v1_5_R2.MinecraftServer.run(MinecraftServer.java
:379)
at net.minecraft.server.v1_5_R2.ThreadServerApplication.run(SourceFile:5
73)
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at org.bukkit.plugin.java.JavaPluginLoader.getPluginDescription(JavaPlug
inLoader.java:243)
... 8 more
Pretty sure this is just something stupid on my behalf that I've missed but any advise would be appreciated. Thanks.
I believe my bukkit version is 2723 if that helps.
mc.maroochycraft.net
Hmm... A question and a suggestion. The question: exactly which version of RC are you running? RC 2.17 is a semi-beta build, as we needed to get something out for 1.5, but everything isn't tested yet, so we have several versions of it available at the moment. Which build might affect what is wrong.
Buuut, it sounds like something has gone wrong with the RC jar itself. Try re-downloading it entirely from our dev bukkit page and let me know if it works. You might also want to update your bukkit build to the 1.5.1 beta at the same time, because why not