Jump to content

[1.8.9][Packet/GUI] Creating a custom merchant : packet to pass entity to gui ?


Major Squirrel

Recommended Posts

Good evening guys,

 

I'm currently trying to create a custom EntityMerchant. Basically, it works the same as the EntityVillager from Minecraft, except that I want to control all the transactions for each merchant (from a DB for example).

 

My entity is currently created, its name is Timmy (yes), and I can't figure out how I could pass the entityId to a gui triggered from server side, so that I can get an Entity object once the gui is open. I took a look at the EntityVillager code : when interacting with the Entity, it displays the villager trade gui passing the Entity (as this) :

 

    /**
     * Called when a player interacts with a mob. e.g. gets milk from a cow, gets into the saddle on a pig.
     */
    public boolean interact(EntityPlayer player)
    {
        ItemStack itemstack = player.inventory.getCurrentItem();
        boolean flag = itemstack != null && itemstack.getItem() == Items.spawn_egg;

        if (!flag && this.isEntityAlive() && !this.isTrading() && !this.isChild() && !player.isSneaking())
        {
            if (!this.worldObj.isRemote && (this.buyingList == null || this.buyingList.size() > 0))
            {
                this.setCustomer(player);
                player.displayVillagerTradeGui(this);
            }

            player.triggerAchievement(StatList.timesTalkedToVillagerStat);
            return true;
        }
        else
        {
            return super.interact(player);
        }
    }

 

Looking more closely at the code, it seems that a S2DPacketOpenWindow packet is sent. The thing that I don't understand is the way I could possibly do the same (or the entityId), using Forge GuiHandler. Sending a packet ? Why not, but what after then ?

 

Furthermore, LexManos shared a trick to pass the entityId through an int (can't find the topic) in the getServerGuiElement method from GuiHandler, but I still don't know what to do next. It is some kind of missunderstanding here that I would like to kill.

 

Thank you for your time and you help. :)

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

To clarify, instead of using #displayVillagerTradeGui, use #openGui and pass the entity ID as one of the last 3 parameters.

 

The last 3 parameters are all ints and are typically used for TileEntity coordinates, but if your GUI is not using a TE, you can use those parameters for anything you want such as the entity ID.

Link to comment
Share on other sites

Thank you guys.

 

Yet, something bugs me : what would be the interest to go through a packet to open a gui instead of opening it directly ?

In my case, I can avoid using a packet to open the gui, since I can directly pass the entity id in the openGui method.

 

I saw few posts on this forum that advise to use packet to open gui.

 

giphy.gif

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

If you do stuff on client - server doesn't know about it. Even if you'd send packet telling server that you did something, server might not really "accept it" - meaning: client opens gui, sends packet with request but on server it happens that "you are not allowed to open the gui right now", but its alredy opened on client - boom, not desired outcome. (same goes with interaction - since client only has "predicted" server values, some things might be true on client and false on server).

 

I for one always code stuff in order: client -> req -> server decides -> packet (or GuiHandler call) -> client does stuff server tells.

 

All in all - is depends on what you need and if server needs to know what you do. You can even open gui directly from Minecraft class.

 

Mind that if client alredy has values that need to be displayed on gui and server doesnt need to know shit, you are free to operate on client only. E.g: Display player stats from IEEP/Capabilities which you KNOW are always synced.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

If you do stuff on client - server doesn't know about it. Even if you'd send packet telling server that you did something, server might not really "accept it" - meaning: client opens gui, sends packet with request but on server it happens that "you are not allowed to open the gui right now", but its alredy opened on client - boom, not desired outcome. (same goes with interaction - since client only has "predicted" server values, some things might be true on client and false on server).

 

I for one always code stuff in order: client -> req -> server decides -> packet (or GuiHandler call) -> client does stuff server tells.

 

All in all - is depends on what you need and if server needs to know what you do. You can even open gui directly from Minecraft class.

 

Mind that if client alredy has values that need to be displayed on gui and server doesnt need to know shit, you are free to operate on client only. E.g: Display player stats from IEEP/Capabilities which you KNOW are always synced.

 

Ok so if I follow your way of coding in order, in my case it would be :

 

Client right clicks on entity --> sends a packet that will be handle to the server --> server decides whether or not to let the client open the gui --> (admitting yes) call openGui method

 

In there, the packet will just be useful to do some "tests" or requirements before deciding to open the gui or not ?

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

