Choonster

Which part didn't you understand? Do you know how to create the replacement recipe? Do you know how to override a registry entry?

Did you read the post I linked?

I haven't dealt with 1.13's data packs yet and I'm not at my computer to test anything, but a possible issue is that your recipe file has .JSON as the extension rather than .json. If changing that doesn't work, post your log (I think it's logs/latest.log in the game directory) using Gist/Pastebin. There may be something useful in there.

@Config does work with Maps that have String keys, the Map becomes a category in the config file and the key-value pairs become properties. See here for an example of this.

If you use a static event handler method, you need to register the Class object with the event bus rather than an instance of the class. See the documentation for more information.

Instead of calling MinecraftForge.EVENT_BUS.register or using the @EventBusSubscriber annotation, you call MinecraftForge.ORE_GEN_BUS.register.

You need to register your event handler with MinecraftForge.ORE_GEN_BUS instead of MinecraftForge.EVENT_BUS.

As it says in the doc comment of OreGenEvent:

When using @Mod.EventBusSubscriber, your event handler methods need to be static. Your lootLoad method isn't.

Both of those are valid. The important thing is that you call that constructor, it doesn't matter where you get the values from.

This particular ArrayIndexOutOfBoundsException is caused by calling the ItemAxe(ToolMaterial) constructor with a non-Vanilla ToolMaterial as it tries to look up the attack speed and damage using the ToolMaterial's ordinal as an array index. These arrays only have as many entries as their are Vanilla ToolMaterials, so any modded ToolMaterial's ordinal causes an ArrayIndexOutOfBoundsException. The solution is to use the ItemAxe(ToolMaterial, float, float) constructor and specify the attack damage and speed yourself.

If your item uses the container item system to damage itself (like my ItemCuttingAxe), you don't need to create your own recipe class; just use one of the existing Vanilla or Forge classes. You only need to damage the item in the recipe if you're using an item from Vanilla or another mod.

Your lang file needs to be called en_us.lang (with an underscore), not en-us.lang (with a dash).

Those files are handled by the UserListX objects in the server's PlayerList instance.

DedicatedServer#init creates an instance of PropertyManager to parse the server.properties file and stores it in the DedicatedServer#settings field. This is the first method called when the server thread starts up.

The whole point of using Block#getActualState is to set the values of properties that aren't saved to metadata and are instead derived from other data (e.g. surrounding blocks or a TileEntity). World#getBlockState only returns the metadata-based state at that position, so your override of Block#getActualState sets the facing property of the state argument to the same value it already had (0). Since the facing property can't be saved to metadata or derived from surrounding blocks, you need to store it in a TileEntity.

Your code is trying to load a Kotlin class, but Minecraft/Forge don't ship with the Kotlin library. As with any other library, you'll either need to have users install it themselves or embed the library in your mod's JAR and have Forge extract it.

Use the non-deprecated overload that takes a Callable argument.

Entity#getEntityId is completely unrelated to global entity IDs. It's a unique entity ID specifically designed to be sent over the network.

You can either generate the random number on the server and send it in the packet or generate it on the client. You need to send the entity's ID (Entity#getEntityId) in the packet and then get the client-side entity from the client World using World#getEntityByID.

The two WorldServer#spawnParticle overloads without an EntityPlayerMP argument loop through all of the WorldServer's player entities and call WorldServer#sendPacketWithinDistance to send the packet to them if they're in range of the specified coordinates. I believe any packet sent through SimpleNetworkWrapper by a mod that's not present on the client will simply be ignored. If a mod present on both sides sends a packet that hasn't been registered on the client, an exception will be thrown.

Yes, call World#spawnParticles on the client World in the packet's handler to spawn the particles.

If you look at the method that handles the particle packet (NetHandlerPlayClient#handleParticles), you'll see that it generates random x, y and z speeds based on the speed you specified in the WorldServer method. If you need more control than the WorldServer methods give you, you can create your own packet to spawn the particles.

You have Recurrent Complex installed on the server but not on the client. It needs to be installed on both sides.

To spawn particles from the logical server, use one of the spawnParticle overloads defined in WorldServer rather than the ones defined in World. These send a packet to players within range of the specified coordinates (or just the specified player if using the overload with an EntityPlayerMP argument) that tells their clients to spawn the specified number and type of particles.