Bukkit

Redstone Views

As of version 0.9, ScrollingMenuSign supports redstone views. This allows you to define a view which can be any (solid) block in the world. The view has configurable attributes defining which menu items (if any) should be executed if the block receives power, or loses power (or either).

Overview

Redstone views are a little different from other view types:

• Redstone views have no visual appearance of their own - they just monitor the powered status of some block in the world.
• Redstone views cannot operate directly on a specific player, because there is no connection between a redstone power event and the player who triggered it (there might not even be a player involved if power levels were changed by some other plugin, e.g. CraftBook, RedstoneChips...)
• Therefore, commands run from a redstone view are by default run as if from the console. This is fine for commands which don't operate on a player (e.g. changing the weather, setting the time of day) but clearly not useful for commands which do require a player.
• However, redstone views can be configured to operate on the closest player to the view, or on all players within a configurable radius around the view.

Permissions

For players to be affected by a redstone view, they must have the scrollingmenusign.use.redstone permission node. All players have this node by default. Note that possession of this node alone doesn't allow redstone views to be created or deleted - scrollingmenusign.commands.sync and scrollingmenusign.commands.break respectively are needed for that.

Creating a Redstone View

To create a new redstone view, the menu for it must already exist. Then:

/sms sync <menu-name> -redstone

You will be prompted to left-click a block to create the view, or right-click anywhere to cancel creation. Once you've left-clicked, the view is created, and you will be told the view name. You will need to remember this view name.

Configuring a Redstone View

Three attributes are used to define what commands are run from a redstone view:

• poweron: the command to run when power to the block goes from low to high
• poweroff: the command to run when power to the block goes from high to low
• powertoggle: the command to run when power to the block changes in either direction

This example allows the time to be changed from day to night and vice versa by pulling a lever:

/sms create timeofday Time of Day
/sms add timeofday Day "/time day"
/sms add timeofday Night "/time night"
/sms sync timeofday -redstone
  (left-click a lever that you've placed, or the block it's attached to, or any block connected via redstone)
  (we assume the view name is "timeofday-1")
/sms view timeofday-1 poweron Day
/sms view timeofday-1 poweroff Night

Now pull the lever a few times and see what happens...

Removing a Redstone View

To remove a redstone view:

/sms break <view-name>

(This actually works for any view type, not just redstone views)

Running Commands as Players

As discussed above, by default all commands triggered from a redstone view are run as if from the console. However, it is possible to have these run as one or more players. If the view's playerradius attribute is greater than 0, then all players within that radius of the view will be considered as potential targets for the commands. If the view's affectonlynearest attribute is true, then only the closest of those candidates will be used. If it is false, all players within playerradius will be used.

In addition, only players who have the scrollingmenusign.use.redstone permission node will be considered. By default, all players have this node. Note that taking this node away would also protect players from any harmful command effects (see first example below), so consider carefully before removing it...

Best illustrated by example. This sets up a pressure plate which does 2 hearts of damage to anyone who steps on it:

/sms create mymenu My Menu
/sms add mymenu Hurt "$H,4 \\that hurts!"
/sms sync mymenu -redstone
  (left-click a pressure plate that you've placed)
  (we assume the view name is "mymenu-1")
/sms view mymenu-1 poweron Hurt
/sms view mymenu-1 playerradius 1.5

Now try stepping on that pressure plate...

Here's another example. Wire this view's block up to some kind of redstone clock (either using torches/repeaters or some plugin like Falsebook or RedstoneChips) for a "healing beacon" which heals all nearby players:

/sms add mymenu Heal "$H,1 \\you feel good!"
/sms sync mymenu -redstone
  (left-click the block which will be your beacon)
  (we assume the view name is "mymenu-2")
/sms view mymenu-2 poweron Heal
/sms view mymenu-2 playerradius 10
/sms view mymenu-2 affectonlynearest false

Caveats

Detecting the closest player is not 100% reliable. It is possible, though unlikely, that if another player is right beside the player who triggered the view, they will be affected instead. There's no foolproof way of detecting the correct player every time. You may wish to experiment with the playerradius attribute to find an ideal balance.

Attributes

See Usage/Managing Views for information on viewing and changing view attributes.

Redstone views support the following attributes: