Jump to content

Draco18s

Members
  • Posts

    16559
  • Joined

  • Last visited

  • Days Won

    155

Posts posted by Draco18s

  1. I have a custom loot function that I want to have run when my own loot tables for my own blocks runs (it sets the number of drops based on a blockstate value).

    Things that did not work:

    • Using Forge registries
      • Forge does not provide a replacement for BuiltInRegistries.LOOT_FUNCTION_TYPE
      • Forge also does not appear to need or provide a replacement for BuiltInRegistries.LOOT_CONDITION
        • CanToolPerformAction just creates a new LootItemConditionType and runs with it, no registration needed

    • Using an existing LootItemFunctionType in LootItemFunctionType getType()
      • De/serializer attempts to cast my function to an unrelated function
    • Using a new LootItemFunctionType()
      • De/serializer gets a null serializer to serialize with
        • Cannot invoke "net.minecraft.resources.ResourceLocation.toString()" because the return value of "net.minecraft.core.Registry.getKey(Object)" is null

    • Attempting to make the same calls LootFunctions.register does
      • Fail with fml.modloading.failedtoloadmod
    • Attempting to make the same calls as LootFunctions.register at different points during the init/setup process (tried numerous events)
      • Most fail with an Optional.get() returning no value (in this case, trying to get the built in registry's ResourceKey as a ResourceKey<E> not a ResourceKey<? extends Registry<E>>)
      • Others fail with fml.modloading.failedtoloadmod

    Things I will not do, but which would probably work:

    • Individually test against 16 different values and individually compute the resulting fixed value count
      • This is so dumb I'm not even going to pretend that I should consider it
  2. Because the when the game is compiled by Mojang, those names cease to exist. So when Forge decompiles it, it has to give them new ones. Those new ones are what's called SRG names, which are unique for every field, variable, method, and class, but are stable from one minor version to another (eg. 16.1 and 16.2 will decompile to the same SRG names). A second pass is then done to convert those into human readable names...which doesn't have a human readable name for everything, so the leftovers are left with SRG names, because someone has to go figure out what the human readable name should be and update the mapping.

  3. Long answer short:
    No, there is no documentation.

    Longer answer:
    The code changes so often and so dramatically that any attempt to document it is impossible (there are a few people who've tried, the last time I saw them update was 1.7). As such your only recourse is to read the code.

  4. 6 hours ago, warjort said:

    Fabric: An a-la-carte (don't pay for what you don't need) approach where the fabric-api concentrates on common use cases and the ecosystem provides more specialised apis, and don't expect it to hold your hand when it comes to writing correct mods

    It also leads to everyone writing their own API addons that duplicate efforts and makes things incompatible with each other because everyone creates a patch that does what they need and only what they need. It also means that when Minecraft updates if you have a mod that relies on one of these additional specialized APIs, you have to wait on that author to update it, even though Fabric's main API is already current.

    Quote

    Forge itself has something of the a-la-carte with mods like curios, "waila", jei, patchoulli, terrablender, etc. having specialised apis not provided by forge.

    Neither Waila nor JEI require additional source patches to work with Forge. They have their own APIs, yes, but that's not what I'm referring to when I say that Fabric requires modders create additional hooks inside vanilla code.

    Forge makes sure that every mod stays well out of vanilla code so that mods don't conflict with each other and crash the game.

    I'm referring to this:
    https://fabricmc.net/wiki/start#mixins_asm

    Fabric pushes modders towards ASM. ASM is dangerous, complex, and highly fragile. It can lead to code that crashes code that isn't your code with the resulting stack trace having no evidence as to which mod caused the issue! It can DO anything, but it doesn't do it safely.

  5. 4 hours ago, Paul Carlisle said:

    could port a fabric mod to forge

    AH HAHAHAHAHA! 🤣

    No seriously though, the two ecosystems are so wildly different that it wouldn't be so much a "port" as "rewritten from scratch."

    Forge: make everything compatible because no one touches vanilla code directly. If Forge doesn't make what you need possible, make a PR.
    Fabric: we can update to new versions quickly because we only have the basics. So if you need something special, you're going to have to patch the vanilla code yourself, have fun~!

  6. 19 hours ago, diesieben07 said:

    Tags are a better option here. Check for BlockTags.LOGS or BlockTags.PLANKS respectively.

    That only gets you LOGS and PLANKS, he doesn't want to know if the item is wood, he wants to know if it's made of wood.
    Example: jungle door.

    Jungle Door is made of wood, but is neither a log nor a plank.

    Doing it with tags, and not creating a new tag, you'd have to check:

    • logs
    • planks
    • wooden_buttons
    • wooden_doors
    • wooden_fences
    • wooden_pressure_plates
    • wooden_slabs
    • wooden_stairs
    • wooden_trapdoors

    And possibly still have to check for other blocks like ladders.

    I'd even go so far as to say the tag mineable/axe would cover it, but it's more like "everything in mineable/axe except..."

  7. 11 hours ago, diesieben07 said:

    This. Catching StackOverflowError is a bad idea (like with any Error).

    Kinda sorta.
    Don't catch fatal errors. Don't create boneheaded errors in the first place so you don't need to catch them.

    Exogenous you must catch, while vexing are...well, vexing: the product of unfortunate design decisions that may (or may not) have a Try alternative that doesn't throw an exception when there's a problem, but if not, the exception must be caught.

    https://ericlippert.com/2008/09/10/vexing-exceptions/

  8. 40 minutes ago, Syric said:

    This matches warjort's info, which says that the game calculates friction based on the block 0.5 blocks below the bottom of the entity.

    My info*
    I looked at the code for it back in 2013, which was in the linked bug report. Warjort just rephrased it.

    40 minutes ago, Syric said:

    My block is as thin as a snow layer. When I put two on top of each other (so with most of a block of empty space between them, like stacking carpets)

    That's what I thought, but I wasn't sure if you meant like carpets or like snow layers where you can make the block thicker, but still take up less than a full block.

×
×
  • Create New...

Important Information

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