RedM roleplay framework-ები: VORP თუ RSG

ახალი RedM roleplay სერვერისთვის არჩევანი VORP-სა და RSG-ს შორისაა. VORP უფრო დიდი ხნის RedM framework-ია, საკუთარი არქიტექტურით და vorp_core-ის გარშემო აგებული RedM-ის მშობლიური resource-ების ყველაზე დიდი ნაკრებით. RSG QBCore-იდან არის წარმოებული და მაშინვე ნაცნობად ეჩვენება ყველას, ვისაც QBCore ან Qbox-ის FiveM სერვერი უმართავს, ox_lib-ის ინტენსიური გამოყენებით და სამუშაოების, ნივთებისა და მოთამაშის მონაცემების QBCore-ის სტილის სტრუქტურით. ორივეს სჭირდება MySQL-თან თავსებადი მონაცემთა ბაზა oxmysql-ით, ორივე იმავე FXServer-ზე მუშაობს, და ვერცერთი ვერ უშვებს მეორის resource-ებს. აირჩიე VORP, თუ გინდა არსებული RedM resource-ების ყველაზე ღრმა მარაგი; აირჩიე RSG, თუ შენმა დეველოპერებმა უკვე იციან QBCore. შემდეგ მას ერთგული დარჩი, რადგან მოგვიანებით გადასვლა პერსონაჟების წაშლას ნიშნავს. ეს გზამკვლევი მათ სათანადოდ ადარებს და ორივეს ინსტალაციას ხსნის.

რას აკეთებს framework RedM-ზე#

FXServer გაძლევს სამყაროს, რომელშიც არაფერია: არც პერსონაჟები, არც ფული, არც ინვენტარი, არც სამუშაოები. framework არის საერთო ფენა, რომელიც ამათ უზრუნველყოფს და რომელსაც ყოველი სხვა resource ესაუბრება.

• მოთამაშეები და პერსონაჟები. იდენტიფიკატორები, ანგარიშებზე ასახული, რამდენიმე პერსონაჟი თითო ანგარიშზე, პერსონაჟის შექმნა, გარეგნობა.
• ინვენტარი და ნივთები. რა არსებობს, ვის აქვს, წონები და ლიმიტები, გამოყენებადი ნივთები.
• ფული. RedM-ზე ჩვეულებრივ ნაღდი და ოქრო, პლუს რასაც საბანკო resource-ები ამატებს.
• სამუშაოები და ჯგუფები. ვინ არის შერიფი, ექიმი, რანჩერი, და რის უფლებას აძლევს ეს.
• API. ფუნქციები და event-ები, რომლებსაც სხვა resource-ები ზემოთ ჩამოთვლილის წასაკითხად და შესაცვლელად იძახებს.

API არის ის ნაწილი, რომელიც გბოჭავს. VORP-ისთვის დაწერილი სამუშაოს resource ნივთების მისაცემად და ხელფასის გადასახდელად VORP-ის ფუნქციებს იძახებს; RSG-ზე ამას გადაწერის გარეშე ვერ გააკეთებს. სწორედ ამიტომ არის framework-ის არჩევა სინამდვილეში ეკოსისტემის არჩევა. იგივე გადაწყვეტილების FiveM-ის ვერსია, იგივე მსჯელობით, არის FiveM-ის framework-ების შედარებაში.

VORP და RSG გვერდიგვერდ#

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

კითხვები, რომლებსაც არჩევამდე უნდა უპასუხო

framework-ის გადაწყვეტილება, მიღებული მხოლოდ რეპუტაციით, ექვსი თვის შემდეგ ხშირად ხელახლა განიხილება. ჯერ ამათ უპასუხე, და არჩევანი ჩვეულებრივ თავისთავად კეთდება:

