@MasterCake has helped me update this to the latest version. Tested on paper-1.21.1-98

Added a spawn command so that I (and anyone who wants to) can spawn a RPS using a command /rps spawn x y z. It does not support ~ at the moment but I plan to add that next.

This was a rushed release because in the previous 2.5.1 I forgot to set the version in the plugin.yml file, but I did in the POM.xml file. I, having not coded in a long time, totally forgot. This time however I triple checked.

Everything else seemed to have worked fine. I tested 2.5.0 with version 1.16.X and nothing was broken except for skull data, but that breaks every version.

I need to create a test environment. After watching a cool video about Minecrafts test environment it made me inspired to do my own.

I will be on alert for when 1.16 drops to add all the new mobs from that.

If you are wondering why you got another update alert it is because the previous version I submitted was pre-compile of bstats causing errors.

I will be on alert for when 1.16 drops to add all the new mobs from that.

• Config has changed, please read below:
  
• I'm still slowly prepping for 1.8 - 1.14.4 support which should happen in 2.5.0 release. The latest thing I did was remove the custom enchant and add an unsafe enchant for the glow effect.
  
• The code has generally been optimization a slight bit. You shouldn't notice any significant difference in performance however, since it was just slight.
• OnDisable trigger (reloading plugins for example) now closes all RPS inventories, not that it was a problem in the first place but it makes it so that it doesn't produce NPE errors.

After that you can modify the new config and change up what you need to. This config is more neater and is getting ready for a few new abilities in 2.5.0, including the INDIVIDUAL_MOB. I noticed that if I keep adding new triggers I didn't want to keep making new config nodes for the default on state, and so any time a new trigger is created even via the API the flag for that trigger will be automatically added in the config. The idea in 2.5.0 is that there will be a disabled_triggers section where sysops can add which triggers they do not want to show up in the RPS menu, let alone just disable the button.


Note: 2.5.0 will modify the permission names for triggers, it will be rps.button.flag_name_lowercased. For now keep it the same

• Fixed Stacktrace output when reloading plugin showing "permission already exists".
• Added try catch on update checker to prevent stacktrace if there is no connection to the host.
• Modified 'rps list [player] to allow return of offline players sensors.
• Added color prefixes in language node for negative, positive, and neutral messages as well as a language node for the chat prefix.
• Color code support on all language nodes, use alternate character code &, make sure if you are using it that you put the language node in single quotes.

Added:


Changed:
Nothing visually changed for end users besides whats been added above. I renamed a few of the java packages so github and still tweaking the new Mobs Behavior API I created in the last version that will help me in the long run add new entity triggers.

Next big update will be a rework of the menu as well as the config file. The desired effect is to be able to toggle basic stuff like what already exists, as well as other uncommon stuff like Monsters, Animals, as well as Group Types like Underwater, Nether, Undead. Lastly I want to be able to create a menu that you can specify a single type of entity, like only Pigs for example. Adding player names would also be an interesting concept.

The config file has horribly named keys like "defaultVehcileEntityTrigger", it will soon be broken down into types like default.triggers.vehicle

Added:


Changed:
Nothing visually changed for end users besides whats been added above. I renamed a few of the java packages so github and still tweaking the new Mobs Behavior API I created in the last version that will help me in the long run add new entity triggers.

Next big update will be a rework of the menu as well as the config file. The desired effect is to be able to toggle basic stuff like what already exists, as well as other uncommon stuff like Monsters, Animals, as well as Group Types like Underwater, Nether, Undead. Lastly I want to be able to create a menu that you can specify a single type of entity, like only Pigs for example. Adding player names would also be an interesting concept.

The config file has horribly named keys like "defaultVehcileEntityTrigger", it will soon be broken down into types like default.triggers.vehicle

Added

1. /rpslist [player] - Grab a players sensors, or your own. Player argument is optional.
2. rpslist permissions "rps.list" default true, and "rps.list.player" default OP for grabbing other players sensors.
3. RPS Limiter ranks/permission sets. Limit the amount of sensors a player can place, more info down below.
4. Vanish detection supported by SuperVanish, PremiumVanish, VanishNoPacket and a few more vanish plugins. Works alongside the same way as if a player was invisible with potions, Invisible Entities Trigger will still reveal you so disable that trigger permission.
5. New language node "lang_restriction_place_limit"

Whats Next?

1. Shift-Clicking Hostile/Peaceful mobs trigger will open a new menu where you can limit to specific Hostile/Peaceful mobs. Only wanting horses for example, you would Shift-Click Peaceful and select the horse, and only horses will be enabled.

