warjort

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.

I just tried loading this modpack and it works fine for me. Split up the file. It is the bottom part that is likely the most interesting. Find where it says "Preparing spawn area" and copy from there.

No that's the latest.log it has no DEBUG information.

This shows integrated dynamics trying to load a class that has a mixin defined for it (the problem is NOT integrated dynamics) The error message is not very informative, but it basically says there is something wrong with some java bytecode somewhere. Unfortunately, it doesn't say which class is being changed or which mixin is trying to change the class. The debug.log may have more information?

You know this modpack is a beta/pre-release? You should report problems to the modpack author. But maybe this workaround is relevant to you? https://www.curseforge.com/minecraft/modpacks/encrypted_?comment=19

Recipes: https://forge.gemwire.uk/wiki/Recipes Tags: https://forge.gemwire.uk/wiki/Tags So if you follow the convention, your ingot should be in forge:ingots/steel or data/forge/tags/items/ingots/steel.json e.g. https://github.com/BluSunrize/ImmersiveEngineering/blob/1.18.2/src/generated/resources/data/forge/tags/items/ingots/steel.json as used in https://github.com/BluSunrize/ImmersiveEngineering/blob/86211504ad15b866e6df4685eb16c239cd6f16bb/src/generated/resources/data/immersiveengineering/recipes/crafting/gunpart_hammer.json

Speak to the mod author. They are likely not properly resetting their rendering context properly after drawing stuff, so it is leaking things into other people's drawing operations.

Your issue is that Mojang changed the format for saving world gen structures within world saves in 1.18.2 This was to make structures more configurable in datapacks. While they have a way of updating vanilla structures, it can't fix modded structures - before 1.18.2 there was no standard format for this data. The only thing I can suggest is to talk the mod authors for the world gen mods that you have. They may know a way to fix the data?

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.