Client appears not to be writing to NBT

[Wirkungsquantum]

Hello community,

 

the other day i had request about some problems i had with texturing a block, it was recommended to me to have a look into packet handling and client server communications. The first thing i did was to figure out whether it was the server or the client having the problem by doing this:

 

	public void readFromNBT(NBTTagCompound nbt){
	super.readFromNBT(nbt);
	this.direction = nbt.getString("DIRECTION");
	Side side = FMLCommonHandler.instance().getEffectiveSide();
	if(side != null && side == Side.SERVER){System.out.println("Server read");}
	if(side != null && side == Side.CLIENT){System.out.println("Client read");}
}

public void writeToNBT(NBTTagCompound nbt){
    super.writeToNBT(nbt);
	//System.out.println(this.direction);
	nbt.setString("DIRECTION", this.direction);
	Side side = FMLCommonHandler.instance().getEffectiveSide();
	if(side != null && side == Side.SERVER){System.out.println("Server wrote");}
	if(side != null && side == Side.CLIENT){System.out.println("Client wrote");}
}

 

It turned out the server is working perfectly fine and that, much to my surprise, it is the client not working properly.

It does neither save to or read from NBT.

 

Thus my first question is: Is this a normal behaviour?

And the second: Do i have to somehow force the client to write and read on its own or can this only be solved by using packets? If so, are there any tutorials other than "http://www.minecraftforge.net/wiki/How_to_use_NBT_Tag_Compound" about how to do this you guys know about?

(Google wasn't much of help)

I *assume* i will need to use packets in order to have other clients see the same thing as the one who set the block does.

I was surprised to see that EE3 (looked it up on github) appears not be using any sort of client server communications for its nbt tags.

 

Well, i hope someone can advice me on this

 

// update:

Some testing with the furnace showed me that it is a normal thing that the client does not read/write to nbt.

Yet i'm not really sure where, when und how to send/receive packages i hope that further studying of opensource mods will help me with this. Help on this however would still be appreciated.

[Wirkungsquantum]

Thanks diesieben07,

 

at first i was still somewhat unsure on how to implement those functions properly so i had a look at the ironchests mod's code and eventually got my code to work. I will put all the functions etc. necessary in this post so as that

a) you (or anyone else for that matter) can tell me whether there is something that could be done in a more efficient way b) anyone who has the same a or a related problem might look the solution up in this thread.

 

Tile Entity:

@Override
public Packet getDescriptionPacket(){
        NBTTagCompound nbt = new NBTTagCompound();
        nbt.setString("DIRECTION", this.direction);
        return new Packet132TileEntityData(xCoord,yCoord,zCoord,1,nbt);
}

public void setDirection(String newDirection){
	this.direction = newDirection;
	worldObj.markBlockForUpdate(xCoord, yCoord, zCoord);
}

@Override
    public void onDataPacket(INetworkManager net, Packet132TileEntityData pkt)
    {
    	this.direction = pkt.customParam1.getString("DIRECTION");
    }

public String getDirection(){
	return this.direction;
}

//Aditionally here's my function to determine a blocks direction relative to the player placing it:

public String direction = "NotSetYet";

public void setDirection(double playerHeight, float playerAngle){
	Side side = FMLCommonHandler.instance().getEffectiveSide();
	playerAngle = Math.abs(playerAngle) % 360;
	if(side == Side.CLIENT) playerHeight -= 1.62;
	if(playerHeight % 1 >= 0.5)playerHeight = (int)playerHeight+1; else playerHeight = (int)playerHeight;

	if(this.direction.equals("NotSetYet")){
		if(playerHeight+1 < yCoord){
			if(playerAngle>=  0 && playerAngle< 45){this.direction ="USE";}
			if(playerAngle>= 45 && playerAngle< 90){this.direction ="UES";}
			if(playerAngle>= 90 && playerAngle<135){this.direction ="UEN";}
			if(playerAngle>=135 && playerAngle<180){this.direction ="UNE";}
			if(playerAngle>=180 && playerAngle<225){this.direction ="UNW";}
			if(playerAngle>=225 && playerAngle<270){this.direction ="UWN";}
			if(playerAngle>=270 && playerAngle<315){this.direction ="UWS";}
			if(playerAngle>=315 && playerAngle<360){this.direction ="USW";}
		}else{
			if(playerAngle>=  0 && playerAngle< 45){this.direction ="DSE";}
			if(playerAngle>= 45 && playerAngle< 90){this.direction ="DES";}
			if(playerAngle>= 90 && playerAngle<135){this.direction ="DEN";}
			if(playerAngle>=135 && playerAngle<180){this.direction ="DNE";}
			if(playerAngle>=180 && playerAngle<225){this.direction ="DNW";}
			if(playerAngle>=225 && playerAngle<270){this.direction ="DWN";}
			if(playerAngle>=270 && playerAngle<315){this.direction ="DWS";}
			if(playerAngle>=315 && playerAngle<360){this.direction ="DSW";}
		}
	}
}

[mnn]

a) you (or anyone else for that matter) can tell me whether there is something that could be done in a more efficient way b) anyone who has the same a or a related problem might look the solution up in this thread.

that's nice of you to share your working code, me (and probably other noobies) appreciate this behaviour

 

i would suggest reconsidering data representation of direction - string operations are not fastest, also this representation wastes memory and network resources (bigger packets).

"USE" ~ 3bytes ~ 256^3 = 16 777 216: it can represent 16 777 216 values (not counting size information of a string instance). but you only uses 16+1 values for directions, you could easily store it in 1 byte (e.g. using enum)