You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importnet.minecraft.server.level.EntityPlayer;
publicabstractclassPlayerOpSender1_19_common ... {
...
// ServerPlayer has become EntityPlayerprotectedabstractstaticclassServerPlayerOpWrapperextendsEntityPlayer {
...
}
...
}
PlayerOpSender1_19.java:
publicclassPlayerOpSender1_19extendsPlayerOpSender1_19_common ... {
...
protectedstaticclassServerPlayerOpWrapperextendsPlayerOpSender1_19_common.ServerPlayerOpWrapper{
...
// CommandSourceStack is now CommandListenerWrapper// createCommandSourceStack should have become cU@OverridepublicCommandListenerWrappercreateCommandSourceStack() {
returnOpSender1_19_common.modifyStack(super.createCommandSourceStack(), source);
}
}
}
PlayerOpSender1_19_1.java:
publicclassPlayerOpSender1_19_1extendsPlayerOpSender1_19_common ... {
...
protectedstaticclassServerPlayerOpWrapperextendsPlayerOpSender1_19_common.ServerPlayerOpWrapper{
...
// CommandSourceStack is now CommandListenerWrapper// createCommandSourceStack should have become cT@OverridepublicCommandListenerWrappercreateCommandSourceStack() {
returnOpSender1_19_common.modifyStack(super.createCommandSourceStack(), source);
}
}
}
I've set up special source to map PlayerOpSender1_19 with 1.19 mappings and PlayerOpSender1_19_1 with 1.19.1 mappings.
However, the method overrides for createCommandSourceStack aren't being mapped correctly. In 1.19 it should become cU, while in 1.19.1 is should become cT. Parts of the file are being remapped, such as CommandSourceStack becoming CommmandListenerWrapper, but the method override is not changing.
It seems that the way the classes are inherited is preventing special source from realizing it needs to change these methods. It might also have something to do with the way the classes are split up across maven modules.
The text was updated successfully, but these errors were encountered:
willkroboth
changed the title
Method override is not being remapped for sub-subclass
Method override is not being remapped for sub-subclass in different module
Aug 13, 2022
willkroboth
changed the title
Method override is not being remapped for sub-subclass in different module
Method override is not being remapped for subclasses in different modules
Aug 13, 2022
I figured this out on my side by shading 1_19-common into 1_19 and 1_19_1. This seems to help special source realize that ServerPlayerOpWrapper extends ServerPlayer and it remaps the method override.
I'll leave this issue open for now because it seems that there is a problem where special source is not considering dependencies when finding classes and methods to remap. Doing it the shading way I found requires quite a bit of hacky finagling that really shouldn't happen.
Special source wasn't remapping createCommandSourceStack() in ServerPlayerOpWrapper because it didn't know it extended ServerPlayer (See SpecialSource#83). This was fixed by shading 1_19-common into 1_19 and 1_19_1.
Maven was then complaining about 1_19-common and 1_19-common-mojang-mapped classes being included multiple times, so that was fixed by filtering them out of the shaded version of nms-dependency.
I have some classes set up like this:
Before mapping:
Module 1_19-common
pom.xml:
PlayerOpSender1_19_common.java:
Module 1_19
pom.xml:
PlayerOpSender1_19.java:
Module 1_19_1
pom.xml:
PlayerOpSender1_19_1.java:
After mapping:
PlayerOpSender1_19_common.java:
PlayerOpSender1_19.java:
PlayerOpSender1_19_1.java:
I've set up special source to map
PlayerOpSender1_19
with 1.19 mappings andPlayerOpSender1_19_1
with 1.19.1 mappings.However, the method overrides for
createCommandSourceStack
aren't being mapped correctly. In 1.19 it should become cU, while in 1.19.1 is should become cT. Parts of the file are being remapped, such as CommandSourceStack becoming CommmandListenerWrapper, but the method override is not changing.It seems that the way the classes are inherited is preventing special source from realizing it needs to change these methods. It might also have something to do with the way the classes are split up across maven modules.
The text was updated successfully, but these errors were encountered: