Choonster

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?

You're storing compound inside of itself, leading to infinite recursion when Minecraft tries to write the NBT to disk.

This is incorrect. There's nothing in the Forge build system that removes @SideOnly classes from the JAR, since Forge mods are universal (i.e. required on both sides) by default. You may be thinking of Mojang's build system for Minecraft, which doesn't include client-only classes in the server JAR or server-only classes in the client JAR. ForgeGradle adds @SideOnly to client- or server-only classes, fields and methods when it merges the client and server JARs for the development environment.

Have you tried my suggestion?

You can probably make use of the active item use mechanic used by bows, food, shields, etc. Try overriding Item#onItemRightClick to do the following: Call EntityLivingBase#isHandActive to check if the player is actively using an item. If they aren't, call EntityLivingBase#setActiveHand to make the player start using your item and then perform the effect. If they are, do nothing. You'll also need to override Item#getMaxItemUseDuration to return the maximum duration in ticks that the player can actively use your item (bows and shields use 72000, which is 1 hour), and optionally Item#getItemUseAction to return something other than EnumAction.NONE.

Enchantments are managed by a Forge registry, so the numeric IDs are automatically assigned per-save and shouldn't be used. Use the registry name in the JSON instead and store the Enchantment instance in the Ingredient for matching.

You can use the Capability system to store additional data on Vanilla TileEntities.

What are you trying to achieve? There's probably a better way to do it than replacing the TileEntity completely.

You'll need to create a copy of IngredientNBT and override Ingredient#apply to perform a partial NBT match instead of a full NBT match. You'll then need to create an implementation of IIngredientFactory that creates an instance of the Ingredient class from the provided JSON object; you can use CraftingHelper.getItemStack to parse an ItemStack from JSON. Register this factory by adding the fully-qualified name to your _factories.json file; you can see an example here. The name you specify for the factory in _factories.json is the name you'll use in the type property of the ingredients in your recipe files. Edit: You might want to use an NBTPredicate for the NBT matching rather than storing a full ItemStack. This isn't really what the OP is looking for, since the conditions are only evaluated once when the recipe is loaded.

Resource packs can't modify server-side files like recipes, structures and loot tables; but the data packs being added in 1.13 probably will be able to.