New GM System

[SkzBR]

I think it would be better to have the commands and configs with true or false setting in the groups.

That way we could revoke a permission from a inherited group.

Example:

gamemaster {
 permissions {
can_trade: true,
// ...
 }
 //...
}
supporter {
 commands {
autotrade: true,
iteminfo: true,
// ...
 }
 permissions {
can_trade: false, // overwrites 'true' of the gamemaster group
// ...
 }
 inherit: gamemaster
}

True. And all not mentioned commands and permissions are automatically true or false? Or true for group_id = 0(user?) and false for group_id != 0 (GM?)...

I think it would be better to have the commands and configs with true or false setting in the groups.

That way we could revoke a permission from a inherited group.

Example:

gamemaster {
 permissions {
can_trade: true,
// ...
 }
 //...
}
supporter {
 commands {
autotrade: true,
iteminfo: true,
// ...
 }
 permissions {
can_trade: false, // overwrites 'true' of the gamemaster group
// ...
 }
 inherit: gamemaster
}

I was thinking on something like this, but i think its harder to implement this in current eAthena design.

[lekkereten]

what about pc_isGM(sd) / getmglevel() ?

[Jonne]

what about pc_isGM(sd) / getmglevel() ?

int pc_isGM(struct map_session_data* sd)
{
return sd->gmlevel;
}

Returns the level. Could become the group ID.

[xazax]

With this system pc_isGM and such functions would make no sense. Same for returning group ID.

The system should work somehow like this:

On read, build the groups ( based on the inheritence, configs ). This would creaty a struct with several bitfields ( and command list?, or commands should have group list? )

And checks like pc_isGM(sd) > battle_config.any_warp_GM_min_level would be replaced by something like pc_isgroupcapableof(sd,ENUM_VAL) or pc_sdcanwarp(sd).

[Toshiro]

On read, build the groups ( based on the inheritence, configs ). This would creaty a struct with several bitfields ( and command list?, or commands should have group list? )

Since there needs to be a way to revoke the ability to use the command for certain groups (in case it is inherited by a group) there would most likely be a more complex structure than just a group list.

[Jonne]

On read, build the groups ( based on the inheritence, configs ). This would creaty a struct with several bitfields ( and command list?, or commands should have group list? )

Since there needs to be a way to revoke the ability to use the command for certain groups (in case it is inherited by a group) there would most likely be a more complex structure than just a group list.

What do you mean? It should still be possible to reload the system. So if I change one groups rights and reload, all inheritances are reloaded as well. If you want commands like @adjgmlevel, well they need to step aside.