Isuse with my alloy furnace

[tnd_blazer]

So last weekend i decided to take on the chalange of making my own mod..
My lord its not as easy as i thought, Anyways.
Everything seems to be working fine, oregen, ores, ect all basic building blocks for it but im still having problems understanding tile entitys and item stacks
call me stupid but i cannot wrap my head around it, i dont know. i dont want a direct fix maby just a point in the right direction and some small explenations 
copys never teach me anything

Anyways here is this source code.. its minecraft version 1.7.10
https://github.com/tndmadman/TTM-TND-TECH-MOD/

[Draco18s]

Blocks and Items are all singletons: that is, only one instance of them exists.

 

All those things you see in your inventory? Those are ItemStack instances that simply point to the Item instance and say "I am a copy of that."

 

TileEntities are because Blocks can only store 4 bits of information in the world ("metadata") and in order to have any more than that, it needs to create an Entity (Cows and Zombies are entities too!) in order to store that data.

[MX_wb]

Sorry, I don't think 1.7.10 is supported here anymore :(. You should use late versions anyway, as they have more useful features such as the json models and blockstates.

[jabelar]

Although he is coding in 1.7.10 (bad!) the concepts of tile entities and item stacks are general so I think it is okay to answer that.

 

To add onto what Draco18s was saying...

 

Tile Entities

 

For performance reasons, the information about each block position as well as the amount of code that runs for each block must be purposefully limited. For example, in one chunk there are 65,536 (=16x16x256) block positions so in a given world it can quickly get to millions of block positions! So instead of having an object instance of block for every position, they have a single instance ("singleton" as Draco18s mentioned) for each block type and then just have a map that indicates the "block state" at each "block pos". Now since they wanted the blocks to be interesting, they allowed a little bit of data (4 bits of "metadata") that could be unique per block position to represent things like what growth stage a plant has, or which direction a furnace is facing, etc.

 

That is all fine for static blocks, but what about blocks that are supposed to change like plants growing, leaves decaying, or furnaces cooking? Those things do require some code to run but they still had to be careful because things like leaves can still be very numerous. So they allowed some blocks to "random tick". Leaves and plants (and other things like water freezing to ice) do such random ticking. 

 

But that wasn't good for things like furnaces which needed continuous code to run plus needed more complex information such as inventories to be stored. Luckily things like furnaces are fairly rare, so for those they can have fully running code -- the fully running code is what a tile entity is.

 

So basically, in order of increasing complexity you have:

- Simple block with no properties (metadata always 0)

- Block with properties (metadata) indicating type (like different logs) or other information (like rotation)

- Block with random ticking to either adjust the metadata (like a plant growing) or to change blocks completely (like water freezing).

- Block with tile entity, fully capable of complex processing (like smelting), animations and data storage.

 

Item Stacks

 

To understand this, you simply need to understand that the Item class really represents a type, and the ItemStack represents the actual item in the world -- meaning a type but also a quantity plus any special information like an enchantment or damage for that particular instance.

 

Basically, an Item never really "exists" in the Minecraft world. Rather there are ItemStacks and the functionality of that ItemStack is defined by the Item in the stack.

Edited February 20, 2018 by jabelar