Jump to content

Hooking chat commands client-side on multiplayer


harik

Recommended Posts

Adding commands server side, either via local server or remote server is easy.  I'm trying to migrate WorldeditCUI to 1.5.1/latest forge, and the sticking point is capturing commands at the local end so it can inject them via the worldedit API channel.

 

What the author currently does is abuse reflection to change private fields to public using the obfuscated field names, and tries to inspect every packet added to the network queue to see if it's of type 'Packet3Chat', and if so decode it and see if it should be passed on or not.  Ugh.  Even if you ignore how hideously ugly that is, it doesn't work with forge as forge overrides some of the classes it intends to hook so bombs out with an unknown field error.

 

It looks like the cleanest place to hook it would be net.minecraft.client.Minecraft.handleClientCommand(string), which is a stub that currently doesn't do anything, and forge already replaces that class.

 

Unless I'm missing something, hooking chatHandler only handles received chat from the server, outbound commands do not show up there.

 

My thought was adding a registerLocalCommand(string command, ILocalCommandHandler) to something (NetworkRegistry?) and have handleClientCommand() call that.

 

Is there a better way to intercept some commands (at the client) before they're sent to the server and handle them locally?  If not, is there any interest in me coding this up and submitting it?

Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...

I'm also in need of this.  Without it i'm forced to modify core files just to have a client-side-only command. 

 

Is there a way to do this via the Forge api that i simply missed? If so, please let me know.  If not, is it planned?  This could be implemented easily and can be tied into the core in a couple places.  Here are the cleanest places i've found to tie in my own code:

 

via EntityClientPlayerMP.sendChatMessage

   public void sendChatMessage(String par1Str)
   {
        //added the 1 line below. CommandManager is my own class, A Forge class
                //would be referenced here instead.  It could then raise a cancellable event
                //to all subscribers of client-side-only commands.  if the event isn't cancelled.
                //then the text will be sent to the server.
        if (!CommandManager.getInstance().HandleCommand(par1Str)) 
          this.sendQueue.addToSendQueue(new Packet3Chat(par1Str));
   }

 

 

OR via GuiChat.keyTyped method:

                //.... near the bottom of the method:
            String var3 = this.inputField.getText().trim();
            if (var3.length() > 0)
            {
                this.mc.ingameGUI.getChatGUI().addToSentMessages(var3);
                //added the 1 line below. CommandManager is my own class, A Forge class
                //would be referenced here instead.  It could then raise a cancellable event
                //to all subscribers of client-side-only commands.  if the event isn't cancelled.
                //then the text will be sent to the server.
                if (!CommandManager.getInstance().HandleCommand(var3))
                 {
                   if (!this.mc.handleClientCommand(var3))
                   {
                       this.mc.thePlayer.sendChatMessage(var3);
                   }
                }
               }

Link to comment
Share on other sites

is there a reason you cannot make the server handle this instead ? else you guys will have to do a coremods

(btw handling commands client side doesnt make sens as the server must always make the change and then propagate them to clients)

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

is there a reason you cannot make the server handle this instead ? else you guys will have to do a coremods

Because i am only making a client-side mod.  Why would i want to make my mod require a specific server plugin as well?  I simply want to show a client-side gui since my mod does not affect the server whatsoever.

(btw handling commands client side doesnt make sens as the server must always make the change and then propagate them to clients)

Wow, what a strange thing to say.  Chibill has the right idea.. my command doesn't need to be sent to the server as the result of the command is client-only.  In fact, since it's client-only i do NOT want it to get sent to the server.  That's why i mentioned it should be a cancellable event.  This way, if a subscriber handles it, then forge will not send it to the server.  If it's sent to the server then i'll get a silly "unknown command" message from the server.

 

I have it running by utilizing a coremod but that obviously goes against the spirit of what Forge is trying to accomplish.  If another mod modifies the same file then i'm out of luck.  This has increased probability since anyone else that is trying to have a client-side command will have to do the same thing i am, and thus we'll conflict.

Link to comment
Share on other sites