1. ვინ დაწერს კოდს? თუ გუნდში Lua-ზე არავინ წერს, არსებული resource-ების მარაგის ზომა ყველაზე მნიშვნელოვანია, და შენ აწყობ და არა აშენებ. თუ შენი დეველოპერები QBCore-იდან მოდიან, RSG მათ ყველაზე ნაკლები უჯდებათ.
2. რომელი resource-ები გჭირდება აუცილებლად? ჩამოწერე ხუთი ან ათი სისტემა, რომლის გარშემოც შენი სერვერია აგებული - ინვენტარის კონკრეტული შეგრძნება, ცხენების სისტემა, კანონისა და ჯილდოს სისტემა, კონკრეტული ეკონომიკა - და შეამოწმე, რომელ framework-ზეა გათვლილი საუკეთესო ხელმისაწვდომი ვერსიები.
3. რომელი ფასიანი resource-ების ყიდვას გეგმავ? ფასიანი RedM სკრიპტები ჩვეულებრივ უთითებს framework-ის მხარდაჭერას. შეამოწმე, რომ საჭირო ვერსია უჭერს მხარს framework-ის იმ ვერსიას, რომელსაც გაუშვებ, და არა მხოლოდ framework-ის სახელს.
4. რამდენი დოკუმენტაცია გჭირდება? გადაწყვეტამდე ერთი საათი წაიკითხე ორივე პროექტის დოკუმენტაცია. ის, რომელსაც შენი გუნდი უფრო ადვილად მიჰყვება, არის ის, რომელსაც უფრო ადვილად მოუვლი.
5. რამდენად აქტიურია პროექტი ახლა? შეხედე ბოლოდროინდელ commit-ებს, ღია issue-ებს და გამოშვების შენიშვნებს ბირთვისა და მისი მთავარი resource-ებისთვის. framework, რომელიც გაჩერდა, framework-ია, რომლის fork-საც გააკეთებ.

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

VORP#

VORP არის resource-ების კოლექცია vorp_core-ის გარშემო: vorp_inventory, vorp_character შექმნისა და გარეგნობისთვის, vorp_menu, ადმინის ხელსაწყოები და უტილიტები, და საზოგადოების სამუშაოებისა და სისტემების resource-ების გრძელი სია, მათზე დაწერილი. ის RedM-ის სიცოცხლის უმეტეს ნაწილს არსებობს, ამიტომ RedM-ის მშობლიური სკრიპტების უმეტესობა, რომლებსაც იპოვი - უფასო თუ ფასიანი - ან VORP-ზეა გათვლილი, ან VORP-ის ვერსიას გთავაზობს.

resource იღებს ბირთვის ობიექტს და მოთამაშის აქტიურ პერსონაჟთან მუშაობს:

local Core = exports.vorp_core:GetCore()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local user = Core.getUser(src)    if not user then return end    local character = user.getUsedCharacter    -- validate on the server, then pay    character.addCurrency(0, 5.0)   -- 0 = cashend)

ძველი VORP resource-ები ბირთვს TriggerEvent("getCore", function(core) ... end)-ით იღებს; მიმდინარე export-ს იყენებს. თუ ძველსა და ახალ resource-ებს ურევ, ორივე სტილი შენს კოდში გამოჩნდება. წაიკითხე VORP-ის დოკუმენტაცია იმ ვერსიის ზუსტი API-სთვის, რომელსაც აყენებ, რადგან ფუნქციების სახელები და ვალუტის ტიპები მთავარ ვერსიებს შორის იცვლებოდა.

ვის ერგება ჩვეულებრივ VORP: სერვერებს, რომლებსაც უნდათ არსებული RedM შიგთავსის ბევრის სწრაფად აწყობა, მფლობელებს, რომლებიც დეველოპერები არ არიან და დაეყრდნობიან იმას, რაც საზოგადოებამ უკვე ააგო, და გუნდებს, რომლებსაც ურჩევნიათ RDR2-ის კონცეფციების გარშემო შექმნილი API და არა GTA V-ის roleplay-იდან მორგებული.

RSG#

RSG იღებს QBCore-ის სტრუქტურას - ბირთვი საერთო მონაცემებით სამუშაოების, ნივთებისა და ბანდებისთვის, PlayerData ცხრილი თითოეული მოთამაშისთვის, callback-ები და ფუნქციები მოთამაშის ობიექტზე - და RedM-ს არგებს. თუ QBCore-ისთვის გიწერია, RSG-ის კოდი ბუნებრივად იკითხება:

local RSGCore = exports['rsg-core']:GetCoreObject()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local Player = RSGCore.Functions.GetPlayer(src)    if not Player then return end    if Player.Functions.RemoveItem("milk", 1) then        Player.Functions.AddMoney("cash", 5)    endend)

RSG მენიუებისთვის, შეტყობინებებისთვის, ზონებისთვის, callback-ებისა და პროგრესის ზოლებისთვის ox_lib-ს ეყრდნობა, ამიტომ UI-ისა და ურთიერთქმედების კოდის დიდი ნაწილი Overextended-ის უფრო ფართო ეკოსისტემასთან არის საერთო. rsg- resource-ები მოიცავს ინვენტარს, პერსონაჟებს, გარეგნობას, სამუშაოებს და roleplay-ის საფუძვლის დანარჩენ ნაწილს.

