Choonster

If you're spawning particles through the World/RenderGlobal methods, they'll only spawn within 32 blocks (exclusive) of the player unless you tell it to ignore the range (by using a vanilla particle type that ignores range or by calling one of the overloads with an ignoreRange parameter). Block#randomDisplayTick will only be called for blocks that are within 32 blocks (exclusive) of the client player on every axis.

Since particles only need to be spawned on the client, just check how far away the client player is from the block before spawning them.

World Saved Data should be what you need. It can be attached per-dimension or per-save. Each side has its own copy of the data, syncing needs to be done manually.

Is this data only used by the save it's attached to, or do you need to access the data of other saves?

You're running a coremod built for Minecraft 1.8 or later on Minecraft 1.7.10 or earlier, which won't work. Which version of Minecraft are you trying to run? If it's 1.7.10 or earlier, you won't get any help here. If it's 1.8 or later, make sure you're running the right version from the launcher.

By "world", do you mean a World object (i.e. a dimension), the map/saved game as a whole, or something else?

RegistryEvent.Register<SoundEvent> is fired on both physical sides, not just the physical client. If the registry is empty on the server, something is wrong. Post your registration code.

I can't reproduce this directly after installing Forge (because the installer downloads Forge), but I can reproduce it after deleting the Forge version from the libraries directory. As a work-around, try re-running the installer.

Read the EAQ, it's linked at the top of this section of the forum. Please stop putting your text in code blocks and colouring it black, it makes it very difficult to read on the dark theme.

That's not the correct URL for Forge 14.21.1.2443 Universal, the file has a -universal suffix before the extension. Which launcher are you using?

I think you'll need to store the powered state in the block state or the TileEntity and use that on the client instead of using World#isBlockPowered directly. Look at BlockRedstoneLight for an example of this (though it unnecessarily uses two Blocks instead of a property).

No it doesn't. If IGuiHandler#getServerGuiElement returns a non-null Container, FML will send a packet to the client telling it to open the specified GUI. It needs to be done on both physical sides. Proxies are for sided code, you don't need a "common" proxy. Anything that needs to be done on both physical sides should be done from your @Mod class (or a class called from it).

The OP is asking about Forge's model animation system, not Vanilla's texture animation system. Unfortunately there's not much documentation on it.

I have some IIngredientFactory implementations here, but none of them do what you're trying to achieve.

If you want conditional ingredients, you'll need to create an IIngredientFactory and specify it in _factories.json. In the IIngredientFactory, you can use CraftingHelper.processConditions to check if the conditions are met. If they are, return an Ingredient instance for the specified item; if they aren't, return Ingredient.EMPTY (an Ingredient that never matches any ItemStack).

An ItemMeshDefinition simply selects a model for an ItemStack, it doesn't combine or generate models itself. This needs to be done by the model. Look at ModelDynBucket or ItemLayerModel to see how they combine multiple textures into a model. I can't really help you with specifics, I can only point you to examples.

Conditions only apply to the recipe, not to individual ingredients. You need to specify the conditions property in the top-level object.

ItemMeshDefinition#getModelLocation is called every time the Item's model is rendered, but the ModelResourceLocations returned by it must be registered with ModelBakery.registerItemVariants at startup; so it can't load new models on-demand.

ItemMeshDefinition is used to select a ModelResourceLocation based on any aspect of the ItemStack.

The creative tab and particles are working on my machine:

Are there any errors in the log?

The root of your repository should be the root directory of your mod, i.e. where build.gradle is. The repository should include the buildscript (build.gradle and gradle.properties [if you have it]), the Gradle Wrapper (gradlew, gradlew.bat and the gradle directory) and your source code/resources (the src directory). Look at my mod and its .gitignore file for an example of the repository structure to use and which files to include.

The log should tell you why the recipe is incorrect. I suspect it's the same issue as this thread, you haven't specified the metadata for an Item with subtypes (minecraft:sand, which is an instance of ItemMultiTexture). You need to specify the metadata with the data property.

I'm not seeing any obvious issues that would stop the particles from working. Create a Git repository for your mod, push it to a site like GitHub (if you haven't already) and link it here; I'll need to debug this locally to locate the issue. I did notice that you have model registration code in a common class, which has the potential to crash the dedicated server. Model registration should be done in a dedicated client-only class. I also recommend moving your Block/Item registration to the corresponding registry events and your model registration to ModelRegistryEvent. This will make it easier to update to 1.12+, where GameRegistry.register is private.

You can do that, but it's much more reliable to give each version its own game directory. This way each version will have its own config files, saves and any other mod-related files.