Blocks & instances. way over my head, could anyone explain?

[Mazetar]

I was sure I knew how blocks where handled and at least the general idea of it, but I guess I'm completely stupid then as I doubt he's trolling inn such a way:P

 

So a guy on the MCF has a tutorial inn which he does this:

public int blockDataValue;
@Override
public void onBlockAdded(World world, int i, int j, int k)
{
this.blockDataValue = ItemBlockBattery.value;
}

And upon dropping it returns a item with the proper value of the block.

 

However, I thought there was only 1 single instance of any given block at any given time?

that the world was just a bunch of block ID's (and meta/te), not several block instances?

 

Into which he replies:

Every separate block in the world has it's own instance.

 

So uhm, I'd like to know whats going on?

ref:

http://www.minecraftforum.net/topic/1793233-tutorial152forge-cephrus-advanced-modding-tutorials/

[Draco18s]

Every block being its own instance would be a MASSIVE drain on system resources.  He's wrong.  This is easily noticable when using setBlockBoundsBasedOnState (and not specifying block bounds for inventory rendering).

 

What's likely happening is that he's getting back the right data values by accident.

[Reika]

Every block being its own instance would be a MASSIVE drain on system resources.  He's wrong.  This is easily noticable when using setBlockBoundsBasedOnState (and not specifying block bounds for inventory rendering).

 

What's likely happening is that he's getting back the right data values by accident.

 

This is entirely correct. You are aware of what static does in Java, yes? Blocks behave as if every variable was static. So if you set a variable property with a method, all blocks have their instance change to the "last written value".

 

As a rather amusing test, you can try registering a TileEntity with Block ID 1 (so that when the game loads, all stone is given a TE). Do this with Task Manager open to the performance tab and watch your RAM usage go up faster than gas prices for Christmas break. 

[Mazetar]

This is entirely correct. You are aware of what static does in Java, yes? Blocks behave as if every variable was static. So if you set a variable property with a method, all blocks have their instance change to the "last written value".

 

Yeah I know the pure basics at the very least, that's why his post and replies made no sense to me.

Since he made his statement in the way that he did I figured there must either be something I failed completely at understanding or he's way into ponyland on this one

 

I know that blocks are defined as static inn Block.java and I do have a understanding of the programming basics for OOP.

But I considered this to be something so simple, so trivial that someone claiming against it in a tutorial on mcf would make someone react.

Therefore since I'm only learning programming by self-study between full time work and all, for about a year..

I reasoned that the possibility of me being dead wrong, would be quite likely

 

So I wouldn't go right out and accuse him of being mistaken.

Especially considering that if I where to be wrong, then this would require me to get someone who could explain me how and why I would be wrong.

And insulting someone wouldn't lead me too learn anything

 

Thanks <3

[Reika]

OK, there is one thing to note here:

Blocks being defined as static in Block.class is completely unrelated to the issue here.

static Block = new Block(stuff)

Makes the Block variable static to the Block class. That is not (well, at least not directly) what makes Blocks themselves static and behave accordingly.

[Mazetar]

well now that you mention it that's true. I didn't think of that despite of the fact that I now realize I knew that inn theory, thank you

 

So that's true and the different Block Classes aren't static so in theory one could create instances of them elsewhere.

But since blocks only are defined inside the Block.class and when the game refers to a block it looks at the instance defined inside Block.class?

then it's not completely unrelated

 

Or well i guess since it's meaningless information, as if you know that there are no other places blocks are defined then you know the answer to the issue regardless of whether it's static or not

[Reika]

well now that you mention it that's true. I didn't think of that despite of the fact that I now realize I knew that inn theory, thank you

 

So that's true and the different Block Classes aren't static so in theory one could create instances of them elsewhere.

But since blocks only are defined inside the Block.class and when the game refers to a block it looks at the instance defined inside Block.class?

then it's not completely unrelated

 

Or well i guess since it's meaningless information, as if you know that there are no other places blocks are defined then you know the answer to the issue regardless of whether it's static or not

 

They are unrelated. Let me explain.

Making the variable in Block static means other methods can access it without instantiating Block.class.

The reason blocks only have one instance, however, is because all other block-creation code (world-gen, placing, etc) refers back to that one instance declared in Block. So that one instance is getting used everywhere.