ვის ერგება ჩვეულებრივ RSG: გუნდებს QBCore-ის გამოცდილებით, სერვერებს, რომლებიც FiveM-იდან RedM-ზე გადადიან დეველოპერებით, რომლებსაც უნდათ, რომ მათი ჩვევები გადმოყვეს, და მფლობელებს, რომლებსაც ox_lib-ის კომპონენტები ურჩევნიათ ინდივიდუალურად შექმნილს.

რა უნდა იდოს ორივეს ქვეშ#

რომელიც არ უნდა აირჩიო, საფუძველი იგივეა:

1. FXServer `set gamename rdr3`-ით და RDR2-ის მიმდინარე იძულებითი თამაშის build-ით. RedM სერვერის დაყენება კონფიგურაციას ხსნის.
2. ჩართული OneSync. ორივე framework მას ვარაუდობს.
3. oxmysql, გაშვებული ყველაფრის წინ, რაც მონაცემთა ბაზას ეხება.
4. `ox_lib`, რომელიც სჭირდება RSG-ს და VORP-ის ეპოქის ბევრ resource-საც.
5. framework-ის ბირთვი, შემდეგ მისი საკუთარი resource-ები, შემდეგ ყველაფერი, რაც მასზეა აგებული.

მონაცემთა ბაზის კავშირის სტრიქონი იწერება server.cfg-ში set-ით, არასოდეს sets-ით:

set mysql_connection_string "mysql://user:password@host:3306/redm?charset=utf8mb4"set mysql_slow_query_warning 150ensure oxmysqlensure ox_lib# framework core and its resources follow, in the order its docs give

mysql_slow_query_warning oxmysql-ს აიძულებს, დაბეჭდოს ყოველი მოთხოვნა, რომელიც 150 ms-ზე ნელია, და ეს roleplay სერვერზე შენი ყველაზე იაფი წარმადობის ხელსაწყოა. დანარჩენი - სქემა, ინდექსები, backup-ები - არის FiveM-ის მონაცემთა ბაზებსა და oxmysql-ში, რომელიც RedM-ზე უცვლელად მოქმედებს.

ინსტალაცია: recipe თუ ხელით#

txAdmin-ის recipe-ები. txAdmin-ის deployer-ს შეუძლია სერვერის recipe-დან აგება: ის resource-ებს ჩამოტვირთავს, server.cfg-ს წერს, მონაცემთა ბაზის ცხრილებს ქმნის და კავშირის სტრიქონს ავსებს. საზოგადოების recipe-ები არსებობს როგორც VORP-ისთვის, ისე RSG-ისთვის. ეს მომუშავე სერვერამდე ყველაზე სწრაფი გზაა, ერთი შენიშვნით: recipe აფიქსირებს იმ ვერსიებს, რომლებისთვისაც დაიწერა. გაშვებამდე შეამოწმე, რომ recipe მოვლილი და ახალია.

ხელით. დააკლონე ან ჩამოტვირთე თითოეული resource framework-ის რეპოზიტორიებიდან, დააიმპორტე თითოეული resource-ის .sql ფაილი შენს მონაცემთა ბაზაში და დაამატე ensure ხაზები დოკუმენტირებული თანმიმდევრობით. უფრო ნელია, მაგრამ ზუსტად იცი, რა არის დაყენებული და საიდან მოვიდა, რაც განახლებისას მნიშვნელოვანია.

SQL-ის იმპორტი ის ნაბიჯია, რომელსაც ხალხი გამოტოვებს და შემდეგ მასზე საღამოს ხარჯავს. framework-ის ყოველ resource-ს, რომელიც მონაცემებს ინახავს, სქემის ფაილი მოყვება, და resource ვარდება - ხშირად ჩუმად, მოგვიანებით nil შეცდომებით - თუ მისი ცხრილები არ არსებობს. დააიმპორტე ყველა პირველ გაშვებამდე, utf8mb4 სიმბოლოების ნაკრებით, რომ აქცენტებიანმა სახელებმა და emoji-მ insert-ები არ გააფუჭოს. phpMyAdmin-ის import და export ნაბიჯ-ნაბიჯ ხსნის .sql ფაილის იმპორტს და შეცდომებს, რომლებსაც ნახავ.

ჩატვირთვის რიგი

რიგი server.cfg-ში ჩატვირთვის რიგია, ხოლო ჩატვირთვის რიგი დამოკიდებულებების რიგია. ტიპური ფორმა ორივე framework-ისთვის:

