Jump to content

Draco18s

Members
  • Posts

    16559
  • Joined

  • Last visited

  • Days Won

    155

Posts posted by Draco18s

  1. 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:

    mod-classes.thumb.png.744be98d245e10e786a0bc194743d625.pngAfter 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."

  2. 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.

  3. Tile Entities are more intensive, not less.

    The game already uses baked models for your blocks, so that won't help, other than cutting down startup time (assuming you do less to compute your models than the base game).

    Unfortunately beyond that, I don't think we can help.

  4. By the way, your block's voxel shape is way more complex than it needs to be. And some of the values have gotten very...mm...floating point precision error'd (like, 7.299999999999997 instead of 7.3)

    Grabbed one and ran it through some code I had from the Advent of Code to get an idea of what it looks like (each character represents a 0.5 pixel area).

    It's a mug.

          #############
          #############
     ##################
    ###################
    ###################
    ###   #############
    ###   #############
    ###   #############
    ###   #############
    ###   #############
    ###################
    ###################
    ###################
          #############
          #############
          ###########
          ###########
          #########
          #########

    You could just make that a single cuboid instead of making Minecraft compute the physics shape at such precision. I could see maybe wanting to make it two or three because of the handle, but 50 slices?

  5. Your coder needs to extend the relevant item class to get the behavior you want. I assume that vanilla has a special item class for the sweet berries already and it's just a matter of either using this item for your block, or extending it.

    But yes, showing the current code will help us address the problem.

  6. It's buried in a complex linq expression here, but example:
    https://github.com/MinecraftForge/MinecraftForge/blob/72598871762a98c566689acddec539fa369ed86c/src/test/java/net/minecraftforge/debug/gameplay/loot/GlobalLootModifiersTest.java#L158-L164

    What that linq expression does is check the itemstack passed to the method to see if it has a smelting result (161), and if so, return the result as a new stack (162), else return the original stack (163).

  7. To invert this statement:

    if(other.getBlock() == Blocks.SLIME_BLOCK || other.getBlock() == Blocks.HONEY_BLOCK) return true;

    Do this:

    if(other.getBlock() == Blocks.SLIME_BLOCK || other.getBlock() == Blocks.HONEY_BLOCK) return false;

    You then need to realize that this statement doesn't do what you want:

    return other.isStickyBlock(); //only stick to other blocks if the other block is also sticky

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.