rps.limiter Permissions in config file
After loading up the plugin, In the config.yml file you will find a node section "rps.limiter", in this section if a new config.yml file is generated you will see something like below, if not you will see a single default one generated.
This will create new permissions based off the names you give it. "rps.limiter.player" for example is the permission key for the first one, "rps.limiter.admin" for the other one. "default: true" is so that every starting player has the permission set to TRUE by default (duh), any limiter rank added without one will be given the default permission of OP (allowed defaults are: true, false, op, not op). The amount can be any integer, and -1 represents unlimited. If an amount is not specified it is automatically set to -1. Server OP's will always have unlimited no matter their permission level.
If there are no limiter "groups/ranks" in the config file players will be able to place unlimited sensors and a "rps.limiter.default" rank will be generated in the config file.

Note: Permissions are checked in descending order so technically you do not need to remove a smaller amount permission when adding a greater amount permission. (for people who have permission stores)

Without really understanding the plugin.yml key api-version I changed it to 1.14. Oopsies.

Should note that less than an hour ago I added Shift-Click ignore menu for building blocks next to/on top of the RPS, as well as Shift-Place hotkey. Read previous updates for more info.

When Shift(Sneaking)-Interacting(placing blocks, exc) the RPS menu will not pop up, this will allow players to build next to or on top of an RPS sensor while using the sensor as the clicked block.

As well I added a hotkey for placing RPS sensors with the users Copy data already pasted in the sensor. All you have to do is Sneak-place an RPS sensor for it to take on the settings of the last copied RPS sensor. This will make it go a lot faster then opening up the menu and and pressing paste for each sensor placed down.

The last versions of 1.13 and 1.14 changed getInventory#getName because in these latest versions an inventory can have multiple names now, so you have to get the name based off the view, complicated to explain but all I did was change 1 line of code ._.

I also while I was at it added the 1.14 mobs to the hostile/peaceful list. I really wish there was an enum that was sort of made so I didn't have to update this myself, oh well. The mobs added where Cat, Fox, Panda, Pillager, Ravager and Wandering traders

While working on another plugin I discovered an NPE. Not sure if it has always been there or just a new one with the 1.13 update, either way I fixed it. It had to do with getHand() returning null, which I didn't think would be possible but apparently it is.


I also added SQLite support, in config it is set to false by default, I would not recommend enabling it yet until I do more performance enhancements on it. For one the sensors in the YML file will not be carried over, and secondly it seams like it behaves a lot slower than the YML file.

Updated RPS to work for 1.13+. This version does not have backward compatibility with older versions and will not work for anything BUT 1.13 and above. Older versions of RPS will still support 1.8 - 1.12. Moving forward I will only be supporting 1.13 and above.


There was a lot of changes that needed to happen to support 1.13 that would break every past version, including changing how the torch turns off/on, as well as the particle effect being ran. Among updated the plugin to work with 1.13 I also did the following:

1. Added Drowned, and Phantom to Hostile Mobs List
2. Added Dolphin, Cod, Armor Stand, Tropical Fish, Turtle, and Egg, Salmon, Puffer Fish, and Giant to Peaceful Mobs lost.


I have done some basic tests however I may have missed stuff. If you find any bugs please let me know ASAP.

I just readded support for 1.8.8, something I neglected to do in the previously updated versions.

So not only was the torch breaking but I found out that the torch wasn't even triggering some stuff.


Don't worry, I tested everything before releasing this one. There shouldn't be another hotfix.

The way I thought I fix the previous deprecated method was actually wrong, and I tested it but I never tested the torch at an angle, I now have and found the error. Apologized for the hotfix again, I didn't even know that bug existed until I tried to make something myself.

In this update I finished the API as well as fixed some minor bugs.

• Added methods for button clicked, RPS created, RPS removed for the API.
• General code changes
• Removed last deprecated method (except for ShapedRecipe)
• Fixed range from having value of 0 if player tries to drop the button…
  
• Fixed GUI menu opening up twice each time which wasn't really a noticeable problem but nice to fix.

I uploaded the wrong compiled version which left an NPE in, apologies.

I did a few changes to make the API finally usable. The config will remove ghost sensors (the ID is the only thing saved in the sensors.yml file) that somehow are left in the sensors file. Still no clue how its happening but at least I have a way to find & delete them.


Last update was sort of required fix because it was a performance issue that I neglected to fix, this one was just side work because someone requested I finish it and future updates shouldn't be coming out this fast.