This has increased probability since anyone else that is trying to have a client-side command will have to do the same thing i am, and thus we'll conflict.

Not if you do it properly. You probably want to patch EntityClientPlayerMP#sendChatMessage. Just add a call to some static method before any other code in the method, if that method returns true also return from the sendChatMessage (the command has been handled). If two mods do this, they don't conflict at all.

 

uh huh... and what happens if another mod replaces the entityclientPlayerMP file entirely?  Having API support is ideal.  Any other alternative is hacky.

Link to comment
Share on other sites

is there a reason you cannot make the server handle this instead ? else you guys will have to do a coremods

Because i am only making a client-side mod.  Why would i want to make my mod require a specific server plugin as well?  I simply want to show a client-side gui since my mod does not affect the server whatsoever.

Then why do you want to use chat commands ?

By staying on client side, you can handle any client input, why use  something that make client interact with server ?

Just build your own chat GUI, if you want it to look like the chat command. You can open it with your own key, and then handle any input message locally.

Link to comment
Share on other sites

is there a reason you cannot make the server handle this instead ? else you guys will have to do a coremods

Because i am only making a client-side mod.  Why would i want to make my mod require a specific server plugin as well?  I simply want to show a client-side gui since my mod does not affect the server whatsoever.

Then why do you want to use chat commands ?

By staying on client side, you can handle any client input, why use  something that make client interact with server ?

Just build your own chat GUI, if you want it to look like the chat command. You can open it with your own key, and then handle any input message locally.

 

This makes absolutely no sense. I already explicitly said that i do not want to contact the server and that the commands are client-side only.

 

I'm not sure why this is necessary to explain, but the idea of the mod is that as the user walks around the map i read all the signs in the rendered area. If a sign is in the Chest Shop format then i parse it and add it to memory.  I then allow the user to do commands to interact with the data.. such as /shop list diamond to see all diamond prices.  Or /shop best bread to see the best bread buy and sell prices.  This is most efficiently done via chat commands rather than fumbling around in a GUI.  Also, why would i make my own chat gui? Where's the sense in that when there's already a chat gui present by default? 

 

Look, i laid out a simple request in the initial post followed by a couple suggested locations to hook into the core.  I have already coded my own workaround for the shortcoming of the API, i dont really need more suggestive alternatives.  They simply clutter the thread and take it off track.  If there's a suggestion that allows the implement to take advantage of an api-centric approach, then by all means, please share it.  Otherwise you're just adding onto the list of possible hack approaches, which is moot to the point at hand.

Link to comment
Share on other sites

This makes absolutely no sense. I already explicitly said that i do not want to contact the server and that the commands are client-side only.

 

I'm not sure why this is necessary to explain, but the idea of the mod is that as the user walks around the map i read all the signs in the rendered area. If a sign is in the Chest Shop format then i parse it and add it to memory.  I then allow the user to do commands to interact with the data.. such as /shop list diamond to see all diamond prices.  Or /shop best bread to see the best bread buy and sell prices.  This is most efficiently done via chat commands rather than fumbling around in a GUI.  Also, why would i make my own chat gui? Where's the sense in that when there's already a chat gui present by default? 

 

Look, i laid out a simple request in the initial post followed by a couple suggested locations to hook into the core.  I have already coded my own workaround for the shortcoming of the API, i dont really need more suggestive alternatives.  They simply clutter the thread and take it off track.  If there's a suggestion that allows the implement to take advantage of an api-centric approach, then by all means, please share it.  Otherwise you're just adding onto the list of possible hack approaches, which is moot to the point at hand.

Look, if you accurately describe a problem, people can then suggest better solutions.

If you can't handle any other ideas than your own, don't ask.

By the way, if you meant this thread as a suggestion, this isn't the right section of these forums.

 

It is sad that you insist into using chat commands when a simple gui can do what you want.

You are only making this harder on yourself.

Link to comment
Share on other sites

its sad that we are STILL using commands at all

 

I agree. A well-built GUI is SO much easier to use, also, it makes it easier for ANYONE to use it. Even a simple GUI is better than a command.

 

For example, with a GUI I could have some buttons. I choose the button "Best" and type the item name I want in a text box next to it.

 

It would then show a list underneath the search containing all the breads (I am searching for bread).

 

 

But I can take that one step further. I do the same search, but I say, "Show me all items that have a price between (lets say) 0 - 50". This would show a list of the items in that price range and then display something like this:

 

ICON FOR ITEM | ITEM NAME | PRICE |

 

Then off you go! I would much prefer to use that then a command that would go:

"The best bread is $1 from Such A Shop".

I am Mew. The Legendary Psychic. I behave oddly and am always playing practical jokes.

 

I have also found that I really love making extremely long and extremely but sometimes not so descriptive variables. Sort of like what I just did there xD

Link to comment
Share on other sites

Look, if you accurately describe a problem, people can then suggest better solutions.

If you can't handle any other ideas than your own, don't ask.

By the way, if you meant this thread as a suggestion, this isn't the right section of these forums.

 

It is sad that you insist into using chat commands when a simple gui can do what you want.

You are only making this harder on yourself.

 

In what way did i inaccurately describe the problem? 

 

The title clearly states client-side only and that the intention is to use them on a mp server.  I fail to see why you'd suggest that i was trying to communicate with the server.  Your post truly made no sense and I can't help that your oversights began before you even entered the thread.

 

I don't even know the categories of the forum. I used the search button and came up with a thread that exactly requested what i was trying to do.  It had no constructive replies on it so i elaborated and gave implementation locations.  This seems like the right approach to me.  Why would i create a new thread that would have the same title?  If the original post was in the wrong location then a mod should have moved it long ago.

 

I specifically said that i was looking for a way to implement the feature via the forge API.  How is suggesting other non-api solutions helpful whatsoever?  If i gave implementation suggestions then obviously I figured out how to implement it and i'm just looking for an api-centric alternative.  And seriously... why would you think that suggesting that i implement a redundant chat interface is anywhere remotely near being a good idea?  Did you think this through whatsoever? Would both be visible all the time? would i have a hotkey to open client-only chat?  This is flat out a bad suggestion and it came immediately after i stated that non-api alternatives are hacky.  I can only assume that you completely failed to read the abundance of relevant context prior to posting or else there'd simply be no reason you'd post what you did.

 

I agree. A well-built GUI is SO much easier to use, also, it makes it easier for ANYONE to use it. Even a simple GUI is better than a command.

 

For example, with a GUI I could have some buttons. I choose the button "Best" and type the item name I want in a text box next to it.

 

It would then show a list underneath the search containing all the breads (I am searching for bread).

 

 

But I can take that one step further. I do the same search, but I say, "Show me all items that have a price between (lets say) 0 - 50". This would show a list of the items in that price range and then display something like this:

 

ICON FOR ITEM | ITEM NAME | PRICE |

 

Then off you go! I would much prefer to use that then a command that would go:

"The best bread is $1 from Such A Shop".

 

I appreciate the gui suggestion and the well-thought-out reasoning you said to back it up.  I just have a preference towards command driven interfaces since they're most efficient.  But again, that's more of a personal preference of mine and i'm sure some others would go the gui route. 

 

My specific mod aside, there's still no way to do client-only commands via forge and it's a simple implementation to add it.  That's all i was trying to relay across .. and it was likely the goal of the two people that posted prior to me as well. 

Link to comment
Share on other sites

I just have a preference towards command driven interfaces since they're most efficient.

you must be kidding me... yes ok it works well on linux because you have auto complete and drawing all the icons take a butload of time, but for a game ????!?!

 

sign-shop is the worst system in the world

 

and really ? efficient?

 

please tell me how typing "/gold" is faster then opening your eyes:

8DUbIyH.png

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

My specific mod aside, there's still no way to do client-only commands via forge and it's a simple implementation to add it.  That's all i was trying to relay across .. and it was likely the goal of the two people that posted prior to me as well. 

You know, till we found an actual use for those "client-only commands" that can't be handled by a GUI, there is no need for them.

