Qbox FiveM სერვერი: მოწყობა, resource-ები და ჩატვირთვის რიგი

ყველაზე სწრაფად მომუშავე Qbox სერვერი ოფიციალური txAdmin recipe-ით მიიღება: გაუშვი FXServer, გახსენი txAdmin, აირჩიე Popular Recipes, შემდეგ QBox Framework, მიუთითე მონაცემთა ბაზა და დააცადე დაახლოებით სამოცი resource-ის ჩამოტვირთვა და SQL-ის იმპორტი. ამის ქვეშ მთელი სისტემა ხუთ resource-ზეა დაფუძნებული - qbx_core, ox_lib, oxmysql, ox_inventory და ox_target - და სამ მოთხოვნაზე, რომელსაც ხშირად ივიწყებენ: ჩართული OneSync, FXServer-ის ახალი build და MySQL-ის ნაცვლად MariaDB ბაზა. ამ პოსტის დანარჩენი ნაწილი გიჩვენებს, როგორ ერთვის ეს ნაწილები ერთმანეთს, საიდან აიღო დანარჩენი Qbox resource-ები, რომელი convar-ები ცვლის core-ის ქცევას და რას გეუბნება კონსოლი, როცა სერვერი არ ირთვება.

თუ ჯერ არ გაგიკეთებია არჩევანი framework-ებს შორის, ESX vs QBCore vs Qbox შედარებაა. ეს პოსტი ვარაუდობს, რომ გადაწყვეტილება უკვე მიღებულია.

რა სჭირდება Qbox-ს ინსტალაციამდე#

Qbox არის QBCore-ის fork, გადაკეთებული Overextended (ox_*) resource-ების საფუძველზე. გარემოს მიმართ ის QBCore-ზე ბევრად მომთხოვნია და პირველი გაშვების წარუმატებლობების უმეტესობა გარემოს პრობლემაა და არა Qbox-ის.

სერვერის build. qbx_core-ის მიმდინარე მანიფესტში არის /server:10731 ტიპის დამოკიდებულება, რაც ნიშნავს, რომ FXServer უფრო ძველ build-ზე resource-ის გაშვებაზე უარს იტყვის. ეს რიცხვი იზრდება, რადგან Qbox ახალ native-ებს იყენებს, ამიტომ წაიკითხე იმ release-ის მანიფესტი, რომელიც ჩამოტვირთე, და ფორუმის პოსტში ნანახ რიცხვს ნუ ენდობი - ამ პოსტსაც. თუ ჩამორჩენილი ხარ, FiveM სერვერის artifact-ების განახლება გასწავლის, როგორ გადახვიდე ახალ build-ზე დანარჩენის დაუზიანებლად.

OneSync. Qbox მის გარეშე არ მუშაობს. txAdmin-ის ვერსიის მიხედვით ის ან txAdmin-ის FXServer settings გვერდზე არის პარამეტრი, ან server.cfg-ში set onesync on ხაზი; Qbox recipe-ის server.cfg ასეთ ხაზს არ წერს, ამიტომ შეამოწმე, შენთან რომელი ვარიანტი მუშაობს. OneSync და მოთამაშეთა slot-ები განმარტავს, რას ცვლის ის რეალურად და რატომ არის მასზე დამოკიდებული ყველა თანამედროვე framework.

MariaDB და არა MySQL. ეს ის პუნქტია, რომელიც ხალხს ცუდად უკვირს. Qbox-ის ინსტალაციის გზამკვლევი პირდაპირ ამბობს: მინიმუმია MariaDB 10.9.0, რეკომენდებულია მიმდინარე LTS release, MySQL არ არის მხარდაჭერილი და XAMPP არასდროს უნდა გამოიყენო. oxmysql ორივე ძრავს დაუკავშირდება, ამიტომ MySQL სერვერზე პირველი გაშვება, როგორც წესი, გაივლის - პრობლემები მოგვიანებით იწყება: SQL-ში, რომელიც MariaDB-ის ქცევაზეა დამოკიდებული, ცხრილებს შორის collation-ის შეუსაბამობაში და იმაში, რომ Qbox-ის მხარდაჭერის არხებში ამის გასწორებაში არავინ დაგეხმარება. თუ ბაზა hosted გაქვს და არ იცი, რომელი ძრავია, phpMyAdmin-ში გაუშვი SELECT VERSION();. MariaDB სერვერი ამას ვერსიის სტრიქონში წერს; უბრალო რიცხვი, მაგალითად 8.4.x, MySQL-ია.

