warjort

Your mods don't match between the client and server. The createaddition and morestoragedraws mods look like a mismatch in versions?

You won't be able to reuse EnderChestBlockEntity like this: https://github.com/Tucky143/Crystal-Minecraft-Mod-for-1.19/blob/fb13bf04866a944fdd76325008a2bb5cf495a0fb/src/main/java/example/examplemod/block/custom/CrystalEnderChest.java#L66 The vanilla ender chest block entity is hard wired to use Blocks.ENDER_CHEST, both in its BlockEntityType and within the class itself. You will need to make your own BlockEntity To answer your direct problem, if you look at BaseEntityBlock, it modifies the RenderShape to be invisible (it assumes you will use a BlockEntityRenderer). If you want to use a json model for a BlockEntity you need to override this back to RenderShape.MODEL

Remove rubidium and its related broken client side only mods from the server, you don't need them there.

This is a crash in your graphics driver when Optifine is trying to create shaders. But this also looks like a "vanilla" client, you are not even using forge?

Look at the link I posted above, Optifine is not compatible with this version of forge.

As I said above. They were written for an earlier beta release of forge 1.19 You could try to run an earlier beta of forge 1.19 like 41.0.63, but then you will probably find other mods don't work because they are written for the stable/recommended 41.1.0 release. Then you would have to find earlier releases of these mods that work with the beta (if they even exist?). I would recommend that instead of messing around with alpha/beta versions you wait for the stable versions of the mods you want to use.

You are trying to use 1.19 mods with 1.19.1 When you download a mod you should make sure it is marked as compatible with the version of minecraft/forge you are using. These mods don't even look like they are updated for the forge 1.19 recommended release, let alone 1.19.1? 🙂 merchantmarkers, TorchSlabsMod, MoreMinecartsMod, WaveyCapesMod, SkinLayerMod, Waddles, IronChests, IronFurnaces, notenoughanimations, buildersadditions If these mods don't have a version marked as compatible with 1.19.1 (released last week), you will have to wait for them to update. e.g. the latest IronFurnaces is for 1.19 and is an alpha release that has not been updated since June. https://www.curseforge.com/minecraft/mc-mods/iron-furnaces/files/all?filter-game-version=1738749986%3a73407

You are trying to use the 1.19 version of mcwwindows in minecraft 1.18

Issue with upgradednetherite - looks like non-threadsafe registration of shield item rendering properties. Contact the mod author.

There are no ERRORs in that long. There are some DEBUG messages which contain the word error, you can ignore them Or you could figure out what they really mean if you are interested, e.g the ones with the stacktrace are netty trying to figure out the optimal method to do reflection for this version of java. The server thread running slow at the start is also normal. It has to do a lot of work when it first loads. If it continues then you might have a problem, either with your computer or some slow code you wrote. 🙂

https://github.com/sp614x/optifine/issues/6974 You have to enable the debug.log in the minecraft settings on curseforge

First you should never just copy/paste from a tutorial. You should try to understand what it is doing at each step. Otherwise you will never be able to fix the inevitable bugs or correct the tutorial code when it is wrong. 🙂 You have at least 2 errors (both are related to misunderstandings in events/registration) You can read about events (along with other things) on this wiki: https://forge.gemwire.uk/wiki/Main_Page It is important you know how this works, it is fundamental to writing forge mods. 1) You are missing the subscriber definition on your ModEventBusEvents class which means the attributes are never added to your entity https://github.com/Overtekk/Pingoo/blob/4b91d22a1d2851b432f38a861623c90f538a9dbe/src/main/java/net/overtek/pingoo/event/ModEventBusEvents.java#L8 @Mod.EventBusSubscriber(modid = Pingoo.MOD_ID, bus = Mod.EventBusSubscriber.Bus.MOD) public class ModEventBusEvents { 2) You should be registering your entity renderer in the EntityRenderersEvent.RegisterRenderers the code here is never invoked and it is not the correct way to do it https://github.com/Overtekk/Pingoo/blob/4b91d22a1d2851b432f38a861623c90f538a9dbe/src/main/java/net/overtek/pingoo/Pingoo.java#L46 It should be something like - untested code - don't just copy/paste without confirming I am correct 🙂 @Mod.EventBusSubscriber(modid = Pingoo.MOD_ID, bus = Mod.EventBusSubscriber.Bus.MOD, value = Dist.CLIENT) public class ClientModEventBusEvents { @SubscribeEvent public static void registerRenderers(EntityRenderersEvent.RegisterRenderers event) { event.registerEntityRenderer(ModEntityTypes.PENGUIN.get(), PenguinRenderer::new); } } NOTE: The Dist.CLIENT, this is a separate class for mod registration events that are only applicable to the client, e.g. graphics like your renderer

