When you @yahgiggle say...
/cp unlock id = unlock the contents of the chest, note if your chest is inside a protected zone the contents will still be locked as before
Does this mean that there is no real way to make a "community chest" (unlocked) in a protected area that any player can access with out having to add all players individually? And still have the area/room and the chest itself protected?
Ah, ok. Did not know that the world DB did not have the "Owner".
I would NOT then:
add an update that if you open a chest and no one owns it, it becomes yours
As Minotorious mentioned, I would think unscrupulous players would go around claiming all the old chests they could find...
I see two options, First what Minotorious said:
Could you maybe add a small scan in the OnEnable() method to register all existing chests and then cross reference with the area ownership database? and then of course all chests not in areas should be ignored.
OR...
Just tell players that they should create new chests for there existing ones and move the contents of their old chest(s) to the new ones.
As for claiming "shack/dungeon chests", we would be no worse off then the way we are now.
hmm that way we can also claim the shack chests
hahaha
on a more serious note now, I think on a server that could be very very dangerous. Just imagine the owner uploading in and then someone going around claiming all the chests before the other players had a chance to log in and claim them.
Could you maybe add a small scan in the OnEnable() method to register all existing chests and then cross reference with the area ownership database? and then of course all chests not in areas should be ignored.
Actually, would it not be possible to query the existing "world database" to find the current owner of all chests, add them all as "locked" in the plugin database with the appropriate owners?
Never mind on the chest ID question... Installed the plugin in SP and I see that the plugin tells you when you open chests.
Can "Owners" of chests lock their existing chests?
This looks nice!
Questions:
How does one determine their chest ID?
Is there a way to "lock" the existing chests in the world?
I haven't seen anyone doing an Area Protection plugin. Is this because the Area Protection capabilities are going to be incorporated into the game?
yes my local wp I can delete, my problem is to delete Global WP on the shared list, that stayed there from the old map.
IMO, The Global WP capability should either 1) Be manageable somehow by only Admins 2) Be removed and replaced with capability of pass a personal WP to another Player 3) Be removed all together.
The Teleport plugin, IMO, is better suited for "World/Global Teleport Points".
NICE! The rotation with the cons while "locked" is a big help!
What is the plan for when the new construction system would be worked. Not actual time/date, but rather where it fits with the other update plans? Is the a place to see a basic plan (not in concrete) for what updates might include certain "features"?
Not sure if I just haven't discovered how, but it would be nice to be able to rotate pnb's while in "Manual Placement" mode (Ctrl Key) like you can do when placing a blueprint. the Arrow/UpDn keys do position (as is now) and Shift Arrow/UpDn keys do rotation. Currently, you have to exit "Manual Mode" to change rotation and then you loose your positioning.
What is the ID of the new "white wood"? I'm not sure I'm seeing it? Is it as white as the "white plaster" (ID: 143)?
Ok, I am officially confused. I thought the commands "/selectarea", "/select area", "/select" and even "/selectportal" would all be 4 separate commands and the plugins/scripts would only respond to their corresponding one.
coders should check there commands to avoid conflict, i checked and the commands had not been used so i used them, this was to keep the script as simple to use as possible.
This is feasible even down the road when there are maybe 100's of plugins? If I were coding, I would rather just use something that I'd be pretty sure is unique, but that's me.
Say I write a plugin 3 months from now and don't take the approach of using a unique name for selecting from a player list (like /playerselect) and I use /select. My plugin will respond with a list of players over the top of your plugin kicking off the "selecting tool" and actually mess up both the plugins. If you had originally used something like "/bpselect" that would not happen.
I am not so sure: each plug-in listening for player chat commands is notified when a chat command is issued. And each plug-in will (presumably) check if it is a command it is interested in.
So, each plug-in recognising a "/select" command will do whatever that command means to it.
That is what I'm getting at... You will have two plugins responding to the command when you only expect one to respond. If the plugins use "unique" commands, like "/we select" or "/bpselect" (block placer) or "/apselect" (area protection), then you won't run into the potential issue of multiple plugins responding to the same command. Same with "/delete", IMO, should be something like "/bpdelete" or "/bp delete", etc.
I thought the command for BP plugin is "/select area" (with a space). While the one for AP is "/selectarea" (no space). Shouldn't the only plugin responding be the BP plugin?
plugins don't get left hanging they are much like a book, they read down every page till they hit what they are looking for so in aother words when you type /select the program will search all the scripts till it finds /select and then run that line of code then stop till the next command has been asked say/delete con
Hmmm. So only one of the plugins will respond to the /select command? Which one? What I'm getting at is if someone else does a plugin using the /select command. It seems that coders should pick "non-generic" commands to avoid conflict.
Are there any plans to "port" this over to a Java Plugin? Have I missed it in the plugins?
/selectarea or /select or /select area <---- are somewhat used by other things but they all do the same thing it would not matter if the code for select read from the protection script was then used to /delete con or what ever, you can even use a blueprint in your hand to select the area and then use the chat to use /delete con
I still see this as an potential issue. If two plugins/scripts are both using say /selectarea and then only one of them gets a command to use the area selected (like /delete con), the other plugin/script is left hanging waiting for what to do with the selected area. Not sure then what would happen if you do another /selectarea and do like a /createarea, would possibly the AP script use the originally selected area and now the BP plugin is left hanging... etc.
Seems like it would be very important to use definitively distinct commands. If something like "/bp select, etc." is difficult, would using something like "/bpselect (no space)" be easier?
Love the idea of scalable doors, but a "workaround" for height anyway is to put the door partly underground.
A little late here giving a response on the latest hotfix(s), but...
It indeed appears that the dungeons in our "old world" are fixed!
AWESOME @red51 !!
Thanks
