Residence 3
Planned feature list of Residence 3:
- Essentially a rewrite - the Bukkit API has changed over time and Residence has been "fixed" as necessary. It's time for a clean-up.
- Vault will be required and direct support of the various permission and economy plugins will be removed.
- Spout support will be stripped away, but if someone wants to make an add-on to provide Spout support, an API will be provided.
- The new code will be modular in design, and the modules will use the API provided to developers, providing a reference example.
- As hinted at, a new API for Residence will be provided though as much backwards compatibility as possible will be provided for the existing developers. It will also include JavaDocs, for an easy breakdown. This will be updated whenever a new jar is made.
- SQL support.
- Better permissions control.
- A full in-game command rewrite, that will overhaul the current configuration process.
Leave a post if you think something should be added. We continue to read these comments, but please try not to repeat posts.
Residence 3 has been scrapped, instead T00thpick1 has spent countless hours cleaning up the 2.x code and adapting a seperate version of Residence that will support mySQL solely, from then on we will continue to update both versions, Although the SQL version will have new features implemented in the future while the flatfile version will merely just be maintained as is.
Add Command flags :)
Implement the melt flag
Please, implement a flag that if a person enter in the residence, the inventory is saved, and cleared, if the person leave the residence, the old inventory is given and the new of the residence destroyed.
Thanks following the residence project!
a "shear sheep " flag would be cool :D
Spout GUI :)
Would be kinda cool if you could make it an option to keep a players residence chunks always loaded on the server.
@josip1
I am considering a GUI, but not using Spout. It has too many incompatibilities.
per world configuration would be amazing
@decebaldecebal Thats actually a pretty good idea, would keep the config size down and make it much more readable, while still keeping functionality.
@smbarbour You could build simple Java GUIs that run outside of minecraft, and connect to the plugin over some other port. Would possibly make managing large servers easier. Maybe when I get a little free time I will play around with that. :)
<<reply 694528="">>
I can use Minecraft GUIs in a client mod that would listen on Packet 250 (the official Custom Payload packet). With a simple GUI command set, it could be usable by a number of other plugins that so desired.
As for the per world configuration, that's definitely planned, and I'm also planning proper database support using the Avaje ebeans implementation that Bukkit provides.
Enable or disable default messages when enter or leave an area (in config)
UTF 8 Support in Languages (Maybe it's awalibe now but i'cant use it)
Admins can make regions what collides with other resdences.
If a player buy a residence and doesn't renew his region the residence rollback itself to it's original status for exapmle if a player buy a server land and build a house on it and he doesen't renew his residence the house miss and anoter player can buy it again and build on this land
Better permission support (more permission nodes)
Option for MySql database?
Online Gui with a server map and players can select to point on the map and they get their own residences between the 2 point. The map show the protected zones for Admins and alrady existing residencies where players can't get a residence. Admin's can accept the players request for new residencies and an option to disable that the Admin need to confirm the player's request. (Maybe with dynmap?)
Admins can write a short description about residences with /res description (residence name) or /res desc (residence name if they arent't in the residence) or in /res info
I don't have more idea now. :D Sry for grammar mistakes.
@tomori_peti
Residence 3 will use a database instead of configuration files (though there will still be some file-based configuration).
UTF-8 support will be possible with the move to the database (YAML doesn't support it)
MySQL will be possible since it will be using Bukkit's Avaje.ebean implementation (you configure it in the server's bukkit.yml - the default configuration is SQLite)
More permission nodes are planned.
Residence descriptions are a good idea.
I have 3 more idea:
Easyer way to add "Members" to residence now i need to type at least 3 command /res pset playername build true /res pset playername use true ... so i think that is a bit too difficult to add "Members" to their residence. command: /res addMember (residencename) (playername)
Members:
They can do all of the basic things but they can't sell, modify flags and delete the residence.
Ability to remove selected areas from residence
Friends: Player can chosse friends with /res friend playername. The friends can build and can use everything in the player's residence. The friends works like Members whit a big difference, they have permissions for all of the player's house who set them to their friend but they can't open containers (if this set to true in config).If somenone set someone as friend a message pop up like this: "Player1 set you to his friend list, do you accept the request? And if he accept it another message pop up:Do you want to set Player1 as friend?(A config for this: Autosetfriend: true/false [description: if someone set another player as friend it will automaticly set him to the requested player's friend if he accept it] )
A third list what allows specified blocks placement in residence (Command: /res lset <residence> [blacklist/ignorelist/whitelist] [material])
Good Work for Residence 3! :D
@tomori_peti
I will definitely add more options. One of my goals is to make managing a residence quick and easy. I'm not sure on the exact implementation, but it may be in the form of /res pset <player> trusted true, or it could be in the form of /res trust <player>.
Also, I may change the command structure around such that the commands automatically use the residence you are in unless you prepend the arguments like "/res remote <residence> trust <player>" or perhaps also requiring something when in the current residence like "/res here trust <player>"
I'm also considering a Neighborhood superarea system where a group of players have rights with individual residences for the players. The residences within would inherit certain permissions from the Neighborhood by default (such as use and maybe container). The flags themselves may be altered as well to "door", "switch", and "interact" with per block permission (i.e. You can use this furnace, workbench, and chest, but not these chests over here.)
I think you missed some idea collect them.
Online Gui with a server map and players can select to point on the map and they get their own residences between the 2 point. The map show the protected zones for Admins and alrady existing residencies where players can't get a residence. Admin's can accept the players request for new residencies and an option to disable that the Admin need to confirm the player's request. (Maybe with dynmap?)
Admins can make regions what collides with other resdences. (That's a bit irritating in residence 2 when you want to make a region but you get a message: it collides whit another residence...)
A third list what allows specified blocks placement in residence (Command: /res lset <residence> [blacklist/ignorelist/whitelist] [material])
Ability to select 2 points in residence and remove the protection between them.
New idea:
/res select showregion
When you do this it makes a box of your region out of maybe black wool or something then removes it after 10-15 seconds.
@josip1
with 1.3 the minecraft client will support server to client updates, adding new blocks etc. It will also be easier to mod the client. With Residence 3, a gui mod will be available.
/res addowner would help.
<<reply 703323="">>
This would be cool. So you don't have to set 10 flags for your good friends.
Is there any ETA? Any source code?
Great that you took over this plugin. Former maintainers got kind of... lazy:)