The fact that you like chat command more than GUI is not really a valid argument by the way.

Link to comment
Share on other sites

I just have a preference towards command driven interfaces since they're most efficient.

you must be kidding me... yes ok it works well on linux because you have auto complete and drawing all the icons take a butload of time, but for a game ????!?!

 

sign-shop is the worst system in the world

 

and really ? efficient?

 

please tell me how typing "/gold" is faster then opening your eyes:

 

Wow, could you possibly be more short-sighted and close-minded?  Sure, in your gold scenario a gui display is more efficient.  Though that's not the case for everything.  My mod is an example of this. 

/list <item name> 

is way the hell faster to execute than hitting a hot key, clicking in the textbox, typing what you want, then hitting enter.  Why would i want to go from mouse to keyboard more times than i need to?  I could also just show a list of all items in the gui and have the user click one but that is obviously horrendously slow and requires more eye movement than simply typing in a chat window.

 

FYI.. you know you can do auto-complete in the minecraft chat window, right?  sigh.

 

I'm done here. 

Link to comment
Share on other sites

  • 2 weeks later...

I need Cleint side commands to make it work because it needs to work on BOTH forge villnail and Bukkit.

 

Fair enough. But why not make it a GUI? Have your own chat GUI that handles only IRC stuff. ( You also might want to make it pause the game ). The GUI would be a lot simpler and much more efficient ( Well, to my reasoning anyway. ) It also means that you do not need to worry about having to make that command turn on/off the IRC stuff. It keeps things SO much cleaner. Once forge created API support for client side commands though, feel free to switch to the chat commands. But since there is no support, do what you can that WILL work.

 

Sorry if this seems a little over the top, I do do that sometimes.. I don't want to seem extremely biast towards GUI's... But I probably am.

I am Mew. The Legendary Psychic. I behave oddly and am always playing practical jokes.

 

