Sensors - Creating and Managing sensors: Version: v2.0.0 Introduction: I’ve made the sensors 1.0 more than a year ago. It was a surprise for me, how the plugin become popular. There were over 2200 downloads. Through the last year, I was receiving a lot of requests with problems about the compatibility with the new Minecraft. And a few days ago, I decided to make a new, working version, writing a source code with new algorithms. The main advantage, I think, is simplicity in use. Now, users don’t have to learn all the commands and use them in game, don’t have to create something like react signs (like in the last version). To control your sensor, in most case, you must type a single command and place a sign next to the sensor. It will trigger a in-sign menu (yes, a menu), controllable by a mouse. You can scroll through sensor options and choose the right properties. Then you choose the “exit” option, and you get your sign back. I’ve also limited the sensor types. Now there are 3 types: line, area and object. I’ve eliminated the racing sensor (the line sensor is enough for this purposes), but I can make it again, if there will be a need. There are also no day/light sensor, because in the new Minecraft, Mojang already made a day sensor. I’ve supported the WorldGuard, Multiworld and Wireless Redstone plugins, but I didn’t support the iConomy (like in previous versions), because the iConomy plugin isn’t up to date (abandoned?). This is the first, released version (beta), so there may be any unfixed bugs, that weren’t spotted by me, but probably will be spotted by you guys. If you find any, let me know. Plugin description: Sensors is a bukkit plugin, that supports creating and managing 3 types of sensors: line – like a laser beam, it detects entities that will go through it area – detects entities in a cylinder shaped area object – gets the state of the assigned object (like chest, pressure plate, button, lever, etc.) and informs the owner about the manipulation (like using it, clicking on it or destroying it) Each sensor can be controlled by a specially created (with a command) sign, which displays a scrollable menu. More about it in the “How to use” section. Every sensor can react in 3 ways: a) only inform the owner about the detection b) send the redstone signal through the neighbor levers c) both For example. Player A created a line sensor in a cave passage and goes to get some food. Meanwhile, the player B sees the cave and wants to check it out. Enters is, the sensor detects his presence and reacts (in one of the chosen ways). If player A, set the inform only option, there will appear a message on a chat. If he chose the redstone signal reaction, the prepared mechanism, connected to the sensor, can be triggered and get rid of the unwanted guest Extra information: In the description, there may appear some concepts. I will explain them: permitted list – a list of players (every sensor has it), which won’t be detected by a sensor. It’s some sort of a friends list. Can be useful, if you have a shelter with a some friends and want the sensor to react only for the enemies. menu sign – (created by the /senmenu command) if you remember, in the previous version, the sensors could by managed only through a commands or through the react sign. Now you can manage the sensors by a special sign, that will show a menu. You can scroll through the items, go to the submenus and choose your options. After everything, you can choose the ‘exit’ command or just destroy the menu sign. Without a right permission nodes, no one, except you and the players from the permitted list, can create/use the menu that controls your sensors. Warning: every menu submenu has a “BACK option, to navigate through options. One more warning about the object sensor – to assign it to a new object (door, pressure plate, lever, etc.) just make a sign menu, choose the “type” submenu, and “object”. Than you can assign a new block by right-clicking on it. How to use (tutorial) (Move your mouse to reveal the content) How to use (tutorial) (open) How to use (tutorial) (close) Most of it is described in the videos, but if someone would like to learn it by a separate sections: Creating sensors: By default, the sensor block is a dispenser. So, we need a dispenser: Also, if you want the sensor, to send the redstone signal, you’ll also need lever(s): For this tutorial, we will create a sensor named caveEntry. So we type a command in a chat: /newsensor caveEntrance (or /snew caveEntry, if you like) You will be requested to put a sensor block. So get the dispenser and put it, where you want, BUT: IMPORTANT: The block facing is important. The “hole” in the dispenser block shows, from where the sensor beam goes. So, you’d better put a sensor block in front of you, like this: To make sure, the sensor can send the redstone signal, put a lever on one of the 4 sides (but I wouldn’t recommend from the sensing side ), like this: or this: Managing your sensors: Be sure, you have a sign and type a command: /senmenu (or /smenu, if you like) Now just put your sign neighborly to the sensor block, like here: Of course, I’ve put a regular sign, just to show, how to put it. But, if we typed the command and placed a sign (you don’t have to write anything in the it!), we will see a menu!: Now we’re ready to go. You control the menu in a described way: going to the next item – RIGHT MOUSE CLICK accepting the choise – LEFT MOUSE CLICK If you want to exit the main menu, just go through the items (by multiple right-clicking on a sign), and when the “EXIT” option is selected, just left-click on a sign. The sign will be destroyed, and you can get the sign back to your inventory. Now, just place a redstone, going from the lever to your mechanism. Example: After detection, the redstone will have a signal. I’ve chosen to detect the owner, and went in front of a sensor. That’s what happened: Now, a little trick: in Minecraft, after the Redstone update, there is such item as the NOT Gate. You can place it in a line of the redstone. Thanks to it, the sensor can e.g. have the door opened (signal) and if it detects something, it will send redstone signal, and by passing by a NOT Gate, there will be no signal: sensor ------> lever ------> redstone signal ------> NOT Gate ------> No signal after detection, and signal without detection Sending redstone signal: As written in the “sensoc creating” part, you need to put a lever near one sensor side. When you have it there, open a sign menu, choose the “reaction type” element, like here: Then, left-click on it, and choose the “redstone” or “both” option. Beeing undetected by any sensor: (dedicated to EvilJackCarver ) There is a special permission: sensor.ninja If the player has it, he will be undetected by any sensor. Of course it’s not the only way to be undetected. There are also options in config file, so the ops can be always undetected (useful for admins, that check players). Commands (Move your mouse to reveal the content) Commands (open) Commands (close) Most of the commands starts with the “sen”. For example, the senmenu command means sensor menu. The ‘|’ char, separates the command alternatives - choose the most comfortable form to you By default, available for everybody: /newsensor <name>| /snew <name> - creates a new sensor with the specified name /mysensors | /smy | /senmy – displays the list of your sensors /senname | /sname – displays clicked sensor name /senmenu | /smenu – creating a sensor-management menu /seninfo <name> | /sinfo <name> – show the ingame window, that provides the information about the sensor /senstatus | /sstatus – show all your sensors state in a semi-transparent frame on the screen /senhide | /shide – hiding all the displayed sensors info By default, for op’s: /senregion <name> <command> | /sregion <name> <command> | /senwg<name> <command> - (works ONLY if the WorldGuard is installed). Makes available managing sensors in the specified region (cuboid). <command> options: lockall (e.g. /senregion mycub lockall) – locks all the sensors in the region unlockall (e.g. /senregion mycub unlockall) – unlocks all the sensors in the region activateall (e.g. /senregion mycub activateall) – activates all the sensors in the region deactivateall (e.g. /senregion mycub deactivateall) – deactivates all the sensors in the region destroyall (e.g. /senregion mycub destroyall) – destroys all the sensors in the region /sensors <operation> | sen <operation> | s <operation>- command, which controls plugin state < operation > options: save (e.g. /sen save) – saves the current sensors list to a file reload (e.g. / sen reload) – erases the current sensors properties and loads a set from a file backup (e.g. / sen backup) – saves the current sensors list to a backup file destroy_all (e.g. / sen destroy_all) – destroys all the sensors on a server lock_all (e.g. / sen lock_all) – lock all the sensors on a server unlock_all (e.g. / sen unlock_all) – unlock all the sensors on a server activate_all (e.g. / sen activate_all) – activates all the sensors on a server deactivate_all (e.g. / sen deactivate_all) – deactivates all the sensors on a server /senmanage <name> <command> <val> | /senman <name> <command> <val> | /sman<name> <command> <val>- change the properties of the sensor <command> options: removeall (e.g. /sman sensor1 removeall ) – clears the permitted players list in the specified sensor activate (e.g. /sman sensor1 activate ) – activates the sensor (it starts detecting) deactivate (e.g. /sman sensor1 deactivate ) – deactivates the sensor (it stops detecting) lock (e.g. /sman sensor1 lock ) – locks the sensor unlock (e.g. /sman sensor1 unlock ) – unlocks the sensor destroy (e.g. /sman sensor1 destroy ) – destroys the sensor maxrange (e.g. /sman sensor1 maxrange 12 ) – sets the maximum detection range (0 – auto) maxheight (e.g. /sman sensor1 maxheight 5 ) – sets the maximum detection height (0 – auto) addplayer (e.g. /sman sensor1 addplayer Notch ) – adds a player to the permitted list removeplayer (e.g. /sman sensor1 removeplayer badGuy ) – removes a player to the permitted list Sensor types (Move your mouse to reveal the content) Sensor types (open) Sensor types (close) a) line sensor – as the names says, it detects entities in front of it. The detection beam, goes to the nearest obstacle or as far as it can go (maximum range value). It is possible to set the beam height, so it can make an sensing wall. b) area sensor – as the names says, it detects entities in a certain area, which has a cylinder shape. c) object sensor – detects any changes (use/trigger/destroy) in an assigned object. To assign it to a new object (door, pressure plate, lever, etc.) just make a sign menu, choose the “type” submenu, and “object”. Than you can assign a new block by right-clicking on it. Config file (Move your mouse to reveal the content) Config file (open) Config file (close) autosave_time – autosaves the sensors list every X minutes sensors_check – (important) the time (in ms) of every periodical sensors check. 1 second = 1000 miliseconds. The less the value is, the better the detection efficiency, but also bigger processor use. limit_per_player – every player can have max. X sensors time_between_msg – if the sensors detects something, it will post a message and wait next X seconds to post another one, if the threat is still detected. The main purpose is not to spam the user with detection messages. save_after_op – “op” means “operation”. If true, the sensors set will be saved to a file, after every operation (create, delete, etc.) activate_new_sensors – if true, the sensor will start its work immediately after creation autolock_new_sensors – if true, the sensor will be locked immediately after its creation animation_menu_open – after creating menu sign, there is played a short animation, that looks like a loading inform_sensor_destroy – if true, the owner will be informed about the sensor destroy detect_ops - if true, the op's won't be detected by the sensors. limit_ops - if false, the ops won’t be limited in sensor creation (like other players) ignore_obstacles_ids – the id’s of blocks that are treated like air, by a sensor – the sensor beam will go through them. permitted_list_autoadd – (permitted list described in “extra information” section) the list of nicks, that will be automatically added to every new sensors permitted list block.id – the id of the block sensor, by default it’s a dispenser sensortype.<type>.: maxrange – max distance from the sensor, in which the entity (or the object changes in object sensor) will be detected maxheight – if the value is 0, the height will be set automatically. If the value is greater than 0, then the sensor will check the sensed area to the specified max height infinite_height – if true, the height of the sensing shape will be infinite (the height won’t be checked, only the area on the ground will matter) Permissions (Move your mouse to reveal the content) Permissions (open) Permissions (close) Line sensor: sensor.line.* - Gives access to all line sensor permissions sensor.line.manage - create an interactive menu to manage the sensor sensor.line.destroy - destroy a line sensor Area sensor: sensor.area.* - Gives access to all area sensor permissions sensor.area.manage - create an interactive menu to manage the sensor sensor.area.destroy - destroy a area sensor Object sensor: sensor.object.* - Gives access to all object sensor permissions sensor.object.manage - create an interactive menu to manage the sensor sensor.object.destroy - destroy a object sensor Miscellaneous: sensor.create - creating sensors sensor.destroy_sb_else - destroy sensor that doesnt remain to us sensor.control_sb_else_sensor - manage somebodys else sensor by command sensor.ninja – A SPECIAL NODE - if a player has this permission, it won't trigger any sensors WorldGuard: commands.wg.locking - locking all sensors in the specified region commands.wg.activating - activate all sensors in the specified region commands.wg.destroy - destroy all sensors in the specified region Locking: sensor.locking.* - Gives access all the locking abilities commands.locking.lock_all - description: locking all sensors on the server commands.locking.unlock_all - unlocking all sensors on the server commands.locking.lock_sensor: commands.locking.unlock_sensor: Activating: sensor.activating.* - Gives access all the activation abilities commands.activating.activate_all - activate all sensors on the server commands.activating.deactivate_all - deactivate all sensors on the server commands.activating.activate_sensor: commands.activating.deactivate_sensor: Destroying: sensor.destroying.* - description: Gives access all the destroy abilities commands.destroying.destroy_sensor - destroying chosen sensor commands.destroying.destroy_all - destroys all the sensors Global sensor managing: commands.add_player - add players to the sensors permitted list commands.remove_player - remove players from the sensors permitted list commands.remove_all - clears the permitted list commands.trigger - triggers the sensor commands.save - saving current sensors set commands.reload - reload current sensor set commands.manage_any - manage any chosen sensor commands.check_sensor_name - checking sensor name by clicking on it commands.change_max_range - changing the sensor max range commands.change_max_height - changing the sensor max height detecting Files (Move your mouse to reveal the content) Files (open) Files (close) There are also less files (only 2 main .yml files and one backup file). Now, there won’t be any .txt files. config.yml – contains plugin configuration sensors_list.yml – contains all information about the sensors backup_sensors_list.yml – a backup of last sensors_list.yml. Can be created manually by a command. Changelog (Move your mouse to reveal the content) Changelog (open) Changelog (close) Version 2.00 Plugin released This is the 2.0.0 beta version, so I would be grateful for any suggestions and bug reports. Videotutorial: dev bukkit link: http://dev.bukkit.org/server-mods/nez_sensors/ <Removed non-bukkit download, and moved to plugin releases. - Iroh>
React signs simulates redstone signal sending by activating nearest redstone wires, so you can connect anything that is enabled by wire signal. See the tutorial video at 6:50.
No workie with 1.3.1 - throws an unhandled exception on any command. Looks like something's missing from a permissions check.
Roger that, (re)grabbing! EDIT: Working now, although I couldn't read the prompts until I edited the config file's language setting. Aaaand I find an issue. My interest in this plugin is for dark-activated lights for the capital city of the server I admin, so I have a single redstone feed with repeaters that runs under the city's streets and turns on redstone blocks embedded in the streets' surfaces. I was using a villager as a crude light sensor - he was in a pen that had an enclosed "safe room" for him with a floor covered with pressure plates feeding the street light line. When night fell he'd go inside and stand on a plate, turning the lights on. It didn't work 100% of the time (villagers do sometimes wander outside at night) but it was better than nothing. I replaced the villager with a light sensor set to darkreact, and placed a react sign on the redstone feed line. The sensor is switching based on light levels, but the react sign's redstone control is doing strange things. At first it was only turning the lights on for a single one-second burst, so I changed ModeSensorReact to zero and reloaded the plugin. Turned on and stayed on, never turned off, even after I placed a light source over the sensor to lock it "on." I tried ModeSensorReact: 1 and SensorReactSpeed: 105 to keep the redstone turned on at least as long as the server checks, and now it's sending a short burst down the line. I also found that making changes to the config file also requires breaking and recreating react signs. Just changing the config file and doing a /sensors reload didn't propagate changes to react signs. EDIT by Moderator: merged posts, please use the edit button instead of double posting.
I have added a new mode to make it possible. It's a ModeSensorReact = 3. The react sign will be giving a constant signal only, if the sensor is detecting its target. Reload command is supposed only to get an actual values from the config file - it has an effect only in the new react signs. If you want to modify previous one's, edit the text on them. I have also taken care of some other bugs (-> changelog).
IDEA: Configuration file Add the possibility to set a #limit of sensor per player Integration with some economy mod (To make people pay to make sensor) Ability to configure sensor to exclude detection of people or only detect selected people (For example, to make a trap that won't hurt its creator)
First two idea's are already in the plugin from the beggining. The last idea also appears - movesensor can exclude its owner from the detecting. Although, economy idea is good. I can also think about ignoring other selected players from detection.
Any chance you can change the light sensor to work with actual light levels that the user can set? This other plugin is perfect for what I want, but it's not updated xD http://forums.bukkit.org/threads/mech-lightsensor-v0-9-light-dependant-levers-1185.5975/ It's just a bit more useful actually setting the level instead of just having day and night
I got an weird problem, any suggestions ? 11:01 PM [SEVERE] Could not pass event BlockPlaceEvent to Sensors Cheers, Cyfer
I need some details - write me a private message and paste all the error and say when the error appears I've uploaded the 1.13 version. Just Another Guy - I've added your idea. You can set it in config file: ReactOnLight: equal or change it by a command: /lightsensor equalreact <name> IMPORTANT: I've changed a bit the system of worldname saving and made some changes to config file, so it is recommended to delete the Sensors folder and restart the server. If you have some important sensors already: - open the "sensors.txt" and "sensors_react_signs.txt" and add to every line: ;<yourworldname> if there is sensor1;688;4;-860;s;Nez;1;Fire;l;inform from now it should be e.g. sensor1;688;4;-860;s;Nez;1;Fire;l;inform;world If you won't do this, your sensors and react signs will be lost! Sorry for all the bugs in te plugin - I was doing "Sensors" alone and I didn't have the testers to check, if it's bug free. Please keep posting bugs and warnings, and I'll try to fix them as soon as possible. EDIT by Moderator: merged posts, please use the edit button instead of double posting.
Don't worry about the bugs - just keep doing what you're doing and you'll win many, many . (Besides, "bug free" really means the bugs are free. ) Sensors is already awesome even if it does/did misbehave a little, and the more you fix and improve the better it'll get. (As far as I know you have the ONLY player/light sensing mod that works in 1.3.x!)
BTW, the new mode works beautifully - my server's capital city now has automatic street lights. Soon, so shall its buildings.
New feature added - the IgnoreList. Thanks to it, you can set and manipulate (add or remove) the list of players, that won't be detected by the specified sensor. example use: setting the only players, that will be ignored: /movesensor ignore Mike14 adam10 john adding the players to the existing list: /movesensor ignoreadd harry notch Barny96 removing the players from the existing list: /movesensor ignoreadd notch Mike14
The latest build of Sensors has a slight quirk that didn't manifest itself until I dropped the server to update Bukkit. During the server restart I saw this in the console: Code: 19.08 14:20:29 [Server] INFO �4[Sensors] �3ERROR - Invalid values in config file. Restoring defaults. ModeSensorReact changed from 3 to 1. Methinks the value check for that setting is still looking for 0-2 instead of 0-3. Changing ModeSensorReact back to 3 and doing a reload reactivated my city's lighting system but I suspect it'll revert again the next time the server is started. Sensors is awesome; we'll help you make it (nearly) perfect.
Download and check the 1.17 version. Now there won't be any strange characters in console. I've also fixed the issue with accepting this new mode. And also, I've updated mu plugin to 1.3.1 R2 I've checked, if the new mode is working, and everythings fine on my server - also when changing the value in the config file - it isn't restored to defaults. What do you think about restoring the default config file, if there are any invalid valuses - it should stay, or there should be Sensors disabling if there are any invalid values?
I grabbed the latest, and everything cycled as desired without unsupported Unicode characters or a complaint about the mode, so both of those fixes work. Looks like the light sensor side of things is ready to rock! As for your question, what I always thought was nice to do would be to comment out a bad value and replace it with a good one, so that the user could see what was changed and what it was changed from. No idea if there's a practical mechanism to do that in YML files, though.
Hi. This plugin seems to say "You don't have permission" when ever I try to put a normal sign down. Is this meant to happen?
Indeed - add "sensors.*" to whatever groups you want to be able to use sensors, and it's not a bad idea to deny "sensors.reload" from everyone except admins/ops.
Hi, I have a problem : when i enter a player in the ignore list the react sign work like i do nothing. Can you help me?
can you add a separate plugin on this lemme explain what i mean. signs that work just like levers just in a cool way i got the inspiration from you controll sign part like :SIGNTEXST [SWITCH] [BLANK] (WILL BE THE ON OFF INDICATOR WHEN DONE) CHANNEL (redstone state channel of course) OUT/IN (out is the state that transmitt and in is the incomming state) and scince you got the code in the controll sign why not make one like this if y havent allready
Got a request - mind adding a perms node so that users with the perms node (say, sensors.ignore or sensors.bypass, or, hell, even sensors.movesensor.bypass, sensors.firesensor.bypass, etc.etc.) would not trigger any alerts from any sensor, or any of that specific type of sensor [should it be the latter two suggestions]? Also, support for VanishNoPacket would be lovely - I'd like to be able to move around stealthed and able to keep an eye on my admins should I need to go past a sensor undetected. I'd also like it so that admins can see any sensor's detection. It's case sensitive.