Draco18s

In trying to help Custom Ore Gen get updated for 1.14 I noticed that: a) OreGenEvent is gone b) Nothing has replaced it c) The features field of the biome (which now handles ore gen) is protected with no getter. What's the intended way to go about modifying ore generation now?

You break out of the loop. It terminates. No more looking at other directions. Everything's over. Go home. Return to when ye came.

WE FOUND ONE, ABORT THE SEARCH, SEND EVERYTHING THERE.

Yes, that is quite informative.

https://mcforge.readthedocs.io/en/latest/concepts/registries/#injecting-registry-values-into-fields

I did not know this was a thing. Thanks.

Error is pretty self explanatory.

Yes. I know that. That wasn't my question. My question was why the separation between hasCap and getCap even existed at all. Because 95% of mod makers aren't people with a decade of professional experience learning from people with an equivalent amount of experience (and from a decade of experience, I can assure you that even that isn't sufficient sometimes) as evidenced by the number of people who come here asking for help and say they've "been following LoreMaster's Youtube tutorials" or "using MCreator" or similar. See prior comment. In my own code I did it because I hadn't done a clean up pass on the code yet. I did a quick-and-dirty get-things-working implementation that I knew was not fully compliant with good practices. My focus was on re-implementing existing mechanics, not optimizing performance. Hell, I wouldn't have even thrown my crap up on GitHub if it weren't for the fact that I had an unrelated issue (invalid data files causing all data files to fail). If it really bothers you that much, I've now fixed it. Regarding the old system, what I was agreeing with, and what d7 actually said, emphasis mine: Yes, except I don't know how you expect[ed] people to implement this [correctly]. No one did it right, despite the Forge-supplied examples because: (1) no one looks at Forge supplied examples, (2) they're lazy, and (3) they don't care. And my addendum was (4) even if they did they would find places where hasCap was never called anyway leading to confusion about what it was for and why it existed and people continuing to implement it in the getCap!=null way. Examples? Well I said I wasn't sure if I was remembering correctly. But sure, let me go look... Here's one (1.12.1 build 2462; because that's what I had built an old mod against and had readily available). net.minecraftforge.client.model.animation.AnimationTESR: IAnimationStateMachine capability = te.getCapability(CapabilityAnimation.ANIMATION_CAPABILITY, null); if (capability != null) I'm trying to understand the separation between hasCap and getCap. You have more experience than I do, you designed it, but its really frustrating for me to communicate with you.

That I can agree with, its just that for the vast majority of use-cases the caps are something that are existent before "anyone" calls for it because it's used by the TE itself (inventory, energy, etc). And that's why "everyone uses it wrong." They use it "wrong" because the performance difference is so negligible as to be irrelevant. Then, if you're going to call has() followed immediately by get() if you're interested in a Thing, its going to need to be constructed anyway. And if Thing wasn't meant to be provided under the conditions you queried, it won't get created. I wasn't asking about your specific chunk of pseudocode. I was trying to ask in general. The "I see what you did there, but what about x?" In any case I am just trying to get a handle on the reasoning behind the design decision; I've met you in meatspace, I know you're not this grouchy, so stop taking everything I say as a personal attack. But I'm going to have to disengage.

MCreator is absolute garbage. Stop using it.

Is hasCap supposed to return true for a given capability, even if that capability is only exposed on one side? Also, why would you check this here? Wouldn't you create the handler in the TE constructor? Also no one (that I know of) does this. The worst case I know about is doing CombinedInventoryWrappers and that's usually only for when the side is null (block breaking covering 90% of cases where it would be called with a null side). And if the Combined wrapper is really that expensive, then fine, I can cache it, no problem.

Also you should post in Support & Bug Reports for issues like this. Modder Support is for people who make mods.

WTF is this garbage?

I don't see what the problem (in a technical sense) is. You have a block, it has a facing state and it has a powered state. Got it. What's the issue?

I would swear that when I went looking, Forge (that is, in the vanilla patches) didn't use hasCap anyway (it did the null check). That was a while ago, so I could be wrong. In any case, d7 is basically right. The logic in the two functions was the same, and I never saw a reason to duplicate that code. I suppose the logic could have been in hasCap and getCap would query hasCap to decide whether or not to return...except that doesn't help when you have multiple capabilities that are of the same type but discriminated by side. So back in getCap the logic went.

Lets see...is it running on the client? Yes! Is it running on the server? Yes! Is it running on both sides? Hmmm....

We will not help you.

Why does it matter? Thieves don't care about your source and you can't protect the jar.

No one is going to steal your code. They're going to steal the compiled, obfuscated jar.

Didn't have it handy or I would have. https://github.com/MinecraftForge/MinecraftForge/issues/5615

This is correct. I had a mod that adjusted biome temperature/rainfall over time (for seasonal variation) and there would be grass/leaf color discontinuities right along standard chunk boundaries where one side hadn't been re-rendered recently.

Blockstates can only change models right now. Defaults are ignored entirely and texture overrides don't. They're parsed but not actually applied. There's already an open issue on Forge's git repo.

You haven't registered your event handler. This would be done with the @EventBusSubscriber annotation

Hmm. Yeah, looks like I had a bad recipe or two. That did the trick. Seems really unhelpful that one bad data file causes all data files to be bad. I'd been ignoring it because "I'm not worried about that right now, I want to test my enchantments."

Its funny what you can find by searching.