[1.8] Custom furnace

[Sakuya is my waifu]

so i was digging in TileEntityFurnace class and at the top you can see something like this:

private static final int[] slotsTop = new int[] {0};
    private static final int[] slotsBottom = new int[] {2, 1};
    private static final int[] slotsSides = new int[] {1};

what does those numbers mean?

~thanks

[Draco18s]

Out of curiosity, what's the performance difference between keeping them as constants versus returning

new int[]{0}

every time where is needed?

[Sakuya is my waifu]

so for example if you change up any of those (input, output, fuel) you should have more slots right? but their positions? i don't quite understand where actual slot positions are defined... first time making tile entity with functional container and i'm like  (ﾟｰﾟ

 

[Draco18s]

ItemStack[] inventory = new ItemStack[3]; //0 is 0, 1 is 1, 2 is 2

[Sakuya is my waifu]

derrrp ._. just found containerfurnace class *brainfarts* gonna play around with that ; - ;

[Sakuya is my waifu]

Out of curiosity, what's the performance difference between keeping them as constants versus returning

new int[]{0}

every time where is needed?

Modern JVMs love short-lived objects. The young generation (newly created objects) garbage collectors are very efficient at getting rid of objects, so it might even be faster (because you get less cache-misses) to use a new object every time. In the end both have probably comparable performance and it doesn't matter.

 

So it doesnt matter if i use something like this:

public static final int fuel = 2;

instead of original, right?

[Draco18s]

Out of curiosity, what's the performance difference between keeping them as constants versus returning

new int[]{0}

every time where is needed?

Modern JVMs love short-lived objects. The young generation (newly created objects) garbage collectors are very efficient at getting rid of objects, so it might even be faster (because you get less cache-misses) to use a new object every time. In the end both have probably comparable performance and it doesn't matter.

 

Cool.  Its one of the things I never turned into a property because it was something that was never referenced for any reason except by that interface, so I felt no need to "save it for later."  (More expensive stuff, like Reflected objects, absolutely, but simple objects? na).

 

So it doesnt matter if i use something like this:

public static final int fuel = 2;

instead of original, right?

 

It has to be an array:

public static final int[] fuel = {2};

[TheGreyGhost]

so for example if you change up any of those (input, output, fuel) you should have more slots right? but their positions? i don't quite understand where actual slot positions are defined... first time making tile entity with functional container and i'm like  (ﾟｰﾟ

Hi

You might find this tutorial project useful

https://github.com/TheGreyGhost/MinecraftByExample

 

MBE31 has an example of a custom furnace that explains the slot numbering a lot better than looking at vanilla.

 

-TGG