ინსტალაცია txAdmin recipe-ით#

recipe არის YAML ფაილი, რომელსაც txAdmin თავიდან ბოლომდე ასრულებს: ჩამოტვირთავს repository-ებს, ფოლდერებში ამოალაგებს, კონფიგურაციის ფაილებს ჩაწერს და SQL-ს შემოიტანს. Qbox-ისას Qbox-ის პროექტი ინახავს და მიმდინარე txAdmin-ზე ის Popular Recipes-ში ჩანს.

1. გაუშვი FXServer ცარიელი data ფოლდერით. txAdmin გაიხსნება და გაძლევს PIN-ს Cfx.re ანგარიშის დასაკავშირებლად.
2. აირჩიე Popular Recipes, შემდეგ QBox Framework.
3. როცა მოგთხოვს, ჩასვი Cfx.re-ის licence key. გასაღები შენია და Cfx.re პორტალზე გენერირდება - საიდან მოდის, ნახე FiveM სერვერი და txAdmin.
4. შეიყვანე მონაცემთა ბაზის მონაცემები. txAdmin მათგან connection string-ს აგებს და recipe-ის ყველა SQL ფაილს ამ ბაზაზე გაუშვებს.
5. დააცადე დასრულება, გადახედე txAdmin-ის რედაქტორში ნაჩვენებ გენერირებულ server.cfg-ს და გაუშვი სერვერი.

recipe ბევრს ჩამოტვირთავს. ამ დროისთვის resource-ებს ასე ალაგებს:

resources/  [ox]/          ox_lib, oxmysql, ox_target, ox_inventory, ox_doorlock, ox_fuel  [qbx]/         qbx_core, qbx_spawn, qbx_garages, qbx_police, qbx_ambulancejob...  [standalone]/  cfx defaults, illenium-appearance, Renewed-Banking, loadscreen...  [voice]/       pma-voice, mm_radio  [npwd]/        npwd (phone), qbx_npwd  [npwd-apps]/   phone apps  [assets]/      map assets

სერვერის root-ში ის ხუთ კონფიგურაციის ფაილსაც წერს: server.cfg, permissions.cfg, ox.cfg, voice.cfg და misc.cfg. დაყოფა შეგნებულია - server.cfg იკითხება მარტივად, ხოლო ox_inventory-ისა და ox_target-ის პარამეტრების გრძელი სია ox.cfg-ში ცხოვრობს.

SQL, რომელსაც ის შემოიტანს, რამდენიმე ფაილია და არა ერთი: ბაზისური qbox.sql, შემდეგ qbx_core.sql, შემდეგ ავტომობილების, ავტოსალონის, ავტომობილების გაყიდვის, weed-ის, lap race-ისა და ნარკოტიკების ცხრილები და ტელეფონის საკუთარი იმპორტი. ეს მნიშვნელოვანია, თუ ოდესმე ხელით აშენებ, რადგან ერთის გამოტოვება resource-ს ტოვებს, რომელიც სუფთად ირთვება და პირველივე გამოყენებისას ER_NO_SUCH_TABLE-ს გაგდებს.

recipe განიხილე როგორც საწყისი წერტილი. ის აყენებს job-ებს, ძარცვებს და ტელეფონს, რომელიც შეიძლება არ გინდოდეს, და თითოეული მათგანი განსაახლებელიცაა და გაფუჭებაც შეუძლია. გავრცელებული და გონივრული ნაბიჯია, რომ recipe-მ სერვერი ააშენოს, ერთი საღამო ითამაშო და ნახო, როგორია Qbox, როცა მუშაობს, და მერე [qbx] ფოლდერი დაჭრა იმამდე, რაზეც შენი სერვერი რეალურად არის.

core resource-ები და თითოეულის დანიშნულება#

framework-ს ხუთი resource ატარებს. დანარჩენი არჩევითია; ეს ხუთი - არა.

