Leaderboard

Well, whatever program you are using to create models - it is not a good one and you'd be better of creating models yourself. Not only is it wasting CPU cycles with it's inneficiently generated code it is also the cause of your issue - GlStateManager.color(1.0F, 1.0F, 1.0F, 0.0F); These lines in your model code are making your entity invisible by setting it's alpha to 0. You have to manualy set the alpha to 1 in all of them.

That's 32bit, you need x64 instead of x86

Just keep this up, everybody seems to ask help with gradle here.

RenderingRegistry.registerEntityRenderingHandler(EntityPhantom.class, new RenderPhantom(Minecraft.getMinecraft().getRenderManager(), new ModelPhantom(), 0 )); This is an outdated and a deprecated way to register renderers for your entities. Use the overload that takes IRenderFactory as it's second argument. This also must be done in pre-init. You can't have client-only code in a common class like this. Use proxies. You are not registering your mob on a server due to the fact that you are only calling register from your client proxy. Entity registration is common. Almost. Proxies are not for registering. Just register the entity in pre-init and a renderer for it in your client proxy's pre init handling. When you are using EntityRegisty::registerModEntity the IDs will never conflict with IDs from other mods/vanilla. As a matter of fact you should start with an ID of 0 and go up from there. I am not sure if 700 will even work as it is not a byte... I'll look into it. EDIT: It's fine, forge uses integers to sync entity ids. You do not need to use a separate method to register a spawn egg, EntityRegisty::registerModEntity has an overload that does this for you. This is just an advice, using the separate method is fine. The model code is ridiculously inefficient with GL state changes. Why is it enabling blend before rendering every part and then disables it just to enable it again a line later? You can enable all your GL flags at the beginning, render everything and disable them after that. Why are your model fields are named as if they were deobfuscated? This is your model, you can name them however you want. GlStateManager.scale(1.0F, 1.0F, 1.0F); Scaling anything by 1/1/1 is pointless. It's as pointless as it gets as it does literally nothing. I am not sure what is going on with the renderer itself. It might be a GL issue, might be a texture issue. Try fixing everything else that I've pointed out and see if that also solves it. If it doesn't post the updated code and your mob texture and I'll try debugging it to see what is the cause of the issue.

There's currently no way to specify custom config GUI entries for properties created through the annotation-based config system without reflecting the Configuration instance from ConfigManager and calling Property#setConfigEntryClass manually. Could an annotation be added that allows a custom Property.Type or IConfigEntry class to be specified for the generated Property? On a related note, it's currently not possible to use GuiConfigEntries.BooleanEntry, GuiConfigEntries.CycleValueEntry or GuiConfigEntries.ChatColorEntry with Property#setConfigEntryClass because their constructors aren't public. Attempting to do so throws a NoSuchMethodException for the constructor when the config GUI is opened. It's also not possible to extend these and add a public constructor, since the constructors are private or package-private. Edit: Reported this on GitHub here.

You never put any values in your EnumVariant.META_LOOKUP. You very well could use the EnumVariant#values()

The actual ore dictionary matching has moved to OreIngredient (forge:ore_dict in JSON), which you can use as an Ingredient in any Vanilla or Forge recipe class. You can create and register recipes in code if you want, but moving to the JSON system is recommended.

no