RE:NODE

სახელმძღვანელოები12 წუთის საკითხავი

FiveM framework-ები: ESX, QBCore და Qbox შედარება

რით განსხვავდება ESX, QBCore და Qbox, რა სჭირდება თითოეულს ქვემოთ, როგორ იტვირთება resource-ები და რომელი აირჩიო ახალი roleplay სერვერისთვის.

0 მკითხველი

აირჩიე ერთი framework და ყველაფერი მასზე ააგე. ESX Legacy-ს უფასო resource-ების ყველაზე დიდი მარაგი აქვს და სამუშაოებს ბაზაში ინახავს. QBCore ახალი roleplay სერვერებისთვის ნაგულისხმევი არჩევანია და თითქმის ყველაფერს Lua ფაილებში ინახავს, რომელთა წაკითხვაც შეგიძლია. Qbox არის QBCore, ხელახლა აგებული ox_* სტეკზე, უფრო სუფთა და სწრაფი, მაგრამ მზა resource-ების ნაკლები რაოდენობით. სამივე ერთსა და იმავე FXServer-ზე მუშაობს, სამივეს ახლა oxmysql და ox_lib სჭირდება ქვემოთ, და არცერთი არ გაუშვებს მეორის სამუშაოს სკრიპტებს დამატებითი შრომის გარეშე. framework FiveM სერვერზე ერთადერთი გადაწყვეტილებაა, რომლის მოგვიანებით შეცვლაც მართლა ძვირია, და სწორედ ამიტომ ღირს ოცი წუთი, სანამ რამეს დააყენებ.

რა არის framework სინამდვილეში#

FXServer თავისთავად გაძლევს GTA-ს multiplayer სესიას წესების გარეშე: მოთამაშეები ჩნდებიან და სულ ესაა. framework არის resource-ების ნაკრები, რომელიც ამატებს იმას, რაც roleplay სერვერს ეგულება: მუდმივი პერსონაჟი, რომელიც ბაზის მწკრივზეა მიბმული, ფული ანგარიშებზე, ინვენტარი, სამუშაოები ხარისხებით, და გზა იმისა, რომ ერთმა resource-მა მეორეს ჰკითხოს, არის თუ არა მოთამაშე პოლიციელი.

ეს იმდენად კოდია, რამდენადაც შეთანხმება. როცა resource-ის ავტორი წერს „requires ESX", ის გულისხმობს, რომ მისი სკრიპტი ESX-ის shared ობიექტს იძახებს და ელის ESX-ის event სახელებს, მის ბაზის ცხრილებს და მის item განმარტებებს. სწორედ ამიტომ არ მუშაობს framework-ების არევა: esx_ resource, რომელიც xPlayer.getJob()-ს ითხოვს, qb-core-ისგან საერთოდ არაფერს იღებს, რადგან ეს ფუნქცია იქ არ არსებობს.

framework სერვერი ამიტომ ერთი ჩამოტვირთვა არ არის. ეს არის core პლუს ბაზის სქემა პლუს სადღაც 60-სა და 400 სხვა resource-ს შორის, სადაც ცხოვრობს როგორც სიამოვნება, ისე მარცხის რეჟიმები. FiveM server and txAdmin პოსტი ამ ფენის ზემოთ მყოფს განიხილავს; ეს პოსტი იმაზეა, რასაც resources/-ში ათავსებ.

ESX, QBCore და Qbox გვერდიგვერდ#

ESX LegacyQBCoreQbox
Core resourcees_extendedqb-coreqbx_core
სამუშაოები განსაზღვრულიაბაზის ცხრილებშიshared/jobs.lua-შიshared/jobs.lua-ში
Item-ები განსაზღვრულიაბაზის ცხრილშიshared/items.lua-შიox_inventory-ში
ინვენტარიჩანაცვლებადიqb-inventoryox_inventory
უფასო resource-ების მარაგიყველაზე დიდიძალიან დიდიყველაზე პატარა
კოდის სტილიყველაზე ძველი, არეულიმოწესრიგებული, ვრცელიყველაზე მკაცრი, ახალი

