DavidM

(I can't seem to partially quote a post on mobile) That is not what I meant. You'll have to replace the constants in Blocks class via reflection.

AFAIK no. How big is your mod (the compiling time shouldn't be significant unless the mod is big, like more than 1 million lines of code)? What is taking up such a long time according to the log?

Yes (that is the definition of backdoor - coders creating exploits in the code for their personal gain). In that case, the problem is not "backdoor", but rather "cheating/hacking" (depending on whether the situation happens in-game or on your server). There are anti-cheat plugins that you can use to prevent the former.

1. Don't use bases. They are an abuse of inheritance. 2. Try replacing the constant values of items and block in Items and Blocks class respectively with your custom instances. I haven't met this exact problem before, but I guess it is caused by vanilla's still trying to use the original values from those two classes.

You don't need to build the jar to test your mod. Simply launch the client via gradlew runClient or the equivalent shortcut in your IDE.

We do not provide copy-paste code on this forum. Which part do you not understand? If you want the effect to occur on a vanilla item (as opposed to a custom item added by your mod), subscribe to PlayerTickEvent and check for the item in hand instead.

You need to learn about the concept of sides. Input events are client side; you cannot do anything that would affect the server (interact with world, blocks, entities, etc). Instead, subscribe to PlayerTickEvent, and check if the event is fired on the server side and check PlayerEntity#isSneaking for sneaking.

This is nostalgic... Reminded me of that time back in middle school where we were asked to make a chess game in Java as a class assignment. Back on topic. If you really want to reference the chess controller from every single chess piece, then I guess you could make a tile entity for each of them (or even make the chess pieces into entities, which is something I would do since you can create the animation of chess pieces sliding across the board). From that point on, just send all interactions on the chess pieces to the chess controller and let it handle the logic. Note that the chess piece should only store the BlockPos of the chess controller, and fetch the actual tile entity of it when it is actually needed. On a side note, I think that with the new way block properties are handled after the flattening, it is possible to store the chess controller's BlockPos as a property instead of creating a tile entity for it. Not sure if that is a good idea from the design perspective though.

Override Item#onUpdate (which is called every tick if an instance of the item is in the player's inventory) and check if the isSelected parameter is true (which will be true if the player is holding the item). If true, the check if the player is crouching (PlayerEntity#isSneaking or something) and apply your effects.

That is changeable in the player's attribute. Obtain the attribute via LivingEntity#getAttribute and pass in the REACH_DISTANCE in PlayerEntity to obtain the reach attribute. You can modify that to change block reach distance. Unfortunately I don't think there is a convenient method of changing the reach for entity interactions. You'll have to do some manual ray casting.

Use World#addEntity (spelling might be off), and pass in an instance of the desired entity.

1. You need to use ObfuscationReflectionHelper (can’t remember the exact spelling). 2. Reflection is expensive. Use it once and store the result in a static field and use that from now on. 3. You should directly reference PlayerEntity.class instead of using getClass.

Is this a client only mod? What would be the function to be like from the end user's perspective? You could just send a right click input to place the block down.

Oh I'm just being lazy there. Instead of finding the registry reference during the appropriate time, I used a LazyValue to find it via GameRegistry.findRegistry the first time I call it. It is functionally the same with: if (registry == null) { registry = findRegistry(); } doStuffWithRegistry();

Note that you also shouldn't look up methods via reflection every time the camera updates. Look them up once, and store them in a static field.

There are helper functions that allows you to encode complex data (such as ITextComponent and BlockPos) to NBT. I personally store my capabilities in static fields marked with @CapabilityInject annotation so that the value of the capability is injected at runtime. An example is this. Here are some links to the capability part of my test mod if you need: My capability object. My capability provider. My capability storage. My event subscriber for attaching capabilities to player. My packet that syncs the data of capability to the client.

That is not valid Java. Please learn Java before making a mod. I would also suggest to get more familiar with your IDE so that you can understand its warnings and errors.

Is that a JoJo reference?

By "that directory" I meant the mdk directory (the one containing gradlew). Pronouns such as "that" usually refers to the appropiate object mentioned immediately before the current sentence, and in this case, it is the mdk directory (note that gradlew is a file, not a directory).

Please post the error. Please also post the code using services like pastebin, as it is currently almost unreadable.

You should sync capabilities of other players to the client.

You should use different launcher profiles for different versions of Forge. Each of them can point to a different game directory, and you can keep your mods separated.

That feature has been removed. Use launcher profile instead.

If something actually affects the game (like changes to the world, as well as inventory), then it should be done on the server. Think to yourself "if the player can freely edit this value/call this function, would that affect other players as well as bring an unfair advantage/disadvantage?" If yes, then throw it on the server.

Make the player size a capability and sync it everywhere (not literally; only to tracking clients and self), and on the client, render the model based on that player's size capability.