[1.8][CLOSED] Is IExtendedEntityPorperties disallowing using SideOnly?

[Ernio]

Consider this:

 

 

I am using per-entity client value to make per-entity smooth health bar transition.

Clearly getting error: Caused by: java.lang.NoSuchFieldError: lastTickHealth

When mod is ran on Dedicated server (on client works just fine).

 

My question is - what "fact" (piece of code) is not allowin this to be? IEEP clearly doesn't like SideOnly, but why?

 

EDIT:

Oh and SideOnly on methods is perfectly fine, IEEP only crashes when SideOnly is used on FIELDS (like in exception I have above).

[jabelar]

You don't need to go overboard with SideOnly.  You only need SideOnly if the code in the method calls on something that is SideOnly.

 

The whole SideOnly thing is kinda inconsistent even in the Minecraft code. Generally it shouldn't hurt to have a class compiled that never gets run, so I think the savings (i.e. in memory) they get by annotating some things as SideOnly isn't worth the hassle of it all.

 

But generally don't annotate as SideOnly unless you're forced to -- because you're calling code that is SideOnly.

 

Even diesieben07 says: (from thread at http://www.minecraftforge.net/forum/index.php/topic,18608.msg94192.html#msg94192)

there is nothing wrong with you using it, provided with you knowing what you are doing.

But it also gives you no notable benefit:

Accidental usage of client-only methods / classes: It would crash anyways, probably with a ClassNotFoundException

It has some problems, the following code for example will crash on a Server, even if the field is never accessed:

@SideOnly(Side.CLIENT)

public String someString = SomeOtherClass.method();

That combined with the fact that unexperienced modders usually understand @SideOnly as a way to differentiate between Client and Server Thread ("logical side") leads to me not recommending it (unless you are overriding a Minecraft method which already has it, then you should in fact add it).

[SanAndreaP]

Also, SideOnly only removes the definition of a field, not the assignation, since that is laying in another part of the bytecode @SideOnly can't access easily.

So if you need to use SideOnly(CLIENT) on a field (I do this only if the type is also SideOnly(CLIENT), e.g. on an IIcon field), then just define it w/o assigning it a value like

@SideOnly(Side.CLIENT)
public Bla foo;

 

and then assign a value within a method which has also the SideOnly(CLIENT) annotation.

[Ernio]

"there is nothing wrong with you using it, provided with you knowing what you are doing."

I know how it works, I simply don't want to store useless values on server side.

 

SanAndreas - this is exacly what I needed to know (that you can't initialize those values).

 

This closes issue