ESX Legacy არის ჯერ კიდევ ფართოდ გამოყენებული უძველესი framework-ის მხარდაჭერილი ხაზი, რომელიც esx_core-ად არის გამოქვეყნებული - ერთი repository, რომელიც შეიცავს es_extended-ს და მის მენიუს, შეტყობინებებს და progress-bar resource-ებს. ბოლო ვერსიებს oxmysql და ox_lib სჭირდება; ძველები mysql-async-ს იყენებდა და tutorial, რომელიც mysql-async-ის დაყენებას გირჩევს, მოძველებულია. ESX-ის გამორჩეული ჩვევა ისაა, რომ სამუშაოები და ხარისხები jobs და job_grades ცხრილების მწკრივებია და არა კონფიგურაციის ფაილის ხაზები, რაც ნიშნავს, რომ სამუშაოს დამატება SQL-ის წერას ან phpMyAdmin-ში დაწკაპუნებას ნიშნავს. ზოგს ეს მოსწონს. უმეტესობა მას ESX-ის ყველაზე გამაღიზიანებელ ნაწილად თვლის.

QBCore არის framework, რომელზეც ახალი roleplay სერვერების უმეტესობა იწყება და რომელსაც უმეტესი tutorial, YouTube ვიდეო და ფასიანი სკრიპტი უმიზნებს. მისი კონფიგურაცია უბრალო Lua-შია qb-core/shared/-ის ქვეშ - items.lua, jobs.lua, gangs.lua, vehicles.lua, weapons.lua, locations.lua - ამიტომ სამუშაოს დამატება ერთი ცხრილის ჩანაწერია და გადატვირთვა. კომპრომისი ისაა, რომ კოდის ბაზა სწრაფად გაიზარდა, qb-* resource-ების ხარისხი განსხვავდება და ბევრი, რასაც ხალხი უშვებს, ფორკის ფორკია.

Qbox არის QBCore-ს გაგრძელება, აგებული Overextended სტეკზე: ox_lib, oxmysql, ox_inventory, ox_target, ox_doorlock. ის აგდებს იმას, რასაც QBCore თავსებადობისთვის ინახავდა, მოითხოვს Lua 5.4-ს და მიმდინარე FXServer build-ს, და item-ების განმარტებებს core-იდან ox_inventory/data/items.lua-ში გადააქვს. მას მოჰყვება თავსებადობის ფენა, რომელიც qb-core-ზე პასუხობს, ამიტომ არცთუ მცირე რაოდენობა qb-* resource-ისა უცვლელად მუშაობს - მაგრამ არა ის, რაც ინვენტარს ეხება, და არა ის, რაც QBCore-ს ცხრილებში პირდაპირ წერს. თუ შენი resource-ების სია ძირითადად ისაა, რასაც თავად დაწერ ან მძიმედ შეცვლი, Qbox სამუშაოდ უფრო სასიამოვნო ადგილია. თუ შენი სია ძირითადად ჩამოტვირთულია, QBCore ნაკლებად გეწინააღმდეგება.

კიდევ ორს ნახავ დასახელებულს. ox_core არის Overextended-ის საკუთარი framework: პატარა, თავისი აზრის, თითქმის მზა კონტენტის გარეშე, განკუთვნილი მათთვის, ვისაც საკუთარი სერვერის დაწერა უნდა. vRP ამ ყველაფრის წინაპარია და წარსულში დატოვება სჯობს. რასაც ფორუმზე არ უნდა კითხულობდე, არ არსებობს framework, რომელიც „ყველაზე სწრაფია" ისე, რომ ეს იგრძნო - framework tick-ზე მილიწამის ნაწილს ჯდება, 200 resource კი, რომელსაც მასზე აგროვებ, ყველაფერ დანარჩენს.

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

