So say I want to create a bottle that holds a liquid that can be used in crafting (similar to water bottles in brewing) and a bucket of the same liquid used to pick up and place source blocks of that liquid. When I create the item, would I want to use

public static Item contatiner;

,

public static ItemGlassBottle container;

, or

public static ItemBucket container;

? WHat is the difference between each of them? How would they be used?

If you are referring to the declaration in your main mod file,

Item

is sufficient.  It is unlikely you will be directly referencing the

ItemBucket

methods not present in

Item

anywhere in your code except inside your bucket.

 

But if you do, you can just cast it to a local variable anyway.

But what is the difference between each of them? Why would I use and not use each of them. I currently have two of my items (which are glass bottles holding fluids) as

public static ItemGlassBottle item_name

instead of

public static Item item_name

. Should I have done this or shout I leave it as

Item

? What changes does it make from Item to ItemGlassBottle or other corresponding Item definitions.

 

 

EDIT: Same things for block creation. I'm trying to create a block that will act like air (invisible, untouchable, etc.). Would I use

Block

or

BlockAir

when I create it? What's the difference?

Are you talking about the type of the field that holds the instance or the type of the instance itself? The type of the field doesn't matter (as long as it's compatible with the instance's type), the type of the instance determines the behaviour of the block/item.

 

ItemGlassBottle

overrides

Item#onItemRightClick

to decrement the stack size and add a water bottle to the player's inventory when they right click while looking at water. This is hardcoded to detect water and add a water bottle, so if you wanted to do the same thing for your own liquid you'd need to override the method yourself. Since

ItemGlassBottle

doesn't add any other behaviour, there's not much difference between extending

Item

and

ItemGlassBottle

.

 

BlockAir

overrides several methods to make it completely invisible and untouchable, so it's probably easier to extend it or instantiate it directly when making a similar block than extending

Block

and overriding the same methods to do the same thing.

So if I wanted Glass Bottles and Buckets to pick up my own custom liquid, I would have to remake the

ItemGlassBottle

and

ItemBucket

to fit my liquids as well? Would this require the creation of a new, custom bucket and glass bottle item or not? If not, how would I make sure that normal glass bottles and buckets can pick up my liquid?

You can subscribe to

FillBucketEvent

to allow the vanilla bucket to pick up your fluids. You may want to make sure the

Fluid

being drained is one you've actually specified a bucket model for, otherwise you'll end up giving the player an item with no model. There's no equivalent of this event for the glass bottle; but you could subscribe to

PlayerInteractEvent

(with the

RIGHT_CLICK_AIR

action), check that the player is holding a glass bottle and looking at one of your fluids, give them the appropriate filled bottle and then set

useItem

to

Result.DENY

.

 

How you implement the bucket item itself is up to you, you can either use metadata or NBT to store the contained

Fluid

. If you're using metadata, you can register it with

FluidContainerRegistry

. If you're using NBT, you can implement

IFluidContainerItem

(or extend

ItemFluidContainer

, the default implementation);

FluidContainerRegistry

doesn't support NBT-based containers.

 

You can see my

FillBucketEvent

handler here and my bucket item here. A lot of this logic is adapted from the vanilla bucket.

But what is the difference between each of them?

 

The difference is called a subclass.  The reason we use

Item

and

Block

is because we don't actually care about the subclass 99% of the time, so it makes things cleaner.

 

The only reason you'd use

ItemBucket

(etc) is if you are doing a lot of casting from simple type to specific subtype.  For example if you really really wanted to you could just use

Object

instead.  But you'll find yourself doing a whole lotta casting.