[MISC] ScrollingMenuSign - scrollable command menus with many view types [BukkitDev]

ScrollingMenuSign - scrollable command menus

​

Note: ScrollingMenuSign is now on dev.bukkit.org:​

​

http://dev.bukkit.org/server-mods/scrollingmenusign/​

All documentation for the plugin can now be found there. General discussion for the plugin is fine here, but please use dev.bukkit.org tickets for problem reports.​

ScrollingMenuSign lets you attach a scrollable command menu to any sign or map and add menu items to it. Right-click the sign to scroll the list of items, left-click it to select an item and execute its associated command. The inspiration for this plugin was the large number of Minecart Mania station names I (and others) have to remember and type in.



Some possible uses:

• A menu of station setting commands for Minecart Mania
• Newbie user guide menus
• Warp menus for your favourite teleportation plugin
• A shop menu - buy/sell/swap items & credits
• Controlled access to commands that users can't normally run

Links:

• Download ScrollingMenuSign.jar 1.3.2 for CB 1.2.5+
• View source code on github
• Project page (including user manual) on dev.bukkit.org

Changelog

See the Changelog on dev.bukkit.org

 

Okay. Thanks

 

Three big things:

• Synchronised signs - actually quite a big internal rewrite. There will no longer be a 1-to-1 relationship between menus and signs - one menu will be able to have any number of signs, which are basically just views on the menu. They'll be kept in sync with the menu automatically. Only thing that will be independent is each sign's scroll position.
• CommandSigns integration - use the CS API to run commands, which give us a whole load of nice stuff Permissions bypass, Economy, etc.
• Command script files - put a set of commands in a file in your plugin directory to allow a sequence of commands to be run from one menu item.

 

@desht sounds great! About those script files. Any way of in-game creation of those so all people can do it instead of FTP'ing back and forth?

 

Yeah, in-game creation will be possible (not guaranteed to be in v0.3 though).

Actually, I'm thinking possibly a macro-type system rather than simple files. Macros could be stored in a YAML file, e.g. something like:

Code:

daytime:
- \making it day time!
- /@time day
- \it's now day time!

Then a menu item like 'Day|%daytime' would :

• say "making it day time!"
• run /time day (using CommandSigns permissions elevation )
• say "it's now day time!"

Putting the macros in a YAML file makes it easier to modify them with in-game commands, as well as keeping it easy to edit/upload them directly.

Thoughts?

OK, I've tested v0.2.1 and the in-development v0.3 with CB818 and I can't see any problems. Done various combinations of server reloads & restarts, logging out & in again etc. and all seems to be working well. Please let me know if you're still seeing any problems.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

@desht v0.3 done? Just opened your github and saw that the main page is v0.3

EDIT: Perhaps a wiki for macros?

 

New release available:

v0.3 (1/6/2011)

• CommandSigns integration. If the CommandSigns plugin is present, ScrollingMenuSign can use its command parser to handle all commands. Strongly recommended - among other goodies, you get elevated permissions support, and economy support for free! See CommandSigns documentation for details.
• Fully synchronised menu signs. What does this mean? One menu can now have any number of signs associated with it (even zero), each sign being an independent view on the menu's contents. Update the menu, all associated sign automatically reflect its contents.
• Command macros. You can set up macros which call multiple commands, and can even call each other (yes, recursive loops are detected and stopped!)
• All /sms subcommands can now be abbreviated to their shortest unique spelling. E.g. "/sms c" instead of "/sms create".

Indeed it's done, and there is already a Wiki page for macros I've split the Wiki out in several sections, there's a link to macros from the front page. Let me know if it's clear enough, I can add some more examples/tutorials if needed.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

The link to macro-instructions under the Usage on your wiki is pointing to a wrong place.

 

Fixed!

 

@desht not all my menu items are aligned, bug or?

 

Known behaviour with signs really, and it's always been this way. I don't believe there's any way around it - signs don't use a fixed-width font.

 

Okay, thanks.

Also, if you aim at the top of the sign and rightclick (config: execute) it allows the placement of blocks, perhaps stop that?

EDIT: Removed part of message because it was my own fault that it didn't work.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

This could be a configurable. I've gotten used to only holding tools, not blocks, when I need to right-click any object which has special plugin handling

 

I'm trying to create a sign with my servers features for the members but there is a small feature that's missing:
Doing this: "/sms add Features Signs||Scrollable signs!" prints out my name as it tries to do an empty command, but shows the message just fine. Perhaps do so two | after eachother doesn't try to do a command?
Also, does SMS use CommandSigns permissions? What will happen if a user does "/sms add x x|/*time day", does it fail to enable if the user hasn't got permission to do /* or will it bypass the enabling phase of CommandSigns allowing all users to create signs with /@ /* and @?

Also, if you try to remove an index which isn't there (Ie a sign with 4 entries and you use index=5) it gets in "Internal error". So "/sms remove x 5" on a sign with 4 entries gives a red message with "An internal error occurred"

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Thanks, I'll look at fixes for both of those problems fairly soon.

