imacatlolol

Did you maybe forget to use RenderingRegistry.registerEntityRenderingHandler?

Deferred registries are designed to always fire in the correct order, you don't need to worry about that when you're using them. They're basically just event listeners under the hood.

I've got a TER with a variety of animations and OpenGL effects, and one of its properties is to render an arbitrary block on top of it. This is quite easy to do with BlockRendererDispatcher#renderModelBrightness, but the caveat is that it doesn't render with ambient occlusion. Looks great with flat lighting, but sticks out like a sore thumb with smooth lighting. I've tried using BlockRendererDispatcher#renderModelSmooth, but it then seemingly ignores lighting altogether. I've never been great with rendering code, so here's the relevant excerpt of that in case I just forgot something: BlockPos pos = tileEntityIn.getPos(); buffer.begin(GL11.GL_QUADS, DefaultVertexFormats.BLOCK); buffer.setTranslation(-pos.getX(), -pos.getY(), -pos.getZ() - 1); renderer.getBlockModelRenderer().renderModelSmooth(world, model, state, pos, buffer, true, new Random(), 0, EmptyModelData.INSTANCE); buffer.setTranslation(0, 0, 0); tessellator.draw(); I'm probably going about this all wrong. I'd appreciate some pointers!

WorldSavedData uses its read and write methods to save and load things with the NBT format. NBT has no built-in data types for BlockPos, nor an easy way of storing the key-value pairs that maps use. Still, look at how vanilla uses NBT to figure out how to work with it. If you're using integers for the energy values, you could save them all as a single integer array with NBT. Basically, every four integers in the array would be your x y z and energy values. There are other ways of doing this of course.

Please show your logs, and use the debugger instead of just adding exit methods in places. This probably isn't part of the issue, but it also looks like you don't need that EventBusSubscriber annotation since you're using IEventBus#addListener.

Yeah, looks like you simply forgot a step. Call ModLoadingContext#registerConfig to do the actual registration. I personally just do it in my mod's constructor method, not sure if there's a better place for it.

Ha! That's what I get for putting off the update, I guess.

Ah! That's a great workaround, thank you!

This has been a thorn in my side for a while, and I've never been able to find a good solution. Whenever I update Forge, the newly mapped sources get applied just fine. However, the previous version still ends up lingering around in my environment, resulting in my searches getting cluttered and generally being a nuisance. The solution that I've been using up until now is to just delete my Gradle cache by hand. In some cases, I have to delete the entire cache for it to be resolved, which forces me to sit around waiting to Forge to patch and re-map the game's sources for my desired version. This gets out of hand pretty fast if I'm swapping versions a lot, and can be troublesome if I'm developing for multiple versions in the same project. Chances are that I'm doing something wrong here. Probably an IDEA configuration or Gradle task that I don't know about. Any ideas?

I can verify that what Draco said is true, and enchanted books are the only exception to the rule. In order to get the result you want, you will have to use AnvilUpdateEvent and force it. Still, study the method that Animefan mentioned. You may also want to set your SubscribeEvent annotation to a different priority to make your mod's behavior easily overridden like vanilla, but that's entirely up to you.

You're using a jar that just contains source code. You need to use a jar with compiled code. In the case of JEI, you can actually use it as a Gradle dependency.

It's a block state issue. You're using Block, but it doesn't have the axis state that's needed for the variants. Use RotatedPillarBlock instead. In the future, please post your logs when something's not working to make it easier to find the issue.

You're using a RegistryObject, so just call its get method.

Just a heads up, the isActiveItemStackBlocking method inside LivingEntity might be more useful for this case. As for the events not firing, I'm not sure. What is your code, and what are you doing to test it? In some cases, LivingAttackEvent doesn't always fire on players (like if a player is in creative, I think). In fact, it should actually be firing twice on players if I'm reading the code right... Wait nevermind, I think it only fires once. The code is just confusing.

Most things that use the colors (excluding leather armor and such) don't use them dynamically; you'd have to actually change the textures, names, etc. to have any effect. In any case, no. There's no reasonable way to change anything to do with DyeColor. Oh right, reflection duh.

Well there's a few options, but generally you'd want to use setMotion for this sort of thing. I haven't messed around much with entity motion, but if I had to guess, you would first call getMotion to use as a base, then add the look vector (getLookVec) multiplied by some amount. Not sure if it'll work as expected, but it should give you an idea of where to go from there.

You can call getAttackTarget for that. Make sure to also validate the target using canAttack just to keep things clean. I'd recommend checking out the updateAITasks in BlazeEntity as a reference. Lots of stuff can be learned just by exploring vanilla classes. Nah don't worry, we all are at the beginning.

The latter half of updateAITasks in the original BatEntity class might be part of the issue. Try playing around with the code there (such as making it only run when the bat doesn't have an attack target) and seeing if that helps.

RedstoneParticleData is not a particle. Extend RedstoneParticle instead.

Make a custom particle and override getRenderType.

If I had to guess, use the PARTICLE_SHEET_LIT type of IParticleRenderType. You could also make your own if it doesn't work in the way you want.

Good point, it might be easier to go with the WorldSavedData, especially since that was what OP wanted in the first place. It's at least still valuable to learn about Forge's config system in general I guess.

Oh, I didn't know. Thank you for the clarity!

@Cadiboo has a great example mod that includes examples of how to make configs here.

Show your code. That's a good idea, but I'm pretty sure onEntityCollision only triggers when an entity is inside of a block's space. Since your block is a full block, I don't believe that code will ever run.