Extending Blocks from Vanilla - Questions about Design Philosophy with regards to Vanilla Block Properties, compatibility

[The_Fizz]

To illustrate my question, I'll first describe what I'm trying to do.

The goal of my mod is to add new Doors to minecraft that are 1x3 rather than the Vanilla doors' 1x2.
These 3-block tall doors should accommodate all the behavior of the vanilla 1x2 doors, including mob interaction (villager opening/closing, pathfinding, zombie breaking).

The vanilla DoorBlock class seems to be very close to what these Tall Doors would need... except for one property and the functions that use it:

public static final EnumProperty<DoubleBlockHalf> HALF = BlockStateProperties.DOUBLE_BLOCK_HALF;

Since the modded doors should have 3 parts, if I were to use this cleanly, I would want something like EnumProperty<TripleBlockPart> PART = MyBlockStateProperties.TRIPLE_BLOCK_PART;

I can do this... if my class does not extend DoorBlock. In fact, I already have the doors functioning without extending DoorBlock. But doing it this way means Villagers, Zombies, and anything else that has behavior specific to DoorBlock won't use my TallDoorBlock properly, and could cause compatibility issues with other mods (e.g. a mod that couples door interaction in double doors, such as Quark)

 

So the point of this thread is to ask how to properly implement this:

public class TallDoorBlock extends DoorBlock {
  //...
}

... while conforming to Forge-friendly design practices.

But this could pose a challenge, since according to this thread - "Overriding vanilla block without extending its class",

Quote

The blocks must have the same set of block state properties.

and

Quote

The properties must match exactly, you cannot add, remove or modify any properties.

 

That seems reasonable enough for most purposes, but since DoorBlock has this property "DoubleBlockHalf" which controls which texture to load for that block, and various interaction state things, I am not sure how to implement a 3-block tall door that extends this without adding a new property e.g. (IsThirdBlock) to manage textrues and interaction for the 3rd block of the door.

 

Is there a common practice for implementing a new Block, modeling from a Vanilla Block class, but needing additional BlockStateProperties that the Vanilla class does not accommodate?

[Draco18s]

6 minutes ago, The_Fizz said:

But this could pose a challenge, since according to this thread - "Overriding vanilla block without extending its class",

That is not what you're trying to do.

You're adding new doors not replacing the vanilla door.

[The_Fizz]

3 minutes ago, Draco18s said:

That is not what you're trying to do.

You're adding new doors not replacing the vanilla door.

Sorry, to be clear, I am trying to Override the DoorBlock class to add new doors.

I did not mean for the title of that thread to have anything to do with my current goal, but was just using information from that thread.

[The_Fizz]

  

22 minutes ago, The_Fizz said:

Sorry, to be clear, I am trying to Override the DoorBlock class to add new doors.

I did not mean for the title of that thread to have anything to do with my current goal, but was just using information from that thread.

To be even more clear, I am trying to Override the behavior of the vanilla DoorBlock class, using Inheritance, to add new doors.

To summarize my questions:

1. Is inheritance from DoorBlock (public class TallDoorBlock extends DoorBlock) the right approach to achieve the desired behavior of a DoorBlock with vanilla mobs like Villagers who interact with doors?

2. If inheritance is the right approach, then is it possible (and the right approach) to add new properties to TallDoorBlock, such as EnumProperty<TripleBlockPart> (where TripleBlockPart is an enum with LOWER, MIDDLE, and UPPER)?

3. If it is the right approach to add a new property (such as TripleBlockPart), what becomes of the vanilla property DoubleBlockHalf inherited from DoorBlock? Should it be used, such as making the middle block of the tall door have DoubleBlockHalf UPPER? And then should the TripleBlockPart UPPER also have DoubleBlockHalf UPPER?

 

(I apologise for my imprecise phrasing)

Edited January 2, 2022 by The_Fizz

[Luis_ST]

24 minutes ago, The_Fizz said:

1. Is inheritance from DoorBlock (public class TallDoorBlock extends DoorBlock) the right approach to achieve the desired behavior of a DoorBlock with vanilla mobs like Villagers who interact with doors?

the Villager interaction on Doors is handelt via the DoorBlock and the WoodenDoors Tag,
a custom DoorBlock which does not extends the vanilla DoorBlock would break the Villager interaction

30 minutes ago, The_Fizz said:

2. If inheritance is the right approach, then is it possible (and the right approach) to add new properties to TallDoorBlock, such as EnumProperty<TripleBlockPart> (where TripleBlockPart is an enum with LOWER, MIDDLE, and UPPER)?

you need to overwrite the complete behaviour, create custom Enums for BlockStateProperties, ...

31 minutes ago, The_Fizz said:

If it is the right approach to add a new property (such as TripleBlockPart), what becomes of the vanilla property DoubleBlockHalf inherited from DoorBlock?

replace it with a custom one

32 minutes ago, The_Fizz said:

Should it be used, such as making the middle block of the tall door have DoubleBlockHalf UPPER? And then should the TripleBlockPart UPPER also have DoubleBlockHalf UPPER?

if you want to do it like that then yes, since you overwrite the block completely it doesn't matter
But I would recommend you to use UPPER, MIDDLE, LOWER. it would make the whole thing clearer

[The_Fizz]

3 hours ago, Luis_ST said:

the Villager interaction on Doors is handelt via the DoorBlock and the WoodenDoors Tag,

