warjort

Remove rubidium-extras until they fix it: https://github.com/TeamDeusVult/MagnesiumExtras/issues/26

https://github.com/sp614x/optifine/issues/6974

You posted this yesterday and nobody answered you. Probably because it is too much effort to to answer your question, which I can paraphrase as "Here's some random code I wrote please tell me the bugs." Your code looks something like the vanilla crafting table but with the recipe book hacked out of it. I would guess you probably removed some other important code with it? The part where it does the recipe handling is the slotChangedCraftingGrid() method. You should start debugging there. See if the method is even called. Check if the parameters and results of the method calls make sense to what you are trying to do in game. If you have specific questions about bits you don't understand feel free to ask them. But don't ask us to write/fix your whole mod for you. You will likely get no answer like your original question. 🙂 You would be more likely to get an answer if you put something that compiles and runs on github for people to download. An alternative would be to look at another mod that implements crafting tables without recipe books. Then you have a starting point you know works. e.g. https://github.com/BlakeBr0/ExtendedCrafting Make sure you follow the license and credit the original author if you borrow their code.

https://johann.loefflmann.net/en/software/jarfix/index.html

You also have a number of long ticks before you got disconnected. Are you sure your computer can run both the server and your client at the same time? Look at task manager and check your memory status. It might be doing a lot of paging of memory to and from disk if you don't have enough real memory to run both.

These messages look suspicious. They represent network packets the server sent, but the client doesn't understand them. Check you have latest versions of those mods on the client and server and then ask the mod authors if these are a problem.

Ah so you didn't think showing that was important? 🙂 You still don't show your block model or the shapes you think should work. I assume your issue is the black part on underside of the top. Does it kind of work if you put the block on top of a transparent block like glass or even in mid-air so the block beneath is lit? Have you tried telling it the only parts of the block's shape are the top and bottom parts. i.e. pretend the glass looking parts and side bars don't exist. e.g. try something like this simple shape which is just a thin slice at the top and bottom: public static final VoxelShape SHAPE_BOTTOM = Block.box(0.0D, 0.0D, 0.0D, 16.0D, 1.0D, 16.0D); public static final VoxelShape SHAPE_TOP = Block.box(0.0D, 15.0D, 0.0D, 16.0D, 16.0D, 16.0D); public static final VoxelShape SHAPE = Shapes.or(SHAPE_BOTTOM, SHAPE_TOP); @Override public VoxelShape getShape(BlockState p_60555_, BlockGetter p_60556_, BlockPos p_60557_, CollisionContext p_60558_) { return SHAPE; } I am not saying it is the solution (if it even works), only that it might point to where your problem is. But then I am no expert on Minecraft's lighting code. It makes your average tax-code look comprehensible in comparison. 🙂

There is not much there in that stacktrace it just shows the server processing player movement packets sent by the clients. So the server thread is not stuck or looping, unless one of your mods is doing something strange to this code. I can see from your mod list you have spark installed, have you looked at its data? https://spark.lucko.me/docs/guides/Finding-lag-spikes

