ChampionAsh5357

If you create the blocks and features, then you would need a mod. However, all of that would still be handled by the datapack itself. If you wanted those ores and features to spawn in a vanilla biome, then you would use BiomeLoadingEvent after you update to the latest minor.

1.12.2 is not supported on this forum. Please update to at least LTS 1.15.2 to receive support.

I looked at the source in the version I was using and it wasn't? It was replaced with a wrapperTooltip.

Update to the latest minor.

If you're in the player container, you shouldn't need to set anything directly to the inventory. Set it only to the container slot stacks, those will update the inventory. Second, if the item is getting duplicated, you probably aren't removing the stack on click. That should be handled cliently where when you click, you send the bundle and the slot it clicks. You remove the bundle from the slot clicked in the screen, but you don't add the other stack in its place if it's not empty. Similarly on the server, you grab the stack in the slot where you clicked, put it into the bundle, and put your stack in the slot replacing the cobblestone. Please make sure that you copied the stack you're adding or else you will dupe the bundle most likely.

Ah, well, that's a tiny bit problematic as a model does not need an IReorderingProcessor. As for how it's rendered, that's handled through FontRenderer#func_238416_a_ and the size of the background is determined by line 153 of Screen#renderToolTip. Those are passed into a reordering processor incase the game is in a different language which reorders the characters into their correct format. So, the easiest thing you could do is handle a string which specifies a registry name and replace on render. Either way, you're going to need to split the tooltip rendering to reference the IReorderingProcessor after you have received a list of the text components.

Deprecation is for usage, overriding is fine.

I really wouldn't look at the advancements as a reference to a skill tree type thing. The system works completely different from that of skills. Well yes, you can only have an advancement that's loaded into the game. But, you're also missing how advancements determine whether to unlock in this case. That's handled and stored somewhere completely different. It grabs them from the files they are reading. Simple as that.

Handling this on the wrong side. You would send the information to the server which would modify the values and affect the creative screen respectively. Most likely as the handling would need to be custom.

A tooltip is quite literally a box with things drawn on top of it. So yes, it's completely possible, you'll just probably need to write a whole bunch of handling for it within RenderTooltipEvent if I'm not mistaken.

First, update to the latest minor. Second, this just sounds like a datapack that replaces the overworld dimension. There is no real need to have anything declared in code here. If they want your datapack, they add it. If not, they don't have it.

It's now an attribute called REACH_DISTANCE. You should apply attribute modifier using Item#getAttributeModifiers.

First, Problematic Code 11. Second, no need to register the configured feature. Third, you need to defer execution of the configs Fourth, one try will fail about 99.9% of the time. Fifth, you don't need to register the configured feature. Sixth, try to avoid using someone else's source as a direct reference as it most likely has problems of its own. Instead, indirectly view the code and try to understand what it's attempting to do and apply the underlying logic in the correct method.

Yes, you would then be able to deserialize the instances correctly and on world load. If you really don't feel like it, you can also just add a reload listener to the server datapack and just refresh the data whenever that is loaded. Or, if you expect it to never change will ingame, I believe FMLServerStartedEvent is perfect for that.

So, just as a notice, it recognizes that the resource class path exists; however, it doesn't recognize the actual mod itself. I can see that from this line: So it most likely doesn't recognize your mod as a dependency for some reason. Either because it's not compiled onto the build path or something else not recognizing it as an actual jar. That's my final bit of insight.

ITag<Item> itemTag = ItemTags.getCollection().get(entry); Here is the issue I see. You will need to create recipes that deserialize on datapack load. Otherwise, this will return null or nothing since it hasn't been populated yet.

If I'm not mistaken, JEI does initialize recipes after the world loads up so it should be fine for tags. You just shouldn't have any direct references to tags in your code. They can be deserialized by the recipe itself.

I'm sorry then, that's all I can think of at the current moment. Would you mind posting the debug.log as well and I'll see if I can come up with anything else.

Well once you change your build.gradle, you need to tell your client, server, and data start that the information has changed. That's done by refreshing the gradle dependencies, regenning the runs, and then clicking on either runClient, runServer, or runData. Else, it won't recognize anything that has changed. Hmmm, this should work imo with my knowledge in gradle. My only other thought is that the api is not a mod itself. And if that's the case you need to include the one with the mod annotation.

Well that depends on how you are calling the tags. Recipes are not affected by block tags, only item tags. My guess is that you're calling the tags collections before they are initialized in the world.

Maybe, I might also just be giving you incorrect information as well as gradle tends to be spaghetti when it comes to anything. I'm assuming that you already did the refresh, regen, and then run I mentioned above? I am working off the assumption that the api is part of the current folder structure.

Ah, well then you probably need to create a configuration block (e.g. configurations{...}) and having the compile from one classifier to extend from another (e.g. <classifier>Compile.extendsFrom compile).

Update to latest minor and refresh gradle dependencies again.

Sorry, I just reread your question and realized it wasn't your api. Use 'implementation' instead of 'compile', refresh gradle, regen runs, and then try again.

Uhhh, so you try to set the state for the model after you set the state for the model? You would need to remove any code relating to how you built the previous state parser.