ensure oxmysqlensure ox_libensure <framework core>ensure <framework inventory>ensure <framework character and appearance>ensure [framework]ensure [jobs]ensure [maps]

სამუშაოს resource, რომელიც ბირთვამდე ეშვება, ბირთვის ობიექტს ითხოვს, იღებს nil-ს და სესიის დარჩენილ ნაწილში არაფერს აკეთებს, ჩვეულებრივ აშკარა შეცდომის გარეშე. თუ რამე მუშაობს მას შემდეგ, რაც ხელით გადატვირთავ, მაგრამ არა სერვერის სრული გადატვირთვის შემდეგ, ის ზედმეტად ადრე ეშვება. კვადრატულ ფრჩხილებში მოთავსებული საქაღალდეები, როგორიცაა [jobs], შიგნით არსებულ ყოველ resource-ს უშვებს თანმიმდევრობით, რომელსაც ვერ აკონტროლებ, ამიტომ ყველაფერი, რის resource-ებს შორისაც დამოკიდებულებებია, საერთო ფრჩხილის გარეთ შეინახე ან ცალსახად ensure გაუკეთე.

წარმადობა#

არცერთი framework არ არის ნელი სერვერის ჩვეულებრივი მიზეზი. RedM-ზეც, როგორც FiveM-ზე, სერვერის სკრიპტები ერთ მთავარ thread-ზე სრულდება და ხარჯი ზემოთ მოთავსებული resource-ებიდან მოდის: ციკლები, რომლებიც ყოველ კადრზე ეშვება, მონაცემთა ბაზის მოთხოვნები ციკლების შიგნით, event-ები, რომლებიც ყველა მოთამაშეს საჭიროზე გაცილებით ხშირად ეგზავნება. დიაგნოსტიკა იგივეა - resmon 1 კლიენტის F8 კონსოლში, profiler record სერვერზე, კონსოლის hitch-ის გაფრთხილებები და txAdmin-ის tick-ის გრაფიკი - და აღწერილია FiveM სერვერის წარმადობაში.

ორი შენიშვნა framework-ის სპეციფიკაზე. ინვენტარის resource-ები roleplay სერვერზე ყველაზე მეტ სამუშაოს აკეთებს მონაცემთა ბაზაში, ამიტომ შეამოწმე მათი შენახვის ქცევა: ყოველი ცვლილების დაუყოვნებლივ შენახვა უსაფრთხო და ძვირია, ინტერვალით შენახვა იაფია და ავარიისას მონაცემებს კარგავს. ხოლო პერსონაჟების მონაცემები, რომლებიც ყველა მოთამაშისთვის ერთდროულად ტაიმერით ინახება, რეგულარულ hitch-ს იწვევს; განაწილებული შენახვები ამას თავიდან აგარიდებს.

განახლება და აქტუალურობის შენარჩუნება#

ორივე framework მოძრაობს, და მათზე აგებული resource-ები საკუთარი ტემპით მისდევს.

• დააფიქსირე ვერსიები. იცოდე, ბირთვის და თითოეული მთავარი resource-ის რომელ გამოშვებას უშვებ. განაახლე გააზრებულად და არა recipe-ის ხელახლა გაშვებით.
• განაახლე ბირთვი მის საკუთარ resource-ებთან ერთად. ბირთვის განახლებას ხშირად ინვენტარისა და პერსონაჟის შესაბამისი განახლებები სჭირდება; წაიკითხე გამოშვების შენიშვნები ნაკრებისთვის.
• გაუშვი სატესტო სერვერი. მეორე ლიცენზიის key იმავე Cfx.re ანგარიშიდან, server-data-ს ასლი, მონაცემთა ბაზის ასლი. ჯერ იქ განაახლე.
• გააკეთე მონაცემთა ბაზის backup ყოველ განახლებამდე და იცოდე, რომ მისი აღდგენა შეგიძლია. backup-ები, რომლებიც მართლა აღდგება ამის არგუმენტს გვთავაზობს.

ფასიანი RedM resource-ები ხშირად escrow-ით არის დაცული და მიბმულია Cfx.re ანგარიშზე, რომელსაც შენი ლიცენზიის key ეკუთვნის, ზუსტად ისე, როგორც FiveM-ზე. ყიდვამდე შეამოწმე, რომ resource შენს framework-სა და მის მიმდინარე ვერსიას უჭერს მხარს.

framework-ის event-ების დაცვა

