warjort

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. 🙂

Same problem, but its the controllable mod.

The whole point of using a RegistryObject is that creating the real object is deferred until it is safe to do so. You are creating the EntityType objects in static initializers (i.e. during classloading) which is long before this is true.

You are trying to run broken client side only mods on the server. Remove rubidium and its related mods, e.g. oculus from the server, you don't need them there. It's literally one of line of configuration for the mod author to correct this problem and yet they still haven't fixed it. 😞

Aren't you already listening to the EntityStruckByLightining event? You need some way to differentiate the item entities you spawned from the normal ones. One simple way might be to look at the ItemEntity's age to see if it is zero, i.e. it was just created.

Yes forge 42 is 1.19.1, 41 is 1.19

You are trying to use the 1.19.1 version of torchit in 1.19 https://www.curseforge.com/minecraft/mc-mods/torch-hit/files

No I don't, sorry. Maybe somebody else will help you find the correct file? It will have lines that contain Render thread/DEBUG For the last error you posted it will probably not be relevant anyway. I was more interested in it to see which mod was causing the mixin error, but that doesn't appear in your latest post. If there is no new information available, I don't know what more I can add?

Don't, this is the kind of thing mod developers do because they think their mod is more important than everybody else's. 🙂 Even if you can fix all the issues this causes with vanilla code, there's no way to predict how this might break other mods. You should create a new item. If the user or modpack developer thinks your item is better than the vanilla item, they can change the recipes to use your item.

See SignRenderer

This is normal. Beyond a certain point the server stops ticking entities to save resources. See DistanceManager.isEntityTickingRange() and its uses.

I have no idea. We've identified some of the errors you are having. If you are not going to post the debug.log to see if it has further information, you will have to take what we have found back to the modpack author.

Use the /locate command it will list all structures in the autocompletion. The part before the : is the mod name.

That's still not the debug.log Your error now is showing : Something in that modpack is trying to start a rest server on the client. Which is very dubious. It can't do it for you because the port is already in use.

The vanilla chest uses For its items.

Look at the code where it crashes. It has an itemStack::copy of the item stack in each slot. The error says one of your slots contains a null, when you should be using ItemStack.EMPTY for unoccupied slots.

Although the games loads for me, when I exited the game, I got the error code -1073740940 which is C0000374 or "heap corruption". Given this modpack contains libvlc native code, that is a likely candidate for the problem. You might be seeing the same problem but in a different place? Heap corruption gives random errors in random places. 🙂

This is usually caused by having a very old version of java installed. Try updating it, or downloading a more recent release: https://adoptium.net/ It can also be caused by wrong configuration in your hosts file. c:\Windows\System32\drivers\etc\hosts or /etc/hosts on other OSes.