desht

Actually, looking at the GUI code from PneumaticCraft, that's what we're doing too You're right that it's not very elegant, but it does work. Right, yes - that's perfectly OK to do. You can keep a GUI object around for a while by holding a reference to it even though it's not the current GUI.

GuiScreen#onGuiClosed() is probably what you want here. It's actually called whenever the current GUI object (if already non-null) changes, which is generally by Minecraft#displayGuiScreen() - note that a change from non-null to null also counts here. So when you create your sub-GUI, store a reference to Minecraft.currentScreen in your sub-GUI constructor, and in your sub-GUI's onGuiClosed() override, call Minecraft#displayGuiScreen(parentGuiReference) to redisplay the parent GUI. Note that you're not actually reusing the GuiScreen object - the sub-GUI is a separate object which exists at the same time as the parent GUI. If you need to pass data from the sub-GUI back to the parent GUI, store a reference to the sub-GUI in the parent when you create it (most likely in actionPerformed() when the player clicks a button). The parent's initGui() method should check for a non-null sub-GUI field and use that to extract any data that was entered by the player. The important point being that the parent GUI object still exists while the sub-GUI is being shown (because the sub-GUI holds a reference to it), so you're redisplaying an existing GUI object, not a new one. And the sub-GUI object still exists after it's closed (at least until the parent closes), because the parent GUI holds a reference to it.

No, not at all. Tile Entities are objects which a) store some extended state for blocks, where the 4 bits of metadata isn't enough (e.g. vanilla signs, banners, chests...), and b) possibly having some ticking behaviour (e.g. vanilla furnaces). There's a many-to-one relationship for Tile Entities to Blocks (there's only one vanilla Chest block, but every chest in the world has its own distinct Tile Entity). Tile Entities are present on both the client and server, and don't have any knowledge of how to render themselves. What you seem to be referring to is rendering, which is done (at least for rendering not handled by the block model) by subclasses of TileEntitySpecialRenderer (aka TESR). This is distinct from Tile Entities themselves; there's at most one TESR for each type of Tile Entity (most TE's don't have a TESR at all), and when its render() method is called - which is every frame on the client while the TE is in view of the player - it's passed the Tile Entity instance that it's rendering. So, as @V0idWa1k3rsuggested, you could examine the code for TileEntityBannerRenderer, specifically the render() method to see what it does. Hint: it contains a ModelBanner instance, which is rendered by the TESR with bannerModel.renderBanner(). What you need to do is to determine the texture to bind from the banner in ItemStack form, and call bannerModel.renderBanner() with the appropriate OpenGL transformations etc. when the dragon is rendered. You should be able to hook RenderLivingEvent.Post to do your extra model drawing, but doing all the setup to render it correctly is up to you...

And yet McJty's compatlayer allowed binary compatibility between mods for 1.10 and 1.11. So it is possible, but probably more work than is worth it in the long run (as I mentioned, McJty dropped compatlayer for 1.12). Best bet is just to keep your code as clean as possible, and put in the porting work when the time comes. And pay attention to any PSA's & tutorials about what's changing ahead of time.

@Animefan8888 already pointed out your mistake, but as an aside: get out of the habit of overriding methods without using the @Override annotation right now. That's guaranteed to come back and bite you at some point.

1.10 -> 1.12 is relatively straightforward. There will be some method name changes, which are generally fairly easy to work out using your IDE and examining the decompiled Minecraft source. One big change is that null ItemStacks should never be used from 1.11 onwards, instead use ItemStack.EMPTY and ItemStack#isEmpty(). Missing null ItemStack usages is a common source of NPE's in ported mods, and they can be tricky to track down in some cases. Other than that, recipe registration changed in 1.12 (recipes are now defined in JSON files for the most part, and while the old way can be made to work, it should be considered deprecated). And there are the registry changes, which it sounds like you're aware of.

Override Block#onBlockActivated() and run your teleport code from your overridden method.

No, there is no mod compatibility at all between major Minecraft versions. (Apart from odd cases like 1.9->1.0 which were mostly compatible - but don't count on that ever happening again). Also worth noting that compatibility layers have been attempted in the past, most notably McJty's compatlayer - which worked pretty well between 1.10 and 1.11, but it's worth noting that he decided 1.12 was too different to be feasible to support and therefore gave up on it for 1.12.

Right, TESR's aren't necessary at all for pipe rendering (and will hurt your client-side performance if you have more than a few). I'd also recommend taking a look at TheGreyGhost's examples here: https://github.com/TheGreyGhost/MinecraftByExample - in particular MBE05 covers dynamically rendering connections based on a block's neighbours.

Once ChunkEvent.Load is fired, the chunk is for all intents and purposes loaded - the event is not cancelable and the chunk data is in the chunk provider's loaded chunks map. The only thing that hasn't yet occurred is population, which is a server-side thing anyway. You could always schedule your code to run on the next tick via Minecraft#addScheduledTask() (given your mention of map textures, I'm assuming you're doing this client-side).

Don't forget to disable the transparency when you're done (in RenderPlayerEvent.Post).

Yes, you're right (although the method to use is Block#getBlockFaceShape, as diesieben07 pointed out). If it's not SOLID, snow won't settle. Of course, changing that can have other effects (e.g. torch/button placement), so might not be appropriate.

Snow settling happens in WorldServer#updateBlocks() - look for the profiler section marked "iceandsnow". Looking at that code, there are no specific snow-formation events fired, so your options are: Override neighborChanged() in your custom block's class (the method is deprecated, but overriding it is OK). In the override, you can check if the block above your block has become a snow layer, and if so, remove it. (note: that's extra block update work, which might become a performance issue if you plan to have a lot of your custom block in the world) Have your custom block emit enough light to prevent snow formation (light level of 10, I believe). Might not be practical. Enhancement request or PR to Forge to have a custom snow formation event fired. Not sure if that would fly.

This is Linux. We don't reboot after setting one little variable Have you exported the environment variable, @KeeganDeathman? Looks like your shell sees the var but the gradle process doesn't, which suggest the variable isn't exported.

That should be assets/<modid>/recipes/<filename>.json - "recipes", not "recipe"

In 1.12+, you should always be using JSON for regular crafting recipes. McJty has a good doc about it here: https://wiki.mcjty.eu/modding/index.php?title=Recipes-1.12 including creating custom recipes (e.g. copying NBT from an ingredient to the result).

In addition to what V0idWal1k3r said, getting the block meta directly is guaranteed to fail in 1.13, while the getPickBlock() solution should continue to work fine.

Ask yourself first why you need the integer metadata. What are you planning to do with it? The only use for the metadata is for saving to disk. Anything you do with an IBlockState should be via properties: https://mcforge.readthedocs.io/en/latest/blocks/states/. In the case of logs, it's a little awkward since vanilla adds two separate blocks for logs (4 bits of metadata is not enough to store both the variant and the rotation): BlockOldLog and BlockNewLog. So you'll need to check the block type and then get the BlockOldLog.VARIANT or BlockNewLog.VARIANT property as appropriate.

Thanks, I'd missed your original tutorial link. This is starting to make more sense now. I'll probably have a go at converting one of the animated PneumaticCraft machines to use the animation system in the near future and see how it goes. I might have some useful feedback for you...

I think the armatures file is pretty much undocumented right now, and although there's a grammar floating around for the ASM file, it's really a reference rather than a tutorial. What does the "joints" section in the armatures file do? "joints": { "pole": {"0": [1.0]}, "platform": {"1": [1.0]} }, So I think the "0" and "1" correspond to elements of your model? But what does the [1.0] argument signify? Well done on getting this far, though. More than I've managed (I've investigated a few time, but always given up) !

By the way, you mentioned that you don't use ItemStackHandler because your inventory is "virtual" - there's still nothing to stop you using it, and if you just need a simple inventory to hold a collection of items, it's by far the best option; you get some robust and well-tested code for free. If you need any custom handling (e.g. only allow certain items in certain slots), there's also nothing stopping you from subclassing it. (Of course, there may be good reasons to have a custom IItemHandlerModifiable implementation, but ask yourself if it's absolutely necessary).

The attackEntityFrom() method is responsible for actually doing the damage too. You still need to call super.attackEntityFrom(...) to keep the original behaviour (and you probably want to return the return value of that call from your overridden method). (Also, you didn't annotate getEntityAttributes() with @Override - please don't get into that habit; it's guaranteed to come back and bite you sooner or later).

Sounds like blending is enabled. Try calling GlStateManager.disableBlend() before you do your line drawing. Or ensuring an alpha value of 1.0 is passed in your call toGlStateManager.color(...)

First off, you should really be using GlStateManager rather than direct GL11.* calls. Regarding your problem, a GlStateManager.disableTexture2d() call before you draw might help here (although I am speculating, admittedly).

Thanks for that. I've looked into the Forge animation system in the past, but documentation is really lacking. I know Botania uses it for a couple of blocks, and I've been through the examples in https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/test/java/net/minecraftforge/debug/client/model/AnimatedModelTest.java but I'm still not getting my head round how it all hangs together. And I can't find any examples at all for item animation.