ორივე framework ხსნის სერვერის event-ებსა და callback-ებს, რომლებიც ფულსა და ნივთებს ცვლის, ხოლო მათზე აგებული resource-ები ასობით მეტს ამატებს. ნებისმიერ მიერთებულ კლიენტს შეუძლია ნებისმიერი სერვერის event-ის ნებისმიერი არგუმენტებით გამოძახება, ამიტომ ყოველმა handler-მა, რომელიც იხდის, სერვერზე უნდა შეამოწმოს შეყვანა: გამოიყენე source და არა კლიენტის მიერ გამოგზავნილი მოთამაშის ID, გამოთვალე რაოდენობები სერვერზე, შეამოწმე, რომ მოთამაშე იქ არის, სადაც ქმედება ხდება, და აქვს ის, რის გაყიდვასაც ამტკიცებს, და შეზღუდე სიხშირე. ზემოთ მოცემული RSG-ის მაგალითი ნივთს გადახდამდე აშორებს; VORP-ის მაგალითი მხოლოდ უთითებს, სად უნდა იყოს ეს შემოწმება, და ბევრი უფასო resource მას მთლიანად გამოტოვებს. FiveM-ის anticheat-ის ვარიანტები მეთოდს დეტალურად ხსნის, და ის RedM-ზე უცვლელად მოქმედებს, sv_entityLockdown-ის ჩათვლით OneSync-ის ქვეშ.

framework-ის მოგვიანებით შეცვლა#

მიგრაციის გზა არ არსებობს. VORP და RSG პერსონაჟებს, ნივთებსა და ფულს სხვადასხვა ცხრილებში ინახავს სხვადასხვა სტრუქტურით, და მათზე აგებული ყოველი resource ერთი API-სთვის არის დაწერილი. გადასვლა ნიშნავს ახალ მონაცემთა ბაზას, resource-ების ახალ სიას და შენი მოთამაშეებისთვის პერსონაჟების წაშლას. ზოგიერთი სერვერი ამას ღონისძიებად აქცევს - ახალი სეზონი, რუკის ახალი რეგიონი - მაგრამ ეს მაინც ნულიდან დაწყებაა. ეს ყველაზე ძლიერი არგუმენტია, რომ არჩევანზე საღამო დახარჯო, სანამ პირველი მოთამაშე შემოვა.

FAQ#

VORP ჯობია თუ RSG ახალი RedM სერვერისთვის?

არცერთი არ ჯობია უპირობოდ. VORP-ს RedM-ის მშობლიური resource-ების უფრო დიდი მარაგი და უფრო გრძელი ისტორია აქვს; RSG ნაცნობია QBCore-ის დეველოპერებისთვის და ყველგან ox_lib-ს იყენებს. აირჩიე შენი გუნდის გამოცდილებისა და საჭირო resource-ების მიხედვით.

შემიძლია VORP და RSG resource-ების ერთ სერვერზე გაშვება?

არა. თითოეული resource ერთი framework-ის API-სა და მონაცემებზეა დაწერილი. ორივე ბირთვის ერთდროულად გაშვება გაძლევს პერსონაჟებისა და ინვენტარების ორ ნაკრებს, რომლებმაც ერთმანეთის შესახებ არაფერი იციან.

ორივე framework-ს სჭირდება მონაცემთა ბაზა?

დიახ. ორივე ინახავს პერსონაჟებს, ინვენტარებსა და ფულს MySQL-თან თავსებად მონაცემთა ბაზაში oxmysql-ით, და თავის ცხრილებს თითოეულ resource-თან ერთად მოწოდებული .sql ფაილებიდან აიმპორტებს.

შემიძლია QBCore-ის resource-ების გამოყენება RSG-ზე?

პირდაპირ არა. RSG QBCore-ის სტრუქტურას მისდევს, რაც პორტირებას ბევრად ამარტივებს, მაგრამ QBCore-ის resource-ები GTA V-ის native-ებსა და QBCore-ის საკუთარ export-ებს იძახებს. მათ RDR3-ისა და RSG-ისთვის მორგება სჭირდება.

შემიძლია მოგვიანებით VORP-იდან RSG-ზე გადასვლა?

მხოლოდ თავიდან დაწყებით. მონაცემთა სტრუქტურები განსხვავებულია და მხარდაჭერილი მიგრაცია არ არსებობს, ამიტომ მოთამაშეები თავიანთ პერსონაჟებს კარგავენ. აირჩიე გაშვებამდე.