Title says most of it...to expand on it:

 

I have a block that sets down a bush with berries on it (it is a TESR) that can be sheared to drop berries. I put read/write to NBT in the TileEntity class (linked below) but it isn't working. Any ideas?

 

Tile Entity class: http://pastebin.com/3fWdLqLf

 

Thanks!

You may have to sync your NBT data between the client and the server... That is pretty much all I got.

 

To test this theory, in the block's onBlockActivated method, put a

System.out.println(bAmt); // bAmt is your berry amount. Get that however you need to

inside an if statement checking if the world is server side. If the server side world has the correct berry amount, then it's a syncing issue. If not... Well. We shall keep digging.

Can you confirm that the tile-entity is created and initialized in the first place?

You may have to sync your NBT data between the client and the server... That is pretty much all I got.

 

To test this theory, in the block's onBlockActivated method, put a

System.out.println(bAmt); // bAmt is your berry amount. Get that however you need to

inside an if statement checking if the world is server side. If the server side world has the correct berry amount, then it's a syncing issue. If not... Well. We shall keep digging.

 

I tossed a println in there for the bAmt and it printed out the correct number in the console. I restarted the client and it seems to be saving the amount but not updating the texture when the world is re-loaded.

 

EDIT: Forgot to mention that the println was inside an if(!world.isRemote)

That would point us towards your render code. You probably have a higher range for the berry amount than metadata can handle, but if not you could always use metadata instead.

That would point us towards your render code. You probably have a higher range for the berry amount than metadata can handle, but if not you could always use metadata instead.

 

Render class: http://pastebin.com/kZJw9WLM

 

This is my render class. Is calling the same method my block class calls the issue? Would calling the bAmt from the block be any different? The berry amount can go from 0-7

It all looks fine... try System.out.println(bAmt) right before the switch statement and System.out.println("rendering " + whatCaseThisIs) in each case of the switch statement. I know it sounds weird but that switch statement has opengl calls and to me they seem the most likely offenders in this scenario. I'll look again and let you know if anything dawns on me.

It all looks fine... try System.out.println(bAmt) right before the switch statement and System.out.println("rendering " + whatCaseThisIs) in each case of the switch statement. I know it sounds weird but that switch statement has opengl calls and to me they seem the most likely offenders in this scenario. I'll look again and let you know if anything dawns on me.

 

A System.out.println(bAmt); right before the switch spams the console (quite a bit haha) with the amount showing visually (of course) but if the game has, say...3 berries, and I log out and back in, the println before the switch still spams the amount of berries showing up but when I use my other println (called from the Block class on blockActivated) it shows the amount that is held rather than the amount shown.

 

This leads me to believe my call to the TileEntitySapphireCrop.getBerryAmount(); method is not calling correctly.

 

I can add and take away berries which makes the texture change, changing what output I have inside the Render class. This also changes the amount of berries actually held (but not shown correctly). These amounts don't beyond 0-7 for either of the rendering or block classes.

I would change your getBerryAmount method to:

public int getBerryAmount()
{
    if (this.worldObj.isRemote) System.out.println("client");
    else System.out.println("server");
    System.out.println(bAmt);
    return bAmt;
}

MoxEmerald, have you heard of this thing called clue t and this thing called server? No? Okay. That explains everything.

 

As I was saying before, this is a client/server syncing issue. You need to sync the servers data to the client via a packet (tile entities have built in packet stuff, but i have no clue how that works. I suggest making your own packet).

 

So MoxEmerald, please, learn. And always remember that data will ALWAYS need to be synced between the client and server. Or else you get these problems.

I would change your getBerryAmount method to:

public int getBerryAmount()
{
    if (this.worldObj.isRemote) System.out.println("client");
    else System.out.println("server");
    System.out.println(bAmt);
    return bAmt;
}

 

So with that, my onBlockActivated method calls both client and server. The render class only calls client. I am thinking now that the client and server and not syncing, unfortunately that is untreaded water for me so I don't know how to sync the two.

 

