warjort

Looks like an issue with jrhc mod. It is trying to load a client class while the player data is being saved. Client classes don't exist on the server. Check you have the latest version then contact the mod author.

You need to post your logs/debug.log from the server. From what you describe, it sounds like the player data is not getting saved for some reason? There is probably an error in the log explaining why.

I can't see any error in the log. The last thing there is stitching textures. This can be memory intensive, especially when you have a lot of mods. If you are running out of memory this can cause the java garbage collector to work hard and sometimes go to 100% cpu if it is having a hard time finding memory. Sometimes you can have the opposite problem. If you allocate more memory than is physically available, the operating system will start paging memory to the swap file which slows things down. Start task manager and see if there is there is a problem with the java process running minecraft, it's cpu, paging and memory usage. Of course, servers don't load textures, they have no screen/gui. 🙂

You should just remove the normal isPetrified field. Then make your isPetrified()/setPetrified() access the entityData. Just doing isPetrifed = false isn't going to call setPetrified() and so it won't sync to the client. Similarly doing if (isPetrified) on the client isn't going reference the entityData which has the value sent from the server.

This looks like a flaw in the way AbstractContainerScreen works. Or at least it didn't anticipate you doing this. I wrote this simple test which reproduces your problem. @Mod.EventBusSubscriber(modid = MODID, value = Dist.CLIENT) public class TestScreenToolTip { static List<Component> LIST = Collections.nCopies(10, Component.literal("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")); @SubscribeEvent public static void testInit(ScreenEvent.Init.Post event) { if (event.getScreen() instanceof InventoryScreen screen) { event.addListener(new MyButton(screen)); } } static class MyButton extends Button { public MyButton(Screen screen) { super(screen.width / 2 - 100, 140, 200, 20, CommonComponents.GUI_CANCEL, (button) -> { // nothing }, (button, poseStack, mouseX, mouseY) -> { screen.renderTooltip(poseStack, LIST, Optional.empty(), mouseX, mouseY); }); } } } If you look at AbstractContainerScreen.render() the widgets get rendered before everything else, the super.render() call. Then when it comes to drawing the item decoration's damage bar (which is after) it does RenderSystem.disableDepthTest() so it ignores the z co-ord and just draws it. Normally if you were the writing the screen yourself, you could just change the render method to draw the buttons last or at least after the slots. But you don't control the order of things for this screen. I can confirm that fixes the problem by adding an additional event listener. @SubscribeEvent public static void testRender(ScreenEvent.Render.Post event) { if (event.getScreen() instanceof InventoryScreen screen) { screen.renderables.forEach(widget -> { if (widget instanceof MyButton) { widget.render(event.getPoseStack(), event.getMouseX(), event.getMouseY(), event.getPartialTick()); } }); } } The issue with the above fix is I am drawing my button twice. Once normally and then again at the end of the screen rendering. There must be a better solution to this problem? 🙂

