[MISC] Sensors v2.00 - Creating and Managing sensors [1.6.2]

Discussion in 'Archived: Plugin Releases' started by xa19, Jul 28, 2012.

  1. Offline

    xa19

    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) (open)

    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:
    [​IMG]
    Also, if you want the sensor, to send the redstone signal, you’ll also need lever(s):
    [​IMG]
    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:
    [​IMG]
    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:
    [​IMG]
    or this:
    [​IMG]

    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:
    [​IMG]
    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!:
    [​IMG]
    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:
    [​IMG]

    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:
    [​IMG]
    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:
    [​IMG]
    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 (open)

    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 (open)

    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.
    [​IMG]
    b) area sensor – as the names says, it detects entities in a certain area, which has a cylinder shape.
    [​IMG]
    c) object sensor – detects any changes (use/trigger/destroy) in an assigned object.
    [​IMG]
    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 (open)

    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 (open)

    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 (open)

    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 (open)

    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>
     
  2. Offline

    XENGS

    Can they also send redstone signals?
     
  3. Offline

    xa19

    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.
     
  4. Offline

    Actium Praetor

    No workie with 1.3.1 - throws an unhandled exception on any command.

    Looks like something's missing from a permissions check.
     
  5. Offline

    md_5

    Nice, approved!
     
  6. Offline

    xa19

    Bug fixed.
     
  7. Offline

    Actium Praetor

    Roger that, (re)grabbing!

    EDIT: Working now, although I couldn't read the prompts until I edited the config file's language setting. :p

    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.
     
    Last edited by a moderator: May 27, 2016
  8. Offline

    xa19

    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).
     
  9. Offline

    asgard20032

    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)
     
  10. Offline

    xa19

    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.
     
  11. Offline

    asgard20032

    Well, i didnt saw anything about configuration in description...
     
  12. Offline

    cyfer696

    I got an weird problem, any suggestions ?

    11:01 PM [SEVERE] Could not pass event BlockPlaceEvent to Sensors

    Cheers,
    Cyfer
     
  13. Offline

    xa19

    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.
     
    Last edited by a moderator: May 27, 2016
  14. Offline

    Actium Praetor

    Don't worry about the bugs - just keep doing what you're doing and you'll win many, many [diamond]. (Besides, "bug free" really means the bugs are free. :D)

    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!)
     
  15. Offline

    Actium Praetor

    BTW, the new mode works beautifully - my server's capital city now has automatic street lights. Soon, so shall its buildings. :D
     
  16. Offline

    xa19

    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
     
  17. Offline

    Actium Praetor

    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. :D
     
  18. Offline

    xa19

    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?
     
  19. Offline

    Actium Praetor

    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.
     
  20. Offline

    sfkc1588

    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?
     
  21. Offline

    xa19

    It seems that you didn't add permissions to my plugin to your permissions plugin.
     
  22. Offline

    Actium Praetor

    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.
     
  23. Offline

    Jox91

    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?
     
  24. Offline

    the413danny

    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
     
  25. Offline

    EvilJackCarver

    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.
     
  26. Offline

    xa19

    [UPDATE]
    Sensors 2.0.0 released!
     

Share This Page