`qbx_core` თვითონ framework-ია: მოთამაშეები და პერსონაჟები, ფული, job-ები და gang-ები (ჩაშენებული multijob-ით), კავშირის რიგი, პერსონაჟის არჩევის ეკრანი და თავსებადობის ხიდი, რომელიც qb-core-ზე პასუხობს. მისი კონფიგურაცია qbx_core/config/-შია (client.lua, server.lua, shared.lua), ხოლო თამაშის მონაცემები - job-ები, gang-ები, ავტომობილები, იარაღი - qbx_core/shared/-ში. QBCore-ისგან განსხვავებით, Qbox-ს core ობიექტი არ აქვს. export-ებს პირდაპირ იძახებ:

local player = exports.qbx_core:GetPlayer(source)if not player then return endplayer.Functions.AddMoney('bank', 500, 'weekly-wage')

`oxmysql` არის მონაცემთა ბაზის ხიდი. ის კითხულობს mysql_connection_string-ს და ყველა სხვა resource-ს თავის query ფუნქციებს აძლევს. FiveM-ის ბაზები და oxmysql შეიცავს connection string-ს, იმპორტს და ნელი query-ების მუშაობას, ამიტომ აქ არ მეორდება.

`ox_lib` არის საერთო ბიბლიოთეკა: callback-ები, შეტყობინებები, მენიუები, progress bar-ები, ზონები, locale-ები. თითქმის ყველა Qbox resource მას მანიფესტში '@ox_lib/init.lua'-ით ტვირთავს. Qbox-ში შეტყობინებები ox_lib-ზე გადის, ამიტომ საკუთარი notification resource-ის ჩასმა ox_lib-ის და არა qbx_core-ის რედაქტირებას ნიშნავს.

`ox_inventory` ცვლის QBCore-ის slot inventory-ს. ნივთები განსაზღვრულია ox_inventory/data/items.lua-ში, მაღაზიები და stash-ები მის გვერდით data ფაილებია, ნივთების სურათები კი ox_inventory/web/images-შია. მას უნდა უთხრა, რომელ framework-ზე მუშაობს, setr inventory:framework "qbx"-ით - recipe-ის ox.cfg ამას აყენებს, ხოლო ხელით აგებული სერვერი, რომელიც ამას დაივიწყებს, ღებულობს inventory-ს, რომელსაც ვერც ერთ მოთამაშეს პოულობს.

`ox_target` არის "მესამე თვალის" ურთიერთქმედების სისტემა: დააჭირე ღილაკს, შეხედე ობიექტს, მიიღე ვარიანტები. Qbox-ის job-ების უმეტესობა თავის ქმედებებს მასში არეგისტრირებს, ამიტომ სერვერზე მის გარეშე პოლიციელები და მექანიკოსები ვერაფერს აკეთებენ.

ამ ხუთის გარშემო recipe ამატებს ნაწილებს, რომლებიც როლურ სერვერს ნაგულისხმევად აქვს: qbx_spawn გაჩენის ადგილის ასარჩევად, qbx_vehicles და qbx_garages პირადი მანქანებისთვის, qbx_vehiclekeys, qbx_medical და qbx_ambulancejob, qbx_police, illenium-appearance ტანსაცმლისთვის, Renewed-Banking და pma-voice ახლომდებარე ხმოვანი კომუნიკაციისთვის.

სად ვიპოვოთ Qbox resource-ები#

ყველაფერი ოფიციალური GitHub-ზე Qbox-project ორგანიზაციაშია და ყველა ოფიციალური resource qbx_ პრეფიქსით იწოდება. docs.qbox.re დოკუმენტაციის საიტზე თითოეული core resource-ის გვერდზე არის მისი export-ები, event-ები და convar-ები.

სამი წესი უმეტეს პრობლემას გიშველის:

• ჩამოტვირთე release-ები და არა მწვანე Code ღილაკი. ox_lib-სა და ox_inventory-ს frontend framework-ზე დაწერილი web ინტერფეისები აქვთ და წყაროს ხე აგებულ ფაილებს არ შეიცავს. release zip-ი შეიცავს. სერვერი, რომელიც ox_inventory-ს source ჩამოტვირთვიდან უშვებს, ბეჭდავს გაფრთხილებას, რომ UI აგებული არ არის, და მოთამაშეები ხსნიან inventory-ს, რომელიც იქ არ არის. Qbox-ის დოკუმენტაციაც სტაბილურობისთვის მხოლოდ საკუთარი resource-ების გამოშვებული ვერსიების გაშვებას გირჩევს.
• 1.0.0-ზე დაბალი ვერსიის ნომრები ნიშნავს beta-ს. Qbox ამას პირდაპირ ამბობს. გამოსაყენებელია, მაგრამ minor ვერსიებს შორის breaking change-ები მოელოდე.
• დაარქივებული repository-ები დასრულებულია და არა მიტოვებული. რამდენიმე ძველი Qbox resource დაარქივდა, როცა მათი საქმე სხვაგან გადავიდა - ჩვეულებრივ qbx_core-ში ან რომელიმე ox_* resource-ში. თუ გზამკვლევი გთხოვს resource-ის დაყენებას, რომლის repository დაარქივებულია, დაყენებამდე შეამოწმე, რა ჩაანაცვლა.

მესამე მხარის resource-ები სამ ჯგუფად იყოფა. Qbox-ისთვის დაწერილი resource-ები ისე მუშაობს, როგორც მოელი. Overextended სტეკისთვის დაწერილი resource-ები (ox_*-ის გამთვალისწინებელი) ჩვეულებრივ მუშაობს, რადგან Qbox მასზეა აგებული. QBCore-სთვის დაწერილი resource-ები ხიდით მუშაობს - ის მომდევნო თავშია - რეალური შეზღუდვებით.

როცა resource-ს იპოვი, დაყენებამდე წაიკითხე მისი fxmanifest.lua: dependencies ბლოკი გეუბნება, რა სჭირდება, lua54 'yes' გეუბნება, რომ ის თანამედროვეა, ხოლო ყველაფერი, რაც os.execute-ს იძახებს ან უცნობ დომენზე HTTP მოთხოვნებს აგზავნის, შეჩერების საკმარისი მიზეზია. მოდიფიცირებული სერვერის სისუფთავე ამის ყოველ ჯერზე გაკეთების გრძელი არგუმენტია.

ensure რიგი და როგორ იწყებს recipe ყველაფერს#

აი გაშვების თანმიმდევრობა, რომელსაც Qbox recipe წერს, შემოკლებული კომენტარებით:

exec voice.cfgexec ox.cfgensure mapmanagerensure chatensure spawnmanagerensure baseeventsensure ox_libensure qbx_coreensure ox_targetensure [ox]ensure [qbx]ensure [standalone]ensure [voice]ensure [assets]ensure [npwd-apps]ensure qbx_npwdensure npwdexec permissions.cfgexec misc.cfg

მასში ორი რამ არასწორად გამოიყურება და არასწორი არ არის.

პირველი, oxmysql qbx_core-მდე არსად არის დასახელებული. არც სჭირდება, რადგან qbx_core თავისი მანიფესტის dependencies-ში oxmysql-სა და ox_lib-ს აცხადებს, ხოლო FXServer resource-ის დამოკიდებულებებს თვითონ resource-მდე იწყებს. აშკარა ensure ox_lib სიცხადისთვის არის; დამოკიდებულების მექანიზმი ამას ისედაც გააკეთებდა. ამიტომაც ხდება, რომ oxmysql-ის ფოლდერის არარსებობა ხმამაღლა qbx_core-ზე ვარდება და არა ჩუმად მოგვიანებით.

მეორე, ensure [ox] qbx_core-ის შემდეგ სრულდება, თუმცა ox_inventory ამ ფოლდერშია. ეს სწორია: Qbox-ზე მომუშავე ox_inventory-ს სურს, რომ core უკვე ჩართული იყოს, რათა მოთამაშეები და მათი ნივთები წაიკითხოს. კვადრატულ ფრჩხილებში ჩასმული ფოლდერის ensure იწყებს მასში მყოფ ყველა resource-ს, რიგით, რომელსაც არ უნდა დაეყრდნო, ამიტომ ყველაფერი, რასაც მკაცრი რიგი სჭირდება, ფოლდერამდე საკუთარ ხაზზეა დასახელებული.

