Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requests for VoxelGuest #3

Open
DukeVindzor opened this issue May 31, 2012 · 8 comments
Open

Requests for VoxelGuest #3

DukeVindzor opened this issue May 31, 2012 · 8 comments
Assignees
Milestone

Comments

@DukeVindzor
Copy link

Hi here is some requests I think could help making voxel guest more flexible:

  • Have a possibility in config to decide if you want VoxelGuest to use displaynames in messages. Example: If displayname=true VoxelGuest will use displayname for messages like /who, all asshat related, joining and leaving messages and so on. (If displayname=false VoxelGuest will do as it does now and use the real username. This is a needed feature for roll playing servers.
  • Adding the possibility to turn off join/leave messages and /who for servers who need something special with these messages from another plugin.
  • This last request is not that needed and I guess it will be a lot of work to change, but I will just tell you and you decide. Using permissions for regions and cubicle makes the permission configs far more messy than it needs to be. I mainly think of when a player is permitted to a cubicle or region (cause whenever a player is permitted to a region or cubicle he/she will get a node about that in permissions). If it was possible, maybe rather have the permission for a cubicle or region in the VoxelGuest/players/.prop. If you did that, the cubicle system could also be used as the greatest guest management plot system on bukkit. As now, if you use it for guests you will have loads of nodes in your permission for players you really don't need there.
@itsjoekent
Copy link

Were going to have Baseball435 work on one of these, in the end we will try our best to fulfill this. Thank you for the suggestions!

@itsjoekent
Copy link

Baseball will not be doing these. I might do some myself, they will get done though!

@DukeVindzor
Copy link
Author

Sure no problem, no hurry, really

@itsjoekent
Copy link

Okay, read this over.

Point 1: VoxelGuest at it's current state is server administration. Admins need to know actual player names, not fake names that they might not know. There are many plugins that can take care of this issue.

Point 2: Once again, VoxelGuest isn't meant for role play. There are plugins made for that.

Point 3: Which nodes in particular do you believe are not needed?

@DukeVindzor
Copy link
Author

Point 1: You are correct, admins should have the real name, however I only thought of using displaynames in messages coming up in chat. Admins will be able to see who it is due the the check command that come with all dispalyname plugins. Also, I suggested giving admins a choice to use it so servers having problems not recognizing player could have real names.

Point 2: I understand, my suggestion were only meant to make the plugin more flexible and fit for more servers :)

Point 3: It is not the permission node by the plugin that is the main cause, but when a player that isn't in the permission config get a node for cubicle or region, it creates a whole player node. Like this:

Player123:
permissions:
- voxelguest.cubicle.interact.1

Which is unnecessary cause this player have no other nodes and doesn't need to be in the config. 3 lines might not seem like much, but we can multiply this by the number of players getting cubicles and regions, it would takes quite some space.
All the nodes are needed, I just think they shouldn't be in permissions.

@itsjoekent
Copy link

Point 1: If you need it for chat we can already do this via iSay. Guest has no chat functionality, and does not utilize the plugin either.

Point 2: I know, and we love suggestions! I'm just trying to maintain the standards psanker left

Point 3: Cubes have many permission nodes, and many are player specific. What your seeing here is the yml file for players, not ranks. This form of permissions is used when players need certain permissions that people in their own rank shouldn't have. The format is part of YML. We cannot change how it works. It is a very space specific language (A single tab could break an entire file).

What would you suggest for a better system?
Server owners hate using our .txt files, permissions is made for this, permissions is built into the API, making it easier to write code for it, and I don't see why a large file is a problem?

@DukeVindzor
Copy link
Author

At point 1 I just mean that the plugin uses displayname in the chat for messages like joining and leaving. But if you don't want do do this, you could just make is possible to disable the custom joining, leaving and kick messages. That way if a server want to have other messages with for example displayname, they just get another plugin and turn of the messages from VoxelGuest.

At point 3; As I said in the start, I understand that would be hard to change and it is only to make permission look cleaner. I like it like this cause I get a better overview on the permission for any bugs, problems or mistype. For suggestion of what file to use, I would suggest a system like WorldGuard, (or maybe like this, guess it is a txt file..):

"Cubicle-name":
Owner:
Co-owners:

"Region-name":
Owner:
Co-owners/groups:

But once again, I don't want you to trouble with this too much. I take no for a no and fully understand if you feel these suggestions as unnecessary.

@itsjoekent
Copy link

Your option could work, but it would require a lot of re-coding to be done. Maybe when VoxelGuest is remade for the mod API, we can include this idea.

Thanks for the suggestions though!

itsjoekent pushed a commit that referenced this issue Jan 27, 2013
Just adding extra mob spawning stuff
@ghost ghost assigned nristock Dec 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants