Choonster

It's overridden in WorldServer to call ChunkProviderServer#getNearestStructurePos, which in turn calls IChunkGenerator#getNearestStructurePos. ChunkGeneratorOverworld implements this to look for a hardcoded set of Vanilla structure types, so there's no good way for mods to hook into it. This PR aims to resolve that.

Advancements and other server-side files aren't loaded from resource packs, which are client-only. 1.13 will allow loading of advancements from data packs.

Unlocalised names are controlled by the Item class and translations of those are specified in the lang files, there's no JSON involved. If your variants were displaying their names correctly in 1.11.2, they should still do so in 1.12.2 unless you've changed something. Post your Item class, the class where you register your Items and your en_us.lang file.

It could be useful in some circumstances, but I'm not sure how many people would actually need it. It probably wouldn't hurt to open an issue/PR, the worst that can happen is that it's closed because Lex/mezz don't see a wide use for it.

Then I think the least hackish way to handle this would probably be adding the condition to your recipes. If you really don't want to do that, you could probably integrate with JEI to hide your uncraftable recipes.

If the recipe is for your custom crafting table, does that mean you're calling CraftingHelper.findFiles yourself to load the recipes? If so, you could check that the recipe's output is non-empty between loading and registering it.

Use the minecraft:item_exists recipe condition to prevent a recipe from being registered if an Item doesn't exist.

I don't think that's the right part of the log. The section you're looking for will start with this line (the first thing logged by the version checker Thread when it starts the check for a mod): [screenshotuploader] Starting version check at http://darkeyedragon.me/mods/updates/screenshotuploader.json Could you please post the whole log using Gist?

Judging by the log output you posted, it looks like an exception was thrown while processing your mod's version check. The version checker (the Thread created in ForgeVersion#startVersionCheck) logs the received version check data and any thrown exception at the DEBUG level, which is only visible in the FML log and not in the IDE's output window. The FML log will probably tell you what's going wrong.

There's only one logical server running at a time. In single player and LAN, the logical server is running in the physical client of the host. In multiplayer, the logical server is running in the physical (dedicated) server.

You'll need your own IRecipeFactory implementation that creates a recipe of the appropriate type and uses the config option to determine the output item's count. You can see the IRecipeFactory implementations for the Vanilla and Forge recipe classes in CraftingHelper.init. The IRecipeFactory class needs to be registered in the _factories.json file, just like IConditionFactory and IIngredientFactory.

Could you clarify what you mean by this? Do you mean that the replacement recipe is only enabled if a config option is set? If so, you can create an IConditionFactory that returns the value of the config option and use the condition in your recipe. diesieben07 explains this in more detail here: Edit: IConditionFactory, not IRecipeCondition.

You don't need to register the config anywhere, Forge automatically loads the config from every class annotated with @Config. You've linked an old version of my code, you can see the latest version (as of the writing of this post) here. You can use the branch/tag dropdown near the top of the page on GitHub to switch to a branch, which will show you the latest code in that branch. Is there something specific you're struggling with? If you post your code we may be able to help you further. There's a WIP documentation page for the annotation config system here.

Only the fields of the top-level class need to be static, the fields of the other classes need to be non-static. You could create your @Config class such that it has two static fields of the same type, one public (to store the server-side settings and be used by the config system) and one protected (to store the client-side copy of the server-side settings). You can then create the fields for all of your settings inside of the class you used for the fields. Something like this: @Config(modid = "<modid>") public class ModConfig { public static final ConfigOptions serverOptions = new ConfigOptions(); protected static final ConfigOptions clientOptions = new ConfigOptions(); public static class ConfigOptions { public int foo = 1; public float bar = 3.0f; public String baz = "baz"; } }

That's actually a mistake, I intended to do that in RegistryEvent.Register<Block> rather RegistryEvent.Register<Item>. LexManos recommended this here. The two events are fired at roughly the same time, but it makes more sense to register TileEntities with Blocks rather than with Items. Edit: Fixed.

You're running 1.10, but you've installed a coremod that was built for 1.7.10 or earlier. Why are you using 1.10? Ideally you should update to 1.12.2, but failing that at least use 1.10.2. There's no reason not to use the latest bugfix release within a major version.

Create a class that extends ItemBlock and overrides Item#getItemBurnTime and then register an instance of this as the Item form of your Block.

That should be @SubscribeEvent, not @EventHandler.

Don't call TileEntity#writeToNBT unless you actually need to serialise the TileEntity to NBT (e.g. to store the data in an ItemStack). Minecraft automatically calls it when the chunk is written to disk. Your TileEntity's data should be stored in regular fields and only written to NBT when necessary.

Judging by the "ForgeData" tag, it looks like you're using TileEntity#getTileData somewhere; don't do this. The tag returned by TileEntity#getTileData is for mods to store custom data on external TileEntities; but the capability system is a much better way to do this. When you call TileEntity#writeToNBT, pass an empty compound tag as the argument.

1.11.x has these methods and it has the registry events. All of the advice you've received here still applies.

Subscribe to GuiOpenEvent instead, it can be cancelled to prevent the GUI from opening.

There are three overloads of IForgeRegistryEntry.Impl#setRegistryName (which is inherited by Item): (String) (ResourceLocation) (String, String) Even if it did require a ResourceLocation, it's not a very complicated class: it's simply a domain (your mod ID) and a path (the name of your Item).

That doesn't change anything, it still shouldn't be used.

You need to use submodels to combine multiple models. Are you sure you actually need multiple models and not just a single model with multiple textures?