არცერთი framework დამოუკიდებელი არ არის. სანამ core დაიწყება, ესენი უნდა მუშაობდეს:

  • `oxmysql` - ბაზის ხიდი, რომელსაც ყველა მიმდინარე framework იყენებს. ის კავშირის სტრიქონს convar-იდან კითხულობს და query ფუნქციებს ყველა სხვა resource-ს აძლევს. სრული დეტალები აქ: FiveM databases and oxmysql.
  • `ox_lib` - საერთო ბიბლიოთეკა callback-ებისთვის, შეტყობინებებისთვის, კონტექსტური მენიუებისთვის, progress bar-ებისთვის, zone-ებისთვის და point-ებისთვის. ის shared script-ად იტვირთება @ox_lib/init.lua-ით და მას resource-ების მზარდი რაოდენობა მოითხოვს, Qbox-ი აირჩიე თუ არა.
  • ხმის resource - pma-voice ჩვეულებრივი უფასო არჩევანია და მას mumble ტრაფიკი სჭირდება, ამიტომ ხელი არ ახლო, თუ არ იცი, რატომ ცვლი.
  • Cfx საბაზო resource-ები - mapmanager, chat, spawnmanager, sessionmanager და hardcap, რომლებიც ნაგულისხმევ სერვერის მონაცემებში მოდის. framework-ები spawn-ისა და პერსონაჟის ნაკადს ცვლის, მაგრამ მაინც ელის, რომ session და chat ნაწილები არსებობდეს.
  • `screenshot-basic` - პატარაა და txAdmin მას მოთამაშეების ეკრანის სურათებისთვის იყენებს.

ჩატვირთვის რიგი დეკორატიული არ არის. resource, რომელიც MySQL.query-ს იძახებს, სანამ oxmysql ჯერ კიდევ იწყება, შეცდომას აგდებს, ხოლო სამუშაოს resource, რომელიც shared ობიექტს core-ის ამუშავებამდე ითხოვს, nil-ს იღებს და დანარჩენი სესიის განმავლობაში ჩუმად არაფერს აკეთებს. server.cfg-ში ეს ნიშნავს:

server.cfg - order matters
ensure oxmysqlensure ox_libensure es_extended        # or qb-core, or qbx_coreensure ox_inventoryensure pma-voice# anything that depends on the framework goes after the frameworkensure esx_policejob

ensure resource-ს გაუშვებს, ან თუ ის უკვე მუშაობს, გადატვირთავს, რაც მას სწორ ზმნად აქცევს კონფიგურაციის ფაილში. ფაილის ყოველი ხაზი დაშლილია აქ: FiveM server.cfg explained.

დაყენება: txAdmin recipe-ები ხელით გაკეთების წინააღმდეგ#

txAdmin-ის deployer-ს შეუძლია სერვერი recipe-დან ააგოს - YAML ფაილი, რომელიც repository-ებს ჩამოტვირთავს, resources/-ში ამოფუთავს, SQL-ს იმპორტს გაუკეთებს და საწყის server.cfg-ს დაწერს. ის დაყენებისას ბაზის კავშირის სტრიქონს გეკითხება და ცხრილებს შექმნის იმ ბაზაში, რომელზეც მიუთითებ. recipe-ების სიაში შედიოდა Cfx-ის ნაგულისხმევი შაბლონი, ESX Legacy build და community build-ები, და ის txAdmin-ის ვერსიებს შორის იცვლება, ამიტომ წაიკითხე, რას გთავაზობს შენი ინსტალაცია სინამდვილეში და არა ის, რასაც ორი წლის წინანდელი ვიდეო გვიჩვენებს.

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

code
resources/  [system]/            # build helpers from the default server data  [standalone]/    oxmysql/    ox_lib/    pma-voice/  [core]/    es_extended/    ox_inventory/  [jobs]/    esx_policejob/    esx_ambulancejob/

FXServer resources/-ს ასკანერებს იმ საქაღალდეებისთვის, რომელთა სახელები კვადრატულ ფრჩხილებშია, და მათ შიგნით რეკურსიულად ეძებს. საქაღალდე ფრჩხილების გარეშე თავად resource-ად მიიჩნევა და უნდა შეიცავდეს fxmanifest.lua-ს, თორემ უხილავია. ensure ყოველთვის resource-ის სახელს იღებს და არა გზას, ამიტომ ensure esx_policejob მუშაობს, რამდენადაც ღრმად არ უნდა ჩადო.

