Jump to content

Some suggestions for groups (script commands)


Rafael

Recommended Posts


  • Group:  Members
  • Topic Count:  3
  • Topics Per Day:  0.00
  • Content Count:  36
  • Reputation:   2
  • Joined:  07/08/12
  • Last Seen:  

I think it would be a good idea to add some commands to work with groups. When we had levels instead of groups, it was so much simplier... but working with groups is really complicated, since we never know when a group exists or not. If we try to change a player's group to one that does not exist, we can see that it doesn't exist just checking his getgroupid() after the change, but the player will still get an error in his chatbox saying the group doesn't exist. If we change it succefully, he gets two messages saying almost the same thing: your group has been changed (I'm talking about @adjgroup).

Since rAthena doesn't use the simpliest system of levels anymore, I hope your development team can make some good commands for the new system. So scripters can take some advantage of this change (for now, this change just SUCKS for scripts, despite it's really great for organization in conf path).

What I'm suggesting:

1. Remove one of the two messages the players receive when their group is changed successfully using @adjgroup OR...

1.1. (Better idea) Create a script command (that doesn't produce any messages) for changing temporarily the group of a player (similar to @adjgroup).

Why? The old @adjgmlevel didn't produce messages in the target's chatbox. So it was a nice atcommand to be used with the command "atcommand". But @adjgroup produces a lot of annoying messages, so it needs to be used very carefully...

2. Create a command that lists all the groups, sorted by id. It returns the amount of groups and creates at least two arrays: $@groups_id[], $@groups_level[]. A third array could be $@groups_name[], but I almost sure it isn't necessary. And/or create the two commands below (or at least the second one):

2.1. groupid_exists(group_id): tells you wether a group exists (returns 1) or not (returns 0).

2.2. getgrouplevel(group_id): returns the level of a group. Returns -1 if the group doesn't exist (with this command, we don't really need the command groupid_exists).

Why? In the old system we knew that all levels from 0 to 99 just existed... and maybe a higher level would also be not a problem. We knew level 0 was the default. We also knew that levels 20+ were used for Game Masters, levels 1-10 for special players (usually called VIPs or donaters), and levels 11-19 usually had no use (since level 10 and levels 11-19 had the same commands, so there was no need for giving a player level 11 or higher). So, that was all we had to consider in our scripts...

But now, using groups, all we know is that group id 0 is the default group, group id 1 is used for special players, groups 2-4, 10 and 99 are used to Game Masters. But we know NOTHING about custom groups, since they can't follow any pattern anymore. We don't have an interval of levels, since level 0 is for players, and any level above 0 is for GMs... all we have are the group ids, that say NOTHING! A higher group id could still be a special player's group, and a lower one a GM's group (it couldn't happened with level system). Working with this "blindness" is really hard for scripters.

3. This isn't really necessary. The commands in suggestions 1-2 are enough, but this is just an extra feature... So, if you have time:

3.1. group_create(group_id, group_level, inherit="", name="") - creates a group (if it already exists, does nothing). Inherit tells all the groups inherited by this one, separated by commas.

3.2. group_togglecmd(group_id, command_name, enabled) - enables or disables an atcommand for an existant group.

3.3. group_togglepermissions(group_id, permission_name, enabled) - enables or disables a permission for a group (maybe we could use numbers for the permissions, instead of names, and add the constants to const.txt).

Why? Since a group needs to exist so we can use it, a script that works directly with groups becomes limited by the amount of groups in confs/groups.conf file. Removing this limitation would be really nice to scripts that make admins' life easier, despite it's unnecessary. The admins should know how to create groups by themselves.

If you do not understand something, please let me know me and I'll try to explain it better. English isn't my native language and I've never practiced it, so sorry for any mistake.

Thanks for reading =D.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...