I have also found that I really love making extremely long and extremely but sometimes not so descriptive variables. Sort of like what I just did there xD

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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

    • I'm developing a dimension, but it's kinda resource intensive so some times during player teleporting it lags behind making the player phase down into the void, so im trying to implement some kind of pregeneration to force the game loading a small set of chunks in the are the player will teleport to. Some of the things i've tried like using ServerLevel and ServerChunkCache methods like getChunk() dont actually trigger chunk generation if the chunk isn't already on persistent storage (already generated) or placing tickets, but that doesn't work either. Ideally i should be able to check when the task has ended too. I've peeked around some pregen engines, but they're too complex for my current understanding of the system of which I have just a basic understanding (how ServerLevel ,ServerChunkCache  and ChunkMap work) of. Any tips or other classes I should be looking into to understand how to do this correctly?
    • https://mclo.gs/4UC49Ao
    • Way back in the Forge 1.17 days, work started for adding JPMS (Java Platform Module Support) to ModLauncher and ForgeModLoader. This has been used internally by Forge and some libraries for a while now, but mods (those with mods.toml specifically) have not been able to take advantage of it. As of Forge 1.21.1 and 1.21.3, this is now possible!   What is JPMS and what does it mean for modders? JPMS is the Java Platform Module System, introduced in Java 9. It allows you to define modules, which are collections of packages and resources that can be exported or hidden from other modules. This allows for much more fine-tuned control over visibility, cleaner syntax for service declarations and support for sealed types across packages. For example, you might have a mod with a module called `com.example.mod` that exports `com.example.mod.api` and `com.example.mod.impl` to other mods, but hides `com.example.mod.internal` from them. This would allow you to have a clean API for other mods to use, while keeping your internal implementation details hidden from IDE hints, helping prevent accidental usage of internals that might break without prior notice. This is particularly useful if you'd like to use public records with module-private constructors or partially module-private record components, as you can create a sealed interface that only your record implements, having the interface be exported and the record hidden. It's also nice for declaring and using services, as you'll get compile-time errors from the Java compiler for typos and the like, rather than deferring to runtime errors. In more advanced cases, you can also have public methods that are only accessible to specific other modules -- handy if you want internal interactions between multiple of your own mods.   How do I bypass it? We understand there may be drama in implementing a system that prevents mods from accessing each other's internals when necessary (like when a mod is abandoned or you need to fix a compat issue) -- after all, we are already modding a game that doesn't have explicit support for Java mods yet. We have already thought of this and are offering APIs from day one to selectively bypass module restrictions. Let me be clear: Forge mods are not required to use JPMS. If you don't want to use it, you don't have to. The default behaviour is to have fully open, fully exported automatic modules. In Java, you can use the `Add-Opens` and `Add-Exports` manifest attributes to selectively bypass module restrictions of other mods at launch time, and we've added explicit support for these when loading your Forge mods. At compile-time, you can use existing solutions such as the extra-java-module-info Gradle plugin to deal with non-modular dependencies and add extra opens and exports to other modules. Here's an example on how to make the internal package `com.example.examplemod.internal` open to your mod in your build.gradle: tasks.named('jar', Jar) { manifest { attributes([ 'Add-Opens' : 'com.example.examplemod/com.example.examplemod.internal' 'Specification-Title' : mod_id, 'Specification-Vendor' : mod_authors // (...) ]) } } With the above in your mod's jar manifest, you can now reflectively access the classes inside that internal package. Multiple entries are separated with a space, as per Java's official spec. You can also use Add-Exports to directly call without reflection, however you'd need to use the Gradle plugin mentioned earlier to be able to compile. The syntax for Add-Exports is the same as Add-Opens, and instructions for the compile-time step with the Gradle plugin are detailed later in this post. Remember to prefer the opens and exports keywords inside module-info.java for sources you control. The Add-Opens/Add-Exports attributes are only intended for forcing open other mods.   What else is new with module support? Previously, the runtime module name was always forced to the first mod ID in your `mods.toml` file and all packages were forced fully open and exported. Module names are now distinguished from mod IDs, meaning the module name in your module-info.java can be different from the mod ID in your `mods.toml`. This allows you to have a more descriptive module name that doesn't have to be the same as your mod ID, however we strongly recommend including your mod ID as part of your module name to aid troubleshooting. The `Automatic-Module-Name` manifest attribute is now also honoured, allowing you to specify a module name for your mod without needing to create a `module-info.java` file. This is particularly useful for mods that don't care about JPMS features but want to have a more descriptive module name and easier integration with other mods that do use JPMS.   How do I use it? The first step is to create a `module-info.java` file in your mod's source directory. This file should be in the same package as your main mod class, and should look something like this: open module com.example.examplemod { requires net.minecraftforge.eventbus; requires net.minecraftforge.fmlcore; requires net.minecraftforge.forge; requires net.minecraftforge.javafmlmod; requires net.minecraftforge.mergetool.api; requires org.slf4j; requires logging; } For now, we're leaving the whole module open to reflection, which is a good starting point. When we know we want to close something off, we can remove the open modifier from the module and open or export individual packages instead. Remember that you need to be open to Forge (module name net.minecraftforge.forge), otherwise it can't call your mod's constructor. Next is fixing modules in Gradle. While Forge and Java support modules properly, Gradle does not put automatic modules on the module path by default, meaning that the logging module (from com.mojang:logging) is not found. To fix this, add the Gradle plugin and add a compile-time module definition for that Mojang library: plugins { // (...) id 'org.gradlex.extra-java-module-info' version "1.9" } // (...) extraJavaModuleInfo { failOnMissingModuleInfo = false automaticModule("com.mojang:logging", "logging") } The automatic module override specified in your build.gradle should match the runtime one to avoid errors. You can do the same for any library or mod dependency that is missing either a module-info or explicit Automatic-Module-Name, however be aware that you may need to update your mod once said library adds one. That's all you need to get started with module support in your mods. You can learn more about modules and how to use them at dev.java.
    • Faire la mise à jour grâce à ce lien m'a aider personnellement, merci à @Paint_Ninja. https://www.amd.com/en/support 
  • Topics

×
×
  • Create New...

Important Information

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