ხელით გაკეთება ოთხი ნაბიჯია და შენ უნდა შეგეძლოს მათი გაკეთება:

  1. ჩამოტვირთე framework-ის core-ის რელიზი, ამოფუთე resources/[core]/-ში და შეამოწმე, რომ საქაღალდის სახელი ემთხვევა იმას, რასაც დოკუმენტაცია გირჩევს, ensure გააკეთო.
  2. გააკეთე framework-ის SQL dump-ის იმპორტი შენს ბაზაში. გააკეთე ეს პირველ გაშვებამდე და არა მას შემდეგ, რაც ჩავარდება.
  3. ჩასვი კავშირის სტრიქონი server.cfg-ში და დაამატე ensure ხაზები დამოკიდებულების რიგით.
  4. გაუშვი სერვერი გახსნილი კონსოლით და წაიკითხე ყოველი ხაზი, სანამ პირველი მოთამაშე არ ჩნდება.

manifest და რისი გაგება შეიძლება მისგან#

ყოველ resource-ს აქვს fxmanifest.lua. მისი წაკითხვა დაყენებამდე უფრო მეტს გეუბნება, ვიდრე ფორუმის პოსტი, საიდანაც ის მოვიდა.

fxmanifest.lua
fx_version 'cerulean'game 'gta5'lua54 'yes'author 'someone'version '1.2.0'shared_scripts {    '@ox_lib/init.lua',    'config.lua',}client_scripts { 'client/*.lua' }server_scripts {    '@oxmysql/lib/MySQL.lua',    'server/*.lua',}dependencies { 'ox_lib', 'oxmysql' }

@resource/file.lua ფორმა ფაილს სხვა resource-იდან იღებს, სწორედ ასე ჩაირთვება oxmysql და ox_lib. fx_version 'cerulean' manifest-ის მიმდინარე თაობაა; adamant და bodacious უფრო ძველია და ისევ მუშაობს. lua54 'yes' resource-ს Lua 5.4-ზე გადაიყვანს და Qbox-ის resource-ებს ის სჭირდება. escrow_ignore ბლოკი ნიშნავს, რომ resource ნაწილობრივ დაშიფრულია Cfx asset escrow-ით, რაც ფასიანი სკრიპტებისთვის ნორმალურია და ნიშნავს, რომ მის შეცდომებს თავად ვერ გამოასწორებ.

რას უნდა დააკვირდე, სანამ სხვისი resource-ის გაშვებას გადაწყვეტ: os.execute, PerformHttpRequest უცნობ დომენზე, გრძელი base64 სტრიქონი, რომელიც load-ს გადაეცემა, ან ნებისმიერი add_ace, Lua ფაილში ჩაწერილი. გაჟონილი ფასიანი სკრიპტები FiveM სერვერების backdoor-ით დაინფიცირების მთავარი გზაა და payload ჩვეულებრივ ამ ოთხიდან ერთ-ერთია. Keeping a modded server clean ამ არგუმენტის ზოგადი ვერსიაა.

framework-ზე წერა#

ფორმა ყველგან ერთია: framework ობიექტს ერთხელ იღებ, მოთამაშის ობიექტს სერვერის ID-დან იღებ, მასზე მეთოდებს იძახებ.

ESX Legacy, server side
local ESX = exports['es_extended']:getSharedObject()RegisterCommand('wage', function(source)    local xPlayer = ESX.GetPlayerFromId(source)    if not xPlayer then return end    xPlayer.addAccountMoney('bank', 500)end, true)
QBCore, server side
local QBCore = exports['qb-core']:GetCoreObject()RegisterCommand('wage', function(source)    local Player = QBCore.Functions.GetPlayer(source)    if not Player then return end    Player.Functions.AddMoney('bank', 500, 'weekly-wage')end, true)