შენი დამატებების წესები აქედან გამომდინარეობს. resource, რომელიც Qbox-ის export-ებს იყენებს, qbx_core-ის შემდეგ მოდის. resource, რომელიც ox_inventory-ის ნივთებს იყენებს, [ox]-ის შემდეგ მოდის. თუ საკუთარ resource-ებს ისეთ ფოლდერში აგდებ, როგორიცაა [custom], სიის ბოლოს, [qbx]-ის შემდეგ, დაამატე ensure [custom]. ხოლო exec ox.cfg ხაზი ensure ხაზებამდე უნდა იყოს, რადგან setr მნიშვნელობები resource-ის დაწყებისას იკითხება - convar, რომელიც resource-ის გაშვების შემდეგ დაყენდა, არაფერს ცვლის შემდეგ restart-მდე. ფაილის ყველა დირექტივა განმარტებულია FiveM server.cfg განმარტებით.

qbx_core convar-ები#

Qbox-მა ბევრი რამ, რაც ადრე Lua კონფიგურაცია იყო, convar-ებში გადაიტანა, ამიტომ core-ის ქცევა server.cfg-ში იცვლება და არა ფაილების რედაქტირებით, რომლებსაც შემდეგი განახლება გადააწერს. ესენია დოკუმენტირებული convar-ები ნაგულისხმევი მნიშვნელობებით:

რამდენიმეს თითო წინადადება ეკუთვნის.

Multijob. თუ qbx:max_jobs_per_player-ს 3-ზე ასწევ და qbx:setjob_replaces-ს false-ზე დააყენებ, მიიღებ multijob-ს დამატებითი resource-ის გარეშე: /setjob არსებულს არ გადააწერს, ახალ job-ს დაამატებს და მოთამაშე მათ შორის გადაერთვება. QBCore-ზე სწორედ ეს იყო ცალკე multijob სკრიპტის დაყენების ყველაზე გავრცელებული მიზეზი.

`cleanPlayerGroups`. გაშვებისას core წაშლის player_groups-ის ჩანაწერებს, რომლებიც აღარ განსაზღვრულ job-ებზე ან gang-ებზე მიუთითებს qbx_core/shared/-ში. job-ის წაშლის შემდეგ ეს სწორედ ის არის, რაც გინდა - და უსიამოვნო სიურპრიზი, თუ jobs.lua-ში job გადაარქვი და ელოდი, რომ ყველას შეუნარჩუნდება. გადარქმევა ასე გააკეთე: დაამატე ახალი job, გადაიყვანე ხალხი, მერე წაშალე ძველი.

ავტომობილების persistence. FiveM ხანდახან შლის entity-ებს, რომლებსაც არ უნდა შლიდეს, და მოძრაობისას პირადი მანქანის გაქრობა ის შედეგია, რომელსაც მოთამაშეები ამჩნევენ. qbx:enableVehiclePersistence მას თავისი თვისებებით ხელახლა ქმნის. recipe მას set-ის ნაცვლად setr-ით წერს, ისევე როგორც qbx:enableBridge-ს, რადგან client მხარეც მათ კითხულობს. შეცვლისას იგივე ზმნა შეინარჩუნე.

`bucketLockdownMode`. relaxed და strict client-ებს უკრძალავს ქსელური entity-ების შექმნას ნაგულისხმევ routing bucket-ში, რაც spawn-spam ჩიტერების მთავარი გზაა. strict არღვევს ყველა resource-ს, რომელიც client-იდან entity-ებს ქმნის, ამიტომ ჯერ staging ასლზე გამოცადე.

გახსოვდეს set-ისა და sets-ის წესი ყველა სხვა FiveM გზამკვლევიდან: sets მნიშვნელობას სერვერების სიაში აქვეყნებს. ამ მნიშვნელობებიდან არცერთი საიდუმლო არ არის, მაგრამ set-ის წერის ჩვევა მნიშვნელოვანია ერთი ხაზისთვის, რომელიც საიდუმლოა - mysql_connection_string.

QBCore resource-ები Qbox-ზე: ხიდი#