All those shapes are mostly used for things like lighting, block/entity collision and hitboxes. For the rendering you need to change the RenderType, the default is RenderType.SOLID if you don't change it. The old way was to use ItemBlockRenderTypes.setRenderLayer() but that has been deprecated as of 1.19 The recommended way is to put this configuration in your block model json. /** @deprecated Set your render type in your block model's JSON (eg. {@code "render_type": "cutout"}) or override {@link net.minecraft.client.resources.model.BakedModel#getRenderTypes(BlockState, net.minecraft.util.RandomSource, net.minecraftforge.client.model.data.ModelData)} */ @Deprecated(forRemoval = true, since = "1.19") public static void setRenderLayer(Block block, RenderType type) {

Item.useOn() is first called on the client, if you return SUCCESS, then the same method will be called on the server. See for example MapItem.useOn() or one of other vanilla Items similar to your usecase.

Issue with neko's enchancted books trying to load client classes on the server. Check you have the latest version then report it to the mod author.

Mojang won't fix things in 1.18.2 unless it is a security issue. Their supported version is 1.19.1

If Minecraft 1.18.2 doesn't support your OS I don't know? One option would be to spin up a virtual machine and use an OS that is supported. Or maybe MacOS has some emulation mode that lets you run it on a supported architecture? e.g. pretend its x86 if you have arm

Changing the gradle config will have no effect. Forge doesn't use gradle for this, it emulates the minecraft launcher. It uses those package files I linked to earlier and downloads the stuff it is told to use from Mojang's website.

Do you understand how Suppliers work in terms of deferring code execution? Are those RegistryObject.get() invocations run during classloading or during the Supplier.get() for the List at registration time? It should be more like this. public static final Supplier<List<OreConfiguration.TargetBlockState>> OVERWORLD_LEGENDARY_ORE = // Pass the suppliers, the blocks have not been created yet we are in the classloading regOverWoldOres(BlockInit.LEGENDARY_ORE, BlockInit.DEEPSLATE_LEGENDARY_ORE); public static Supplier<List<OreConfiguration.TargetBlockState>> regOverWoldOres(RegistryObject<Block> normalOre, RegistryObject<Block> deepslateOre) { return Suppliers.memoize(() -> List.of( OreConfiguration.target(OreFeatures.STONE_ORE_REPLACEABLES, // Use the supplier at registration time when the blocks now exist normalOre.get().defaultBlockState()), OreConfiguration.target(OreFeatures.DEEPSLATE_ORE_REPLACEABLES, deepslateOre.get().defaultBlockState()))); }

I believe Forge has to use whatever Minecraft uses. Which for 1.18.2 is 3.2.1 See: https://launchermeta.mojang.com/v1/packages/f1cf44b0fb6fe11910bac139617b72bf3ef330b9/1.18.2.json 1.19 uses 3.3.1: https://piston-meta.mojang.com/v1/packages/92e6f1eba1748a43b8e215d0859a42bce4f999d2/1.19.json

None of the code above shows a RegistryObject.get(). Please don't just post any error you get in this forum without thinking about it. We are not here to write/debug your code for you. You need to take the time to work things out for yourself. You spent less than 6 minutes on this problem.

If there is nothing in ForgeRegistries, use the vanilla Registry class. Double check it is not @Deprecated which means it is in ForgeRegistries and you missed it. 🙂

The error says it can't load this native library. I don't know enough - anything 🙂 - about native code on the different MacOS architectures to be to tell you might be wrong, sorry.

That is not the debug.log and it doesn't contain the error. You are registering different items to the same name (both are "nature_wood"). https://github.com/JPermSolves/ElementalSwords/blob/340e43851f6c86709501ad042069a89adbf93ce8/src/main/java/net/juder/elementalswords/block/ModBlocks.java#L30 https://github.com/JPermSolves/ElementalSwords/blob/340e43851f6c86709501ad042069a89adbf93ce8/src/main/java/net/juder/elementalswords/item/ModItems.java#L31

No, you need to add a breakpoint in that exception handler for Main.main() and see what the value of "throwable1" is. If that doesn't tell you anything useful, you will have to trace through the initialisation code inside the try block to see where/why it is failing.

Did you try using the debugger like I suggested on the linked thread. This should tell you the real error message? And did you try resetting/clearing the gradle cache? See the other thread again.

https://github.com/SizableShrimp/EntityModelJson

Neither of those logs contains the "DecoderExceptions (incorrect header check, invalid distance too far back, etc.)" error message? The server does have a message saying you disconnected as you say. And the client has a message saying JEI is responding to a disconnect event, but no error message. The "DecoderException" error message says there is a problem with the decompression of the network packet. One thing I notice is you have the following on the client: but on the server it is So it looks like the server is trying to use ipv6. If you look at the changelog for forge 1.18.2 https://maven.minecraftforge.net/net/minecraftforge/forge/1.18.2-40.1.69/forge-1.18.2-40.1.69-changelog.txt It says So one option would be try the latest release of forge, 40.1.69 which has this change. Another would be to configure the server to use ipv4 like the client? -Djava.net.preferIPv4Stack=true NOTE: I don't know if this really the cause of the DecoderException, it could be caused by one of the mods and the ip version is just a red herring. 🙂

NOTE: That will return minecraft:air if for some reason the item is not registered.