The_Fizz

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.

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.

I'm working on porting a version of my mod from 1.16.5 to 1.18.1. After refreshing the Gradle project (from the 1.16.5 forge dependency to the 1.18.1 forge dependency), my IDE was suddenly unable to resolve the Constants import. I struggled to find any online documentation regarding this, and only after a lot of trial and error I noticed that using forge for 1.17.1 helped resolve the import, and marked it deprecated, with docstrings describing where to find the 1.18.1 equivalents. If this sort of thing happens again, where in the documentation can I find deprecation lists and related information across versions? (so that I don't have to flicker between Gradle dependencies and reload the entire project - which seems a little unstable with my IDE, which is VSCode in case it matters). Thank you in advance!

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! 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?

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)

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 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", and 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?