Leaderboard

You should be able to do it either way. The nice thing about extending is that, for the most part, you can leave what you like as-is, and change what you don't like (with some exceptions). For example, if you like how most of TileEntityChest works, but not how it handles a certain method, you can override just that method (if you have access to it). That aside, you could *instead* extend a more basic class, such as TileEntity, and would have to write code yourself for anything you want but it doesn't have. Going with that same logic, you could, in many cases, write a class completely from scratch without extending anything. What it comes down to in most cases is finding the class which most closely reflects what you want to accomplish, extending or copying it, and then editing. I can't give an authoritative answer on what's best in your case in the long run, but at a minimum you will need to extend TileEntity. TileEntity or one of its subclasses, because the AnvilChunkLoader only calls the readFromNBT() and writeToNBT() methods for TileEntity instances (including any instance of an object which extends TileEntity). I suppose if I were in your shoes, I would copy the entirety of the EntityTileChest class as-is, rename it, and edit as necessary. The field used for storage in TileEntityChest is set to private access, so you won't have direct access to it if you extend TileEntityChest, which in turn means you probably won't be able to use TileEntityChest's built-in NBT methods as they are, but you can certainly use them for reference to see how they do things. All in all, if the only feature you don't have working it disk save/load, then just keep what you have now, copy/paste TileEntityChest's two NBT methods in, and then edit them (you can copy it straight out of my previous post, in the spoiler). Again, I haven't actually made a container myself, I'm just going off of what I see in the vanilla code and what I know about how MC handles data in general, so I can't really get any more detailed than this atm, though I'm sure someone else could (someone who has done it). You could also try to find a mod on curseforge which adds a container and is open-source, and take a peek at their code for an example. Edit: Forgot to answer your last question about !this.checkLootAndWrite. First, just to be clear, the method itself is checkLootAndWrite(). The exclamation mark is negation, which means if !checkLootAndWrite() is true, then checkLootAndWrite() is false. And the "this." part just means that we're calling it from "this instance", which in most cases is redundant, but can sometimes prevent confusion and errors involving fields/methods with the same name from other classes/instances. And yes, you could extend TileEntity and write that method from scratch...*OR* you could extend TileEntityChest and overwrite that method, which would replace its functionality. In this *particular* case the result would be the same, because that *particular* method is only called from TileEntityChest and its subclasses (not from any of its superclasses, and not from any other external classes). In intelliJ, you can see where a method is called from (or just in general, what connects to what) by middle clicking it or by setting the typing cursor on it and pressing ctrl+B But yeah, maybe someone else can give you a more specific answer, or check out some repository code of an open-source mod with a working container

You are doing everything wrong from what I can see, you should read and check out https://github.com/Cadiboo/Example-Mod Your actual issue is caused by this

Does your biome class extend BiomeOcean? Does your biome set its height? You should post your class code and the code where you declare/initialize the field "kelpForest" so ppl can get a better idea of what may be wrong.

Also familiarize yourself with Minecraft's existing mechanics. Not just what it does, but how it does it. Many of the "I want X but Y" questions can be answered just by cribbing from vanilla.

As there have been few attempts to create this functionality (that I can find) I decided that I'd have to do this myself. And seeing as it boodly doesn't exist anywhere, I thought I'd share. It does not extend GuiTextField, though it probably could, but it was easier to just take everything that was GuiTextField and make a new class and just make changes as needed, particularly as a lot of GuiTextField's fields were private and thus not visible to a subclass (using getters and setters was frustrating, as many setters either didn't exist or had annoying side effects, such as ignoring newlines and up/down arrow keys). https://gist.github.com/Draco18s/2b02762b597e67a9b887aed241f25077 Known issues: Minimum height of 2 lines enforced (are you really going to complain?) Does not support multi-line selections (they are trouble some to handle; rendering, copying, etc) Does not feature a scroll bar (yet) Mouse wheel scrolling clamped to range that keeps the cursor within the visible text box range (technical limitation; could be overcome, but the limitation relates to automatically scrolling the cursor into range when using the arrow keys) Page up/down not supported (yet) Sometimes the selection highlight appears in edge-case situations that cause the cursor to reposition due to another (e.g. moving from one line to another when pasting multi-line content, etc) Up/down arrow cursor movement is "by column" rather than "by rendered position" as I can't be arsed to figure out where the carat should go instead (my usage will be moving to a monospaced font, where those two values are the same).