Cadiboo

If the textures are there normally but not when you run data generators you might want to make a GitHub issue after confirming that this isn’t intended behaviour.

Renderers get registered after all registry events have finished. So after EntityTypes. I’ll put an example in my example mod

Pretty much. You might be able to just extend it and use suppliers and you can probably clean up a bit of it’s code in your class.

If you need it before it exists, you’re out of luck.

You can also find them in the client-extra jar in your IDE’s libraries.

Yes. https://github.com/MinecraftForge/MinecraftForge/pull/6464/commits/c8c5de901da70bedb084570d170d46a2c9a1a84d https://cadiboo.github.io/tutorials/1.15.1/forge/3.3-config/

Assuming you’ve set up a forge workspace already, do it the easy way with DeferredRegister. Since you have prior java experience I’ll link my example mod instead of my tutorials. https://github.com/Cadiboo/Example-Mod/blob/1.15.1/src/main/java/io/github/cadiboo/examplemod/init/ModItems.java Remember to register your DeferredRegister in your mod constructor!

Why are you using a Java model? There’s the ISTER system if you really need to render a Java model but you should definitely use the static model system OR load your model parts from files to support resource packs.

All you need to do is install DCEVM (I do it as a full rather than alt JVM) and then change your project SDK to point to it. HotSwapAgent isn’t necessary.

Update your mappings?

Minecrafts got like everything abstracted away in multiple ways. Looking at vanilla’s code is the best way to understand stuff. The basics of rendering are - get the render buffer you want - add data to that buffer Your data then gets drawn by minecraft AT A LATER DATE. So you cannot interact with open GL directly as by the time your data is rendered, the open GL state will have been changed by other stuff. You render data to a render type buffer by adding vertices to the buffer. You do this by calling methods on the buffer like “pos”, “color”, “tex” and then finish it off for each vertex with “endVertex()”. These methods are chainable so you can do “buffer.pos(x, y, z).color(r, g, b, a).tex(u, v).endVertex();”

You’re definitely going to want to call super regardless of if you’re going to deflate soon or not. No. There is only one renderer instance. This instance renders all of your entities one by one. So you need to get the data from your entity in your Renderer and act according to that data

EntityTypes get created after Items. You’re trying to use an EntityEntry from your item when you make a spawn egg. This can’t work. As I said, the situation is problematic. That’s why I said you should make your own spawn egg that accepts a Supplier<EntityType> instead of an actual EntityType.

Probably, I know that it works on 18 and 19. If you decide to update to 1.14.4 instead of 1.15.2 just leave rendering alone completely as it changed a lot in 1.15 and it’s not worth rewriting your code twice.

public final class ModItems { // 1: This shouldn't be in a class called ModItems // 2: You shouldn't be using this method, thats why its depreciated, you should be using the registry events @SuppressWarnings("deprecation") private static <T extends Entity> EntityType<T> register(String key, EntityType.Builder<T> builder) { return Registry.register(Registry.ENTITY_TYPE, key, builder.build(key)); } public static final DeferredRegister<Item> ITEMS = new DeferredRegister<>(ForgeRegistries.ITEMS, Main.MODID); // This shouldn't be in a class called ModItems //public static final DeferredRegister<EntityType<?>> ENTITY_TYPES = new DeferredRegister<>(ForgeRegistries.ENTITIES, Main.MODID); // 1: This shouldn't be in a class called ModItems // 2: You shouldn't use static initialisers // 3: You shouldn't register stuff statically // You should create and register your objects inside the registry events public static final EntityType<UnicornEntity> UNICORN = register("unicorn_entity", EntityType.Builder.create(UnicornEntity::new, EntityClassification.AMBIENT).size(0.5F, 0.9F)); // This is correct - it's how you should be doing your registration, but it shouldn't be in a class called ModItems //public static final RegistryObject<EntityType<UnicornEntity>> UNICORN = ENTITY_TYPES.register("unicorn_entity", () -> EntityType.Builder.create(UnicornEntity::new, EntityClassification.AMBIENT).build(null)); public static final RegistryObject<Item> RAINBOW_INGOT = ITEMS.register("rainbow_ingot",() -> new Item(new Item.Properties().group(ModItemGroups.RAINBOW_MOD_GROUP))); public static final RegistryObject<Item> UNICORN_ENTITY_EGG = ITEMS.register("unicorn_entity_egg", () -> new SpawnEggItem(UNICORN, 0xf0f0f0, 0xdf51f5, new Item.Properties().group(ModItemGroups.RAINBOW_MOD_GROUP))); } You should remove entity related stuff from your ModItems class and make a new class like so: public final class ModEntityTypes { public static final DeferredRegister<EntityType<?>> ENTITY_TYPES = new DeferredRegister<>(ForgeRegistries.ENTITIES, Main.MODID); public static final RegistryObject<EntityType<UnicornEntity>> UNICORN = ENTITY_TYPES.register("unicorn", () -> EntityType.Builder.create(UnicornEntity::new, EntityClassification.AMBIENT).size(0.5F, 0.9F).build(null)); } and register your DeferredRegister in your mods constructor like this.

Do they get loaded when you run the game though?

That’s not right. If you look at the DeferredRegister documentation you’ll see why it isn’t right. I would just not use vanilla’s spawn egg code - it wasn’t made to be used by mods Or at least I would extend it and make it use a supplier for your entity type.

https://github.com/Cadiboo/Example-Mod/blob/43476b64c30e816fc717d1c3d059f28ce5b9ff6d/src/main/java/io/github/cadiboo/examplemod/container/ElectricFurnaceContainer.java#L25

Don’t send it yourself, vanilla will send the packet for you. Edit: Yeah, if you only need it for the GUI there is a better way of doing it

Show what you’ve tried. EntityType registration should work perfectly with DeferredRegister (aside from spawn eggs as I’ve said)

if (bird.inflated) inflatedModel.render(); else normalModel.render();

Do some research in Java generics. The name T is just convention the same way as it is convention to use i as a loop variable

I would just switch the models then, why do you need a render layer?

How are you making your blocks emit light values that travel further than normal?

You never define the M type parameter