Hi.

 

I would like to edit what EntityRender does. I first tried the naive way : extend it, and replace the (already public) field Minecraft.entityRenderer, at preInit.

		assert(Minecraft.getMinecraft().entityRenderer != null);
	Minecraft.getMinecraft().entityRenderer = new ModdedEntityRenderer(Minecraft.getMinecraft(), Minecraft.getMinecraft().getResourceManager());
	((IReloadableResourceManager) Minecraft.getMinecraft().getResourceManager()).registerReloadListener(Minecraft.getMinecraft().entityRenderer);

As expected, Crash report : http://hastebin.com/uzumikujim.txt

The original renderer is instanciated at startGame() and probably holds data I loose when overriding the field with a fresh instance, hence the crash I suppose.

Could I do it any other way than byte code patching or is it really too deep for more.. conventional modding ?

 

 

Question: Where did you initlialize the renderer? Your preInit in your main class? Client-Proxy? CommonProxy?

Minecraft#getMinecraft is purely client-side. Running it on the server-side will always return nullpointer, because for the server, that method does not exist.

 

I do apologize if you already know of this. You'd be surprised how many try to run Minecraft#getMinecraft server-side.

	EntityRendererSpecial entityRenderer = (EntityRendererSpecial) Minecraft.getMinecraft().entityRenderer;
	Minecraft.getMinecraft().entityRenderer = entityRenderer;

In the client proxy, yes.

 

Anyone can try for himself. Do a class that extends EntityRenderer (no need to edit anything, just do a useless class) and add the code I posted in OP in ClientProxy.preInit(), the crash will happen, it's easy to reproduce.

 

I do not know exactly what happens between startGame() and the triggering of preInit(), maybe doing the swap earlier (than preInit()) could do the trick.. which is assuming the rest of startGame() after the instanciation does not modify entityRenderer which is a big assumption since it has already been registered and can by that point be called by absolutely everything in the mean time.

 

Given prompts that appear sometimes, I'm f*cking up something with FML too, so my hope is decreasing.

 

 

This piece of code didn't crash for me

 

@EventHandler
public void preInit(FMLPreInitializationEvent event) {
	if (event.getSide() == Side.CLIENT) {
		EntityRendererSpecial entityRenderer = (EntityRendererSpecial) Minecraft.getMinecraft().entityRenderer;
		Minecraft.getMinecraft().entityRenderer = entityRenderer;
	}
}

 

Now add a simple test() method with let's say, a println, and call it.

((SpecialEntityRenderer) Minecraft.getMinecraft().entityRenderer).test().

Boom, crash. Because this is not an instance of SpecialEntityRenderer, so you're calling something the object don't have.

When existing methods are called, it's the EntityRenderer behavior that will be chosen, not the Special one.

What edit are you trying to make to EntityRenderer?

I would like to differentiate the lightmap updating between dimensions by editing EntityRenderer.updateLightmap(), change the perceived brightness (lighter/darker) according to moon phases or random days I decided.

I would like to differentiate the lightmap updating between dimensions by editing EntityRenderer.updateLightmap(), change the perceived brightness (lighter/darker) according to moon phases or random days I decided.

There is a way with reflection for that, look at how the dynamic texture is managed.

There is a way with reflection for that, look at how the dynamic texture is managed.

 

Forcing my own lightmap texture so ? I think it does handle sky exposure, maybe phases.. I'm not sure how that would work out...

 

You already did it yourself in the past ?

 

Believe me as I've been stupid enough to try this; DO NOT REPLACE THE ENTITYRENDERER! You'll break Optifine, you'll break shaders, you'll need to rewrite all your code with every update; just dont do it.

 

Changing the EntityRenderer.updateLightmap() is extremely basic using an ASM system, or a Forge Hook if you get one. I'd much rather look into both than making that mistake again