[1.16] Converting a legacy block after update

[A Soulspark]

After accepting the way I was doing things in my mod wasn't quite ideal, I decided I have to upgrade a certain block when users update into the newest version of my mod.

This block currently has a Content blockstate (an enum with 3 values) and it should convert into a different block for each value. So,

• tea_kettle:kettle[content=empty] -> tea_kettle:empty_kettle
• tea_kettle:kettle[content=water] -> tea_kettle:water_kettle
• tea_kettle:kettle[content=hot_water] -> tea_kettle:boiling_kettle

 

I just don't know how to do that! Maybe I'd need to keep the tea_kettle:kettle block and when it gets instantiated into the world, I immediately run the conversion. But

1. How do I detect a block getting instantiated?
2. Is there a better solution to this?

[Draco18s]

Honestly this is a perfectly valid blockstate block. All three "versions" are a tea_kettle, but with some stateful information (full, empty, hot).

[A Soulspark]

 

20 hours ago, Draco18s said:

Honestly this is a perfectly valid blockstate block. All three "versions" are a tea_kettle, but with some stateful information (full, empty, hot).

That's true, but an empty kettle doesn't need a tile entity, whereas the other two do, and they have other states that are only necessary in each case.

e.g. the boiling kettle has a fullness state, for how many uses it has left. this isn't necessary for empty or full kettles, as their "fullness" doesn't change: it's 0% or 100%.

 

Plus, each version also has a different item/name/texture, and it was really troublesome to manage all that in a single item and block.

If what I'm trying to do is extremely forbidden, then I could revert ofc. But this just sounds like it makes more sense :v

[kiou.23]

14 minutes ago, A Soulspark said:

 

That's true, but an empty kettle doesn't need a tile entity, whereas the other two do, and they have other states that are only necessary in each case.

e.g. the boiling kettle has a fullness state, for how many uses it has left. this isn't necessary for empty or full kettles, as their "fullness" doesn't change: it's 0% or 100%.

the method hasTileEntity, and createTileEntity, take the current blockstate as a parameter, so you can decide wether or not your block has a tile entity based on the blockstate. that solves this problem

 

blockstates do seem like the easier way to do what you want...

[A Soulspark]

29 minutes ago, kiou.23 said:

the method hasTileEntity, and createTileEntity, take the current blockstate as a parameter, so you can decide wether or not your block has a tile entity based on the blockstate. that solves this problem

 

blockstates do seem like the easier way to do what you want...

ok, I'll try that. but is it possible to have multiple block items for the same block, just with different states? last time I tried this, the Creative inventory got messed up and it just added one of the items multiple times.

 

p.s.: I do need multiple items because there are recipes where only hot kettles can be used.

[Draco18s]

Yes, but you need a custom BlockItem that knows what state needs to be set.

[kiou.23]

12 minutes ago, A Soulspark said:

ok, I'll try that. but is it possible to have multiple block items for the same block, just with different states? last time I tried this, the Creative inventory got messed up and it just added one of the items multiple times.

what comes to mind is that you could extend BlockItem, to make a KettleBlockItem, which places a block with a given blockstate, which you can set when creating a new instance of it in registration... look like the more elegant way of doing it, but I'm really not sure (and after looking at the BlockItem class for a few seconds trying to see wht you could override, I imagine it'd give a headache)

and you could change what item the block drops based on blockstate as well

Edited March 15, 2021 by kiou.23

[A Soulspark]

2 hours ago, Draco18s said:

Yes, but you need a custom BlockItem that knows what state needs to be set.

2 hours ago, kiou.23 said:

what comes to mind is that you could extend BlockItem, to make a KettleBlockItem, which places a block with a given blockstate, which you can set when creating a new instance of it in registration... look like the more elegant way of doing it, but I'm really not sure (and after looking at the BlockItem class for a few seconds trying to see wht you could override, I imagine it'd give a headache)

and you could change what item the block drops based on blockstate as well

alright, I think this turned out well. I had already done this "multiple items per block" thing before, but this time I managed to solve the duplicate items in Creative by adding a fillItemGroup() override to my items. I still had to split the blocks into Empty and Water Kettles because I'll later add Milk Kettles too.

Still, it indeed would've been a lot messier if I'd done it with 3 blocks and 2 tile entities lmao. thanks for the guidance!

[Draco18s]

You can get an idea of how I handle it here:

https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L134

(I needed to support Silk Touch on a property that made no sense to be separate blocks)

Magic registry stuff (old event-style rather than new DeferredRegister style):

https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L57

getPickBlock (reg names were dynamic, so this is a bit ugly):
https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java#L80

getStateForPlacement:
https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java#L90

 

I had to do some custom shenanigans for the loot table as well. But if your three items are sensibly named I don't think you need to do much that vanilla doesn't already support. It was just easier for me to write a loot condition that got the blockstate's numerical value and did a lookup on the item than it was to specify a 1:1 relationship in the loot table.

Edited March 16, 2021 by Draco18s