CreateYourOwnMenus
Hiding scripts is no longer possible from Minecraft 1.16 due to changes in item lore formatting
As the name suggests, this plugin allows you to create your own menus. The menus are based on inventories, with each slot holding a clickable menu item. When a player clicks on a menu item, it performs all of the commands listed in the item's lore (the text underneath its name) in a similar manner to command blocks. You can design the menu in-game by selecting any item, naming it in an anvil, modifying its lore using a command, and using commands to create and open a menu for editing to place it anywhere in the inventory that you wish. You can modify your menus any time you want.
Thanks to TheMobCave for providing the video tutorial. Please like and subscribe!
The video tutorial was of CreateYourOwnMenus v0.2, so the latest version has even more features! One major change is that the /menu script command now has sub-commands. E.g. /menu script add [text] instead of /menu script [text]. As well as: insert, delete, replace, clear, show and hide.
Screenshots
See the gallery for screenshots.
User Reviews
"This looks amazing and would make my role playing server a lot easier for players so they don't have to remember a lot of commands." - Ccamm
"This looks amazing! I'm sure that we'll be able to use this in my new server project." - parrothead1337
"This plugin allow so much things :o" - TheNemesisA5
Features
- Use commands to manage all of your menus
- Use any in-game item as a menu item
- Edit menus in-game using inventories
- Open menus using commands, command blocks or other menus
- Activate any menu item simply by clicking it in an open menu
- Alternatively, activate menu items by holding in hand and right-clicking (can be used to open menus and more)
- Modify the lore of any item using commands /menu script clear and /menu script [comment/command] commands
- Add, remove, modify and share menus using their .yml files in the "plugins/CreateYourOwnMenus/menus" folder
- Optionally run the command as the player instead of console by using the /sudo command E.g. /sudo @p kill
- Show/hide menu script commands using the /menu script show and /menu script hide commands
- Delay execute of commands in a script using the /delay [ticks] menu script command
- Use {curly braces} to add dynamic arguments to commands (prompts the clicking player)
- If you have Vault installed you can use /requirecurrency to check if a player has a given amount of currency
- Translate into other languages using LanguageAPI
What it does not do
- This is not intended to include a full-fledged scripting language. It simply executes commands in series and is interrupted on failure. For more complex actions, conditions and program flow you should be using a plugin like Skript to run scripts on menu item clicks.
- It cannot run commands as a player with "elevated permissions". There is currently no safe way to do this within the Bukkit API without introducing errors, compatibility issues and/or require updates every build of Minecraft, CraftBukkit or even Bukkit. You can work around this by granting the permissions, performing the actions and then revoking them again, or by calling out to another plugin that supports this. I do not intend to add this feature until there is a safe way to achieve it.
Plugin Suggestions
This is a list of plugins that work well with CreateYourOwnMenus.
- Use the MicroJump plugin for BungeeCord /server command support for BungeeCord users
- Use the Skript plugin to open menus on player joining, or various other events, and create advanced scripts that you can run when clicking a menu item
- Use the Vault plugin to provide currency support using the /requirecurrency menu script command
Commands and Permissions
A full list of commands and permissions is available on the Commands and Permissions page.
Detailed command help is available in-game by typing /menu
Sharing
Find and share pre-created menus on our forums!
Scripting
A basic scripting guide is available on the Basic Command Scripting thread.
Other tutorials and guides are available on the forum
Security Considerations
The menu scripts always run as console. By default, this is not a problem as only operators have the ability to create menu items and modify menus, however if you give other players permissions to do this, be aware that it will also give them the ability to effectively run any command they wish as console.
Development
Sources are available on GitHub: https://github.com/XHawk87/CreateYourOwnMenus
Ideas
- Add internationalisation support
- Add a "cyom.menu.edit.[menu id]" permission to allow editing of a specific menu only
- Add "cyom.script.allow.all" permission to allow adding any command to a menu script, except those specifically denied (Default op)
- Add "cyom.script.allow.[command name]" permission to allow adding specific commands to menu scripts (child of cyom.script.allow.all)
- Add /menu script import [file] and /menu script export [file] for quickly importing or exporting the lore of a menu item to a simple text file
- Add "cyom.slot.lock.#" to lock specific inventory slots in a player's inventory and treat it as a menu
- Modify /menu grab command to place items into the same slots in a player's inventory where applicable, displacing other items, and otherwise finding any free slot
- Trigger a menu item when it is used to attack or break blocks with
- Add /use special command to allow the item to be used as a normal item (this cannot be used after a delay or prompt)
- Organise menus into folders, and accessed in the form "folder.menu"
- Store menu items in a format that is easier to edit manually, marking lines as hidden without the section symbols all over it
- Provide a faux creative mode for non-op creative players so that server owners can grant creative abilities to non-op players without introducing security risks
- Command support for tab-autocompletion
- Add escape character for {input prompts} so you can still use datatags
Bugs
- Items in locked slots are still dropped on death instead of remaining in their slots
- Items with the /consume command will only be removed if the stack size is 1
Deprecated Features
- To reduce the number of special menu item commands, the /GiveChest, /TakeChest and /CountChest commands will be removed and less complex and easier to understand Skript alternatives will be provided in their place
Help
This plugin uses Java 7
If you get the followed error on starting up the server with this plugin installed "Unsupported major.minor version 51.0". This means you are using an out of date version of Java. If you don't know how to upgrade, please contact your server hosting provider and ask them for help in upgrading to Java 7, or contact Oracle customer support. Mac OS X users require JDK 7 instead of JRE 7.
Very wide text boxes on menu items
Due to a Minecraft client formatting error, the invisible characters on the first line can cause the lore text box width to be increased despite taking up no space when there is visible text on the same line. This can be mitigated when hidden by keeping the first line empty using /menu script insert 0 &a. When commands are shown, it may become difficult to read them.
Non-op Creative Players spawning menu items without permission
Warning: A new security loop-hole has been discovered in the Minecraft server. It is possible for players with certain modified clients to create items for themselves that contain any lore that they want so long as they are in Creative Mode. This does not require operator status or permissions, only Creative Mode. If you have Non-operator creative players on your server be advised that if they use a modified client, it is possible for them to create any menu item that they want without needing permissions.
You can alleviate this somewhat by adding commands to the "blacklist-commands:" section in the config.yml. This will stop anyone but operators from using menu items with those commands on them. E.g.
blacklist-commands: - op - stop - kick - grantperms etc etc
Another option is to keep those players in Survival mode, but use other plugins to give them creative-like powers such as infinite resources, fast breaking and flight.
Ghost items appearing on clicking a menu item
If you are experiencing ghost items in 1.7.2 using this plugin, it is due to the client-side Minecraft bug (https://mojang.atlassian.net/browse/MC-41165). This only affects 1.7.2 and is fixed in 1.7.4. The bug is not dangerous as it is not a real item. Any attempts to move the item out of the inventory, place it, or fill the same slot will result in it disappearing. Since this is a client-side only bug, it is recommended that players be urged to update from 1.7.2 to 1.7.4 as soon as possible. Note: it is possible to play on CB 1.7.2 R0.1 beta using a Minecraft 1.7.4 client.
After restart, my menus all have weird characters wherever there were hidden commands or colours
This is a text-encoding issue caused by the some CraftBukkit servers attempting to read menu files in the wrong text encoding by default. You can fix this by telling Java to use UTF-8 by default for CraftBukkit.
For users of McMyAdmin, MultiCraft and other server launchers, there should be an option to specify text-encoding in your settings and switch to UTF-8. If not, you should have a way to add optional command line arguments, and follow the advice below for a startup script.
If you are using a startup script you will have something along the lines of:
java -Xmx1024m -jar CraftBukkit.jar
You need to add the following option somewhere after java and before -jar. E.g.
java -Xmx1024m -Dfile.encoding=UTF8 -jar CraftBukkit.jar
After updating CraftBukkit (build #3009+), my Skript custom commands aren't working from menu items
Changes in CraftBukkit build #3009 (1.7.2-R0.3-SNAPSHOT) have updated the Bukkit plugin command system that broke Skripts custom command handler. This prevented Skript from receiving commands that had been directly dispatched by other plugins. This issue was fixed in Skript 2.1.1+, so downloading the latest version of Skript should correct the problem.
It says @a or @w instead of the player's name
If a @a or @w target selector is the last character in a command, it is not currently replaced correctly. This will be fixed in the next dev build. In the meantime, attempt to ensure there is a non-whitespace character after the last target selector.
Every time I click an item in my inventory it activates it like it was a menu item
You may have inadvertently locked all of your inventory slots by misuse of the '*' permission node. This will grant you all permissions, including 'cyom.slot.lock.*' which is used for locking inventory slots so that they can be used as menus. The best solution for this is to stop using the '*' node and instead only grant yourself the specific extra permissions that you need. However if you insist on using the '*' node you will need to grant yourself the negative permission '-cyom.slot.lock.*' in order to prevent your slots from getting locked.
Every time I restart my server, all changes I made to my menus are undone
There is a time-related bug with previous builds of CYOM that prevent file saving. To fix this you must update to the latest dev build: http://dev.bukkit.org/bukkit-plugins/createyourownmenus/files/18-create-your-own-menus-v0-5-8-dev/
I can't use {NBT data tags} in my commands
Unfortunately, we already have a use for the {curly braces} as dynamic arguments that predate their use in Minecraft, so you can't use NBT data tags in your menu commands. However, you can get around this in a couple of ways:
Any items that you need to be given to a player with data tags can be pre-created and placed in a menu, then you can use the /menu grab command to give them to the player. Since you can grab multiple items at once, and edit the menu visually, it makes for a rather convenient way of setting up item kits on a server.
You can also use a custom scripting plugin like Skript to set up a custom command to run the commands for you. Using Skript in this way allows a great deal more flexibility for your menu scripts by adding logic, variables, persistence and program flow, and if you need help with them they have a lot of friendly people on their forums who are always happy to help.
Donations
If you'd like to contribute towards the continued development, support and maintenance of this project, please consider joining me on Patreon, and making a one-time or recurring pledge.
Support Channel
If you need help you can leave a comment below and I will get back to you as soon as I can. You can also join my IRC chatroom using the following link, but please read the tutorial first. http://webchat.esper.net/?channels=XHawk87&prompt=1
I am happy to give support, but repeatedly answering the same question that is explained in bold red on the plugin page is highly tedious. Don't be lazy, read first, then ask questions. It's the polite thing to do
@Xhawk87
I figured that would be an issue, and adding to the @w's effects would break other menu scripts, like you said. Out of curiosity, could something like @w:* work? Usually the * wildcard means all, but since the @w symbol already associates the command with all players in that world, perhaps instead have it do the opposite? Just a thought :)
As for a rawtell support...would something as simple as [Message to send to user] work? Or a slash combined with an udnerscore...like /_
I figured that would be the case...I think it's time I look into skript's db abilities...
Thanks again for your reply :)
@Guomania
With what? It'd help if you actually posted what the problem is :P
So can anyone help me out
@Omanoctoa
Some interesting suggestions.
Unfortunately, @w is already used for "all players in world", and can't be used to also mean "the name of this world". If I changed it now, it would break any scripts using the old meaning. I am not sure what other symbol would work well for the name of the current world. It would need to be something fairly short and intuitive.
Otherwise it wouldn't be hard to add to the existing menu script parser. In the meantime, it is possible to solve this issue using Skript using %world of player-argument% and passing in the player @p using CYOM. The script would then execute the desired plugin command using these tags. The processing overheads would be minimal, and it keeps your menu item scripts looking neater, needing only a single command with fewer parameters and crazy symbols.
Sending raw text messages to players is something I am interested in adding support for. However I wouldn't use the backslash (\) character as it is usually used as an escape character and using it for a different purpose may cause confusion. I think a command would have a clearer meaning, E.g. /rawmsg [player] [message...]. It would take a little bit of work, but its fairly straightforward to add. In the meantime, you can do this using Skript i.e.
Adding support for file and especially database I/O would be a pain, and scripting language for making use of it even more so. However, Skript once again can come to the rescue as it is possible to configure it to store certain variables in your MySQL database as simply as prepending them with a custom prefix E.g. db_. Check out your config.sk file in plugins/Skript and check under the Database header.
There is also additional database support available using the skQuery add-on, documentation available on the skUnity website.
@XHawk87 While trying to set up some commands on items I realized there are a few basic variables that would be useful to add. If it's not too much work, could you consider...
- A variation of the @w target symbol, to output the world the player is in, dynamically. This way a menu could be used in any world without per-world modification. For instance with say, MythicMobs that uses this syntax /mm mobs spawn (mob) # (world,x,y,z). Your current setup has this function, put runs the command for ALL players in the current world as the user, which is not helpful for per-user-world commands.
- A simple operator to send a raw message to the user, without depending on other plugins or commands. Another plugin which I've directed you to before (CommandSigns) performs this using a slash (opposed to backslash) like so... /commands 1 \This text sent to user only. This would make it possible to tell players who use an item or click a menu a particular message, without broadcasting it. Other plugins have this functionality, but having the ability to use it directly from CYOM would make it more efficient.
- Now a big one. The ability to draw something from a file or database. Now I understand you are against this sort of dynamic elements as it would require further scripting and a complete formatting language, but please hear me out. I have found, through using CYOM, that I would love to be able ot save things occasionally and then pull them from a file. Now I can do this in a hacky fashion, by appending a line of lore to the very item used, exporting that item to file and then clearing that line, but that's messy. Instead, a way to save your other variables/targeters or just any input to a file would be incredibly valuable. In my head, it would work along the same concept as the commands you use to add script to an item /menu script append blahblahblah, but instead of script, change a file.
So in theory... /menu file (append/remove/clear/insert/load) (FileName:LineNumber) (VariableName), or for example /menu file load PlayerName:134 name
Now, this command would work the same way as script subcommands would, adding lore, except for the 'load' subcommand, which would simply output the file's contents. The difference is it functions like the export/import command. But rather than importing LORE, it imports the file's contents to a temporary VARIABLE. That variable could then be called using @v VariableName, in commands run by menu items. This would add massive functionality to CYOM, without too much extra work from you. Basically just repurposing the script commands and adding a "load" subcommand. User defined variables could be stored in a separate folder, and called/modified/added when used.
Though once again, I think this may step into the realm of dynamic scripting languages, my hope is to have possibly inspired you :)
Again, thanks for creating this awesome plugin :)
@assasinsheep
I had some unrelated issues with ProtocolLib last month and realized mine was about a year out of date. Try updating ProtocolLib if you haven't already.
As for your issue in itself...are the items being removed from the menu (deleted) when you click on them, or are they just clearing form the screen and reappearing when you re-open the menu. I understand you are no longer experiencing this issue, but it may be beneficial to understand the cause in solving future issues. Plus ProtocolLib is a fairly heavily-depended plugin, so fixing this issue may be helpful.
hi I am having a issue where whenever I click anything in the menu all the items disapear. Rather then saying this is not a valid menu item it clears it so there is nothing in the box this may be a issue with another plugin since I never had the following problem before
this seems to no longer happen ever since I got rid of protocolib for some reason it was messing around with the menus anyways its fixed
I had a thought regarding silent commands. Instead of trying to stop the command from outputting, what about simply redirecting the output? I mean, I imagine this would be difficult as well, but in theory, instead of that user receiving the error message (or ackowledgement), simply redirect that portion of the command to say...a defined offline player. I dunno if it would work and I imagine it would cause an error in itself, but in theory...?
@XHawk87
Ok, Thank you
@CJ190
Yes, I did, in fact.
You can find details of how to use the menu grab command here: http://dev.bukkit.org/bukkit-plugins/createyourownmenus/pages/commands-and-permissions/
You can find information on how to use command blocks here: http://minecraft.gamepedia.com/Command_Block
Alternatively, you can find the Skript plugin here: http://dev.bukkit.org/bukkit-plugins/skript/
Please don't ask me to do it all for you. I am very busy, and I have little time for those who can't be bothered to even say "please" and "thank you" to people who help them.
@XHawk87
But it does not give the subject of the menu at the entrance to the server player. I need to have been the subject of all the players. Or do you have described it, and I do not understand?
@CJ190
If you want to open a menu from an item in your hand, you just need to put:
/menu open @p my_menu_id
In its lore using this command with the item in your hand:
/menu script add /menu open @p my_menu_id
Menu items will run their script if clicked in a menu, in a locked inventory slot, or if held in hand and you click on something with it.
The slot locking will keep the item in place, as I described in the answer to your first question, and you can place the items in their inventory as I described in the answer to your second.
Am I missing something? I believe I have described how to do everything in that video.
@XHawk87
This is: https://www.youtube.com/watch?v=VA2c9D5L1eA&feature=youtu.be
@CJ190
I am not entirely sure what you are asking for, however if you want to give a menu item to players in a lobby for example, you can do that with the /menu grab command.
Create a menu to serve as a template, and then /menu grab that menu for the player. The menu mirrors an inventory, and will attempt to place the items in same relative slot in the player's inventory as it is in the menu.
You can run this command from a command block, or using a scripting or triggers plugin such as Skript or VariableTriggers.
@XHawk87
On some servers, such as writing a script on the diamond /Menu open menuName.
And this diamond in the throwing back, and every player at the entrance to the server it is in your inventory.
Can it be done with this plugin, or need another? If other, what?
@CJ190
Slot locking works using permissions. You must use your permissions managing plugin to assign that slot locking permission to a player. To lock a slot for all players, you should grant that permission to all players. Your permission plugin should contain a feature to do this, please refer to its documentation.
There is also a special "disable.slot.locking" permission node that disables all slot locking. This is not intended to be used directly, it is designed as a failsafe to prevent players who use the '*' permission node in PEX from accidentally locking all of their slots. If you wish to lock slots, you should avoid using the '*' permission node. You can alternatively negate "disable.slot.locking", but you will also have to disable every other slot you do NOT wish to be locked.
Help me.
How locked the slot for all Players???
@XHawk87
I was just about to reply and you replied :D I didn't notice any console errors or anything, but I've used Craftbook's internal CommandItems module and it works properly. That's a good theory though and most likely the cause, though not sure why the entire lore is being wiped. Anyways, I've solved it for now :D
CYOM and Craftbook combined....oohooo scary stuff :D
@Omanoctoa
Happy new year!
The hidden commands work by placing a section symbol before each character, even though most of these are not valid colour codes. This is just speculation, but Craftbook may be trying to determine what colour codes they are and coming up with an error and stopping. Did you check the console to see if there was an error?
Happy new year!
I had a very strange idea...I tried to allow players to craft a handheld menu item. In theory, as a sort of quest item. I'm using Craftbook for this as it works great, but I've run into a strange issue. When I create an item with any lore and commands and then hide the commands, upon crafting the item the hidden commands AND visible lore is replaced by a single & (ampersand). Even stranger, if I craft an item without hidden commands, the lore is visible but the commands are either wiped altogether or do nothing.
While I assume this could be partly just Craftbook not supporting those kind of tags (I expected that, with the hidden commands), I don't understand why it is wiping the visible commands, as they should at least be converted into regular lore. Any thoughts? I know this is out of your territory here, just figured I'd ask...
@Vons2
Yes, just add "/close" to the end of the menu item script.