SerpentDagger

Since rendering a texture like this is not a toggled operation, but rather a drawing operation completed every render tick, all you have to do to "clear" a texture from an area is not render it during that render tick.

"1": "rotbm:linarite_block", For custom textures: You should store block textures in textures/blocks/block_texture_file_here.png. You should store item textures in textures/items/item_texture_file_here.png. Since the custom texture does not exist in the domain "minecraft", as it is not a Minecraft texture, you use the domain that it does exist in instead when specifying the location within the json file. In your case that would be the domain "rotbm". The path from that domain's textures folder follows the domain, as explained above. For vanilla textures: They already exist, you shouldn't store them because they're already there. Since the vanilla texture already exists in the domain "minecraft", you use the domain "minecraft" when specifying the location within the json file. The path from the domain's textures folder follows the domain, as explained above. Alternatively, if no domain is specified, the default is "minecraft" already. You still need to supply the path though.

That's correct. Just so long as the references defined at the top within the "textures" section point to valid locations within your assets folder, the textures will work fine. The trouble you were having was simply that the locations you defined in the json didn't correspond with the actual locations of the file.

It's pretty much up to you. There are a couple different approaches to take. Either you could have another gui class and offload more functions from the main window into the popup one, or you could create something yourself to handle the instructions from the main window that wouldn't be as complicated or sophisticated as a new gui (for example, something that simply drew an image when told to, held its x & y, etc). After doing either of those things, you could have the popup window be contained and controlled by the primary window, which would just involve having them as fields within that class and doing whatever needs to be done to them through that class. Or you could keep the handling of the popup window external, doing things to it alongside the main window. That would leak a little more gui handling into the outside world though.

If it's the same texture, then you can definitely use the same file, and should. Basically, it just defines some texture references, lists the display properties, then supplies a list of elements that use the texture references. There's a link to the generator at the top of the file. It doesn't work with custom texture locations, but you can just use random textures while creating the model and then change the references once it's generated by using find and replace.

Well, once the Json is working, then you can alter its scale however you want. For example, in my wand's model file I have these custom scales to keep it looking the right size from different viewpoints, but I could alter them just to make the wand huge too.

You've cleared up one of them, as you can see in the error log, but it's still missing the texture at textures/linarite_block.png. That's the location referred to by the line here: It's looking in the domain "rotbm", but there are no subfolders specified. I'm not sure what the path you mean to be pointing to is, but if it's the same linarite_block.png as the other one, the path should probably look more like blocks/linarite_block, as with the others. Each of the lines like the one above is specifying a ResourceLocation, and ResourceLocations are of the form domain:path. The domain is the folder within assets, and the path is the file path from a context-specific location to the proper file. In the case of textures, that context-specific location is the textures file within domain. Therefore, when you provide a location domain:filename, in the case of textures it looks for the file filename.png in the path domain/textures/filename.png.

For example, instead of "block/linarite_block", you would write "modidinsteadofthistext:block/linarite_block". Also, "block" there should be "blocks" if it's meant to reference a texture at modidinsteadofthistext/textures/blocks/linarite_block, and ditto for the others. I haven't used obj models myself, since I like the blocky look, but this topic might be helpful to you.

The texture file locations in the Json are wrong. Specifically, they're missing a domain, which means that "minecraft" is defaulted to. Since your textures aren't located in "minecraft", you need to prefix the texture locations with their proper domain, which is probably your modId. You should also make sure that the paths correspond to actual file paths and locations.

If you subscribe to EntityJoinWorldEvent, then you should be able to access the entity through the event and change it however you want to.

It would be helpful if you could show the whole classes, as the event system is impacted by that.

Ah, well that's even more convenient then. I'll have to give that a try. lol

What's the current state of the code? By this do you mean you want to send a message to the player, or send a message via the player?

In Eclipse, at least, when I add a file to the project without explicitly doing so through Eclipse itself, it doesn't register that there exists a new file, or even that it's out of sync with the reality of the situation, until I forcibly remind it of the fact: either through renaming one of the folders containing the unnoticed file, or perhaps through restarting the program (although I'm unsure of the merits of that method, as I always use the former due to its convenience).

From your GitHub page, it looks to me that everything is in order. Have you made sure your development environment is properly in sync with the file system? I had some trouble with that at one point.

Thanks, that's exactly what I was looking for. I'll convert my NBT things over to Capabilities, then, since it seems there's no real advantage in using NBT data instead.

What are the specific differences between Capabilities and NBT data? For example... Under what circumstances should I use each? Which is quicker to access? How do they store data? I know from the documentation that Capabilities, particularly the ones already provided by Forge, are very useful in compatibility, so it's clear that they should be used accordingly. It's less clear, however, which to choose for less universal or less openly visible/utilized concepts. If there's other information that might be interesting or useful that you'd like to share about them, that would also be appreciated. Thanks in advance.

The @Mod annotation sets some values for your mod and marks the class it annotates as the entrance point to your mod. More information You've got a bunch of events that are being set up, and the methods that will be run when each event triggers. More information The most important among them would probably be the registry events (you've got only one at the moment: the Block event). More information on registries The annotation above your RegistryEvents class registers the method within (marked with @SubscribeEvent) to the Forge event bus, meaning it will be called when the Block registry event is fired (instead of never). Basically, you set up some information in @Mod, can do things that need to be done inside the events, and register Blocks and Items inside the registry events. If you have a more specific question I'd be happy to answer it if I can, but in general I'd just suggest reading the Documentation and other sources to learn what things do.

It depends what you mean by "waraxe." What exactly do you want this item to do, and how do you want it to behave in respect to the rest of the game (i.e, like a sword, or like an axe)? Also, what version are you using? Also also, show us what you've tried already (the code).

It's looking for the model of the ItemBlock that corresponds to the Block, using the registry name of the ItemBlock, which you probably set to the registry name of the Block. Since ItemBlock models are stored in models/item just like other items' models, that's where it's looking. So for that you need an ItemBlock model in models/item that's named [Block'sRegistryName].json. assets/weird needs to be assets/[yourmodid]. That's already the case, assuming "weird" is your mod id. At the moment, though, I'm not sure why the other models aren't being loaded properly, as it seems your file path is correct with basic_item. Make sure your development program is properly in sync with the file system-- I had a lot of trouble from Eclipse with that at one point.

Does this file exist here? Show your folder tree, please.

Actually, I meant that you should add a comma into the place where you're missing one (right before "S"). "O" is currently an unterminated object, because it doesn't have a comma separating it from "S".

Actually, it's telling you that there should be a comma or } there instead of a string. "S" is a string, and there should be a comma there instead, because you're currently missing one.

Hmm. It seems, then, that you've installed a 1.14 version by mistake? Regardless, assuming it works the same way in 1.(?), Block#getBlockLayer() is annotated with @SideOnly(Side.CLIENT), so it only exists on the physical client. Block#isOpaqueCube(), however, is present on both the physical client and the physical server. So when you call getBlockLayer() within isOpaqeCube(), it'll crash a physical server. Edit: Also, Block#isOpaqueCube() is deprecated. I think you only have to use Block#getBlockLayer() now.

You query the isRemote field of a World object... if (!world.isRemote) { /*Whatever*/ } ...where world is an instance of World.