FiveM-ის Discord whitelist და როლების უფლებები

Discord FiveM სერვერზე ორ ცალკე სამუშაოს ასრულებს, და ყველაფერი უფრო ადვილი ხდება, როცა მათ ერთ რამედ აღქმას შეწყვეტ. whitelist წყვეტს, ვის შეუძლია მიერთება: ამას txAdmin თავად აკეთებს, Discord სერვერის წევრობით ან როლით, ყოველგვარი დამატებითი ინსტალაციის გარეშე. უფლებები წყვეტს, რისი გაკეთება შეუძლია მიერთებულ მოთამაშეს: ეს ნიშნავს Discord-ის როლების ACE ჯგუფებად გადაქცევას add_principal identifier.discord:<id> group.<name>-ით, როცა ისინი შემოდიან, ან მზა resource-ით, ან ორმოცი ხაზი საკუთარი კოდით. ორივეს სჭირდება Discord-ის ბოტი შენს guild-ში და ორივე დამოკიდებულია მოთამაშის Discord-ის იდენტიფიკატორზე, რომელიც მხოლოდ მაშინ არსებობს, თუ FiveM-ის გაშვებისას Discord-ის desktop აპი მუშაობს. ეს გზამკვლევი აყენებს ბოტს, txAdmin-ის whitelist-ს, როლებიდან ACE-ზე გადაყვანას და ხსნის ჩავარდნის შემთხვევებს, რომლებსაც პირველ კვირაში შეხვდები.

როგორ ერგება ნაწილები ერთმანეთს#

როცა მოთამაშე უერთდება, FXServer მის იდენტიფიკატორებს აგროვებს - license, discord, fivem, xbl, live, IP და steam, თუ Steam Web API key დაყენებული გაქვს. discord იდენტიფიკატორი მოთამაშის Discord-ის მომხმარებლის ID-ია, და ის მხოლოდ მაშინ არსებობს, როცა FiveM-ის გაშვებისას Discord-ის desktop კლიენტი მუშაობდა და შესული იყო. Discord ბრაუზერის ჩანართში არ ითვლება.

whitelist-ის ნაბიჯი შენი ბოტის მეშვეობით ეკითხება Discord-ს, არის თუ არა ეს მომხმარებელი შენს guild-ში და რომელი როლები აქვს, და მიერთებას იღებს ან უარყოფს. უფლებების ნაბიჯი იმავე როლებს იღებს და მოთამაშის Discord-ის იდენტიფიკატორს ACE ჯგუფებში ამატებს, ასე რომ IsPlayerAceAllowed და ACE-ით შეზღუდული ბრძანებები მათ ხედავს. პირველს txAdmin აკეთებს. მეორე resource-ია, რადგან txAdmin-ის საკუთარი ადმინების სია მის ვებ-პანელსა და თამაშის შიდა მენიუს მართავს და არა ACE-ს.

Discord-ის ბოტის შექმნა#

ორივე ნაბიჯს სჭირდება ბოტის ანგარიში შენს Discord სერვერზე. მას არ სჭირდება მუდმივად ონლაინ ყოფნა ცალკე პროგრამად - txAdmin და უფლებების resource მის token-ს მოთხოვნების გასაგზავნად იყენებს.

1. გახსენი Discord Developer Portal, შექმენი New Application და დაამატე მას Bot.
2. დააკოპირე ბოტის token. მოეპყარი როგორც პაროლს: ვისაც ის აქვს, ბოტს აკონტროლებს და შენი წევრების სიის წაკითხვა შეუძლია.
3. Bot გვერდზე ჩართე Server Members Intent. წევრებისა და როლების ძებნა მასზეა დამოკიდებული, და მისი დავიწყება ყველაზე გავრცელებული მიზეზია, რის გამოც whitelist ყველას უარყოფს.
4. OAuth2-ში შექმენი მოსაწვევი URL bot scope-ით და მოიწვიე ბოტი შენს guild-ში. წევრებისა და როლების წასაკითხად მას განსაკუთრებული უფლებები არ სჭირდება.
5. Discord-ში ჩართე Developer Mode (User Settings, Advanced). დააწკაპუნე მარჯვენა ღილაკით შენს სერვერზე და Copy Server ID, შემდეგ მარჯვენა ღილაკით ყოველ საჭირო როლზე და Copy Role ID.

