Draco18s

Its probably not added in yet. There's a reason its called a beta.

ItemBase is not magical. That thing you want put in ItemBase can instead (gasp!) go in your item's constructor.

Yes. Evertything is automatic.

Your block is calling a method in ItemBlock at a time that it should not be.

Advancements are json files, just like recipes. The syntax is very simple and available on the minecraft wiki

Wow that's disgusting. This will permanently change the container item (until your recipe comes along and changes it again). Every other recipe using the item will return a copy. That is not how that was ever meant to be used.

Resource locations have always been able to do that.

Welcome to The Flattening. Metadata "variants" are no longer a thing.

Its just that the smelting system hasn't moved over yet.

If you look at the generator class you'll see some code about setting the block state. Which means: You have a world You have a position If you have a world and a position you can get the block state above and check it against that of Water.

A ResourceLocation is a location for a resource (i.e. a model.json, a texture, etc). It's a convenient way for you as a modder to say "go look here" without having to understand where "here" actually is (because resource packs will override the default assets you ship and you shouldn't know or even care that this has been done!) A ModelResourceLocation is specifically a ResourceLocation that points to a model file. As far as you're concerned, its just a resource location that points to a file in a slightly different place (you still need to supply the target file and that file will be in a subfolder named "model" or "models,"1 but otherwise it doesn't change how you use it in the code. The two pieces of information a resource location needs in order to find an asset are two things: 1. Domain 2. File name The domain is the same as your mod ID. This tells the game "don't look in the vanilla assets folder, look in the a folder named <modid>. You can specify domains that aren't your mod ID, as well. For example, if you want to create an item that looks like an apple, you can specify the domain "minecraft" and you can use vanilla texture files even if a custom resource pack has been installed that only alters vanilla textures. The file name is essentially which asset to load. e.g. "apple". Typically you'll name your asset files for the block or item that they are for, but you don't have to (it just makes everyone's life easier). This file then must exist in the domain that was specified, if it doesn't, you'll get a MissingVariantException of one form or another. And I say "one form or another" because it's an error caused by another error. If the game goes to load the asset you told it to and it isn't there, the FileNotFoundException will be thrown. But because the game is trying to build models, the model fails to get built, and that throws another error. If you told the game that your block has several states and then don't list one of them in your blockstate.json file, well, that's a MissingVariantException. If you included it in the blockstate file, but pointed to a model that fails to load because it existed, but had an error in it, that's a MissingVariantException Caused By MalformedJSONException. And so on. Any time you see "MissingVariantException" and a stack trace, keep scrolling down to the next error, it'll almost always start with "Caused By" and another error type. That error is the one you need to fix. For example, lets take the log in your original post: The three highlighted sections tell us everything: 1) the problem item or block, 2) the underlying error and 3) what file the game was trying to read. These will vary slightly depending on exactly what error is the one that needs to get fixed, but this is what to look for. 1. I believe that it was originally "models" and that Mojang removed all the lingering s's, so this will vary slightly by MC version.

It probably hasn't been discovered yet and may still only have a SRG name.

Option A: dont pass your mod id Option B: use the version that takes 2 strings

There's a dot there. That's wrong. If you're trying to do "modid:block" you failed, because that's a colon. This is why I don't suggest that people construct their registry names themselves, but let the game do it.

Blocks are comprised of 3 things: 1) A blockstate file that tells the game how to translate a block state (the metadata equivalence) into a model 2) A model file that tells the game what shape the block has (stairs are not cubes!) and what texture is on each face. 3) One or more texture files. If you want your block to be a full cube (like dirt or stone) then you probably want to use "model": "cube_all" instead. Additionally you will need to specify textures, "textures": { "all" : "<your texture>" }

You told the game to look for a model: It doesn't exist.

This makes no sense to me. You're "pulling textures from blackstates" huh, what? Again, you vcan have a model with 2 textures per face (one of which points at a texture from your mod and one that does not) just fine with the existing system.

You have used this word twice with two different meanings. I cannot follow your question.

So, uh, center = center and size = size? Not much to compute there. So you need to move or resize the world border based on the players location? Well. Move the center to the player's location and set the size to some value while they're inside the unrestricted region. ..

So, you kw that function call you put in the method created by IHasModel? The one to your proxy. Copy that line. Go to where you have your model registry event handler method where you cast items in a list to IHasModel. Take that line with the cast and delete it. You can also remove the instanceof check. Paste the line you copied. Replace this with the loop iterator (probably item). Delete IHasModel and all references to it. Tada, you're done.

Why is it there? If users want to change it they can do so with a resource pack.

You? Probably not.

Sure can. Of course, that central block is probably not the one that you want to initiate things, as the player can't place a block in mid-air. But you can treat it as the "central core" if you will, that if any block breaks, it knows where the core is, tells the core to break, and if the core breaks, it can tell every block around it to break.

Why did you copy the entire boat class like that? You shouldn't need to override all those functions (like setDamageTaken) and then do the exact same thing as EntityBoat.

Now you can check to see if there is any possible way that addPettingTask = false; ever gets called. Its possible that it never does.