As I explained on the other thread, minecraft has no support for this when right clicking a block. You need to code this yourself. I already suggested adding a "progress" counter to your block by making it a BlockEntity. Another way would be to use a player capability. Where you record for each player which block they have been right clicking and for how long. That is effectively how the normal item use like eating works. That code is pretty complicated though. It starts with Item.onUse() calling Player.startingUsingItem() with all sorts of policy callbacks between the Item and player as it progresses. Some of the code is in the LivingEntity class where the tick() is handled. You could probably write it simpler if you are not trying to make something so generic (i.e. you don't need all those callbacks).

Issue with create crafts and additions. Check you have the latest version then contact the mod author.

You need to show what you are actually doing. I already guessed (wrongly) once on this thread that you were doing custom rendering. I shouldn't have to guess. From that small snippet of code out of context it looks like you are calling Screen's renderTooltip() which should do it for you. There is something else you are doing wrong.

Posting random contents of files out-of-context is useless. You don't even give file paths. We can't tell if you have them in the correct place. Anyway, compare your loot table with the vanilla obsidian block: https://github.com/misode/mcmeta/blob/data/data/minecraft/loot_tables/blocks/obsidian.json e.g. minecraft:block is not a valid LootPoolEntryType (see LootPoolEntries for vanilla types) - you probably have an error in run/logs/debug.log for this You can also confirm what tags your block has if you put your crosshair on it then press F3 and look in the bottom right corner.

It still shows jei and roughly enough items. jei rei You may have other plugins for these mods. Please don't post logs in the forum. It is difficult/impossible to use search when you have mutliple logs in the same thread. Post a link to file sharing site. And post the debug.log not the latest.log so we have all the information.

Reposting the same question in a new thread is pointless. The answer is still the same and you are just wasting people's time. https://forums.minecraftforge.net/topic/117609-check-event-time/

GUI screens are actually 3d in minecraft. The z direction is the distance out of the screen. Look at how the class Screen handles tool tips by both translating the z co-ord of the PoseStack and changing ItemRenderer.blitOffset which controls the same thing for the drawing items. Note how it uses +400 in renderTooltipInternal() and +200 in ItemRender.renderGuiItemDecorations() - the latter being things like the damage bar.

Please don't hijack other people's threads. Create your own. https://files.minecraftforge.net/net/minecraftforge/forge/index_1.18.2.html

You can't have both jei and roughly enough items.

Your plane-server.toml config file is invalid/corrupted. Since you are running a server, it should be in world/serverconfig If you don't have a backup of this file and don't know how to fix it, you can delete it and it should recreate it with default values.

Looks like an issue with Kubejs/Rhino trying to load client classes on the server. The only one that shows a stracktrace is: I would guess it is just a lot of noise. With Rhino catching and ignoring the errors. It looks like it loaded the game properly. You can report the log spam to the mod author if you want.

Not really my area of expertise, but... Look at what EnchantmentTableRenderer EnchantTableRenderer does and adapt it to your needs. NOTE: how it sets up the model in the constructor not on every render call. The last four parameters of model.render() are rgba. I don't know what it actually does with Block models? Like I said not an expert.🙂

This link has a guide for 1.16 -> 1.17 including a tool for semi-automating it and a reference to a bot on the forge discord for getting new names from old names. https://gist.github.com/50ap5ud5/beebcf056cbdd3c922cc8993689428f4 The 1.19 changes (including another tool) are linked here: https://forums.minecraftforge.net/topic/114502-forge-411-minecraft-119

I don't think its documentated, but you need to return a new ItemStack not the original. Something like: @Override public ItemStack getContainerItem(ItemStack itemStack) { // Copy the original var result = itemStack.copy(); // Damage it result.hurtAndBreak(1, ForgeHooks.getCraftingPlayer(), player -> { if (player != null) { player.level.playSound(null, player.getX(), player.getY(), player.getZ(), ITEM_BREAK, player.getSoundSource(), 1.0f, 1.0f); } }); return result; }

Create for 1.18.2 requires at least forge 40.1.60 https://github.com/Creators-of-Create/Create/blob/0c5ccf38ee15f446f385290f2238f2ae975681cd/gradle.properties#L11

Post a link to your debug.log

The problem is you haven't told curseforge that it needs to enable the debug.log for forge. It is a toggle button in the "advanced" section. Curseforge calls the jvm arguments "additional arguments". It's at the very bottom. Anyway, I think your problem is with the create mod, see the link to the issue I posted above. You should be speaking to them on how to fix it. If the issue is only with LAN games, you can try setting up a real server.

Your behaviour class runs on the server. While the mobInteract runs on both the client and server. https://forge.gemwire.uk/wiki/Sides So you are only modifying that value on the server. But it needs to be on the client for rendering. You should define the petrified flag like you have the cloak color so the data is synched from the server to the client.

That doesn't contain an error either. It doesn't show you starting minecraft. Did you restart the launcher after the crash? That will clear the log. Also, do you have a file beginning hs_err_pid in your minecraft folder that is from the time of the crash? If you do, don't post the whole file just post the first 20 lines so we can see the error.

That's immersive engineering doing it for its hemp plant.