ახლა გაქვს token, guild ID და როლების ID-ების სია. token მხოლოდ ერთ ადგილას შეინახე. თუ მას server.cfg-ში ჩადებ, გამოიყენე set, არასოდეს sets ან setr - sets მნიშვნელობას სერვერების სიაში აქვეყნებს, საიდანაც მას ამოიღებენ. გარემოს ცვლადები და საიდუმლოებები ხსნის, როგორ შეინახო ის სქრინშოტებისა და რეპოზიტორიების გარეთ.

whitelist txAdmin-ით#

txAdmin-ს აქვს ჩაშენებული whitelist და ჩაშენებული Discord-ის ბოტის ინტეგრაცია, ამიტომ თავად კარისთვის resource არ გჭირდება.

1. txAdmin-ში გახსენი Settings და Discord ჩანართი. ჩართე ბოტი, ჩასვი token და guild ID და შეინახე. txAdmin დაუკავშირდება და გეტყვის, დაინახა თუ არა guild.
2. გახსენი whitelist-ის პარამეტრი (მიმდინარე ვერსიებში Settings, Player Manager-ის ქვეშ) და აირჩიე რეჟიმი.

ზუსტი სახელები txAdmin-ის ვერსიებს შორის ოდნავ იცვლება, მაგრამ ეს ხუთი ქცევა სტაბილური იყო.

Discord server roles არის ის, რაც roleplay სერვერების უმეტესობას უნდა: განმცხადებლები Discord-ში შედიან, განაცხადს გადიან, იღებენ "Whitelisted" როლს და ამ მომენტიდან შეუძლიათ მიერთება. როლის წართმევა წვდომას მათი შემდეგი მიერთებისას აუქმებს. ჩასვი როლების ID-ები და არა სახელები; სახელები შეიძლება გაორდეს და გადაერქვას, ID-ები - არა.

Approved license ერგება პატარა კერძო სერვერს Discord-ის პროცესის გარეშე. უარყოფილ მოთამაშეს მოკლე მოთხოვნის ID ეჩვენება; ადმინი მას txAdmin-ის whitelist-ის გვერდიდან ან ბოტის whitelist ბრძანებით Discord-ში ამტკიცებს, და მოთამაშეს შესვლა შეუძლია.

უარყოფის შეტყობინება კონფიგურირებადია. აიძულე, რომ მოთამაშეებს ზუსტად უთხრას, რა გააკეთონ - "Join discord.gg/yourserver and complete the application" - და რა შეამოწმონ, თუ ფიქრობენ, რომ whitelist-ში არიან: ღიაა თუ არა Discord-ის აპი და სწორი ანგარიშია თუ არა. ეს ერთი წინადადება ათობით support ticket-ს ზოგავს.

Discord-ის როლებიდან ACE უფლებებამდე#

whitelist ხალხს შიგნით უშვებს. Discord-ის როლისთვის თამაშის შიდა ძალაუფლების მისაცემად - ადმინის ბრძანებები, სტაფის მენიუ, დონორის მანქანა - ACE principal-ები გჭირდება. მექანიზმი იგივეა, რაც აღწერილია FiveM-ის server.cfg-ის ახსნაში: ჯგუფები ace-ებს ფლობს, ხოლო principal მოთამაშის იდენტიფიკატორს ჯგუფს უერთებს.

add_ace group.admin command allowadd_ace group.admin command.quit denyadd_ace group.mod command.kick allowadd_principal group.admin group.mod

