ulx toolallowgroup/tooldenygroup

[atomicspark]

Just like the ulx toolallowuser/tooldenyuser, I think we should be able to allow and deny tools by groups. This way we don't have to input every user. Also toolallowuser/tooldenyuser, seems to only work with their names. This would be bad if they joined with a different name. Group permissions ftw!

[Megiddo]

It denies it to their player object, so if they rejoin it's cleared.

Well, I'm working on the new UCL string access, and this seems like a good use for it. Should be a cinch to implement.

[atomicspark]

Hmm. Maybe you could put the command in the users.txt and groups.txt. This would work exactly like the allow and deny for ULX commands. Benefits? Well all the permissions would be in these two files and they would save between server sessions. Also permissions would be tied to groups or users id, instead of just player objects).

Example for groups.txt (I only use user.txt for immunity, but I'm sure you could figure out how it will look for users.txt):

Code: [Select]

Out{
//Other groups omitted for example
    guest{
        allow{
            "1"        "ulx votekick"
        }
        deny{
        }
        toolallow{
            //Only needed if something is globally omitted.
        }
        tooldeny{
            "1"        "spawn_tool" //VMF Suite spawn tool. Name is of the Lua file. Just like how ulx tooldeny works.
        }
    }
}

[Megiddo]

With the new access strings we can just have it setup like this...

Code: [Select]

Out{
"[ULX]Megiddo"
{
"id" "STEAM_ID_LAN"
"type" "steamid"
"groups"
{
"1" "superadmin"
}
"deny"
{
"1" "tool_welder"
]
}
}


[atomicspark]

Ah cool. So allow and deny can be universal. Very nice. I assume it's the exact same for groups, yes?

[Megiddo]

Correct

[Kingtendo]

Can the access strings be used in ULX 3.11 and Ulib 2.05 ?

[spbogie]

No, we've done some major reworking of the internal components of the UCL for the next version. In current released versions the access strings only apply to commands.