This was actually one of the major pieces I needed - I wasn't giving my custom doors the wooden_doors tag, and so while testing the version of my mod that does extend DoorBlock, I wasn't seeing any change of behavior. (Is there a way to do so programmatically, by the way? I plan to patch-in support for other mods' doors, such as Biomes O' Plenty, but for each mod I would need to check their own Tags and see whether they add their mod's door to wooden_doors before doing so in mine, right?)
After applying the wooden_doors tag to my mod's doors, Villagers appear to be interacting with the door alright (with a few buggy things, like they seem to toggle the door 3 times instead of 1 time for a Tall door...), and Zombies... sort of seem to break the door, but the breaking texture overlay is not appearing - something I'll also check out.

So, thank you @Luis_ST!

3 hours ago, Luis_ST said:

replace it with a custom one

My only lingering concern is whether Minecraft depends on the DoubleBlockHalf for more than I'm realizing - for example, if its involved in how a door is toggled by a Villager, then I wonder if that's the reason villagers seem to toggle it thrice?

[Luis_ST]

7 minutes ago, The_Fizz said:

Is there a way to do so programmatically, by the way?

i'm not sure what you mean

7 minutes ago, The_Fizz said:

I would need to check their own Tags and see whether they add their mod's door to wooden_doors before doing so in mine, right?

they also have to use the vanilla Tag, you just have to make sure that your mod is loaded after all other mods.
then loop through the tag values and remove yours and the vanilla doors, then you have the Doors from other mods

12 minutes ago, The_Fizz said:

My only lingering concern is whether Minecraft depends on the DoubleBlockHalf for more than I'm realizing

the class is used in the Data Genaerator (for generationg the models) and inside the DoorBlock

13 minutes ago, The_Fizz said:

if its involved in how a door is toggled by a Villager, then I wonder if that's the reason villagers seem to toggle it thrice?

these is handelt by DoorBlock#setOpen

[The_Fizz]

36 minutes ago, Luis_ST said:

i'm not sure what you mean

36 minutes ago, Luis_ST said:

they also have to use the vanilla Tag, you just have to make sure that your mod is loaded after all other mods.

I'm saying, if a mod adds a Door, it's possible the mod creator does not want Villagers to interact with it and intentionally adds it only to the doors vanilla tag, and not the wooden_doors vanilla tag.

If my mod is to implement a Door of my Mod's class, TallDoorBlock, but based on the door from the other mod, I have to manually check that other mod to see whether the creator of that mod gave it the wooden_doors tag to know whether my mod should apply the wooden_doors tag to the TallDoorBlock version of that door as well.
Ideally, I would be able to programmatically add the TallDoorBlock version of the door to whatever tags the other mod creator decided to add theirs to, so that I don't have to check the tags defined in the resources of that mod's jar file myself for each third party door type I wish to support.

Does that make sense?

Does forge provide utility methods to read tags set by already-loaded mods?
How can I set the tags for blocks added by my mod without writing it in the DataPack itself (resources/minecraft/tags/wooden_doors.json)?/Does forge provide a way to set tags dynamically (generate the tags in the datapack, from Java code?)

If this is documented somewhere, please feel free to link it! Right now I'm reading from https://mcforge.readthedocs.io/en/latest/utilities/tags/, but it only seems to describe adding tags in the DataPack of your mod.

[Draco18s]

9 hours ago, The_Fizz said:

Sorry, to be clear, I am trying to Override the DoorBlock class to add new doors.

Are you replacing the vanilla doors?
No?
Then you are not overriding the registry entry for vanilla doors. The "overriding vanilla blocks" issue deals with registering a block with the same registry name of a vanilla entry (eg. "minecraft:door"). You are not doing this, the problem that thread mentions is not relevant.

You are extending the door class. You are overriding methods not the blocks.

You can do whatever the heck you want to your own blocks, you don't even need to extend BlockDoor if you want to (though not recommended). The problem mentioned in that thread is how due to the way blockstates are serialized you can't add new states to existing blocks. You aren't adding new states to an existing block, you're adding whatever the fuck you want to your own block.

[The_Fizz]

1 hour ago, Draco18s said:

Are you replacing the vanilla doors?
No?
Then you are not overriding the registry entry for vanilla doors. The "overriding vanilla blocks" issue deals with registering a block with the same registry name of a vanilla entry (eg. "minecraft:door"). You are not doing this, the problem that thread mentions is not relevant.

10 hours ago, The_Fizz said:

To be even more clear, I am trying to Override the behavior of the vanilla DoorBlock class, using Inheritance, to add new doors.

To be honest, your tone could use some work. I know you provide assistance for free, but this does not need to be a toxic environment.

As you can see, I already clarified what I meant - I am overriding behavior of the vanilla DoorBlock class - or as you say just now, methods, which, yes, define behavior, which I said already.
Like I also already said and apologized for, I did not mean for the thread I linked to imply I had the same goal as theirs. Regarding that thread - as I've already said - I was repeating the restriction stated there ("The blocks must have the same set of block state properties") to seek clarification on to contexts in which it applies. Despite your repetition, there is nothing inherent about the way that restriction was described in that thread that implied it only applied for the thread author's stated goals or key issue and not for the practice of extending classes in general, possibly due to limitations of the Minecraft-Forge ecosystem.

Please be patient with addressing the difficulties of semantics.

[Luis_ST]

so in summarize you want to extends the vanilla Doors to a height of 3 Blocks?
am I right?

[Draco18s]

11 hours ago, The_Fizz said:

As you can see, I already clarified what I meant - I am overriding behavior of the vanilla DoorBlock class - or as you say just now, methods, which, yes, define behavior, which I said already.

Yes I know how that works. The problem was that you used the language in an ambiguous way such as to convey a lack of distinction between overriding the behavior of the existing vanilla doors vs. overriding the behavior by class extension for new doors.

11 hours ago, The_Fizz said:

I was repeating the restriction stated there ("The blocks must have the same set of block state properties") to seek clarification on to contexts in which it applies. Despite your repetition, there is nothing inherent about the way that restriction was described in that thread that implied it only applied for the thread author's stated goals

The restriction, as stated by diesieben07, was in direct response to "I got this error." That error only applies to the situation of replacing vanilla blocks with your own to modify the behavior of the vanilla blocks. If you had read further down, you'd have found this:

On 8/19/2021 at 3:35 AM, EMT32 said:

This diagram should make it easier to understand:

After changing the code to use original block properties I'm able to run it without any errors.

Which precisely details the type of state extension you are interested in performing with the comment "this works."