სტატიკური ხაზები, როგორიცაა add_principal identifier.discord:216735154273419264 group.admin, მუშაობს, მაგრამ ისინი Discord-ში როლების ცვლილებებს არ მისდევს. resource, რომელიც principal-ებს მოთამაშის მიერთებისას მისი მიმდინარე როლების მიხედვით ამატებს, მისდევს.

ყველაზე ცნობილი მზა ვარიანტია Badger-ის resource-ების წყვილი: Badger_Discord_API, რომელიც Discord-თან ურთიერთობს, და DiscordAcePerms, რომელიც მიერთებისას როლების ID-ებს ჯგუფებზე ასახავს. ისინი ფართოდ გამოიყენება და კარგად არის დოკუმენტირებული; კონფიგურაციის ფორმატისთვის მათ საკუთარ README-ს მიჰყევი, რადგან ის ვერსიებს შორის იცვლებოდა.

თუ გირჩევნია ზუსტად იცოდე, რა მუშაობს, სამუშაო იმდენად პატარაა, რომ თავად დაწერო:

local GUILD = GetConvar("discord_guild_id", "")local TOKEN = GetConvar("discord_bot_token", "")-- Discord role ID -> ACE grouplocal ROLE_GROUPS = {    ["111111111111111111"] = "group.admin",    ["222222222222222222"] = "group.mod",    ["333333333333333333"] = "group.donor",}local function discordId(src)    local id = GetPlayerIdentifierByType(src, "discord")    return id and id:gsub("discord:", "")endAddEventHandler("playerConnecting", function(name, setKickReason, deferrals)    local src = source    deferrals.defer()    Wait(0)    deferrals.update("Checking your Discord roles...")    local id = discordId(src)    if not id then        deferrals.done("Open the Discord desktop app, then restart FiveM.")        return    end    local url = ("https://discord.com/api/v10/guilds/%s/members/%s"):format(GUILD, id)    PerformHttpRequest(url, function(status, body)        if status == 200 then            local member = json.decode(body)            for _, group in pairs(ROLE_GROUPS) do                ExecuteCommand(("remove_principal identifier.discord:%s %s"):format(id, group))            end            for _, role in ipairs(member.roles or {}) do                local group = ROLE_GROUPS[role]                if group then                    ExecuteCommand(("add_principal identifier.discord:%s %s"):format(id, group))                end            end        end        deferrals.done()    end, "GET", "", { Authorization = "Bot " .. TOKEN })end)

და server.cfg-ში:

set discord_guild_id "123456789012345678"set discord_bot_token "your-bot-token"add_ace resource.discord_perms command.add_principal allowadd_ace resource.discord_perms command.remove_principal allowensure discord_perms

ორ add_ace resource. ხაზს მნიშვნელობა აქვს. resource ვერ გაუშვებს add_principal-ს ExecuteCommand-ით, თუ ეს ბრძანება მისთვის ნებადართული არ არის, და მათ გარეშე სკრიპტი მუშაობს, არაფერს სასარგებლოს არ ბეჭდავს და ჯგუფს ვერავინ იღებს.

კოდის დეტალები, რომელთა გაგებაც ღირს და არა უბრალოდ კოპირება:

• `deferrals.defer()`, შემდეგ `Wait(0)`. deferring მიერთებას აკავებს, სანამ ასინქრონულ სამუშაოს აკეთებ; ლოდინი აუცილებელია update-ის ან done-ის გამოძახებამდე.
• წაშლა დამატებამდე. principal-ები იდენტიფიკატორზეა მიბმული და სერვერის გადატვირთვამდე რჩება, ასე რომ მოთამაშე, რომელმაც Discord-ში როლი დაკარგა, ჯგუფს ინარჩუნებს, თუ არ წაშლი. ციკლი ჯერ ყოველ ასახულ ჯგუფს ასუფთავებს.
• არაწევრი აქ მაინც შედის. ეს resource მხოლოდ უფლებებს ასახავს. არაწევრების უარყოფა txAdmin-ის საქმეა; ამის ორ ადგილას კეთება ნიშნავს გამართვის ორ ადგილს.
• `GetPlayerIdentifierByType` ხელმისაწვდომია სერვერის მიმდინარე build-ებზე. ძალიან ძველებზე ამის ნაცვლად GetPlayerIdentifiers(src)-ზე გაიარე ციკლით.