Regarding CommandSigns permissions: you just need scrollingmenusign.commands.add to add an entry like that (same as any other entry). To execute it, you'll need scrollingmenusign.execute and the &CommandSigns fake user needs permissions for the actual command, just as if it was run from a real CommandSign.

 

Actually, looking real quickly at where you're calling the handler, it appears that it uses player permissions just like CommandSigns. In other words, if the player has permissions to execute the command, you're golden. If not, the command will need either the /* or /@ prefix and the fake user will need permission to execute the command.

 

Got misunderstood here. @Fluff you have done some permission nodes for the /@ and /* and such, those are required if a player wants to enable a sign with those in it. My question: since SMS doesn't use "/commandsign enable" will any user then be able to create the /@ and /* signs without needing the 'commandSign.super.*' if they create them through SMS?

 

ScrollingMenuSign doesn't require commandSign.super.* to create such a menu entry - it doesn't go through the /commandsign enable process. To reiterate, you'll need:

• scrollingmenusign.commands.add to add a menu entry (this applies regardless of what sort of entry you're adding)
• scrollingmenusign.execute to be able to execute this entry (again this applies to any command)
• The &CommandSigns fake user needs permissions to run the command itself, or you'll just get a message like "You are not allowed to do this." when you try to execute the menu entry. E.g. if you're using the General plugin for your /time command, ensure &CommandSigns has the general.time.set permission.

All I can suggest is try it and see

 

So all players with permissions to create SMS signs can create /* signs and therefore use all commands that the fake user has permission for?

 

Yeah OK, I see what you're getting at. Bit of a security hole. I could add a new scrollingmenusign.super permission check or pethaps just check for commandSigns.super.* ?

 

@desht think just the commandsign ones as they are integrated, mostly because those functions are within CS and therefore it is pointless to create a check in SMS as people who don't use CS would be checked, (or is there some nice bukkit api way to do otherwise?).

 

Well, the /*, /@, $ and @ constructs are only meaningful if you're using CommandSigns, so I might as well just check for those using the commandSigns.super permissions - if people are using those constructs, then presumably they have already installed and set up CommandSigns.

Actually, the ideal would be for @Fluff to expose another CS API call to permission-check the command before enabling it (I'm referring to the hasRequiredPermissionsToEnable() call, if you're reading this - the code to check permissions based on the sign type could be moved into a public method?). But in the meantime, I'll just duplicate that little chunk of code in the SMS entry adding code

 

I'm having an issue with this where I'm typing /sms create mymenu My Menu and all that jazz, but when I look at the sign, nothing goes onto the sign, and further commands don't do anything else (visually, at least), either. I do have Essentials which has EssentialsProtect which adds protection to signs, which I thought might be the issue, but I de-ops'd myself and removed that permission from myself and it still doesn't work. Any advice?

 

Released v0.3.1:

v0.3.1 (2/6/2011)

• Fixed uncaught IndexOutofBoundsException when removing entries from a menu
• Adding menu entries which use special CommandSigns commands (/@, /* etc.) are now subject to the same permissions checks as if you were creating them on a CommandSign directly. E.g. you need commandSigns.super or commandSigns.super.fakeuser to create an entry with a /* command, etc.
• Empty commands now do nothing, instead of making the user say a a line with no text. This can be useful if you just want a menu entry to give the user a feedback message and nothing else.

Hmm, are you looking straight at the sign when you do "/sms create ..." ? If not, the menu will still be created (as of v0.3), but without an associated sign. You can check by typing "/sms list" - it will show your menu, and the number of signs associated.

If you want to attach the sign to the menu after you've created it, look right at the sign, and type "/sms sync mymenu" (you can do this with any number of signs - one menu can have many signs viewing it).

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

It doesn't automatically make it, but that sync trick worked! Thanks!

 

Directly looking at a sign and doing "create menu" does nothing to the sign as of now. You apparently need to do the "sync menu" on the sign before it gets activated.

 

Doh! There was a basic logic error in the code that checks for a sign in front of you. Fixed now, v0.3.2 uploaded.

Version 0.3.2 released:

v0.3.2 (2/6/2011)

• Fixed a silly bug that ignored any sign the player was looking at when creating a menu.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

@desht download link still points to 0.3.1

 

0.3.2 is uploaded now. Sorry about that.

 

I has an idea!
would you be able to make it so you can execute more than one comannd per line. you could have a ':' to separate commands this way you could have a sign with a line like "a nice day" and have what ever commands you need to change the world to day with no rain or other options.
ex:
/sms create world1 world_settings
/sms add world1 a_nice_day|/time day : /rain off| its a nice Day now

 

You can already do this with macros - https://github.com/desht/ScrollingMenuSign/wiki/Macros
e.g.

Code:

/sms macro add niceday /time day
/sms macro add niceday /rain off
/sms add world1 a_nice_day|%niceday|its a nice Day now

Macros have the advantage of not being restricted by the maximum number of characters you can type on one line.