It doesn't look like libraryferret, aquaculture or the dummmmy mod have updated to the recommended release yet either. You should check you have the latest versions of these mods. Otherwise, you will have to wait for them to update.

Which version of forge does it say optifine is compatible with here? https://optifine.net/downloads They haven't (yet) updated optifine for forge's recommended release.

That's not totally true. You can subclass CraftingMenu as long as you override 2 key methods public class MyCraftingMenu extends CraftingMenu { private final ContainerLevelAccess access; public MyCraftingMenu(int p_39356_, Inventory p_39357_, ContainerLevelAccess p_39358_) { super(p_39356_, p_39357_, p_39358_); this.access = p_39358_; } public MyCraftingMenu(int p_39353_, Inventory p_39354_) { this(p_39353_, p_39354_, ContainerLevelAccess.NULL); } // Override to return your menu type that identifies the screen to use @Override public MenuType<?> getType() { return MY_MENU_TYPE.get(); } // Override to identify the block instance (used to force the user out of the screen if the block is destroyed) @Override public boolean stillValid(Player p_39368_) { return stillValid(this.access, p_39368_, MY_CRAFTING_BLOCK.get()); } } Of course this assumes the vanilla CraftingMenu is a useful for what you want to display on the screen. If your crafting screen is radically different you will want your own AbstractContainerMenu implementation with the forge additions described above.

That code awards the "construct beacon" achievement to any players near pPos. The code to draw a beacon beam is in BeaconRenderer.renderBeaconBeam()

Item.canBeHurtBy() Yes I saw that, but I got the impression the original poster was writing something more generic from the original question. 🙂

By the way, nobody answered the other question. You should use something like (untested code):

Do you really think creating a new EntityType and writing all the code to replace spawnAtLocation() and maintain in when Mojang changes it future is simpler than modifying one value? 🙂

There is another way you can do this. A lightning bolt does 5 points of damage and ItemEntitys are created with health = 5 If you use an Access Transformer to make the health field public, you can modify your spawned ItemEntity so it has enough health to survive a lightning strike. The side effect might be the ItemEntity also survives other damage its not supposed to, e.g. an explosion.

You should upgrade through 1.19 first. The announcement: https://forums.minecraftforge.net/topic/114502-forge-411-minecraft-119/#comment-507843 contains this link: https://gist.github.com/amadornes/cead90457e766f6d4294cb6b812f91dc and also this list of changes https://gist.github.com/SizableShrimp/882a671ff74256d150776da08c89ef72 1.19.1 is pretty new so it won't have changed much (if at all) compared to 1.19

Not for this issue, yes. But it does mean your mod won't stop working on a dedicated server. 🙂

Are you really trying to handle this on the client? The event is only fired on the logical server from what I can see. See LightningBolt.tick() You should remove the Dist.CLIENT.

Use same pattern you use for all RegistryObjects: - private static final EntityType<CrabEntity> crab = createStandardEntityType("crab", CrabEntity::new, MobCategory.MONSTER, 1.3f, 1.8f); - public static final RegistryObject<EntityType<CrabEntity>> CRAB_ENTITY = ENTITY_TYPES.register("crab", () -> crab); + public static final RegistryObject<EntityType<CrabEntity>> CRAB_ENTITY = ENTITY_TYPES.register("crab", () -> createStandardEntityType("crab", CrabEntity::new, MobCategory.MONSTER, 1.3f, 1.8f)); Then you get the real object later when you need it using CRAB_ENTITY.get()

entityculling, notenoughanimations, customcrosshair and legendary tooltips also have a similar problem. These graphics guys, just don't test their mods properly. 🙂