warjort

The log does not say. One of those problem mods is crashing the game before forge/minecraft can print an error summary. Your launcher_log.txt or whatever is the equivalent for your launcher may contain an additional error message?

The errors in your log are: [12:23:23] [main/ERROR]: Missing language javafml version [36,42) wanted by DistantHorizons-1.6.7a-1.19.jar, found 43 [12:23:23] [main/ERROR]: Missing mandatory dependencies: minecraft, minecraft, cloth_config, commonality, minecraft, minecraft [12:23:23] [main/ERROR]: Unsupported installed optional dependencies: apexcore The first says you have a version of distant horizons that doesn't want forge 43.x.x The second is probably somewhat related to the first. It says 4 of your mods are not for the version of minecraft you are using you are missing cloth_config, and one wants a different version of commonality to the one you have. And the last one says something is not compatible with the version of apexcore you have.

This is the forge support forum. We can help you locate the problem mod, we can't fix it. You already know which mods are causing the problem so contact the mod authors. But check you have the correct versions for your version of minecraft first, and look at their mod pages or issues pages to see if they already include information about known compatibility problems.

4 of your mods are not for minecraft 1.18.2 And you are missing geckolib3.

You don't need to do this. You should be able to trigger these effects from the server without messing around with actually destroying blocks. serverLevel.levelEvent(LevelEvent.PARTICLES_DESTROY_BLOCK, blockPos, Block.getId(blockState))

Issue with the weaponleveling mod, contact the mod author.

Please in future when you post code use the <> button. From your error message, it looks like your Atlases.addWoodType() is now called Sheets.addWoodType() That is the method that creates and registers sign Materials. It is this registration being missing in the call to Sheets.getSignMaterial() that is causing your NPE.

That is not how this works. The ints used to identify blocks/blockstates are not necessarily the same when you restart minecraft. The int -> blockstate is dependent upon which mods are loaded and in what order they register blocks. You can't just save int ids in a file and expect them to be the same or even valid when you reload them in the future. What minecraft does is use a palette (as I said above). This is to save space and redundant processing. e.g. in simple terms you might have a save file of 3x3 blocks that is 1, 1, 2 1, 0, 0 2, 3, 1 The palette could then look something like this 0=minecraft:air 1=minecraft:stone 2=minecraft:snow{layers=4} 3=minecraft:oak_log{axis=x) At reload you then deserialize minecraft:stone to find the BlockState and use that where you have stored 1 in your save. What minecraft actually does with its palettes in its code is slightly more complicated than my simple explanation because it can do further optimisations.

Your byg config file has references to friendsandfoes and domesticationinnovation, mods you don't currently have installed.

In general vanilla blocks are not designed to be reused by subclassing. They usually have lots of hardcoding. Look at FenceBlock.connectsTo() used by FenceBlock.getStateForPlacement() In particular how isSameFence() uses block tags to decide if blocks can connect and the hardwiring of FenceGateBlock. You can also try putting a fence gate next to your block to see what happens. 🙂

If you are going down that path, you can just repackage the jsoup jar to add a META-INF/mods.toml. Then you need to publish it somewhere so you can reference it. Since users of your mod will also need to have access to it, probably the easiest place to put it is on curseforge and reference it in your build(s) using: https://www.cursemaven.com/

That error code is a crash in native code. You probably have a file beginning hs_err_pid in your minecraft folder from the time of the crash? If you do don't post the full file (it will have your user credentials in the dump), just post the first 30 lines with the error. But from your description it sounds like a bug with your launcher. I can see from the log, the launcher is actually adding code to the minecraft runtime: -javaagent:D:\minecraft files\my modpacks\Install\sklauncher-fx.jar=1.18.2

All you have done is make the classes available at compile time. The jsoup.jar is not a mod so forge won't recognise it. If you look at that rhino project it has a mod.toml: https://github.com/KubeJS-Mods/Rhino/tree/1.18/main/forge/src/main/resources/META-INF There is at least one other way you can do it: https://forge.gemwire.uk/wiki/Jar-in-Jar It's not something I have personally used, so I can't tell you what the pros and cons are.