If you do stuff on client - server doesn't know about it. Even if you'd send packet telling server that you did something, server might not really "accept it" - meaning: client opens gui, sends packet with request but on server it happens that "you are not allowed to open the gui right now", but its alredy opened on client - boom, not desired outcome. (same goes with interaction - since client only has "predicted" server values, some things might be true on client and false on server).

 

I for one always code stuff in order: client -> req -> server decides -> packet (or GuiHandler call) -> client does stuff server tells.

 

All in all - is depends on what you need and if server needs to know what you do. You can even open gui directly from Minecraft class.

 

Mind that if client alredy has values that need to be displayed on gui and server doesnt need to know shit, you are free to operate on client only. E.g: Display player stats from IEEP/Capabilities which you KNOW are always synced.

 

Ok so if I follow your way of coding in order, in my case it would be :

 

Client right clicks on entity --> sends a packet that will be handle to the server --> server decides whether or not to let the client open the gui --> (admitting yes) call openGui method

 

In there, the packet will just be useful to do some "tests" or requirements before deciding to open the gui or not ?

 

When the player right clicks on an entity, the client sends a packet to the server and then calls the entity's interaction method (this actually happens up to twice, once for

Entity#interactAt

and once for

Entity#interactFirst

; the second packet and call only happen if the first returned

false

). This happens in

Minecraft#rightClickMouse

 

When the server receives these packets, it first checks that the entity exists and the player is close enough to interact with it. If these conditions are met, it calls the interaction method that the packet was sent for. This happens in

NetHandlerPlayServer#processUseEntity

.

 

You should open your GUI from the server-side call of

EntityLiving#interact

(called from

Entity#interactFirst

), i.e. when

world.isRemote

is

false

.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

When the player right clicks on an entity, the client sends a packet to the server and then calls the entity's interaction method (this actually happens up to twice, once for

Entity#interactAt

and once for

Entity#interactFirst

; the second packet and call only happen if the first returned

false

). This happens in

Minecraft#rightClickMouse

 

When the server receives these packets, it first checks that the entity exists and the player is close enough to interact with it. If these conditions are met, it calls the interaction method that the packet was sent for. This happens in

NetHandlerPlayServer#processUseEntity

.

 

You should open your GUI from the server-side call of

EntityLiving#interact

(called from

Entity#interactFirst

), i.e. when

world.isRemote

is

false

.

 

Actually, I do this :

 

    @Override
    protected boolean       interact(EntityPlayer player) {
        ItemStack           itemstack = player.inventory.getCurrentItem();
        boolean             flag = itemstack != null && itemstack.getItem() == Items.spawn_egg;
        boolean             flag2 = itemstack != null && itemstack.getItem() == Items.name_tag;

        if (this.isEntityAlive() && !player.isSneaking()) {
            if (this.worldObj.isRemote) {
                player.openGui(Main.instance, Reference.GuiIdentifiers.GUI_MERCHANT, this.worldObj, this.getEntityId(), 0, 0);
            }
            return (true);
        } else if (flag && player.isSneaking())
            this.setDead();
        else if (flag2 && player.isSneaking()) {
            this.changeCustomName();
        }
        return super.interact(player);
    }

 

the isRemote being true is just a test to open a GuiScreen to draw the Entity currently rightclicked the same way it happens when you open a horse inventory. I think I have to tell you what I really want to do. In fact, I have so much questions that are related to my goal but can't be asked in the context of this topic.

 

I want to create an EntityMerchant that acts as an EntityVillager. When rightclicking on it, it opens an interface in which the player can trade with the merchant. While the interface is open,

. The EntityMerchant clicked is being drawn on the gui and all the possible trades that the player can do are related to the entityId. When the player quit the interface, the music stops.

 

For this goal, I suppose I have to trade my GuiScreen for a GuiContainer. This would require a server handling. That is all I've thought about for now.

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

When #isRemote is true, that means your code is currently on the logical client side, and is NOT when you want to open container-based GUIs.

 

Entity#interact is called on BOTH client and server side during the interaction process - first on the client during the initial mouse-click, then again on the server after the server receives a packet. You should open the GUI when the world is not remote, i.e. on the server side, since the GuiHandler will open both the Container (server side) and the GUI (client side) automatically when invoked on the server.

 

If you were in a situation that didn't have Minecraft automatically sending packets for you, say you wanted to open your Container-based GUI by a key press instead of entity interaction, then you'd have to do as Ernio said and send your own packet from the client requesting the server to open the GUI.

 

