-
Posts
16559 -
Joined
-
Last visited
-
Days Won
155
Posts posted by Draco18s
-
-
11 minutes ago, modrinth said:
boolean FlashSwitch = false;
Blocks and items are singletons, this value is shared across all "instances" of your item. You have to store this data in an ItemStack's capability.
-
Solved
public static final DeferredRegister<LootItemFunctionType> FUNCS = DeferredRegister.create(Registries.LOOT_FUNCTION_TYPE, MODID);
I hadn't been able to find Registries.LOOT_FUNCTION_TYPE
-
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
-
-
De/serializer gets a null serializer to serialize with
-
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
-
Using Forge registries
-
Just so you know, that's not the only way items can end up inside block inventories.
I know there's a way for the inventory to determine if an item is valid for its slot, but I'm not sure there's a reciprocal call asking the item if it can be placed in the slot.
-
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.
-
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. -
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.
QuoteForge 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_asmFabric 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.
-
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~! -
4 hours ago, Luis_ST said:
A Double value should never be null.
If you wish to disable the logic use a value which will deactivate the code (like 0).
Then execute the code only if the value not the deactivation value (in this case is larger than 0).A Double (with a capital D) absolutely can be null, because it's an Object that boxes a double (lower case d).
-
Nope, that class looks fine.
Did you register the serializer? Did you add it to the forge/global_loot_modifiers.json list? -
You have an error on line 85 of CopperKilnGuiMenu
-
14 hours ago, tomatosauce said:
As far as I know, the shapes and voxel shape classes only seem to work with quadrilateral shapes.
Correct.
Look at how vanilla handles the lectern. -
BlockState#GetBlock()
-
16 hours ago, Gepardius said:
Minecraft.getInstance()
This is client side only.
-
BlockPos.GetAllInBox, or whatever mojang called it.
It literally gives you an iterable that solves this.
-
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..."
-
You can use the block's Material
-
"Exit Code -1" is just the "application closed with an error" message, it is not itself the error.
Post the whole log.
-
Need more context
-
Well.
Yes.
Blocks aren't meant to take up visual space outside their 1x1x1 cube. Two vanilla blocks have this issue as well.
-
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.
-
Compare a stored worldtime to the last-checked world time.
If different, you know it hasn't ticked any times, if it has, it's ticked at least once.
-
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.
-
https://bugs.mojang.com/browse/MC-1127
Resolved as "working as intended"
3 minutes ago, Syric said:when I place two of the custom block on top of each other
Clarification required.
[SOLVED] Modifying canApply doesn't affect enchantment table
in Modder Support
Posted
Override boolean canApplyAtEnchantingTable(ItemStack stack, Enchantment enchantment) in your item class.