java.lang.NoSuchMethodException: crazypants.enderio.base.EnderIO.checkModLists
flamechair opened this issue · 22 comments
Issue Description:
Note: If this bug occurs in a modpack, please report this to the modpack author. Otherwise, delete this line and add your description here. If you are using an unreleased version of Ender IO (e.g. for 1.8.9), please don't open an issue for features that have not been announced as "finished" or "working".
What happens:
Stack trace on server start:
https://gist.github.com/iamtpage/c16360d906b84d0af94203a9e50b74be
What you expected to happen:
No stack trace
Steps to reproduce:
- Boot up server
- Watch server log
...
Affected Versions (Do not use "latest"):
- EnderIO: EnderIO-1.12.2-5.0.29
- EnderCore: EnderCore-1.12.2-0.5.35
- Minecraft: 1.12.2
- Forge: 1.12.2 2705, and SpongeForge (spongeforge-1.12.2-2705-7.1.0-BETA-3260)
Your most recent log file where the issue was present:
https://gist.github.com/iamtpage/9f143d33af8faeccc6b0e407291d9244
Sounds like sponge forge to me. Try removing that first. Does this cause a crash or any errors in game?
84e786b
Might be why it just it started up in the latest version... but yeah... probably spongeforge
Issue is reproduced without Sponge.
SideOnly doesn't work with other registering annotation. Consider using ClientProxy instead.
can somebod shed a bit light on this? is he using EIO client side without being on the server? shouldn't this be blocked by the handshake? (even for different versions)
@HenryLoenwind we're talking about a server boot issue, before client can even try to connect.
Please elaborate how is that link with client/server synchronization?
What happens here is that we have code that runs on the client and prevents the "ender io is on the client but not the server" situation. However, that could should not run on the server (obviously...). But Forge sees that we have that code and complains that we don't run it on the server.
This is not a crash, this is a warning by Forge.
(Technical background: A "stack trace" is not a crash. It is just an address. Just the same like "Main Street 4489" is not the location of a fire, unless you call 911 and tell them so. But people who listen to 911-calls all the time may automatically assume so when they hear an address...)
oh wow, okay i missed that part with the warning right at the beginning, so this is not a crash, sorry to bother then, but i was boggled why it would crash even but it isn't just complaining :)
np. And if I sound a bit annoyed, then that's carried over from work. We just had a hotfix deployment with a window of acceptable downtime to deploy it of 6am to 8am...and someone put in a database script that ran for over 5 hours...
open doors my friend open doors ... wanna change jobs for a few days? it's just that some co-workers in a remote location change code in drivers without notifying others :D just because they needed a quick fix
We have to ways of fixing it:
- Make it so that Ender IO works in multiplayer if it's only installed on the client and not on the server
- Get the Forge people to see that solution 1 would be idiotic
ok, I remember now.
Could we remove the @SideOnly(Side.CLIENT) annotation and filter the content by the Side side parameter instead?
Yes, but the you would no longer get those nice "Ender IO needs XY at version Z or higher, you only have version F" messages but "Ender IO's network check handler failed".
As this has been linked in from the Forge ticket, here's an overview about how Forge works at the moment:
clientSideOnly --- The mod will not be loaded on dedicated servers, it's jar will be injected into the classpath instead.
serverSideOnly --- The mod will not be loaded on clients, it's jar will be injected into the classpath instead.
acceptableRemoteVersions -- If the mod is on a logical server, the server will check the connecting clients against this version range and display a nice error message if it doesn't fit. This key is ignored by the client.
@NetworkCheckHandler -- If it exists, the acceptableRemoteVersions key will be ignore. Instead this code is run on both server and client and if it returns false a cryptic error message will be displayed.
This gives us the following combinations:
- Client-only mod
- Server-only mod
- Client-only mod with optional server component
- Mod that shows cryptic error messages
What happens when EnderIO is on the client, but not on a modded server? a vanilla server?
@LemADEC Ideally it would give a nice error explaining that the server is missing EnderIO and that you cannot join it. In the current reality, it gives a generic "NetworkCheckHandler failed" message to users which is just poor error handling.
My understanding is that we've multiple issues here.
1- Forge doesn't provide a way for mods to mimic or extends the reported error message because they just have a boolean return value from the @NetworkCheckHandler. I'm not convinced we've a proper/clean/explicit tracking of this 'API' issue in Forge github. I'm also confused on what's preventing us to use a more 'classic' @SubscribeEvent here.
2- EnderIO is having (something bad?) happening when only client side has the mod installed.
I don't understand what 'bad thing' is happening here in the case of EnderIO.
Mod A is only installed on client, hence its blocks and entities are not available. The only GUI left would be tooltip, HUD and creative menu (?).
Mod B is installed on client and server. Mob A is interacting with its GUI? can we illustrate that with an precise example?
In general you can write a mod in a way that nothing bad happens when it's installed client-only. However, if you don't do that (and Ender IO never was written that way) there can be a thousand minor or major issues. I am not willing to go through the whole codebase to first figure out what code could be executed in that case and then find out if that code is client-only-safe.