The only time you should open a GUI directly on/from the client side is when there is only a GUI component (no Container) and there are not any important conditions to the GUI being opened. If, for a non-Container based GUI, it is important to know for sure the player is e.g. close enough to the entity, then you should send a packet from the server to the client to open the GUI.

Link to comment
Share on other sites

When #isRemote is true, that means your code is currently on the logical client side, and is NOT when you want to open container-based GUIs.

 

Yes, I did know that, I took some time last days reading the Sides concept on readthedocs.

 

*snip*

 

If you were in a situation that didn't have Minecraft automatically sending packets for you, say you wanted to open your Container-based GUI by a key press instead of entity interaction, then you'd have to do as Ernio said and send your own packet from the client requesting the server to open the GUI.

 

Ok, that makes more sense to me now, thank you all. If I have the possibility to open the gui calling EntityPlayer#openGui directly, then I can do it. Otherwise I would need to send a packet from client to server (will be handled to the server then) that will be able to make some checks then opening the gui.

 

The only time you should open a GUI directly on/from the client side is when there is only a GUI component (no Container) and there are not any important conditions to the GUI being opened. If, for a non-Container based GUI, it is important to know for sure the player is e.g. close enough to the entity, then you should send a packet from the server to the client to open the GUI.

 

That means the packet will be handled in the client ? Which method should I call then ? EntityPlayer#openGui to pass through the GuiHandler or another one from Minecraft base code ?