The second before I posted this Kwibble kindly pointed out it was obviously a syncing issue. Time to look into packets! I'll keep this open and post when I figure it out. Thanks again everyone for the help! Wish me luck on figuring out packets. If anybody has any suggestions they would be greatly appreciated.

Check out the two good SimpleNetworkWrapper tutorials in the tutorials section of Modder Support.

 

That's where I learnt packet handling for 1.7.2

Since you're now going with packets I'm assuming that the onBlockActivated from the client call gave the wrong number but the onBlockActivated call from the server gave the correct number. If so good call Kwibble.

 

But if this were a packet issue why doesn't it manifest itself before a save and quit?

Check out the two good SimpleNetworkWrapper tutorials in the tutorials section of Modder Support.

 

That's where I learnt packet handling for 1.7.2

 

I'll check them out now, thanks for the nod in the right direction. Packets here I come!

 

@MoxEmerald: Yes, the client side with onBlockActivated was giving the incorrect number while the server call was correct.

 

I'll post in a bit once I get some work done.

So in my mod I have a tileentity for a ..."custom furnace" that contains an itemstack that contains a custom item that holds a numerical value in it's nbttag. in essence I have an itemstacknbt contained inside of a tilentity nbt. The value gets incremented every 1 second and try as I might I can't find any problems/bugs with it when I save and quit or anything. I am not using packets and I fail to see the difference since I am verifying the value from a description when you hover the itemstack which is on the client side... right? Is verifying the value from the texture used different then from the gui? Or is the gui's value secretly coming from the server side?

 

I simply fail to see why TheMoleTractor would need a packet when I do not.

It all depends on how you make those calls really. And where from.

 

But the main reason TheMoleTractor needs a packet is because he is calling methods from client only: A renderer.

 

Whereas you are interacting with an item, which exists both client and server side. Is the difference a little clearer now?

So in my mod I have a tileentity for a ..."custom furnace" that contains an itemstack that contains a custom item that holds a numerical value in it's nbttag. in essence I have an itemstacknbt contained inside of a tilentity nbt. The value gets incremented every 1 second and try as I might I can't find any problems/bugs with it when I save and quit or anything. I am not using packets and I fail to see the difference since I am verifying the value from a description when you hover the itemstack which is on the client side... right? Is verifying the value from the texture used different then from the gui? Or is the gui's value secretly coming from the server side?

 

I simply fail to see why TheMoleTractor would need a packet when I do not.

 

I actually got it to sync on start-up.

 

In my TileEntity class I have added these two methods:

	public void onDataPacket(INetworkManager net, Packet132TileEntityData pkt)
{
	NBTTagCompound tag = pkt.data;
	readFromNBT(tag);
}

public Packet getDescriptionPacket()
{
	NBTTagCompound tag = new NBTTagCompound();
	writeToNBT(tag);
	return new Packet132TileEntityData(xCoord, yCoord, zCoord, blockMetadata, tag);
}

 

While I am sure there are better ways to do this, this seemed to work.

 

One unfortunate thing (I seem to be hitting every possible snag trying to finish this crop up) is that now when the crop grows in game (using the blocks updateTick) the texture again doesn't update right away. Again an issue with syncing.

The fog is starting to lift, however I feel that the renderer is secondary to the tile-entity. If his tile-entity exists on both sides and it is falling out of sync then isn't this indicative of a problem that could be fixed a little more simply? Adding a packet will correct the situation at specified intervals, but the client and server ticks happen the same number of times per second. As long as the code has reproducible results the two sides shouldn't be falling out of sync.

 

For something more complicated using a packet would be more efficient. However, we're just incrementing a value. If his code is made reproducible running it twice shouldn't hurt anything. Unless Minecraft code isn't as sturdy as I had thought.

 

It occurs to me that I don't know how his value gets changed. Perhaps he's applying a sort of bonemeal, or maybe it's just a matter of time. I suppose that might make the difference as well.

 