როცა qbx:enableBridge ჩართულია, qbx_core აცხადებს provide 'qb-core'-ს, ამიტომ resource, რომელიც qb-core-ს დამოკიდებულებად ასახელებს, დაკმაყოფილებულია, ხოლო exports['qb-core']:GetCoreObject() აბრუნებს ობიექტს, რომელიც QBCore-ისას ჰგავს. კარგად დაწერილი QBCore resource-ების უმეტესობა უცვლელად მუშაობს.

რაც ხიდს ვერ გადაურჩება:

• ცხრილებზე პირდაპირი წვდომა. resource, რომელიც მოთამაშის ფუნქციების ნაცვლად თვითონ წერს QBCore-ის players სვეტებში, Qbox-ს გვერდს უვლის და შეიძლება ისეთ სვეტებში წეროს, რომლებიც ახლა სხვაგვარადაა სტრუქტურირებული.
• Inventory კოდი. ყველაფერს, რაც qb-inventory-ს export-ებს იძახებს ან QBCore-ის ნივთის ფორმატს ელოდება, inventory-ის გამოძახებები ox_inventory-სთვის უნდა გადაუწეროს.
• არაპუბლიკური შიდა ნაწილები. resource-ები, რომლებიც qb-core/-იდან ფაილებს პირდაპირ კითხულობენ ან ისეთ ქცევას ეყრდნობიან, რომელიც QBCore-ს არასდროს დაუდოკუმენტებია, ისე ტყდება, რომ მიზეზის პოვნა დამღლელია.
• Multijob სკრიპტები საკუთარი ცხრილებით. ისინი ჩაშენებულ multijob-თან კონფლიქტობს; Qbox-ის დოკუმენტაცია ამბობს, რომ ისინი მხოლოდ მაშინ იმუშავებს, თუ qbx_core-ის export-ებზე გადიან.

ნივთები ერთადერთი ადგილია, სადაც ხიდი ორივე მიმართულებით მუშაობს. qbx_core/shared/items.lua-ში დამატებული ნივთი ox_inventory-ს ავტომატურად გადაეცემა, რაც ხიდით მომუშავე QBCore resource-ებს აკმაყოფილებს. მაგრამ ნივთის ქცევა, რომელსაც client ან server export-ები სჭირდება - მაგალითად, ნივთის გამოყენება - მაინც ხელით უნდა ჩაიწეროს ox_inventory/data/items.lua-ში. ახალი ნივთისთვის, რომელსაც მხოლოდ Qbox-ის გამთვალისწინებელი resource-ები იყენებენ, განსაზღვრე ის პირდაპირ ox_inventory-ში და items.lua საერთოდ გამოტოვე.

ადმინები და უფლებები#

recipe-ის permissions.cfg ACE კონფიგურაციას შეიცავს. txAdmin ინსტალაციისას შენს საკუთარ identifier-ს მასში master admin-ად წერს, add_principal identifier.fivem:1234567 group.admin ტიპის ხაზით. Qbox-ის ადმინ ბრძანებები - /setjob, /setgang და დანარჩენი - შეზღუდული ბრძანებებია, რომლებიც ACE ჯგუფებზე მოწმდება, ამიტომ ყველას, ვინც მათ უნდა იყენებდეს, principal ხაზი სჭირდება. ფაილი იკითხება, როცა server.cfg მას ასრულებს, ამიტომ რედაქტირების შემდეგ გადატვირთე სერვერი ან ცოცხალ კონსოლში გაუშვი exec permissions.cfg.

ადმინების სია ინახე permissions.cfg-ში და არსად სხვაგან. resource-ის Lua-დან მიცემული უფლება ფაილის აუდიტისას უხილავია და ზუსტად ის არის, რასაც backdoor-იანი resource აკეთებს. Discord უფლებები და whitelist FiveM-ისთვის განმარტავს, როგორ დააკავშირო ეს ჯგუფები identifier-ების ხელით აკრეფის ნაცვლად Discord როლებთან.

გაშვების გავრცელებული შეცდომები და რას ნიშნავს ისინი#

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

`qbx_core` არ იწყება და `/onesync`-ზე ან `/server:`-ზე დაუკმაყოფილებელ დამოკიდებულებას ასახელებს. OneSync გამორთულია ან FXServer build მანიფესტის მოთხოვნაზე ძველია. ჩართე OneSync txAdmin-ის პარამეტრებში ან განაახლე artifact-ები. qbx_core-ის რედაქტირება ამას ვერ გამოასწორებს.

