Choonster

I don't think this is possible. There was a PR to add support for this, but it was never merged because it was so large.

This is incorrect. Despite the name, the method actually has a EntityLivingBase parameter. If you look at the EnumFacing enum in your IDE, what's the name of the method that takes a BlockPos and EntityLivingBase and returns an EnumFacing? It should be one of the last methods, just before the static initialiser block and the start of the EnumFacing.Axis enum. MCPBot tells me that the method is known by its SRG name (func_190914_a) in older MCP mappings.

Forge's registries are already stored in the ForgeRegistries class and you can use GameRegistry.findRegistry to find any other registry. There's no need to store the registry from the registry event for later use.

If you look at the CommandLocate class in your IDE, you'll see that it is.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead.

Use the TX button (fifth from the right) to clear formatting or use Ctrl-Shift-V to paste as plain text.

You probably could do that. Depending on exactly how your mod works, it may be easier to simply maintain a list of block positions and search that.

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.