I guess that this is a long winded way of saying that jumping right to a custom packet seems frivolous to me. It should be noted that I have never used packets and as such I've never really had to go through the thought process of deciding I need them. I've always determined that I don't.

 

I apologize for being so meticulous and even spammy, but I hope I'm at least communicating my point of view clearly, if not concisely.

 

@TheMoleTractor you posted while I was typing so...

 

I... don't know. Maybe it's just packet delay (packet does imply a network of sorts). Networks are allowed to... take their time when necessary.

Okay. The way Minecraft (or any client/server) works is like this.

 

Client receives user input.

Client notifies server of what it was given.

Server receives the input.

Server processes input.

Server executes the results.

Server sends client a response.

Client executes the visual side.

 

The server is supposed to handle all the processing. The client just handles user input.

 

 

@TheMoleTractor You will need to change the bAmt value server side only. And EVERY time the value is updated, sync the server to the client. That's why I suggested using your own packets.

Okay. The way Minecraft (or any client/server) works is like this.

 

Client receives user input.

Client notifies server of what it was given.

Server receives the input.

Server processes input.

Server executes the results.

Server sends client a response.

Client executes the visual side.

 

The server is supposed to handle all the processing. The client just handles user input.

 

 

@TheMoleTractor You will need to change the bAmt value server side only. And EVERY time the value is updated, sync the server to the client. That's why I suggested using your own packets.

 

So I have it where the server is incrementing when it "grows" but the visuals are not updating. Is there any viable way to sync it in the updateTick method in the Block class?

@TheMoleTractor Try updating in the tile-entity class. It makes more sense anyways(the value is stored there after all).

 

And if it were that clear cut the client would be required to ask the server side for the nbttag. As we can see though it doesn't do that. If we want that hierarchy we have to build it ourselves. It is not the default for the tile-entity nbttags to sync the way you seem to think Itemstack nbttags automatically sync. Large parts of the game exist on both sides.

 

The client side is more hybrid than you would think, after all minecraft used to run without a server side. What you're describing is an actual client-server relationship, Which would be true enough if we were talking about an actual server- but we're talking about the server side of the client application. As such we are allowed much more flexibility than all that. After all, it all runs on the same processor.

 

There are even scenarios out there where the "clients" do the processing and the "server" distributes the data and handles user input/output. A sort of Cloud Computing scenario could follow those rules.

I would just like to remind you that single player is actually multiplayer with only one person logged in.

 

Have you tested your item nbt stuff on a dedicated server? And I never said its auto synced. You have to have the nbt saved server side for it to actually take effect. With items, they are handled in containers which are server side. It makes more sense for an item to not have problems whereas a renderer will.

 

 

As to the problem persisting... Make a custom packet. Like I said before. Using SimpleMetworkWrapper, you can then make a message to send to server side asking to change the bAmt. That message can send a reply back with the new value, or no reply if the value hasn't changed.

I would just like to remind you that single player is actually multiplayer with only one person logged in.

 

Have you tested your item nbt stuff on a dedicated server? And I never said its auto synced. You have to have the nbt saved server side for it to actually take effect. With items, they are handled in containers which are server side. It makes more sense for an item to not have problems whereas a renderer will.

 

 

As to the problem persisting... Make a custom packet. Like I said before. Using SimpleMetworkWrapper, you can then make a message to send to server side asking to change the bAmt. That message can send a reply back with the new value, or no reply if the value hasn't changed.

 

I'll work on a packet tomorrow and see if that works. I took a look at the SimpleNetworkWrapper in the tutorials and tried making a class that implemented IMessage and another that implemented IMessageHandler, neither of which were classed that existed and I could use.

Yeah... Oops. I didn't read the title very well. Didn't realize you were 1.6.4...

 

There are plenty of packet handling tutorials for 1.6.4 so don't worry.

Yea I am doing this with a buddy (he is texturing and modeling) and he wants to get it up and running before we update to 1.7... So for now we are 1.6.4... I shall scour the internet for tutorials. I'm not worried about finding some good ones.