[1.10.2][Solved] Synchronization of RF energy in TileEntity

[Roboguy99]

I'm trying to implement the RF energy API on a TileEntity. I'm having quite a bit of trouble with synchronizing the energy between server and client though. What confuses me most is that I am already synchronizing another variable,

processTimeRemaining

, without an issue. Replicating the same steps for energy has not worked.

 

I thought perhaps I need a packet, but

processTimeRemaining

works without one, which confuses me.

 

The exact issue is with a progress bar in the GUI not being synced correctly; investigation shows this is because the client/server show different values for the energy. As I said, this issue does not exist with

processTimeRemaining

.

 

Code:

 

TileEntity update

TileEntity sync code (various methods as well as energy getters/setters until pretty much the end of the class)

Container

Gui

 

I'm sure it's something stupid and obvious; it normally is. I've spent hours trying various things, and nothing has worked so far, and I am very confused. Any help is appreciated.

[Draco18s]

So the link to sync code doesn't actually link to anything that does syncing.

That would be here: https://github.com/JakeStanger/Chemistry/blob/master/src/main/java/roboguy99/chemistry/tile/TileOreProcessor.java#L543

 

The part you linked to instead, however, uses magic numbers.  Fuck, did BlockState property enums teach you nothing?

[Roboguy99]

Err...I'm going to say no, they did not...Perhaps you should explain what you mean by BlockState property enums more?

 

That code is far from being finished and tidied, and yes, I know, the magic numbers do need to go ASAP. Hell, the whole class is a disgusting mess that needs splitting.

 

The get/set field methods do sorta sync, but I guess that's not properly syncing between server/client?

 

What *should* I be doing to sync then? And why does

processTimeRemaining

sync when the energy doesn't?

[Roboguy99]

Kill me.

 

public int getField(int id)
{
	switch (id)
	{
		case 0:
			return this.processTimeRemaining;
		case 1:
			return TileOreProcessor.PROCESS_TIME;
		case 2:
			return this.energyStorage.getEnergyStored();
		case 3:
			return this.energyStorage.getMaxEnergyStored();
	}

	return 0;
}

public void setField(int id, int value)
{
	switch (id)
	{
		case 0:
			this.processTimeRemaining = value;
			break;
		case 3:
			this.energyStorage.setEnergyStored(value);
	}
}

 

setField

case 3

should be

case 2

.

 

Further evidence that magic numbers are hell. I'm changing them now.

[Draco18s]

See, I never would have even noticed. I saw magic numbers and went "fuck this, I'm going to assume it's correct."  I couldn't even tell that these methods were (partly) responsible for sync.

[Roboguy99]

Fair enough, lesson learned. I'll try to ever avoid using them in the first place in future.

 

I always fall down the trap of "I'll change those later" and don't until I stare at the code for a week wondering why I put a number where I did.

[KeeganDeathman]

I was unaware the API was available for 1.10, where did you acquire it?

[Guest]

You can download the source for 1.8 from Github and change the import of BlockPos in one class.

[Roboguy99]

I was unaware the API was available for 1.10, where did you acquire it?

 

https://github.com/CoFH/RedstoneFlux-API/tree/1.8

 

It is also very easy to port from 1.7.10, which I did before discovering the 1.8 version.

[Guest]

Yeah, but the 1.7.10 and the 1.8 version have a massive difference: In 1.8 IEnergyProvider and IEnergyReceiver extend IEnergyHandler and not the other way around.

[Roboguy99]

Yeah, but the 1.7.10 and the 1.8 version have a massive difference: In 1.8 IEnergyProvider and IEnergyReceiver extend IEnergyHandler and not the other way around.

 

True. It would be stupid to port it yourself if the devs did it for you anyway. I just said it for the sake of saying it really.