Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

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


Ernio
 Share

Recommended Posts

Consider this:

 

4hwbbn.jpg

 

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).

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

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).

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

Don't ask for support per PM! They'll get ignored! | If a post helped you, click the "Thank You" button at the top right corner of said post! |

mah twitter

This thread makes me sad because people just post copy-paste-ready code when it's obvious that the OP has little to no programming experience. This is not how learning works.

Link to comment
Share on other sites

"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 :)

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

Just a note: @SideOnly is hardly the right tool here. If you need some values only in the client IEEP, make two IEEP classes, one for the client one for the server. Make the client one extend the server one and then choose correctly in the entity construction event which one to use based on world.isRemote. That way you get the memory benefits on the integrated server as well, not only on the dedicated one.

 

</abuse of operator permissions>

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.