[1.8] Suggestion for custom block textures using TextureMap

[PlayerInDistress]

Currently, a hook exists to add custom textures before the texture map is stitched, and it looks like this:

public class CustomBlockTextureStitchEvent
{
   @SubscribeEvent
   public void onTextureStitchedPre(TextureStitchEvent.Pre event)
   {
      event.map.setTextureEntry("lucky:blocks/lucky_block", new CustomBlockTexture());
   }
}

 

This problem with this is that the forge method setTextureEntry does not allow for textures to be overriden, you can only add a texture that is not already registered. What I am trying to do is make my modded block load it's texture from an external location, so I need to add a custom TextureAtlasSprite to the registry which has a custom load method (i.e. CustomBlockTexture).

 

However, since setTextureEntry does not allow for overrides, it has very limited use. All of the bellow functions are suggestions for what could be added to the TextureMap class to make it much more usable, but only one of the needs to be added:

 

public boolean setTextureEntry(String name, TextureAtlasSprite entry, boolean override)
{
    if (!mapRegisteredSprites.containsKey(name) || override)
    {
        mapRegisteredSprites.put(name, entry);
        return true;
    }
    return false;
}

public boolean clearTextureEntry(String name)
{
    mapRegisteredSprites.remove(name);
}

public Map getRegisteredSprites()
{
    return mapRegisteredSprites.put(name, entry);
}

 

The last option is particularly useful as it allows full control over the registry, but any will work.

[LexManos]

This is intentional, why are you overriding someone elses's texture?

[PlayerInDistress]

Sorry for the confusion, the lucky:lucky_block is my texture from my mod. I just want it to be loaded from outside of the mod's zip file, and to do that the current entry in the TextureMap would need to be overriden. I understand that blocking this feature is intentional, but I see no harm in overriding textures. If you do, however, then there could always be some sort of check (such as !name.startsWith("minecraft:")), which would only allow modded textures to be overriden.

 

Lastly, I have actually found a work-around solution for this problem. I have registered a new texture ("lucky:blocks/lucky_block_custom") and have created a custom model loader and used it to load my model, with my custom texture. While this woks, it requires several model loading lines to be copied from different places, feels wrong since I am not actually making a new model, will be annoying to manage and overall seems like way too much for  something as basic as changing the texture.

 

My point is, I could modify this model loader and use it to override any default minecraft texture, as well as textures from other mods. So if I am able to do this, then why shouldn't TextureMap allow it directly?

[PlayerInDistress]

If registering an IResourcePack would make this work, then I will be happy to try it. I will not ask how to do this, nor will I ask for sample code, but it would be really helpful if I at least knew which classes handle this, or had an online reference to an example. It would really save me time looking through all of the code.

[PlayerInDistress]

Thank you very much. I am almost able to do this now, but I can't access Minecraft#defaultResourcePacks. I am not exactly sure how to use reflection. All I need to know is how to register the recourcepack, and the rest I can solve for myself.

[LexManos]

Unneeded suggestion, answer is no. You can do it correctly with already exposed vanilla mechanics. No hacking needed...