[Solved][1.15.2-31.1.1] @SubscribeEvent not working in ExampleMod

[Busti]

I am trying to follow the docs in setting up a 1.15.2-31.1.1 (latest as of writing this post) modding environment. So far everything has been working out nicely, but there is one minor issue that I have run into.  
When loading the mdk into IntelliJ, the @SubscribeEvent annotated method is never called. This one:  
https://github.com/MinecraftForge/MinecraftForge/blob/1.15.x/mdk/src/main/java/com/example/examplemod/ExampleMod.java#L68-L72  

Adding @Mod.EventBusSubscriber(modid = "examplemod", bus = Bus.MOD) to the class does not help either. The nested class (register blocks) is not affected.
However from my understanding that would not be necessary anyways, since Line 39 ( MinecraftForge.EVENT_BUS.register(this); ) accomplishes the same thing.  
I do not expect something so fundamental to be broken, so there must be something that I am doing wrong. Is there an error in my thinking?   

Edit: Using different event types also does not work.  
Edit2: My personal repo is here by the way: https://github.com/sauerkrautMod/sauerkraut  
Edit3: But all tests were done on the Initial Commit

Edited February 12, 2020 by Busti

[unassigned]

You have everything correct, and when I cloned your project on my side on the same forge version it works.

Are you actually getting to a point where onServerStarting should be called? Which seems to be just after the world is finished loading.

[Busti]

Huh, seems that just the @Mod.EventBusSubscriber annotation on the class does not work. "Manually" registering the class using MinecraftForge.EVENT_BUS.register works. I might not have opened a level when performing that test, I am not sure anymore.  
Here is some more confusing stuff:  

• RegistryEvent.Register<Block> blockRegistryEvent is called using the @Mod.EventBusSubscriber Annotation
• FMLServerStartingEvent event is not called using the annotation, but is called using MinecraftForge.EVENT_BUS.register(this); 
• RegistryEvent.Register<Block> blockRegistryEvent is called twice in ExampleMod
  • Removing the annotation from the nested class does not change this  
  • Neither does removing MinecraftForge.EVENT_BUS.register(this);

[Busti]

[deleted duplicate post]

Edited February 11, 2020 by Busti

[Busti]

Ah, turns out I am the one who is being stupid.  
 

Quote

This does not register an instance of the class; it registers the class itself (i.e. the event handling methods must be static).

I haven't been programming java in a while now. static is pretty un-intuitive to me now.

Edited February 12, 2020 by Busti

[Draco18s]

3 hours ago, Busti said:

static is pretty un-intuitive to me now.

Static is for things that are members of the class, not to an instance of the class.

 

Math.PI and Math.Pow() are examples. There is no need to call new Math() in order to access those.

[Busti]

@Draco18s sure, it is just that I have been programming almost exclusively in scala for about 5 years now and I just do not spend that much attention to the static keyword anymore.  
In my little universe "static" stuff goes into object. Also classes are overrated

Edited February 12, 2020 by Busti

[Busti]

There is one thing that I have been wondering.  
Why do we need @ObjectHolder ? What's wrong with writing instances (i.e. of blocks) directly into the public static final variables?  
Why this black-magic pattern of mutating a final field?  

My best guess is that @Mod.EventBusSubscriber creates an instance of its class really early and we do not want to create block instances at that point in time.  

Edited February 12, 2020 by Busti

[Busti]

Ah, DeferredRegister makes it feel much better. Less Black Magic involved. Feels like an Algebraic Data Type.

Edited February 12, 2020 by Busti

[Draco18s]

15 hours ago, Busti said:

Why do we need @ObjectHolder ? What's wrong with writing instances (i.e. of blocks) directly into the public static final variables?  

What if some other mod wants to override your item's class with a new class in order to add functionality?

 

Now your mod would think that your item is one thing and the game would think your item was another thing, because it was overwritten in the registry.

@ObjectHolder synchronizes those things so that your mod gets the correct reference.

 

What if you want to reference an item from another mod, but don't know if that mod is loaded or not? @ObjectHolder, check it for null.

[Busti]

Yeah, I get that and in the end, if it is how things are done, I do not really care. I just have to use it.  
I guess I wanted to peek behind the curtain a bit and find out why things are done this way.  
But still. @ObjectHolder feels really dirty and DefferedRegister is much sexier. Now if java just had a good monadic for implementation ?

Edited February 12, 2020 by Busti

[Busti]

I mean, just look at this:  

public final class ModBlocks {
    public static final DeferredRegister<Block> BLOCKS =
            new DeferredRegister<>(ForgeRegistries.BLOCKS, SauerkrautMod.MODID);

    public static final DeferredRegister<Item> ITEMS =
            new DeferredRegister<>(ForgeRegistries.ITEMS, SauerkrautMod.MODID);

    public static final RegistryObject<Block> BLOCK_COPPER_ORE = BLOCKS.register("copper_ore", () -> new Block(Block.Properties.create(Material.ROCK)));
    public static final RegistryObject<Item> ITEM_COPPER_ORE = ITEMS.register("copper_ore", BLOCK_COPPER_ORE.lazyMap(block -> new BlockItem(block, new Item.Properties())));
}

It's beautiful!

Edited February 12, 2020 by Busti

[Draco18s]

DeferredRegister is newer than @ObjectHolder