Previously to check if a chunk was loaded or not I would call location.GetChunk() however to my attention from user Nishh has informed me that GetChunk() loads the chunk. So instead of feeding the chunk through GetChunk() I will feed in the location which wont load the chunk.

1. Changed the way Entity Types where compared so that previous versions will be supported. 1.8 should be supported and previous others could but have not yet tested.

2. The parrot was accidentally previously added to the Hostile List and not the Peaceful list. No clue how I was able to fudge that up but its all good and fixed now.

3. Changed the event priority of block breaking so that WorldGuard has a priority over if the RPS should be broken or not. Not tested but in theory should work.

Added Native LegacyFactions support and did some general house keeping.


New Permissions:

• rps.button_lfactiontrigger, Perm to use LegacyFactions Trigger, default: true

New Language.yml nodes, should automaticly be added:

• lang_button_lftrigger: LegacyFactions Member Trigger
• lang_button_lf_lore: Click to have your LegacyFaction Members trigger the RPS.

On another note I removed my Location Deseralization Fix that was in the plugin for 8 months now redoing how I use Location in the sensors file. People who will run into a problem will be ones that haven't updated this plugin in 8 months and finally decide to. That being said I decided to remove the fix that checked sensors.yml on every load for invalid Location saves.

I also removed methods that where not being used however was left in the code in case I go back to it which I never needed to. I don't think it will increase performance but its a bit of house keeping on my part and this release was mostly done to support LegacyFactions.

I had to grab an older version of spigot just to test this, I assumed just modfying the string I was passing to test would work but I guess not. Now there should be no problem. Tested on versions that have multiple periods (1.11.2) and ones that don't, 1.12

Appologies, did a quick update before taking a nap and didnt think about multiple pointer versions, also had the wrong version number in the plugin.yml file

Prior to this update I just added new entity types to the list assuming people would either update Spigot or not update my plugin, but contrary to the belief I had to start adding support at some point. This update adds Entity Types to the mob lists only if their version actually has those entities, preventing any errors being thrown.

After testing the previous release I did not restart the server, I didn't think I would have to. A line in my code was in the wrong area producing a null pointer which broke the rest of the file preventing torches that have existed prior to a restart from not working in 2.2.3

• Added Vindicator, Evoker, Vex, Illusioner, Elder Guardian, Stray, Shulker, and Husk to Hostile Mobs list.
• Added Donkey, Llama, Zombie Horse, Squid, Polar Bear, Mule, and Parrot to Peaceful Mobs
• Added Iron Golem to Hostile Mobs to differentiate them from villagers.
• Added permission node 'rps.menu' for permission to use the GUI Menu, defaulted to TRUE.
• Added use-particles to config to tell the plugin to use the purple particles that differentiates it from a regular redstone torch, default to TRUE.

Notes: Categorizing mobs have to be manual since Bukkit has no feature for that. However Mobs have different categories besides just Peaceful and Hostile. There are Passive, Neutral, Hostile, Tameable, and Utility. I will make the 3 extra categories on a future version of RPS.


I understand this update is very soon compared to previous update however I promised I would add the menu option asap and the other stuff just sort of happened. Updates from now on should be weekly at most and I will sort out a nightly build page.

I recieved some outside help in understanding the problems underlying the performance issues and fixed them. There was java math functions I was using constantly which was not needed, I was doing a location check for the range twice, and I didn't initially check if the chunk was loaded in the first place. All of this has changed and I would like to know if anyone sees any difference.


I also added WITHER_SKELETON to the hostile list which it wasn't in.

The question mark says I need people to test the significant performance part. I have only been able to test this with myself, 1 person, BUT in theory I have done 2 steps to make the performance better.r I was able to reduce the Bukkit Schedulers from 1 per RPS torch to just 1. I was also able to change how entities are found by not looping through each one but only to the ones within range.

If an RPS is looking through a lot of entities, specifically the entity list you have enabled on the RPS, and during this loop a player moves from one world to the next it will sometimes cause a IllegalArgumentException Location can not be measured error. This has been fixed in this version.

1. From the previous release I made a mistake with a NPE in the custom enchantment glow, it doesn't fix the glow issue we had earlier but it doesn't cause an NPE so there is that.

2. I added an event cancellation if the user interacts with an RPS torch, this is if they had any number of items that would cause interactions, block placing, water placing, item usage, exc.

1.11 only breaks the particles from the RPS torches which this fixes.

1.11 also breaks the enchantment of the RPS and the buttons inside of the RPS menu, I have not fixed this yet and have not found a solution as of right now. Maybe its still being worked on hence why 1.11 is not officially released yet, who knows? I'll try to figure it out later on, as of now here is a stable version for 1.11 with the enchantment glow bug.

