Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

About GlobalLootModifier system

Recommended Posts

yesterday i decided to port a small mod of mine from 1.12 to 1.16. all in all it wasn't too difficult and took less than a day.

the part that gave me some headache was the GlobalLootModifier system and i want to share the headache with others.

i had the HarvestDrops event in the old branch and noticed it was killed off. simple internet search led me to a few pages on github and apparently this was a big problem and a big hole in forge for months. those days, looks like i would not have been able to port at all... and then i found the instructions about this new system....

so, draco made a thing. i expect people aren't united on whether it's an improvement and i won't go there. the important thing is - this new thing came with a documentation, proper documentation in proper place. plus the three quite different examples for the LootModifier class. documentation and examples? who does that? i made json files like draco said, made LootModifier like he said and the thing worked. it didn't feel like making a forge mod on a brand new version (for me) at all.

with positive item behind us, it was time for negative moments.

in short about the mod: HarvestDrops event is like this (in 1.12 language): loop through drops; for each item stack, if it belongs to the oredictionary group that starts with "gem", there is playersLuckLevel*10% chance to duplicate the item. that's all in there.

so first thing i saw was that loot context has a getLuck method. sweet. launch the game to try and - nope - context.getLuck returns 0.0 when i break a block even though i have luck III effect on me. that's a bug right? looks like a bug.

ok, there should be a player in this context, right? yep, found it. that worked, in terms of me getting a proper luck level, but revealed a few things. first issue was that LootManager.doApply triggers not just for block drops but also when a bat flies into lava or i kill a zombie. that is a bit of a problem for me - i need to spend the first half of doApply method to actually figure out what happened. only when i determine that a player has just mined a block, i can do my main code (outlined above). can we have some enumeration there as a parameter so we know what happened? it would be nicer and faster than every LootManager having to do type checks and casts to know what happened. what do you guys think?

also, turned out that getLuck method returns a correct luck value when i kill a zombie but incorrect one when i mine a block.

that is it for this rant/blog about my first day with 1.16. whoever actually read all of this, will get a sweet berry cookie from me.

Link to post
Share on other sites
18 hours ago, MFMods said:

that's a bug right? looks like a bug.

That is because Minecraft doesn't set the value in the loot context for mining blocks. Why not? Because in vanilla Minecraft luck doesn't affect block drops. Is this a bug? Maybe. Feel free to make a PR to forge to fix it.

As for "figuring out what happend", that's not exactly trivial indeed. But it's also not as trivial to just create an enum and say "the only reasons loot can be generated are now entities, looting from chests and block drops". This limits mods that generate loot in other ways. But this is where the strength of the loot system comes in, because you don't need to actually know precisely what happened. You just know "there is a player involved and we're getting the drops of a block". Whether the player mined the block is not relevant.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.