1. Sign up for news, events and more!

    You're currently visiting the official DarkRP Forums as a guest. Sign up now to participate in our community and we'll let you know when we have news.

HELP: Staff On Duty job won't allow Superadmin.

Discussion in 'DarkRP Modding Questions & Help' started by [CR] Trigger, Sep 2, 2017.

  1. [CR] Trigger

    [CR] Trigger New Member

    So basically, as the title says, on our server we have got many staff ranks able to use the "SOD" job, however when someone with Superadmin privileges attempts to use said job, it says "This is a staff only job" which is our "CustomCheckFailMsg". All can be seen below;

    TEAM_SOD = DarkRP.createJob("Staff On Duty", {
    color = Color(207, 20, 20, 255),
    model = {"models/player/combine_super_soldier.mdl"},
    description = [[You are Staff on duty. Do not AFK within this role.]],
    weapons = {},
    command = "sod",
    max = 0,
    salary = 349,
    admin = 0,
    vote = false,
    hasLicense = false,
    candemote = false,
    category = "Staff",
    customCheck = function(ply) return CLIENT or table.HasValue({"rtrialmoderator", "rmoderator", "rtrialadmin", "radmin", "senioradmin", "headadmin", "headofstaff", "senioradmin", "dtrialmoderator", "dmoderator", "dtrialadmin", "dadmin", "ctrialmoderator", "cmoderator", "ctrialadmin", "cadmin", "csenioradmin", "trialmoderator", "moderator", "trialadmin", "moderator", "admin"}, ply:GetNWString("usergroup"))
    end,
    CustomCheckFailMsg = "This is a staff only job!",

    If you're able to help, then thanks. Any input is helpful as of this stage.
     
  2. Ganged

    Ganged New Member

    You never wrote "superadmin" in the custom check, I see you wrote senior admin twice.
     
  3. Sir Klutch

    Sir Klutch Active Member

    Using network strings and table.HasValue to retrieve a players user group is a terrible habbit.
    Code (Lua):

    customCheck = function(ply)
        return CLIENT or ply:IsUserGroup("rtrialmoderator") or ply:IsUserGroup("rmoderator") or ply:IsUserGroup("rtrialadmin") or ply:IsUserGroup("radmin") or ply:IsUserGroup("senioradmin") or ply:IsUserGroup("headadmin") or ply:IsUserGroup("headofstaff") or ply:IsUserGroup("senioradmin") or ply:IsUserGroup("dtrialmoderator") or ply:IsUserGroup("dmoderator") or ply:IsUserGroup("dtrialadmin") or ply:IsUserGroup("dadmin") or ply:IsUserGroup("ctrialmoderator") or ply:IsUserGroup("cmoderator") or ply:IsUserGroup("ctrialadmin") or ply:IsUserGroup("cadmin") or ply:IsUserGroup("csenioradmin") or ply:IsUserGroup("trialmoderator") or ply:IsUserGroup("moderator") or ply:IsUserGroup("trialadmin")  or ply:IsUserGroup("moderator") or ply:IsAdmin()
    end
     
  4. Ganged

    Ganged New Member


    What you did is a huge mess. why do you have to write IsUserGroup over 10 times? this is simply a waste, there's no such thing as a terrible habit in what he did, he simply didn't even write superadmin.
     
  5. [CR] Trigger

    [CR] Trigger New Member

    Thank you for the input @Ganged I didn't even realise personally, much appreciated.

    Also @Sir Klutch , the method in which you had previously written would have been highly tedious, hence why I went with the "bad habbit" version instead, however, within coding as Ganged had said, there is no such thing as a "bad habbit".
     
  6. Holy admin ranks Batman o_O
     
  7. (FPtje) Atheos

    (FPtje) Atheos Main Developer Staff Member

    table.HasValue is fine with the couple of dozen things people generally put in there and how often the customCheck function is called.
     
  8. Sir Klutch

    Sir Klutch Active Member

    Still a bad habit, regardless. I am not saying it will cause any issues.
    --- Double Post Merged, Sep 2, 2017 ---
    O(1) > O(n) (Not enough to really matter, but it's still good practice)
    https://en.wikipedia.org/wiki/Time_complexity

    *face to keyboard*

    I wrote that at like 7 in the morning in a rush to go to work. Here;
    Code (Lua):

    -- Here you go, O(1) instead of O(n)
    --marginally faster than table.HasValue and much cleaner.
    local job_usergroups = {
        ["rtrialmoderator"] = true,
        ["rmoderator"] = true,
        ["rtrialadmin"] = true,
        ["radmin"] = true,
        ["senioradmin"] = true,
        ["headadmin"] = true,
        ["headofstaff"] = true,
        ["dtrialmoderator"] = true,
        ["dmoderator"] = true,
        ["dtrialadmin"] = true,
        ["dadmin"] = true,
        ["ctrialmoderator"] = true,
        ["cmoderator"] = true,
        ["ctrialadmin"] = true,
        ["cadmin"] = true,
        ["csenioradmin"] = true,
        ["trialmoderator"] = true,
        ["moderator"] = true,
        ["trialadmin"] = true,
        ["moderator"] = true,
        ["admin"] = true,
        ["superadmin"] = true
    }

    TEAM_SOD = DarkRP.createJob("Staff On Duty", {
        color = Color(207, 20, 20, 255),
        model = {"models/player/combine_super_soldier.mdl"},
        description = [[You are Staff on duty. Do not AFK within this role.]],
        weapons = {},
        command = "sod",
        max = 0,
        salary = 349,
        admin = 0,
        vote = false,
        hasLicense = false,
        candemote = false,
        category = "Staff",
        customCheck = function(ply)
            return CLIENT or job_usergroups[ply:GetUserGroup()]
        end,
        CustomCheckFailMsg = "This is a staff only job!"
    })
     
    All I am trying to say is; GetUserGroup and IsUserGroup would be better...
     
    Last edited: Sep 3, 2017
    Richard Hammer likes this.
  9. (FPtje) Atheos

    (FPtje) Atheos Main Developer Staff Member

    False. O(1) algorithms can be faster than O(n) algorithms for inputs below some size, by definition of the O notation.
     
  10. Sir Klutch

    Sir Klutch Active Member

    Oh... Can I have an example on how it would be faster, please? Learn something new every day...
     
    Last edited: Sep 4, 2017
  11. (FPtje) Atheos

    (FPtje) Atheos Main Developer Staff Member

    I couldn't reproduce it with table.HasValue, but there's a pretty well known example: insertion sort is usually faster than quicksort on small inputs and often faster on (nearly) sorted inputs. Note that insertion sort is O(n^2), and quicksort O(n × log(n)), which is a pretty big difference in the long run.

    Insertion sort is in-place and happens to work well on sorted lists. Quicksort is not in place and jumbles things around regardless of whether they were sorted before.
     
    Sir Klutch likes this.

Share This Page