[SOLVED] [1.8.9] java.lang.ClassNotFoundException SideOnly Client Code

[Zetal]

I'm updating my 1.8 code to 1.8.9, and for some reason code that used to work is now giving a "ClassNotFoundException" for one of my GUI's. I register a clientside event handler within a SideOnly(Client) method, in the preInit event. The error is thrown within that eventhandler, so it's weirding me out a bit. I've dealt with the "ClassNotFoundException" error before, but it's always been fairly obvious what's going on behind the scenes, i.e. the server trying to access a clientside class or vice-versa, but in this case neither should be happening.

 

Would appreciate any pointers, thanks.

 

Update: To reiterate the issue, I'm receiving a NoClassDefFoundError for a clientside class, from the client side. It's definitely a client side class (it's a GuiContainer) and it's definitely on the client side, since it's gated within the client proxy, and the eventhandler contains many other clientside classes as well that do not throw this error.

[BusyBeever]

http://www.minecraftforge.net/forum/index.php/topic,22764.0.html

[Zetal]

That doesn't really help my issue, unfortunately, though I appreciate the effort. While that is useful information (that I didn't realize was standard), it doesn't really apply to my current issue.

 

@EventHandler
public void load(FMLInitializationEvent event)
{
    if (event.getSide() == Side.CLIENT)
    {
	MinecraftForge.EVENT_BUS.register(new SCMClientEventContainerClass());
            }
        }

 

As you can see, the code I'm trying to execute clientside is within the FMLInitializationEvent call, which has no way to refer to a world object. More importantly (and which I didn't even realize at the time) is that this doesn't reference SideOnly, and instead uses the event.getSide() method, which brings me back to the weirdness that is the class not being found despite definitely being clientside.

[Ernio]

If you'd post whole code (event class) and crash log. I'd be so happy.

[BusyBeever]

DONT use event.getSide.

If you want to do stuff and dont got an worldObj to check if you are on client on server side use a SidedProxy

[Zetal]

If you'd post whole code (event class) and crash log. I'd be so happy.

 

...You sure that's a good idea? I'm pretty much 100% sure you don't want the whole event class. This project isn't exactly pretty, and the event class in question is about 1600 lines long, mostly filled with pointless garbage that doesn't affect anything for this particular issue.

 

Anyways, I switched over to using a SidedProxy to call my method (which is now being called from within my SCMClientProxy, properly declared via

 

	
        @SidedProxy(clientSide = "bitevo.Zetal.LoMaS.Specializations.SCMClientProxy", serverSide = "bitevo.Zetal.LoMaS.Specializations.SCMCommonProxy")
public static SCMCommonProxy proxy = new SCMCommonProxy();

 

I have discovered that within my event handler, whenever this: "event.gui = new GuiSpecRepair(player.inventory, player.worldObj);" is not commented out, the crash occurs. Not strange on its own, but what /is/ strange is that other GUI classes that are also clientside only can remain uncommented within the exact same method, and the crash doesn't occur.

[BusyBeever]

thats not how sided proxys work.

[Zetal]

What do you mean? I've been using SidedProxy for several versions now- the code runs successfully, and is "sided" properly (since the server doesn't crash for rendering registration).

 

http://www.minecraftforge.net/wiki/Proxies

[Choonster]

There's no point in creating an instance yourself and assigning it to the field, FML will always overwrite it with an instance created from the

@SidedProxy

annotation.

[Zetal]

I have changed that for the sake of cleanliness, but the problem still remains. To reiterate the issue, I'm receiving a NoClassDefFoundError for a clientside class, from the client side. It's definitely a client side class (it's a GuiContainer) and it's definitely on the client side, since it's gated within the client proxy, and the eventhandler contains many other clientside classes as well that do not throw this error.

 

What could be causing this??

[Choonster]

Could you post the crash report and the code mentioned in the stack trace (it doesn't have to be whole classes)? It's hard to help much more than we have since we're just relying on your interpretation of the situation and can't see it for ourselves.

[BusyBeever]

A GuiContainer should not be for clients only, since the server also needs them. So maybe you got an problem in the way you designed the code?

Maybe show ur guihandler with the crash log

[Choonster]

A GuiContainer should not be for clients only, since the server also needs them. So maybe you got an problem in the way you designed the code?

Maybe show ur guihandler with the crash log

 

A

Container

is created on both sides (in the

IGuiHandler

for the server or in the

GuiContainer

for the client). A

GuiContainer

is client-only.

[BusyBeever]

my bad. yeah sorry I had only container in my mind. Nevermind me

[Zetal]

Could you post the crash report and the code mentioned in the stack trace (it doesn't have to be whole classes)? It's hard to help much more than we have since we're just relying on your interpretation of the situation and can't see it for ourselves.

 

Good call, I was looking right over the bottom part of the stack trace. Full stack Trace: http://pastebin.com/1gxyDBfk

 

So it would seem the error stems not from anything related to Sides, but to the fact that, apparently, my class isn't being compiled properly?

 

Here is the GuiSpecRepair class: http://pastebin.com/inyWvFsw (I know it's a mess, I'm sorry. There's so much to do that I get lazy, and there are probably way better ways of doing it, but blergh.)

 

A brief Google search of the error is related to Entities that implement IInventory, but GuiSpecRepair is neither an entity, nor does it implement IInventory, so I'm not sure.

[BusyBeever]

at bitevo.Zetal.LoMaS.Specializations.SpecializationsMod.clientStart(SpecializationsMod.java:492) ~[bin/:?]

can you show that part of the code?

I feel like you should not generate a GuiContainer inside your mod init.

It is crashing in your mod init right?

[Choonster]

func_175173_a

and

sendAllWindowProperties

are the SRG and MCP names of the same method. You have both in your class, so it's possible that the SRG name is being deobfuscated to the MCP name at load time, creating two methods with the same name and arguments.

 

As a general principle, you can delete any non-override method if it's not being used in your class.

[Zetal]

Well, wrap it up boys, it's been solved. Additional Google-fu led me to this extremely awkward link. Shortly afterwards, I removed the methods in GuiSpecRepair that were no longer useful, and the error has stopped occurring. Not sure of the technical causes behind the crash, but there it is. Have a good one, thanks for getting me there

 

Edit: Choonster you pro, you nailed it as I was typing this. Nice work