"No such export GetCoreObject in resource qbx_core". QBCore resource qbx_core-ს core ობიექტს სთხოვს, რომელიც Qbox-ს არ აქვს. გამოსწორება resource-შია: მან უნდა გამოიძახოს exports['qb-core']:GetCoreObject(), რომელსაც ხიდი პასუხობს. ასევე შეამოწმე, ხიდი გამორთული ხომ არ არის.

"This resource is still using the deprecated qbx_core utils". გაფრთხილებაა და არა შეცდომა. დასახელებული resource ძველი release-ია; ჩამოტვირთე მისი უახლესი ვერსია.

მოთამაშეები loading screen-ზე ჩარჩნენ. სტანდარტულ ინსტალაციაზე ეს თითქმის ყოველთვის იმიტომ ხდება, რომ პერსონაჟის არჩევა loading screen-ს არასდროს ხურავს, ჩვეულებრივ ჩაშენებული multicharacter-ის ჩანაცვლების შემდეგ. ან server.cfg-ში დააყენე loadscreen:externalShutdown false-ზე, ან შენს character resource-ს გამოაძახებინე ShutdownLoadingScreen() და ShutdownLoadingScreenNui(). თუ არაფერი შეგიცვლია, კონსოლში ზემოთ მოძებნე resource, რომელიც ვერ ჩაირთო - qbx_spawn-ის ან oxmysql-ის ჩავარდნა იგივე სიმპტომს იძლევა.

"Can't create table ... (Foreign Key Constraint is incorrectly formed)". collation-ის შეუსაბამობა შესაქმნელ ცხრილსა და იმას შორის, რომელზეც ის მიუთითებს - გავრცელებულია, როცა სხვადასხვა resource-ის SQL სხვადასხვა ნაგულისხმევით იყო დაწერილი, და უფრო გავრცელებულია MySQL-ზე. Qbox-ის გამოსწორებაა, რომ CREATE TABLE ბრძანებები აშკარა character set-ით და collation-ით დაამთავრო, შემდეგ კი ცხრილი წაშალო და თავიდან შექმნა:

CREATE TABLE IF NOT EXISTS example_table (  id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,  citizenid VARCHAR(50) NOT NULL) DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

"SCRIPT ERROR: failed to load model". მოდელი timeout-ში ვერ ჩაიტვირთა, ჩვეულებრივ ნელ client-ზე. თუ შეცდომა qbx_core-იდან მოდის, გაზარდე loadingModelsTimeout qbx_core/config/client.lua-ში.

Inventory ცარიელი იხსნება ან საერთოდ არ იხსნება. ან ox_inventory source ჩამოტვირთვაა აგებული UI-ის გარეშე, ან inventory:framework არ არის qbx-ზე დაყენებული, რადგან ox.cfg არასდროს შესრულებულა. შეამოწმე, არის თუ არა exec ox.cfg ensure ხაზებზე ზემოთ.

`ER_NO_SUCH_TABLE` ერთი ფუნქციიდან. recipe-ის SQL ფაილებიდან ერთი არ შემოვიდა. იპოვე resource-ის .sql ფაილი და phpMyAdmin-ით შემოიტანე - დიდ ფაილებზე ნახე phpMyAdmin-ის იმპორტის გზამკვლევი - ფაილის პირველი ხაზების წაკითხვის შემდეგ, DROP TABLE-ის გამოსარკვევად.

Qbox hosted სერვერზე#

RE:NODE-ზე FiveM სერვერს txAdmin ხელმისაწვდომი აქვს, ამიტომ ზემოთ აღწერილი recipe-ის პროცესი ისე მუშაობს, როგორც დაწერილია: სერვერი txAdmin-ში იწყება, აკავშირებ Cfx.re ანგარიშს და ჩასვამ შენს საკუთარ licence key-ს. გეგმაში შედის მონაცემთა ბაზის slot, რომელიც პანელიდან იქმნება გენერირებული host-ით, მომხმარებლითა და პაროლით, და Open in phpMyAdmin ღილაკი, რომელიც ერთჯერადი token-ით შეგიყვანს. პანელი არ ასახელებს ძრავს ამ slot-ის უკან, ამიტომ Qbox-ზე გადაწყვეტამდე გაუშვი SELECT VERSION(); და თუ ეს MariaDB არ არის, ღია თვალით გადაწყვიტე, შეგიძლია თუ არა მხარდაუჭერელ ბაზასთან ცხოვრება.

