Draco18s

You have an @mod annotation somewhere with the id "examplemod". Remove it.

Step 1: download and install Forge Step 2: write code Which part is giving you trouble?

ObjectHolders are what allows for mods to override items with their own version (e.g. "I want to make dirt a falling block" -> register your own block as "minecraft:dirt"). Because of the way Forge populates ObjectHolder fields with values, these replacement actions work even for items and blocks added by any mod.

Not exactly, but yes, but also no. ObjectHolder fields are populated with values by Forge after the event has called all of the handlers that listen for it. Blocks first (object holders for blocks are populated), then items (object holders for items are populated), then everything else, then all object holders are refreshed. Yes, they are. And he probably won't update his practices, because like so many youtube tutorials before him, they regurgitate the same garbage they learned without seeing if there's a better way.

No. @ObjectHolder fields are final. You can't set them directly. Just do this: Even.getRegistry().register(new Generator(...));

Have you tried concating the authors of those mods?

The field can be static, that's ok. You just can't call new there. This has to do with SetRegistryName and Forge needing to insure that the correct domain is applied, which is can only do if the constructor is called in a Forge-controlled event. static blocks can get executed at any time. You should only call new Block() or new Item() in the registry event that registers them and use @ObjectHolder annotations to populate the static field with a value.

This is static so there is no reason to call new here or here. But you should not be creating your items in a static location (common issues, problematic code #14). The indentation levels in your ModSetup class are broken. What does this } close? All three of these methods are empty. Double cast. You're casting a BlockState to a BlockState and then to a BlockState. Same here.

You need to create your own ItemEntity.

An account is literally free.

Funny what googling "download java jdk 8" does https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Loot tables.

Its not my problem. But if you felt like knowing, its drawing the existing sign texture into a GUI. As you might notice from the included images in the first post.

Ah, you're correct. I was thinking of goto-labels.

That isn't the goal here.

Open the log and read the error.

Hum, I wonder what RedstoneWireBlock has to say about this... Oh hey, a colorMultiplier method. Aaannnd....there's no meaningful answer because the math is complicated. Why don't you take a look? Or this graph might help.

To the surprise of no one (if you think about it for more than fifteen seconds): Drawing text binds a different texture to the the drawing functions in OpenGL than the hud icons use. And you aren't changing it back.

I don't like this line. I know what the attempt was doing, but it inadvertently skips several positions. Change the break loop to continue. I don't like this either, because this keeps looping over new positions, but will always fall back to this line (because distance can't ever be less than 0, and that value gets a +1 before taking the minimum of it and i, so i can't ever be lower than 1). Move the label loop: down below the loops. You know, making it do what the vanilla code does: actually exit the loop. Unrelated to your issue, but: You do know what a mutable BlockPos is, right? It means you can modify it. Vanilla does this to avoid creating a bunch of short-lived BlockPos objects and there you are going "fuck it."

That code only checks for raw distance, it doesn't care if that is orthogonal or straight.

You can't do this. How many of your block do you intend to place into the world? More than one? What if they face different directions? DO NOT STORE DATA STATICALLY OR IN A BLOCK/ITEM CLASS. private boolean isOn; *Cough* Just because you removed one thing and put something else in its place doesn't mean its fixed. Its still broken and in the same way. All you exchanged was storing the block's facing in the class to storing whether or not the block emits a signal in the class. You must query the block state in getWeakPower(). if (side == (EnumFacing.NORTH) && isOn == true) Oh for christ's sake. You still aren't checking if side == facing. You're checking "is the side that wants power coming from the north?"

You have to compare the state's facing to the side passed in. Where is this coming from?

Its not random. You want to check the player list to see if the player you're interested is in it. The player list is stored by the MinecraftServer instance and the only way (outside of having access to a world object) is to get it from the FMLCommonHandler instance. The amount of indirection here is relatively minimal.

Yeah, because the mappings you're using are for 1.14.3 and mappings for 1.15 don't exist yet.

You mean the function? Its a function. Go look at what it does.