Closed ChrisLane closed 8 years ago
Try this version. http://dev.bukkit.org/bukkit-plugins/mcore/files/42-massive-core-2-7-4/ The newest versions are for 1.9.
I shouldn't need to. I am currently on 2.8.10 which works correctly with Thermos and is a 1.9 listed version. MassiveCraft supports 1.7.10 even in its current builds which is why the latest version of the plugin works with vanilla CraftBukkit 1.7.10.
The problem is in Thermos I believe.
What about build 55?
Labeling external until can determine it is a thermos issue.
Same issue on build 55. Just a guess but could this be an issue with the reflection changes in MassiveCore and the remapping that's done by Thermos?
Why can't you just use the version you are currently on?
Well I can and I will continue to do so until this is fixed. I'm posting because clearly there's an issue somewhere and it should be fixed.
What you've said is a bit like saying to someone who wants a fancy new car not report an issue with the engine not working and to just stick with their crappy old car. :smile:
Well, I do not think this is a problem with Thermos, but is instead caused by a change in MassiveCore.
I'm all up for plugins working on everything - so please let me know how else I can help 😃
So there is no issue in 2.8.10, but in 2.8.11 it breaks? These releases are 10 days apart, so we can see whats changed by comparing this: https://github.com/MassiveCraft/MassiveCore/compare/2087b10c797dab367c7ddb498d4d85d2287df4f5...c87afdd957d7db2ef2bab7d12f88fc8d4d614be0
And in Spigot 1.7.10 the issue exists - but not in Thermos?
Line 188 is when when some nms is called - this is introduced in 2.8.11:
Class<?> classCraftItemStack = NmsItemStack.get().classCraftItemStack;
NmsAbstract has been used before and hasn't changed for a while. NmsItemStack#setup is called on the construct and is probably the cause of our issues.
Edit #1:
this.classNmsItemStack = PackageType.MINECRAFT_SERVER.getClass("ItemStack");
this.classCraftItemStack = PackageType.CRAFTBUKKIT_INVENTORY.getClass("CraftItemStack");
Roughly translates to:
this.classNmsItemStack = (Class) net.minecraft.server.SERVER_VERSION.ItemStack
this.classCraftItemStack = (Class) org.bukkit.craftbukkit.SERVER_VERSION.inventory.CraftItemStack
Perhaps SERVER_VERSION is being determined incorrectly for Thermos?
(still investigating for you, I'll update if I find anything else)
So there is no issue in 2.8.10, but in 2.8.11 it breaks?
Correct
And in Spigot 1.7.10 the issue exists - but not in Thermos?
The issue doesn't exist in Spigot but does exist in Thermos.
Thanks for looking into this!
I'm attempting to spin up a Thermos instance now and try replicate the issue myself (seeming to just hang, will see how I go) got it working
Edit 1: even when skipping the call in getMassiveCoreGsonBuilder
I get thrown with a java.lang.NoClassDefFoundError: org/bukkit/block/banner/Pattern
error. I guess banners were introduced in 1.8, so they should silently fail (aka move this into the try/catch above) -- but this doesn't happen in Spigot 1.7?
Try the new Factions and MassiveCore: http://dev.bukkit.org/bukkit-plugins/factions/files/89-2-8-14/
Same issue occurs with MassiveCore 2.8.14. Server log: http://paste2.org/0Jjd9Dxp
Just tested and confirmed that MassiveCore 2.8.19 also does not work, same error as the above comment.
This is unfortunately out of my scope! I'm really unsure as to why the error occurs.
Why does net.minecraft.server.v1_7_R4.ItemStack
not exist?
@MarkehMe it's probably remapped
@Robotia any idea where to find out where its been remapped to?
I believe the remap can be found in Forge/fml/ when you clone the Thermos repo and get its submodules, there should be a file called methods.csv and some others like that
I guess it would it be best to assume it was remapped to net.minecraft.item.ItemStack
?
Yes
Confirmed that net.minecraft.item.ItemStack is what the class is remapped to. Done a temporary fix here: https://github.com/ChrisLane/MassiveCore/commit/1dcae6782b1b9ba39f0ae627ba70da671ca78d34
@Robotia I've never done any work with remapping classes myself and I'm sure it's been considered but is it not possible to pass the chosen (forge) class through the original class so that these issues don't occur?
By the original class, do you mean Vanilla Minecraft? I thought about transforming for the packet protocol reflection issue, but it would require a huge amount of time, considering how many packets there are :confused:
By original class I meant bukkit classes that are remapped.
On 15 Aug 2016, at 14:48, Sameer Puri notifications@github.com<mailto:notifications@github.com> wrote:
By the original class, do you mean Vanilla Minecraft? I thought about transforming for the packet protocol reflection issue, but it would require a huge amount of time, considering how many packets there are 😕
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/CyberdyneCC/Thermos/issues/353#issuecomment-239908246, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA4doxmq86hg1-dcahCFsk38O2FnVLcOks5qgMKUgaJpZM4IdFxp.
Server Log: http://pastebin.com/q86AuDhG
FML Log(s): http://pastebin.com/kPsAksQE
Explanation of issue: MassiveCore fails to load on startup and produces the error seen in the server log.
This error occurs in MassiveCore 2.8.11 to 2.8.13 (latest at time of posting) The error does not occur with MassiveCore 2.8.10 or when using Spigot or Craftbukkit.
How to recreate this issue: Server startup
Plugins Installed: MassiveCore 2.8.11
Thermos Version: Build 56
Forge Version: 1.7.10-1614