ფაილ მენეჯერი release zip-ებს ადგილზე ამოალაგებს, რითაც resource-ს ახალი release-ით ცვლი სერვერის ლოკალური ასლის გარეშე, ხოლო SFTP მასობრივ ატვირთვებს ემსახურება, მაგალითად სრულ [qbx] ფოლდერს. მეხსიერება გეგმის ლიმიტია: სრული recipe თავისი ტელეფონით, რუკის asset-ებით და ყველა job-ით უფრო მძიმეა, ვიდრე დაჭრილი სია, ამიტომ რამდენი RAM სჭირდება FiveM სერვერს ღირს წაკითხვად tier-ის არჩევამდე. თუ სერვერი ლიმიტს მიაღწევს, ის swap-ის ნაცვლად ჩერდება და სუფთად გადაიტვირთება, ამიტომ სერვერი, რომელიც დატვირთვისას განუწყვეტლივ restart-დება, ზომის პრობლემაა, რომელიც resmon-ით და txAdmin-ის მონიტორით უნდა შეისწავლო და არა საიდუმლოება.

ნებისმიერი Qbox resource-ის განახლებამდე გააკეთე backup და გაიტანე ბაზა. Qbox-ის release-ები სქემებს QBCore-ზე უფრო ადვილად ცვლის, ხოლო staging სერვერი, რომელიც ბაზის ასლზე მუშაობს - ნახე staging და production ერთ ანგარიშზე - ის ადგილია, სადაც განახლება შენს resource-ების სიას პირველად უნდა შეხვდეს.

FAQ#

თავსებადია Qbox QBCore სკრიპტებთან?

უმეტესად. ხიდი qb-core-ზე პასუხობს და მის დოკუმენტირებულ export-სა და event-ებს ამუშავებს. სკრიპტებს, რომლებიც QBCore-ის ცხრილებს პირდაპირ ეხებიან, ძველ inventory-ს იყენებენ ან არადოკუმენტირებულ შიდა ნაწილებს ეყრდნობიან, ცვლილებები სჭირდებათ. თითოეული გამოსცადე და ნუ ივარაუდებ.

აუცილებელია txAdmin recipe-ის გამოყენება?

არა, მაგრამ ეს ცნობილად სწორ საწყისამდე ყველაზე სწრაფი გზაა. ხელით დაგჭირდება ხუთი core resource მათი release-ებიდან, SQL qbx_core-დან და თითოეული feature resource-იდან, ox.cfg ან ეკვივალენტური setr ხაზები, ჩართული OneSync და ზემოთ ნაჩვენები ensure რიგი.

შემიძლია recipe-ის დაყენებული resource-ების წაშლა?

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

სად დავამატო ახალი job?

qbx_core/shared/jobs.lua-ში, როგორც ცხრილის ჩანაწერი თავისი grade-ებით, შემდეგ restart. job resource-ი მერე მას საქმეს აძლევს. მოთამაშეები ინიშნებიან /setjob-ით, რომელიც qbx:setjob_replaces-ის მიხედვით ან ამატებს, ან ანაცვლებს.

რატომ ითხოვს Qbox MariaDB-ს?

მისი დოკუმენტაცია MariaDB 10.9-ს მინიმუმად ასახელებს და აცხადებს, რომ MySQL არ არის მხარდაჭერილი, ამიტომ მისი SQL და მხარდაჭერა MariaDB-ზეა დაწერილი. MySQL სერვერი პრაქტიკაში ხშირად მუშაობს, მაგრამ მასზე პრობლემები შენი გადასაჭრელია.

რამდენი მოთამაშის დატევა შეუძლია Qbox სერვერს?

ეს OneSync-ზე და შენი licence tier-ზეა დამოკიდებული და არა Qbox-ზე. თავად framework tick-ზე ძალიან ცოტას ხარჯავს; აპარატურას ადგენს resource-ების სია, რომელსაც მასზე აგებ, და streamed asset-ები.