I am guessing from the import that this is related to StructureTemplates? Look at the value for StructureTemplate.ENTITIES_TAG and you will see it is all lower case. i.e. you need to change Entities -> entities If that's not the problem, use NBTUtils.prettyPrint() to show the structure of what you are parsing.

Your code looks very broken. This is just what I found from a quick glance at your code. 1) Fundamentally, you are sending block place/remove events to all clients and then trying to place blocks regardless of whether the client knows about the location. At no point do you check level.isLoaded(BlockPos) so you will be writing blocks (or at least trying to) into unloaded chunks. Which is probably the cause of your crash? 2) Your use of statics with a non-thread safe data type (ArrayList) is asking for trouble unless you can guarantee everything happens on the same thread. This could also be the cause? 3) Using statics like that is just wrong anyway. You want to store this data in a proper object like a Level or Chunk capability where you can save the data, otherwise all your data will be lost when the server reboots. 4) You are not checking the event.phase in your tick event, so your code will run twice per tick. Finally on point (1) why are you doing all this extra work at all? If you pass 3 to setBlock() - or use setBlockAndUpdate() - minecraft will handle all this processing for you. i.e. You can do all the processing on the server and not worry about the client. Minecraft will probably do it a lot more efficiently than you, e.g. sending block updates in groups, using smaller packets and not sending updates to clients it knows don't need them.

Look at MoveToBlockGoal and rework it. i.e. Replace findNearestBlock() with your own logic.

Subscribe to EntityRenderersEvent.RegisterRenderers I have no idea what Atlases.addWoodType() did in older versions. I would guess that since atlases are related to images, what you really want is to put your texture in assets/minecraft/entity/signs/yourwoodtype.png If you want to find out how to port methods from older versions, look at how vanilla used that method in the older game. Then find the same process in the modern game to see the new way of doing it. If you want further help, you are going to need post more than 2 lines of code. So we can see what you are doing with some context.

This is a launcher_log.txt from the 6th of September. While your other logs are from the 11th I would guess the launcher log you posted is your vanilla minecraft install. But from the log it looks like you are actually using a relocated curseforge installation? If that is true, your launcher_log.txt will probably be in D:\minecraft file\my modpacks\Install

The classes won't magically appear inside Minecraft at runtime. You either need to: * Make a new mod for JSoup. This is for example what somebody has done for Rhino (a javascript engine). https://www.curseforge.com/minecraft/mc-mods/rhino * Use a gradle plugin to include the jsoup classes inside your mod jar, e.g. https://github.com/johnrengelman/shadow The second method could give you problems if somebody else does the same thing but a different version of jsoup. You might use their wrong classes depending upon which classes get loaded first. To avoid that problem you need to relocate/shade the class names. But this could also give you problems if jsoup uses its own class names as strings internally, e.g. reflection.

Minecraft.getInstance().keyboardHandler.setClipboard("blah");

for (Item item : ForgeRegistries.ITEMS.getValues()) { // blah }

Problem with valhelsia core, make sure you have the latest version then contact the mod author. You don't create a stable modpack by dumping a large number of mods in the mods folder and hoping it works. You add mods incrementally from a known working core, testing each in turn to see if it causes problems.

NbtUtils.read/writeBlockState() BlockEntity.loadStatic/saveWithFullMeta() The modern way to handle the BlockState is really to use the BlockState.CODEC The game uses a Pallete (to save space) when saving chunk sections, see ChunkSerializer. Or an example using NbtUtils is StructureTemplate

super(pLevel, pPosX, pPosY, pPosZ, pItemStack); You can't use this constructor. It will use the vanilla EntityType

On your previous thread, I told you to look at this: https://github.com/MinecraftForge/MinecraftForge/blob/73c1934e7ef931bafbafd0ceb6dce4cdd5dc02a2/src/main/java/net/minecraftforge/common/ForgeInternalHandler.java#L36 That method discards the old entity and cancels the event to stop the original item entity spawning. Without that, what you are seeing getting destroyed is the old ItemEntity. Why you can't see your new entity I can't say. You don't show all the relevant information, e.g. your entity type registration or the log. You should be able to detect to see if your entity is getting spawned by adding a log statement to the top of your event handler.