Cadiboo

You can call Event#setCancelled on cancellable events. IIRC you should not be cancelling this event though because it results in the items in the crafting matrix being consumed but the item not being given to the player. What are you trying to achieve, from an end-user’s (a player) perspective?

You event subscribe methods here, here and here are not static but you register you class here with the annotation and here with the register class method. You might want to read the documentation on events again. You also register your RegistryEvents to the FORGE event bus here but also register it to the MOD event bus with the annotation here. You should only register your class once AND the RegistryEvents class only handles events that fire on the MOD event bus so registering it to the FORGE event bus is pointless. Other stuff I’ve noticed: - You don’t need a proxy but still use one - Registry#registerAll exists and can be used to register many objects at the same time more cleanly - Your mod would be better suited using DeferredRegister

You obviously copied and modified the vanilla code when you first created that class. When you’re updating a class like that the correct thing to do is copy + paste that class again and then apply your modifications on top of the new code.

You need a model and texture https://github.com/Cadiboo/Example-Mod/tree/1.15.1/src/main/resources/assets/examplemod/models/item

Choose one style (tabs) and have your editor replace all occurrences of the other style with your preferred style. Also be sure to tell everyone that your style is superior at every opportunity.

In 1.12.2 it was very easy with RenderGlobal’s event listeners. However it now requires a coremod to modify the logic OR I think that when your block updates you can invoke a block update (World#notifyBlockUpdate) on blocks in early chunks form inside your own block’s onBreak code or something to fix this. As I said though, this is a vanilla bug and I would recommend against trying to fix it as there is a decent chance that you will cause a stack over flow from recursively updated chunks if two neighbouring chunks both contain your light. That being said, if I was doing this I would make a coremod that hooked into the markRangeForRenderUpdate method and extend it (or also update blocks at the pos offset in each direction) by oldState#lightValue. It might also be good to see if this bug occurs when placing new lights & if not investigate why the behaviour is different.

You should pass in null as the entity type as you’re going to override the getType method to return your one Just override “getType” like any other method. You can use an anonymous subclass if you want. The only issue that I’ve found with this is that the spawn egg textures don’t get generated for your egg. I’m looking into this.

You still need a separate model for each, but sub models can override textures from their parent.

This is not at all true. There is a small (easily fixable on your end) issue with SpawnEggItems. Not Entities.

Use ForgeConfigSpec#defineList. It returns a List<String>.

Yes. Your model instances should go in your renderer. Where else would you have them?

Many reasons including and that entities are common (exist on both client and server) and rendering is client only. No. You can use a lambda/method reference. This has been the case since whenever Java 8 came out, any tutorial that still uses a seperate RenderFactory class is extremely outdated.

The whole point of them is that they are dead simple. The only issue with them is the spawn egg thing which is easily fixed right now (pass null into the constructor + anonymous subclass that overrides getType) and is likely to be made even easier in the future.

So it’s a vanilla bug? If vanilla doesn’t re-render nearby chunks you can do it yourself. I do it in my mod NoCubes to update every block in a 4x4 radius rather than vanilla’s 3x3 but I don’t recommend it.

That sounds like it needs to be done then.

Any reason why Forge doesn’t patch in another constructor the way it does for fluids (or maybe it’s buckets?)

Either write your own better code or use the same hack that’s been used for ages of creating your entity type in the item event that is incompatible with dynamically reloading registries. I would definitely go with the former.

These two topics also describe this issue

ModConfigEvent.ConfigReloading was renamed to ModConfigEvent.Reloading if that wasn’t already clear. This means that mods need to update their code to reference the new name. Can I get a list of your mods please btw? I’m trying to collect some mods that have configs for testing.

Relevant other topics

That’s pretty interesting. Unfortunately I’ve got very little experience with java model rendering so I don’t think I can help.

It just lets the method return both the spec and your configured instance. You need the spec for registration & baking checks later and you need the instance for getting/setting values. If by “setup” you mean “registration”, no. Server config is synced to the client so it needs to be registered on both sides. It is good practice to only register your client config on the client distribution but unless you interact with client-only code in your config (which is unlikely) it’s not necessary.

That’s up to you. As I said, I suggest using OptiFine/DynamicLights as a dependency.

I hadn’t considered that. Still you’ll probably want to change just the movement stuff rather than circumventing the entire tick method. The entity that is currently being rendered is passed into your renderer as one of the parameters. Don’t call anything on your renderer from your entity.

So when you break all of them, why isn’t lighting updating? I would do some debugging comparing what happens when you break a torch to what happens when you remove your light emitting air blocks.