Draco18s

I didn't either, but I am aware that there are things that I am not aware of. (Any other comments on that PR? I've been literally begging for feedback for months). Thanks.

Works for me, I just wanted to query whether or not that was the best practice for something like this.

Based on comments from Lex on my PR for global loot modifiers (so that modders don't need to replace loot tables when creating new enchantments and other effects), one of the sample test mods is set as making a specific item act like silk touch (the use-case was someone wanted one of their mod items to silk-touch harvest glass blocks and only glass blocks, the test mod doesn't do the check for glass, but the general process is going to be the same). As such, invoking the existing loot tables with the extra context parameter (or rather, a modified itemstack parameter) in order to not make assumptions about what silk touch actually does (as someone could create a block that drops something besides itself when harvested with silk touch) to generate the correct loot is the correct approach. However, this requires rebuilding the LootContext object and Lex made this comment: https://github.com/MinecraftForge/MinecraftForge/pull/6401#discussion_r363968404 What is the better way to do this? Using reflection to access the private-final fields does not feel correct to me, as any changes made need to be undone after invoking the loot table generate (as there may be future loot modifiers waiting to be processed), which is why I (attempted to) clone the context object.

Can you please stop making your posts entirely unreadable? Thanks.

Oh hey look. A static initializer. Don't do this. It fucks everything up. Problematic Code #8. This is literally what @ObjectHolders are for. Not this garbage. Edit, I see you're using this to register your blocks. Don't do this either. Just call new inside the registry event.

Ok. Let me very, very blunt here. Explain your problem and post all relevant code, preferably as a git repo. Your last several posts have flip-flopped back and forth over what you did (or didn't do), that it worked (or didn't), and trying to ask a question about why what you did worked (or didn't) that I have no fucking clue what it is you're asking me (including whether or not you still have a problem!).

1.14 is mostly the same as 1.13, which is why it didn't get updates.

...what? Of course it works with "the basic forge" (there is Forge and there is Forge, there aren't "extra plugins"). Your question makes no sense.

I misunderstood. Yes. You need the forge_marker in order to use forge states.

This is new. Just had to do a search for it, as this is the first I'd heard of it. I hadn't read this thread when it was new:

If it "does the same thing with or without that line" then that line isn't related to the error. (That line is what lets you specify two variants once each, rather than X*Y times)

What do you want to display there?

This is what advacements are for. Look at the vanilla data package data/minecraft/advacements/recipes

You removed the facing property and the errors involving the facing property went away. Gasp. The underlying issue (whatever it is) still exists and nothing has changed. I don't know what this issue is.

And the other half of my post?! You still haven't explained why you're going out of your way to get mutable objects only to make them immutable when getAllInBox already returns an immutable list.

So. Question. Why are you asking for an interable of mutable positions if you're converting it to a list of immutable positions? BlockPos.getAllInBox(...) already returns an itterable of immutable positions. You've literally gone out of your way to ask for a mutable list and then gone and turned it back into an immutable one when you could have requested an immutable list in the first place. Related: This does nothing useful. You could have just done Selected.add(pos.toImmutable()).

A question you'd already answered and which wasn't the post you quoted. Ergo why D7 asked "How is that at all related to the message you quoted?" It wasn't related to the post you quoted, but to a post two or three prior.

No, D7 did not do that: That is the version of JDK I am using. That is the last version of the Java 8 D7 suggested reinstalling Java, it was not a question.

Still Drinking

Aren't the item form of blocks present in the static list in Items? I would swear that they were (but will accept fever-dream explanations).

I would have thought so. I can't find any reason why it wouldn't be. The way to approach things is to ask "how does vanilla do this?" There's a few things that vanilla does poorly, but often answers can be found by asking yourself, "what vanilla blocks do the thing I want to do?" Its fine that you asked a question when you had a problem with what you tried, but the problem with your post is that you asked: a question that was dumb ("what's the difference?" answered by looking at the source and seeing that they do two very different things) a question you already knew the answer to ("I'd already seen that") and a question to which the answer supplies no helpful information to the problem you were facing ("I tried that and it still doesn't work") What you should have asked was "I overrode isSideInvisible, but it isn't being called. Why?" and then posted all of the relevant code. So. Post all of your relevant code, preferably as a link to a clonable git repo. We need to see more than just your block class.

Is ItemList a class that extends Item? Is ToolMaterialList? No? Go find your class that extends Item.

Let me just pull up the vanilla source and... gosh, would you look at that. One of them is static and does a bunch of stuff involving voxel shapes, the other isn't static, takes in an adjacent side, and returns a boolean. And oh yeah, the former method calls the latter (if isSideInvisible returns true...shouldSideBeRendered returns false). That seems relevant.