Draco18s

You seem to be wanting to affect the horse, but you look for cow. That item doesn't exist in that loot table, so I'm not sure why you're doing that. Hopefully you pulled in my LootUtils class, yes?

That event does not exist on 1.14. Well, the class does, but it isn't fired. https://github.com/MinecraftForge/MinecraftForge/pull/5871

And now you know why I use my EasyRegistry class The only time I have that kind of problem is when there's a new type of thing I need to register.

You need to tell Minecraft that your model exists in the ModelRegistryEvent, like so: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L198

Having messed with it recently (could weeks ago), have my results: https://github.com/Draco18s/MinecraftForge/blob/Global-Loot-Funcs/src/main/java/net/minecraftforge/common/loot/LootModifierManager.java#L36 Note that the MinecraftServer instance needs to know about your JsonReloadListener. https://github.com/Draco18s/MinecraftForge/blob/Global-Loot-Funcs/patches/minecraft/net/minecraft/server/MinecraftServer.java.patch#L24

Use player.getAdvancements() as your PlayerAdvancements object. The way trigger works is that trigger is passed a player and calls getAdvancements on it in order to get all the listeners. You'll have to do that for every player that joins the server (and call remove when they leave).

You'd have to see how Advancements uses them, I'm pretty sure you can utilize the existing systems for your own use.

What is your use-case here?

Oh. 1.12 Use this: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/LootUtils.java Take that whole thing, put it in your project in (use your own package) and invoke its methods during the LootTableLoadEvent. (Yes, you can use it, its a utility class, I really don't care. I did a lot of futzing around figuring out how the stuff works so you don't have to) Example usage https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/farming/FarmingEventHandler.java#L425

This is unused. You create a SetCount object and then immediately discard it. Also, you should definitely do this json-ly. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/EventHandlers.java#L49-L57 https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/data/harderfarming/loot_tables/entities/leather.json

That's mostly just creating a list or other Set that contains unique blockpos locations for each tree.

Oh yeah, a lot of it isn't relevant, I just meant the one-or-two functions (down to line 395) for propagating upwards from the "root" and making sure to catch every log. That's also old 1.10 code, but basically all it does is look at blocks above and blocks adjacent (as well as 1-above the 8 adjacent positions). That code absolutely catches every log in all the vanilla tree types. This function did the chunk scanning for generated trees (the task you've stated as still needing). https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/util/TreeCountGenerator.java#L55 But it's not perfect. There's all kinds of weird edge cases that are hard to detect correctly (like the aforementioned floating trees).

That horizontal propagation will also work for dark oak (but you'd probably still want all four base blocks "tree" root blocks). Here's how I handled it: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/util/TreeDataHooks.java#L338

Oof, good luck. I did work that tried to detect "living" trees and there are so many edge-cases its insane. Does a tree that has the ground under it replaced by a lake count as "living"? Does a tree growing on gravel count as "living"? Do those 1-tall "bushes" in jungles count as "trees"? Are dark oak trees 1 tree or 4?

It effectively doesn't exist. See this comment: https://github.com/MinecraftForge/MinecraftForge/pull/5871/#issuecomment-542697064

getOpposite doesn't care about horizontal or not.

No, that would be wrong. context.getFace() is the face you're placing against (so the North face). Getting the opposite of that would give you South, facing the block into the block you clicked on, not facing the player. To use the player's facing you use (gasp) context.getPlacementHorizontalFacing() (Its almost like you looked at your own code and went "this is what I use to do the thing you want, so don't do that, do this other thing")

1) Use a spoiler tag 2) "Exit Code 1" is not an error. It is simply the last thing printed before the executable closed (in this case the 1 means "there was an error") This appears to be the actual error: [21:46:18] [main/INFO] [STDERR/]: [java.lang.Throwable:printStackTrace:643]: Caused by: joptsimple.MultipleArgumentsForOptionException: Found multiple arguments for option output, but you asked for only one

Dug into it, found all the right bits, wired it up and...nothing. Turns out: Allow mods actually to have their own usable config gui (#6208) JoJoDeveloping authored and LexManos committed 4 hours ago The bit that allows it to show up was literally just added.

Gotcha. I'll look into it.

Ok, my config toml file is getting populated with values, but the config button on the main menu's mods list is still grayed out. (And yes, the description there is wrong, I put the wrong one in the toml file)

I've seen Cadiboo's code regarding configs (see his post, here), but in implementing it myself I'm not seeing it in-game nor am I getting a config file generated on disk (ok, the file is generated, but it is blank). I'm not sure what I haven't set up, as far as I can tell, its exactly like Cadiboo's example (just with different config fields). https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/flowers/OreFlowers.java#L44-L55 https://github.com/Draco18s/ReasonableRealism/tree/1.14.4/src/main/java/com/draco18s/flowers/config

*Shrug* From my point of view, you created a bunch of stuff all at once (maybe copy-pasted from an old version?) without checking any of it to make sure it worked before going for more. Always work on one block or item or system at a time, make sure its working 100%* before moving on to another. *Sure, there are things that interleave sometimes, such as a crop and its seed, those can be worked on as a single operational group. And sometimes you need to break a thing down into smaller pieces and work on them and they won't be 100% until the larger structure is done, but you can handle that with placeholders and TODOs, but there you know what part isn't complete when you test it (for example, my ore system relies heavily on Custom Ore Gen and several ore generation events that don't exist, but that doesn't mean I can't make the blocks, items, loot tables, recipes, and enchantments, I just know I can't test the ore gen and prospecting systems until those events exist).

Probably.

The simple answer is "any and all." The only time you wouldn't need to would be if you were going to send a new packet somewhere and did not need to interact with anything outside the handler's current scope. These situations will be so rare and edge-case as to be practically nonexistent.