framework-ის უფლებები მესამე სისტემაა#

ACE FiveM-ის უფლებების სისტემაა, მაგრამ framework-ები ზემოდან საკუთარს ადებს და მას სხვადასხვანაირად უკავშირდება.

• QBCore ACE-ს პირდაპირ იყენებს. მისი უფლებების დონეები ACE ჯგუფებია, როგორიცაა qbcore.god, qbcore.admin და qbcore.mod, ასე რომ Discord-ის როლი, ასახული qbcore.admin-ზე, QBCore-ის ადმინის შემოწმებებთან მუშაობს. ზუსტი სახელები შენი ვერსიის config.lua-ში შეამოწმე.
• ESX ინახავს group მნიშვნელობას თითოეული მოთამაშისთვის თავის მონაცემთა ბაზაში (user, admin და ა.შ.) და მას ამოწმებს. Discord-ის როლის ACE ჯგუფზე ასახვა ESX-ის ჯგუფს არ ცვლის; გჭირდება resource, რომელიც მას framework-ის მეშვეობით აყენებს, ან ხელით აყენებ.
• Qbox QBCore-ის მიდგომას მისდევს და ACE-ს ეყრდნობა.

როლების ასახვამდე გადაწყვიტე, სამი სისტემიდან რომელს ეკუთვნის თითოეული უფლება, და ჩაიწერე. "რატომ შეუძლია მოდერატორს ადმინის მენიუს გახსნა, მაგრამ ვერავის აგდებს?" თითქმის ყოველთვის ერთი სისტემაა, რომელიც აძლევს, და მეორე, რომელიც უარს ამბობს. framework-ის მხარე აღწერილია FiveM-ის framework-ების შედარებაში.

txAdmin-ის ადმინები და Discord#

txAdmin ინახავს საკუთარ ადმინის ანგარიშებს საკუთარი უფლებებით - ვის შეუძლია kick, ban, restart, კონფიგურაციის რედაქტირება, თამაშის შიდა მენიუს გამოყენება. ეს ანგარიშები შეიძლება მიება Discord ID-სა და FiveM-ის იდენტიფიკატორს, რომ თამაშის შიდა მენიუმ ისინი იცნოს, მაგრამ txAdmin-ის ადმინის სტატუსი და ACE ჯგუფები ცალკე რჩება. უფროს მოდერატორს ჩვეულებრივ ორივე სჭირდება: txAdmin-ის ანგარიში მოთამაშეების მართვის უფლებებით და Discord-ის როლი, რომელიც თამაშის შიდა ბრძანებებისთვის group.mod-ზეა ასახული.

ორივე სია მოკლე შეინარჩუნე. ყოველ ადამიანს, რომელსაც დაბანვის უფლება აქვს, განბანვაც შეუძლია; ყოველ ადამიანს, რომელსაც კონფიგურაციის უფლება აქვს, შენი მონაცემთა ბაზის პაროლის წაკითხვა შეუძლია. იგივე ლოგიკა ეხება პანელს, სადაც subuser-ები და მინიმალური პრივილეგია ხსნის, რატომ არსებობს მხოლოდ კონსოლზე და მხოლოდ ფაილებზე წვდომა. RE:NODE-ზე subuser-ებს შეიძლება ზუსტად ეს მიეცეთ - მხოლოდ კონსოლი, მხოლოდ ფაილები, billing-ის გარეშე - და წვდომა შეიძლება დროში შეიზღუდოს, რაც ერგება დეველოპერს, რომელსაც ერთი კვირით უშვებ.