Qbox თავის core-ს პირდაპირ exports.qbx_core-ად აჩვენებს, ამიტომ იგივე საქმე არის exports.qbx_core:GetPlayer(source), მოთამაშის ფუნქციები კი შედეგზე კიდია. ESX-ის უფრო ძველი tutorial-ები export-ის ნაცვლად TriggerEvent('esx:getSharedObject', ...)-ს იყენებს; Legacy-ში ის ისევ მუშაობს, მაგრამ ახალ კოდში export უნდა დაწერო, რადგან ის resource-ის გაშვების რიგთან რბოლას ვერ შეხვდება.

RegisterCommand-ის ბოლოს true არის restricted დროშა. ის ბრძანებას ACE უფლებას აძლევს ყველასთვის ღია ყოფნის ნაცვლად, რაც განსხვავებაა admin ბრძანებასა და საჩუქარს შორის პირველისთვის, ვინც შენს resource-ების სიას წაიკითხავს.

შესრულება და სად არ არის framework დამნაშავე#

framework სერვერი, რომელიც იჭერს, თითქმის არასოდეს არის აპარატურის ნაკლებობაში. გაზომე, სანამ რამეს იყიდი:

  • resmon 1 კლიენტის F8 კონსოლში ჩამოთვლის ყოველ resource-ს მისი თითო კადრის CPU დროით. ყველაფერი, რაც 0.5 ms-ზე მაღლა რჩება, სანამ არაფერი ხდება, იმ საქმეს აკეთებს, რომლის კეთებაც არ სჭირდება.
  • txAdmin-ის resource monitor გაძლევს სერვერის მხარეს, სადაც ციკლებში ბაზის query-ები ჩანს.
  • კონსოლი ამბის მეორე ნახევარია. resource, რომელიც ყოველ tick-ზე შეცდომას აგდებს, სიამოვნებით შეჭამს ბირთვს და მიზეზს დაბეჭდავს - იხილე reading the console.

ტიპური მაჩვენებლები სერვერისთვის ჩვეულებრივი roleplay resource-ების სიით:

მოთამაშეებიResource-ებიRAMშენიშვნები
ტესტირება, 1-560-1002 GBშიშველი core და რამდენიმე სამუშაო
16-32100-2004 GBგავრცელებული პირველი საჯარო სერვერი
32-64200-3006-8 GBstreamed asset-ები მნიშვნელოვანი ხდება
64-128300+8-12 GBვინმეს resource-ების აუდიტი სჭირდება

ორი რამ, რაც მეხსიერებას მართლა ჭამს და არა CPU-ს, არის streamed asset-ები - custom ტრანსპორტი, MLO-ები, ტანსაცმელი - და resource-ები, რომლებიც თითო მოთამაშეზე დიდ ცხრილებს ქეშირებს. ორივე შენს resource-ების სიასთან ერთად იზრდება და არცერთი არ მცირდება, როცა მოთამაშეები მიდიან, სწორედ ამიტომაა ყოველკვირეული გადატვირთვა roleplay სერვერებზე სტანდარტული პრაქტიკა.

framework-ის განახლება შაბათ-კვირის დაკარგვის გარეშე#

framework-ის განახლებები plugin-ის განახლებებს არ ჰგავს. core-ის რელიზმა შეიძლება ბაზის სვეტები შეცვალოს, event-ები გადაარქვას და ყველა resource, ძველი სახელებისთვის დაწერილი, ერთდროულად გატეხოს.

  1. წაიკითხე რელიზის შენიშვნები breaking ცვლილებებზე, სანამ რამეს ჩამოტვირთავ. ESX-ის ან QBCore-ის მთავარ ვერსიის ზრდას ჩვეულებრივ მიგრაციის სია აქვს.
  2. ჯერ ბაზა გამოიტანე. ყოველი core განახლება, რომელიც სქემას ეხება, უკან დაბრუნებისას შეუქცევადია.
  3. გაუშვი ახალი core მეორე სერვერზე ბაზის ასლით და შენი რეალური resource-ების სიით და შედი. staging სერვერი იმავე ანგარიშზე ერთ პატარა გეგმას ჯდება და სწორედ ამ საღამოს გიფასებს.
  4. განაახლე framework და resource-ები, რომლებიც მასზეა დამოკიდებული, ერთად და არა სათითაოდ.
  5. ძველი resources/ საქაღალდე არქივად შეინახე, სანამ ახალი სრულ მოთამაშეთა სესიას არ გადაურჩება. What to do when a mod update breaks აღწერს დაბრუნების დისციპლინას.

