[1.7.10] TileEntity Mimicing Changes on All Instances

[Izzy Axel]

I don't know much about TileEntities yet so I'm sure something I did is wrong, but I'm using them to make an adjustable light source, but if I put down multiple, they all get changed in unison when adjusted:

 

BlockContainer

TileEntity

[Draco18s]

The hell is this?

 

public class BlockLightEngine extends BlockContainer {
int light;

[Izzy Axel]

Umm...a class variable?  You are referring to 'light', right?

[coolAlias]

Yes (he is referring to 'light'), but local variables do not work as expected due to all Block and Item instances being singletons, i.e. effectively every local variable is static, meaning it has the same value across all of your Block classes.

 

Another thing, you should NEVER call updateEntity or any other update method, or any write to NBT methods, manually - these are all called at the appropriate times by Minecraft, and calling them manually not only makes things messy, it is apt to introduce buggy or other unwanted behavior (as well as just being less performant).

[Izzy Axel]

Ok, made those changes, but it's still carrying over...

 

BlockContainer

TileEntity

[Draco18s]

And....what is this?

 

this.lightValue

 

$10 says that it's a class-level field of the parent Block class.  Which is still a singleton.

[Izzy Axel]

Hm...then how would I make the TileEntity emit light, if it can't be done via the block?

[coolAlias]

Hm...then how would I make the TileEntity emit light, if it can't be done via the block?

(looking through the Block class)

Hm, what's this?

public int getLightValue(IBlockAccess world, int x, int y, int z)

Looks like you can store the light level in your TileEntity and retrieve the TileEntity's value with that lovely method from Forge

[Izzy Axel]

Unless I misunderstand how you're telling me to use that, the return is the light value, so I can't get the block in updateEntity in the TileEntity and call that method from it to set the value, and overriding it in the BlockContainer will have the same problem as before, due to Block being a singleton. (yeah I tried overriding it, same result)

[Izzy Axel]

That's exactly what I tried:

 

@Override
public int getLightValue(IBlockAccess world, int x, int y, int z)
{
TELightEngine lightEngine = (TELightEngine)world.getTileEntity(x, y, z);
return lightEngine.getLight();
}

 

This still results in every instance of the block emitting the set light value.  I'm not sure this is possible after looking at the Redstone Lamp code, as they do it by replacing the block with one that's lit when it gets a redstone signal, and I'm not making 15 blocks just to get this to work.

[jabelar]

Let's not be too hard on Izzy. Despite some fundamental mistakes, his code actually looks like he could learn to be a good programmer (unlike some of the crazy code some people post that appears hopeless).

 

Izzy, you're bashing into a couple concepts here. Static, instances and singletons.

 

The first one is what a static field is. Putting static means that it is SHARED across all instances of that class. (Well actually it isn't in the instances at all, but is referenced directly through the class). Fields that are not static need to have an instance of the class to reference, and can vary between the instances.

 

An instance is created whenever you use the "new" keyword: MyClass myClassInstance = new MyClass().

 

To see the difference between accessing a static and non-static field, if MyClass has a static int myField you would reference it simply with MyClass.myField. However, if it wasn't static then you'd have to create an instance with MyClass myClassInstance = new MyClass() and then you could reference with myClassInstance.myField. See the difference?

 

Now theoretically you'd want to create an instance for everything in your program that might vary from similar things. In Minecraft you might think that you'd create a block instance for every block placed in the world. The problem is that there are so many blocks in a Minecraft world that you'd run out of memory doing it this way. Instead they only create a single instance (called a "singleton") that has the ability to change a bit by looking up a compressed map of data called metadata.

 

There are cases though where you want your blocks to do something more complicated, or store things like inventories of items. So that is where tile entities come in. But since it is expected that you won't place too many of these they allow you to create an instance for every placement.

 

Putting all this together, you should have just one custom block instance (i.e. there should only be one place through the entire mod where you use new with your class constructor) but when the method for getting the lightvalue is called you want to check the unique tile entity instance at the same position. That tile entity class shouldn't use static fields for calculating the light value, otherwise all the tile entities will report the same value.

 

Hope that helps. I feel if you can wrap your head around these three concepts -- static, singletons used for blocks and items, multiple instances of tile entities -- that you'll really have a breakthrough in your modding and programming in general.

 

 

 

The second concept is the idea of a "singleton" class.