The following language nodes have been added:

• lang_command_consolesender
• lang_command_invisibleenabled
• lang_command_invisibledisabled

The following default language nodes have been modified because of a grammatical error:

• lang_button_gp_lore
• lang_button_tt_lore
• lang_button_vt_lore
• lang_button_pt_lore

1. New command /ignorerps is a toggable command to enable/disable the invisibility effect that the existing permission rps.invisible would already do.
2. rps.invisible has changed from default: false to default: op

1. Fixed bug that was preventing plugin from working and spamming console on all versions of 2.1.4 based off order of methods.

2. Added Vehcile trigger as well as its corresponding language and permission nodes.

3. Added Profile trigger as well as its corresponding language and permission nodes.

1. Added lang_main_itemname language node for the RPS item name.
2. Added an update-checker setting in config.

Decided to finally add plugin metrics as well as made it so the reload command works on all configurable stuff. Prior it only worked on the general config itself.

Thought it would be cool to have the feature to easily copy over settings in case your making an intricate build. I myself have on occasion wished it existed so I granted my own wish.

I am going to change the way I display debug text so that only I can see it so there is no way to accidentally leave any in the future.

When I made a config file of all the strings in the plugin for users to modify I forgot to change how permissions where checked. Originally they where checked by checking the items name, so rps.button_owneronlyedit made sense when the items name was Owner Only Edit. I would do some string manipulation and end up with owneronlyedit being compared to owneronlyedit.

Well now I had to figure out a way to link the pre-made permissions to objects that can be renamed via the language.yml config. So I did. Anyone who had modified the button names already may have either not noticed it yet or did not report the bug.

Logically Owner Only Trigger made no sense. If I wanted just the owner to trigger, I could have just set all the other triggers to false. So that's what I did.
I changed Owner Only Trigger to just Owner Trigger. The language nodes have been changed and after the first load the new ones will be added and the old nodes deleted.

I've been thinking about adding a 3 step toggle instead of the current True False, maybe True, False, Inverted. This will be like a Boolean NOT. If I was to enable Player Entities but set Owner to NOT, it will trigger for all players except for the owner. That's the goal at least, maybe a possibility within the next update.

I have came to realize I better do this now than never. I have cleaned
up some unholy mess that I made early on that I had at some point
planned to clean up, and that time is now. However it had no effect on
the performance of the plugin, just makes it easier in the future to add
new things.

1. Removed ownerOnlyTrigger setting in config, now its a flag in acceptedEntities. Comptabile with existing configs, no need to do anything. Just felt like it needed to be done at some point so sooner or later is better.
2. Continued code optimization. Working on maybe an API for other developers to hook their own triggers in. I also plan on adding some myself.

Accidentally released an untested update, and turns out it had an error. Also left some debug text in.

Accidentally released an untested update, and turns out it had an error.

With the new Location Deserialization fix I made, I forgot the check if the sensors file even existed producing an error on first load.

I had to change the way Locations where stored and read because of Multiverse support. I tested this constantly after finishing it with no bugs, so here is to hoping!

Thank you @Apbreck for mentioning the Owner Trigger bug.

I also added a version checker seeing as I am actually updating the plugin lately. Didn't think I would need one.

button_owneronlyedit was spelled wrong in the plugins config making button_owneronlyedit not exist, hence not being able to toggle for non-op players.

I also added sound effects to when buttons in the GUI menu are pressed.

Sort of progressing into making the plugin more pretty/presentable. Adding sound effects to the button pressing will be next on my list.

• Purple dust particles now emit from RPS Torches when active so people don't confuse them with normal Redstone Torches.
• Added more default config options for all trigger buttons. Reload server with new jar to get the new plugin defaults added to the config file.
• Added version check when typing out /rps.

No bugs reported or found by myself since previous release so I take that as no bugs? Hopefully... in the meantime here are some updates.

There are permissions now set per button so that owners can set up permission shops or just use any existing plugin to reward modifiers or just use the permissions to disable modifiers you don't want players to have control over.

Another permission that's default to false (rps.invisible) will make any user with that permission undetectable against the RPS's.

Another thing added was a give command, using /rps give <user> [amount].

As well as a new Invisible Entities trigger that lets you decide if invisible entities should be able to be triggered.

When changing my worlds name to world2 to test out a different plugin, RPS was spewing out a ton of errors. I forgot to check to see if the location given was null, because that world ("world") was not loaded. Now it does.