RE:NODE-ზე FiveM სერვერებს txAdmin ხელმისაწვდომი აქვს, ფაილ მენეჯერი არქივებს ადგილზე ხსნის, ამიტომ resource-ის რელიზი პირდაპირ resources/-ში მიდის, SFTP ყოველ სერვერზეა მასობრივი ატვირთვისთვის და Schedules ჩანართს ყოველკვირეული გადატვირთვა შეუძლია. ლიცენზიის გასაღები Cfx.re პორტალიდან შენია და არა ჩვენი, ამიტომ ის შენთან ერთად გადადის.

FAQ#

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

არა. მათ სხვადასხვა ობიექტი, სხვადასხვა event-ები და სხვადასხვა ბაზის სქემა აქვს. რამდენიმე resource დაწერილია ორივეს გამოსავლენად და Qbox განზრახ პასუხობს qb-core-ზე თავსებადობისთვის, მაგრამ esx_ სამუშაოს სკრიპტს QBCore სერვერზე გადაწერა სჭირდება და არა კონფიგურაცია.

რომელი framework უნდა აირჩიოს სრულიად ახალმა სერვერმა?

QBCore, თუ კონკრეტული მიზეზი არ გაქვს. უმეტეს უფასო resource-ს, უმეტეს ფასიან სკრიპტს და თითქმის ყველა tutorial-ს სწორედ ის ეყრდნობა, რაც ბევრად მნიშვნელოვანია, როცა შუაღამისას გაიჭედები, ვიდრე ნებისმიერი არქიტექტურული არგუმენტი. აირჩიე Qbox, თუ საკუთარი resource-ების წერას აპირებ და წყაროს კითხვა გიჭირს.

მართლა უნდა ვიხადო resource-ებში ფული?

არა, თუმცა სერვერების უმეტესობა იხდის. უფასო მარაგი სამუშაოებს, მაღაზიებს, გარაჟებს და ინვენტარებს სავსებით ადეკვატურად ფარავს. ფასიანი სკრიპტები ყიდულობს დახვეწილობას და მხარდაჭერას. რაც არ უნდა გააკეთო, გაჟონილი ფასიანი სკრიპტები არ დააყენო: ისინი FiveM სერვერზე backdoor-ის ყველაზე გავრცელებული გზაა, ხოლო ადამიანი, ვინც ფაილი მოგცა, ავტორი არ არის.

საიდან მოდის სამუშაოები თითოეულ framework-ზე?

ESX მათ ბაზის jobs და job_grades ცხრილებიდან კითხულობს, ამიტომ ახალი სამუშაო insert-ია. QBCore და Qbox მათ shared Lua ფაილიდან კითხულობს, ამიტომ ახალი სამუშაო ცხრილის ჩანაწერია და გადატვირთვა. სამივეს შემდეგ სჭირდება სამუშაოს resource, რომ ამ სამუშაოს რაიმე საქმე მისცეს.

რამდენი მეხსიერება სჭირდება framework სერვერს?

ორი გიგაბაიტი core-სა და რამდენიმე სამუშაოს ტესტირებისთვის უშვებს. ოთხი საჯარო სერვერის რეალისტური მინიმუმია, და სრული roleplay სია 64 მოთამაშეზე ჩვეულებრივ ექვსსა და რვას შორის არის. თუ ამაზე მეტზე ხარ 200-ზე ნაკლები resource-ით, რაღაც გაჟონავს და არა დაკავებულია.

მჭირდება საკუთარი ლიცენზიის გასაღები?

დიახ. FXServer არ ეშვება Cfx.re ლიცენზიის გასაღების გარეშე, რომელიც Cfx.re პორტალიდან შენს სახელზე გაიცემა და მიბმულია მისამართზე, რომელზეც მუშაობს, ამიტომ სერვერის გადატანა ნიშნავს გასაღების ხელახლა გაცემას და არა კოპირებას.


კომენტარები

სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.

0/2000