Squirrel ! Squirrel ! Squirrel !

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hi I’m running same mod on a server and realized they are spawning in chests which I don’t want, if I were to edit this data pack to disable them spawning in chests how would I do that? Explain to me like I’m 8
    • every time i use play forge in the launcher it says game crashed unexpected issuse and when i use curseforge it also doesn't work
    • I've attempted to use Jarfix as well. I tried running a previous version (18.2) of Minecraft and added a few random popular mods and the crashing is persistent among the servers. 
    • I attempted Java 17 again and it still doesn't work. Java -version in CMD: java -version java version "17.0.6" 2023-01-17 LTS Java(TM) SE Runtime Environment (build 17.0.6+9-LTS-190) Java HotSpot(TM) 64-Bit Server VM (build 17.0.6+9-LTS-190, mixed mode, sharing)   The error I get after using Java 17 again. 2023-03-24 19:01:56,259 main WARN Advanced terminal features are not available in this environment [19:01:56] [main/INFO] [cp.mo.mo.Launcher/MODLAUNCHER]: ModLauncher running: args [--launchTarget, forgeserver, --fml.forgeVersion, 43.2.8, --fml.mcVersion, 1.19.2, --fml.forgeGroup, net.minecraftforge, --fml.mcpVersion, 20220805.130853] [19:01:56] [main/INFO] [cp.mo.mo.Launcher/MODLAUNCHER]: ModLauncher 10.0.8+10.0.8+main.0ef7e830 starting: java version 17.0.6 by Oracle Corporation; OS Windows 10 arch amd64 version 10.0 [19:01:57] [main/INFO] [mixin/]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=union:/C:/Users/Kheyo/Downloads/Servers/Badaboop%20Server/libraries/org/spongepowered/mixin/0.8.5/mixin-0.8.5.jar%2363!/ Service=ModLauncher Env=SERVER [19:01:57] [main/WARN] [ne.mi.fm.lo.mo.ModFileParser/LOADING]: Mod file C:\Users\Kheyo\Downloads\Servers\Badaboop Server\libraries\net\minecraftforge\fmlcore\1.19.2-43.2.8\fmlcore-1.19.2-43.2.8.jar is missing mods.toml file [19:01:57] [main/WARN] [ne.mi.fm.lo.mo.ModFileParser/LOADING]: Mod file C:\Users\Kheyo\Downloads\Servers\Badaboop Server\libraries\net\minecraftforge\javafmllanguage\1.19.2-43.2.8\javafmllanguage-1.19.2-43.2.8.jar is missing mods.toml file [19:01:57] [main/WARN] [ne.mi.fm.lo.mo.ModFileParser/LOADING]: Mod file C:\Users\Kheyo\Downloads\Servers\Badaboop Server\libraries\net\minecraftforge\lowcodelanguage\1.19.2-43.2.8\lowcodelanguage-1.19.2-43.2.8.jar is missing mods.toml file [19:01:57] [main/WARN] [ne.mi.fm.lo.mo.ModFileParser/LOADING]: Mod file C:\Users\Kheyo\Downloads\Servers\Badaboop Server\libraries\net\minecraftforge\mclanguage\1.19.2-43.2.8\mclanguage-1.19.2-43.2.8.jar is missing mods.toml file [19:01:57] [main/INFO] [ne.mi.fm.lo.mo.JarInJarDependencyLocator/]: Found 8 dependencies adding them to mods collection [19:01:59] [main/INFO] [mixin/]: Compatibility level set to JAVA_17 [19:01:59] [main/ERROR] [mixin/]: Mixin config mixins.oculus.compat.sodium.json does not specify "minVersion" property [19:01:59] [main/INFO] [mixin/]: Successfully loaded Mixin Connector [com.sonicether.soundphysics.MixinConnector] [19:01:59] [main/INFO] [mixin/]: Successfully loaded Mixin Connector [ca.spottedleaf.starlight.mixin.MixinConnector] [19:01:59] [main/INFO] [cp.mo.mo.LaunchServiceHandler/MODLAUNCHER]: Launching target 'forgeserver' with arguments [] [19:01:59] [main/WARN] [mixin/]: Reference map 'createdeco.refmap.json' for createdeco.mixins.json could not be read. If this is a development environment you can ignore this message [19:01:59] [main/WARN] [mixin/]: Reference map 'Weeping-Angels-forge-refmap.json' for weeping_angels.mixins.json could not be read. If this is a development environment you can ignore this message [19:01:59] [main/INFO] [Rubidium/]: Loaded configuration file for Rubidium: 30 options available, 0 override(s) found [19:01:59] [main/WARN] [mixin/]: Reference map 'yungsextras.refmap.json' for yungsextras.mixins.json could not be read. If this is a development environment you can ignore this message [19:01:59] [main/WARN] [mixin/]: Reference map 'yungsextras.refmap.json' for yungsextras_forge.mixins.json could not be read. If this is a development environment you can ignore this message [19:01:59] [main/WARN] [mixin/]: Reference map '${refmap_target}refmap.json' for corgilib.forge.mixins.json could not be read. If this is a development environment you can ignore this message [19:01:59] [main/WARN] [mixin/]: Reference map 'modid.refmap.json' for createtweaker.mixin.json could not be read. If this is a development environment you can ignore this message [Serene Seasons Transformer]: Transforming m_47480_ (Lnet/minecraft/world/level/LevelReader;Lnet/minecraft/core/BlockPos;Z)Z in net/minecraft/world/level/biome/Biome [Serene Seasons Transformer]: Patched 1 calls [Serene Seasons Transformer]: Transforming m_47519_ (Lnet/minecraft/world/level/LevelReader;Lnet/minecraft/core/BlockPos;)Z in net/minecraft/world/level/biome/Biome [Serene Seasons Transformer]: Successfully patched shouldSnow [Serene Seasons Transformer]: Transforming m_8714_ (Lnet/minecraft/world/level/chunk/LevelChunk;I)V in net/minecraft/server/level/ServerLevel [Serene Seasons Transformer]: Successfully patched tickChunk [19:01:59] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [19:01:59] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [19:01:59] [main/WARN] [mixin/]: Error loading class: com/mojang/blaze3d/audio/Channel (java.lang.ClassNotFoundException: com.mojang.blaze3d.audio.Channel) [19:01:59] [main/WARN] [mixin/]: @Mixin target com.mojang.blaze3d.audio.Channel was not found assets/sound_physics_remastered/sound_physics_remastered.mixins.json:ChannelAccessor [Serene Seasons Transformer]: Transforming m_8714_ (Lnet/minecraft/world/level/chunk/LevelChunk;I)V in net/minecraft/server/level/ServerLevel [Serene Seasons Transformer]: Successfully patched tickChunk [19:02:00] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [19:02:00] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [Serene Seasons Transformer]: Transforming m_8107_ ()V in net/minecraft/world/entity/animal/SnowGolem [Serene Seasons Transformer]: Patched 1 calls [19:02:01] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [19:02:01] [main/INFO] [ne.mi.co.Co.placebo/COREMODLOG]: Patching IForgeItemStack#getEnchantmentLevel [19:02:02] [main/INFO] [minecraft/DataFixers]: Building unoptimized datafixer [19:02:02] [main/WARN] [mixin/]: @ModifyConstant conflict. Skipping repurposed_structures.mixins.json:structures.StructurePoolMixin->@ModifyConstant::repurposedstructures_increaseWeightLimitDev(I)I with priority 1000, already redirected by yungsapi_forge.mixins.json:IncreaseStructureWeightLimitMixinForge->@ModifyConstant::yungsapi_increaseWeightLimit(I)I with priority 1000 [Serene Seasons Transformer]: Transforming m_47480_ (Lnet/minecraft/world/level/LevelReader;Lnet/minecraft/core/BlockPos;Z)Z in net/minecraft/world/level/biome/Biome [Serene Seasons Transformer]: Patched 1 calls [Serene Seasons Transformer]: Transforming m_47519_ (Lnet/minecraft/world/level/LevelReader;Lnet/minecraft/core/BlockPos;)Z in net/minecraft/world/level/biome/Biome [Serene Seasons Transformer]: Successfully patched shouldSnow [19:02:03] [main/ERROR] [ne.mi.fm.lo.RuntimeDistCleaner/DISTXFORM]: Attempted to load class net/minecraft/client/KeyMapping for invalid dist DEDICATED_SERVER [19:02:03] [main/WARN] [mixin/]: Error loading class: net/minecraft/client/KeyMapping (java.lang.RuntimeException: Attempted to load class net/minecraft/client/KeyMapping for invalid dist DEDICATED_SERVER) Exception in thread "main" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:32)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:53)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:71)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.Launcher.run(Launcher.java:106)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.Launcher.main(Launcher.java:77)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23)         at cpw.mods.bootstraplauncher@1.1.2/cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:141) Caused by: java.lang.reflect.InvocationTargetException         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)         at java.base/java.lang.reflect.Method.invoke(Method.java:568)         at MC-BOOTSTRAP/fmlloader@1.19.2-43.2.8/net.minecraftforge.fml.loading.targets.CommonServerLaunchHandler.lambda$launchService$0(CommonServerLaunchHandler.java:29)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:30)         ... 7 more Caused by: org.spongepowered.asm.mixin.transformer.throwables.MixinTransformerError: An unexpected critical error was encountered         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:392)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:250)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.service.modlauncher.MixinTransformationHandler.processClass(MixinTransformationHandler.java:131)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.launch.MixinLaunchPluginLegacy.processClass(MixinLaunchPluginLegacy.java:131)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.serviceapi.ILaunchPluginService.processClassWithFlags(ILaunchPluginService.java:156)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.LaunchPluginHandler.offerClassNodeToPlugins(LaunchPluginHandler.java:88)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.ClassTransformer.transform(ClassTransformer.java:120)         at MC-BOOTSTRAP/cpw.mods.modlauncher@10.0.8/cpw.mods.modlauncher.TransformingClassLoader.maybeTransformClassBytes(TransformingClassLoader.java:50)         at cpw.mods.securejarhandler/cpw.mods.cl.ModuleClassLoader.readerToClass(ModuleClassLoader.java:113)         at cpw.mods.securejarhandler/cpw.mods.cl.ModuleClassLoader.lambda$findClass$15(ModuleClassLoader.java:219)         at cpw.mods.securejarhandler/cpw.mods.cl.ModuleClassLoader.loadFromModule(ModuleClassLoader.java:229)         at cpw.mods.securejarhandler/cpw.mods.cl.ModuleClassLoader.findClass(ModuleClassLoader.java:219)         at cpw.mods.securejarhandler/cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:135)         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.world.inventory.MenuType.<clinit>(MenuType.java:7)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.core.Registry.m_235768_(Registry.java:230)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.core.Registry.lambda$internalRegister$54(Registry.java:461)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.core.Registry.lambda$static$70(Registry.java:667)         at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:721)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.core.Registry.<clinit>(Registry.java:666)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.server.Bootstrap.m_135870_(Bootstrap.java:43)         at TRANSFORMER/minecraft@1.19.2/net.minecraft.server.Main.main(Main.java:110)         ... 13 more Caused by: org.spongepowered.asm.mixin.throwables.ClassMetadataNotFoundException: net.minecraft.client.KeyMapping         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinPreProcessorStandard.transformMethod(MixinPreProcessorStandard.java:754)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinPreProcessorStandard.transform(MixinPreProcessorStandard.java:739)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinPreProcessorStandard.attach(MixinPreProcessorStandard.java:310)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinPreProcessorStandard.createContextFor(MixinPreProcessorStandard.java:280)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinInfo.createContextFor(MixinInfo.java:1288)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.apply(MixinApplicatorStandard.java:292)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.TargetClassContext.apply(TargetClassContext.java:383)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.TargetClassContext.applyMixins(TargetClassContext.java:365)         at MC-BOOTSTRAP/org.spongepowered.mixin/org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:363)         ... 34 more Press any key to continue . . .    
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.