[SOLVED][1.10.2] IStateMapper for invalid side SERVER

[oa10712]

I have been working on a mod for the past month or two, and it has been running just fine in single player. However, I attempted to put it on a server for some group testing and I got the following error log: https://pastebin.com/gDeaDKd2

However, this is the line that the error is supposedly at: https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/proxy/CommonProxy.java#L75

and not only is there no reference to IStateMapper there, I don't have any direct usage of it in my mod at all. What am I doing wrong here?

Edited July 2, 2017 by oa10712

[Choonster]

That line references ModFluids, which references the client-only classes StateMapperBase (which references IStateMapper) and ModelLoader, causing this error.

 

All model registration must be done in client-only classes. I recommend switching to registry events now so you can more easily update your code to 1.12.

[oa10712]

Are there any good guides/tutorials/examples for registry events?

[Choonster]

57 minutes ago, oa10712 said:

Are there any good guides/tutorials/examples for registry events?

 

The documentation page I linked explains them. You can see some examples of them in my mod's init classes.

[oa10712]

There also seems to be a related issue, Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/multiplayer/WorldClient, at https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/ModBlocks.java#L33.

Is this going to be fixed by switching to registry events as well?

[Draco18s]

56 minutes ago, oa10712 said:

There also seems to be a related issue, Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/multiplayer/WorldClient, at https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/ModBlocks.java#L33.

Is this going to be fixed by switching to registry events as well?

What the fuck is this

https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/blocks/BlockOre.java#L82-L87

No really. What the fuck.

[Choonster]

41 minutes ago, oa10712 said:

There also seems to be a related issue, Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/multiplayer/WorldClient, at https://github.com/16ColorGames/SuperTechTweaks/blob/master/src/main/java/com/sixteencolorgames/supertechtweaks/ModBlocks.java#L33.

Is this going to be fixed by switching to registry events as well?

 

Switching to registry events won't actually fix either problem itself, it's just something you should do to prepare for updating to newer versions. Moving model registration to a client-only class will fix the first problem.

 

The issue here is that BlockOre references the client-only class Minecraft. You use it in two places (getDrops and getExtendedState) for the same purpose (getting a World when you only have an IBlockAccess), but the replacement will be slightly different in each method due to where they're called from.

 

Since getDrops will usually be called with a World as its IBlockAccess argument, cast it to World (after checking that it is a World) and use that to get the ore data.

 

Since getExtendedState will usually be called with a ChunkCache as its IBlockAccess argument, you can't just cast it to World. Instead, create a method in your proxy classes to get the client World and use this to get the ore data. It's probably best to check if the IBlockAccess is a World first and use that directly, just in case someone calls the method with a World.

 

This would be a lot easier if you just used a TileEntity to store per-position block data.

 

If you're going to stick with the current system, OreSavedData should use a Map with BlockPos keys instead of using nested Maps for each coordinate.

 

Is there a reason you're storing everything as integers rather than storing the Material instances directly?

[oa10712]

7 hours ago, Choonster said:

This would be a lot easier if you just used a TileEntity to store per-position block data.

 

If you're going to stick with the current system, OreSavedData should use a Map with BlockPos keys instead of using nested Maps for each coordinate.

 

Is there a reason you're storing everything as integers rather than storing the Material instances directly?

When I had asked for help previously, I had been using tile entities, but the community reacted like I had personally kicked their childhood puppy, so I switched to using WorldSavedData. The reason I use nested maps is to help with networking, since it was the first way I thought of to reduce the size of the update packets, but I will take a look into merging them into a single map.

As far as storing integers, I thought that it would reduce the RAM required, since this is being designed for a relatively large modpack, as well as that you can use CraftTweaker to add extra materials later on if needed.

[Choonster]

46 minutes ago, oa10712 said:

When I had asked for help previously, I had been using tile entities, but the community reacted like I had personally kicked their childhood puppy, so I switched to using WorldSavedData.

 

I feel like there may have been a misunderstanding here, since TileEntities seem like the ideal tool for this job. Could you link this reaction? I'd like to see the reasoning behind it.

 

 

47 minutes ago, oa10712 said:

The reason I use nested maps is to help with networking, since it was the first way I thought of to reduce the size of the update packets, but I will take a look into merging them into a single map.

 

I don't really get what nested Maps have to do with packet size. You need to send all three coordinates in the packet regardless of how the position is stored.

 

 

48 minutes ago, oa10712 said:

As far as storing integers, I thought that it would reduce the RAM required, since this is being designed for a relatively large modpack, as well as that you can use CraftTweaker to add extra materials later on if needed.

 

There shouldn't be any major difference in memory consumption between an array of ints and an array of objects, if anything you're probably increasing the memory overhead by storing arrays of primitive wrapper classes (Integers). I'm not an expert on this, you should profile it if you want actual numbers.

 

Storing object references rather than IDs shouldn't affect CraftTweaker, just convert from the ID to the Material object.

[oa10712]

Would DimensionManager be the way to get a copy on the server side? Thats the only place I am finding to get an instance of ServerWorld, since MinecraftServer doesn't have a getInstance method. Also, I am attempting to locate the previous threads, I may have had them on a different forum. People seemed very opposed to using TileEntities for ores.

[Choonster]

5 minutes ago, oa10712 said:

Would DimensionManager be the way to get a copy on the server side? Thats the only place I am finding to get an instance of ServerWorld, since MinecraftServer doesn't have a getInstance method.

 

Any World on the logical server (when World#isRemote is false) will be a WorldServer.

 

World#getMinecraftServer will return the MinecraftServer instance (if it's a server-side World).

[oa10712]

20 hours ago, Choonster said:

Since getExtendedState will usually be called with a ChunkCache as its IBlockAccess argument, you can't just cast it to World. Instead, create a method in your proxy classes to get the client World and use this to get the ore data. It's probably best to check if the IBlockAccess is a World first and use that directly, just in case someone calls the method with a World.

How should I get access to a World instance in the first place then?

[Choonster]

1 minute ago, oa10712 said:

How should I get access to a World instance in the first place then?

 

From where? If you're talking about the methods where you were using the client World, I already explained how to get the proper World.

[oa10712]

from the getExtendedState method, you said to create a method that retrieves an instance of the world, but I'm not quite sure how to do that.

[Choonster]

1 minute ago, oa10712 said:

from the getExtendedState method, you said to create a method that retrieves an instance of the world, but I'm not quite sure how to do that.

 

I said to create a method to get the client World, i.e. Minecraft#world. You can only reference Minecraft in the client proxy, you can throw an exception from the server proxy.

 

I have an example of this in my mod's proxy classes.

[oa10712]

Just now, Choonster said:

 

I said to create a method to get the client World, i.e. Minecraft#world. You can only reference Minecraft in the client proxy, you can throw an exception from the server proxy.

 

I have an example of this in my mod's proxy classes.

Ah, ok. I was hoping that it would be related to another issue that popped up when I had been using it that way, I'm now getting a 

io.netty.handler.codec.DecoderException: The received string length is longer than maximum allowed (22 > 20)

which I am guessing is from my packet handling somewhere. From what I have seen, this is usually due to scoreboards or entity names, but I don't use either.

[Choonster]

3 minutes ago, oa10712 said:

Ah, ok. I was hoping that it would be related to another issue that popped up when I had been using it that way, I'm now getting a 

io.netty.handler.codec.DecoderException: The received string length is longer than maximum allowed (22 > 20)

which I am guessing is from my packet handling somewhere. From what I have seen, this is usually due to scoreboards or entity names, but I don't use either.

 

Post the full stacktrace.

 

I suspect it's being thrown because the channel name of your SimpleNetworkWrapper is too long.

 

When you send a client-to-server IMessage, it's converted to a CPacketCustomPayload with your SimpleNetworkWrapper's channel name. This channel name is limited to 20 characters by CPacketCustomPayload#readPacketData.

 

Server-to-client IMessages are converted to SPacketCustomPayload, which also has this restriction.

[oa10712]

12 minutes ago, Choonster said:

I suspect it's being thrown because the channel name of your SimpleNetworkWrapper is too long.

Thanks, that was totally the problem. Everything seems to be working now, I will start work on converting to using events