განაცხადების პროცესი მის გარშემო#

ტექნიკური whitelist ადვილი ნახევარია. პროცესი, რომელიც წყვეტს, ვინ მიიღებს როლს, არის ის, რაც whitelist-იან სერვერს შესასვლელად ღირსეულს ხდის, და ღირს მისი გააზრებულად დაგეგმვა.

• ერთი როლი წვდომისთვის, ცალკე როლები უფლებებისთვის. "Whitelisted" ხალხს მიერთების საშუალებას აძლევს. "Police", "EMS" და "Staff" თამაშში რაღაცებს იძლევა. მათი შერევა - პოლიციის როლისთვის წვდომის მიცემაც - ნიშნავს, რომ ვინმეს პოლიციიდან მოხსნა მას სერვერიდანაც გარეთ ტოვებს.
• განაცხადის არხი ან ფორმა. სერვერების უმეტესობა იყენებს Discord-ის ფორმის ბოტს ან ვებსაიტის ფორმას. იკითხე ის, რაზეც რეალურად იღებ გადაწყვეტილებას: ასაკი, დროის სარტყელი, roleplay-ის გამოცდილება, პერსონაჟის მოკლე კონცეფცია. გრძელი ესეები კარგ მოთამაშეებსაც ფილტრავს და ცუდებსაც.
• ვის შეუძლია როლის მიცემა. შეზღუდე როლების მართვა Discord-ში იმ ადამიანებით, ვინც განაცხადებს განიხილავს. ნებისმიერი, ვისაც "Whitelisted"-ის მიცემა შეუძლია, შენი სერვერის კარს აკონტროლებს, ხოლო ნებისმიერი, ვისაც "Staff"-ის მიცემა შეუძლია, ყველაფერს მის მიღმა.
• წვდომის მოხსნა. წაართვი როლი ბანებისთვის, რომლებიც თამაშის შიდა ბანზე დიდხანს უნდა გაგრძელდეს, და მოთამაშეებისთვის, რომლებიც შენს Discord-ს ტოვებენ. როლის whitelist-ით guild-ის დატოვება წვდომას შემდეგი მიერთებისას ავტომატურად აუქმებს.
• არააქტიური მოთამაშეები. ზოგიერთი სერვერი whitelist-ის როლს თვეების არააქტიურობის შემდეგ აშორებს, რომ საზოგადოება აქტუალური შეინარჩუნოს. ამის გაკეთებამდე მოთამაშეებს უთხარი.

ჩაწერე წესები და მიამაგრე განაცხადების არხში. სერვერის წესები, მოდერაცია და სტაფი ამის ადამიანურ მხარეს უფრო სიღრმისეულად ხსნის, გასაჩივრებების ჩათვლით.

rate limit-ები და საიმედოობა#

Discord ბოტებს rate limit-ს უწესებს. ერთი მოთხოვნა თითო მიმერთებელ მოთამაშეზე ნებისმიერი ჩვეულებრივი სერვერისთვის ლიმიტების ფარგლებშია, თუნდაც გადატვირთვისას, როცა სამოცი ადამიანი ორ წუთში ხელახლა უერთდება. პრობლემას იწვევს როლების განმეორებითი შემოწმება, სანამ მოთამაშეები ონლაინ არიან - ყოველ ბრძანებაზე, ყოველ წუთს, ყოველი სამუშაოს შეცვლისას. მოძებნე როლები მიერთებისას, შეინახე სესიისთვის და განაახლე მხოლოდ მოთხოვნით.

თუ Discord არ პასუხობს, გადაწყვიტე, რა მოხდება. ზემოთ მოცემული კოდი მოთამაშეს ჯგუფების გარეშე უშვებს, რაც უფლებებისთვის უსაფრთხო ჩავარდნაა. whitelist-ისთვის კომპრომისი პირიქითაა: ღიად ჩავარდნა Discord-ის გათიშვისას ნებისმიერს უშვებს, დახურულად ჩავარდნა ყველას გარეთ ტოვებს. txAdmin დახურულად ვარდება, რაც whitelist-ისთვის სწორია, და სწორედ ამიტომ არის Admin-only სათადარიგო ვარიანტი მნიშვნელოვანი.

პრობლემების მოგვარება#

როლის whitelist ყველას უარყოფს. Server Members Intent გამორთულია, ბოტი guild-ში არ არის, ან guild ID არასწორია. txAdmin-ის Discord-ის პარამეტრების გვერდი გეტყვის, ხედავს თუ არა ბოტი guild-ს.

ერთი მოთამაშე უარყოფილია, მიუხედავად იმისა, რომ როლი აქვს. FiveM-ის გაშვებისას მისი Discord-ის აპი არ მუშაობდა, ის Discord-ის სხვა ანგარიშით არის შესული, ან guild-ში მყოფი ანგარიში არ არის ის, რომელიც მის კლიენტშია მიბმული. სთხოვე, დახუროს FiveM, გახსნას Discord და თავიდან დაიწყოს.

როლები აისახება, მაგრამ ბრძანებები მაინც უარყოფილია. resource-ს აკლია თავისი add_ace resource.<name> command.add_principal allow ხაზი, ან ჯგუფს ამ ბრძანებისთვის ace-ები არ აქვს მიცემული.

მოხსნილი სტაფი ძალაუფლებას ინარჩუნებს. principal-ები გადატვირთვამდე რჩება. წაშალე დამატებამდე, როგორც ზემოთაა, ან გადატვირთე სერვერი.

უფლებები თამაშში მუშაობს, მაგრამ txAdmin-ში არა. ეს სხვადასხვა სისტემებია. მიეცი ადამიანს txAdmin-ის ანგარიშიც.

FAQ#

სჭირდებათ მოთამაშეებს გახსნილი Discord Discord-ის whitelist-იან სერვერზე შესასვლელად?

დიახ. Discord-ის იდენტიფიკატორი მოდის Discord-ის desktop აპიდან, რომელიც FiveM-ის გაშვებისას მუშაობს. მის გარეშე შესამოწმებელი არაფერია, და როლზე დაფუძნებული whitelist მიერთებას უარყოფს.

შემიძლია whitelist resource-ის დაყენების გარეშე?

დიახ. txAdmin-ის whitelist Discord სერვერის წევრობასა და Discord-ის როლებს პირდაპირ უჭერს მხარს, როგორც კი მისი Discord-ის ბოტი კონფიგურირებულია. resource-ები მხოლოდ როლების თამაშის შიდა ACE უფლებებად გადასაქცევად გჭირდება.

რატომ უნდა გამოვიყენო როლების ID-ები სახელების ნაცვლად?

სახელების შეცვლა ან გაორება შეუძლია ნებისმიერს, ვისაც როლების მართვის უფლება აქვს, რაც ჩუმად შეცვლიდა, ვინ შედის. ID-ები როლის მთელი სიცოცხლის განმავლობაში ფიქსირებულია.

თუ ვინმეს txAdmin-ში ადმინს მივცემ, ის თამაშშიც ადმინი ხდება?

ACE-ის თვალსაზრისით არა. txAdmin-ის ადმინებს შეუძლიათ txAdmin-ის საკუთარი მენიუსა და პანელის გამოყენება, მაგრამ ACE ჯგუფები და framework-ის ჯგუფები ცალკეა, და თითოეული ცალკე უნდა მიეცეს.

რა მოხდება, თუ ჩემი ბოტის token გაჟონავს?

დაუყოვნებლივ გაანულე ის Developer Portal-ში და განაახლე ყველგან, სადაც ინახება. გაჟონილი token ნებისმიერს აძლევს საშუალებას, იმოქმედოს ბოტის სახელით და წაიკითხოს შენი guild-ის წევრების სია.