QBCore-დან Qbox-ზე გადასვლა: bridge, ინვენტარი და ბაზა

QBCore სერვერის Qbox-ზე გადაყვანა უფრო ბაზისა და ინვენტარის საქმეა, ვიდრე სკრიპტირების. qbx_core აცხადებს provide 'qb-core'-ს და მოყვება bridge, რომელიც პასუხობს ძველ exports['qb-core']:GetCoreObject() გამოძახებებს, ამიტომ qb-* სამუშაოების, მაღაზიებისა და HUD-ის resource-ების უმეტესობა რედაქტირების გარეშე ირთვება. ის, რაც არ გადადის, არის qb-inventory: Qbox მუშაობს მხოლოდ ox_inventory-ზე და უარს ამბობს გაშვებას, თუ qb-inventory ჩართულია, ამიტომ item-ების აღწერები, ყველა მოთამაშის ინვენტარი და შენი stash-ები, ბარგაჟნიკები და სახელური ყუთები (gloveboxes) გადასაყვანია. გარდა ამისა, qbx_core.sql ცვლის players ცხრილს და ამატებს player_groups ცხრილს multijob-ისთვის. ყველაფერი ჯერ სერვერისა და ბაზის ასლზე გააკეთე, ძველი resources/ საქაღალდე და ბაზის dump შეუხებელი შეინახე და გადართვა კვირის კი არა, ერთი საღამოს საქმე იქნება.

რომელი framework აირჩიო და რა არის თითოეული, აღწერილია პოსტში FiveM frameworks: ESX vs QBCore vs Qbox. აქ ვვარაუდობთ, რომ არჩევანი უკვე გაკეთებულია და გაქვს მოქმედი QBCore სერვერი რეალური მოთამაშეების მონაცემებით, რომლის დაკარგვაც არ გინდა.

რა იცვლება რეალურად QBCore-სა და Qbox-ს შორის#

Qbox QBCore-ის გაგრძელებაა და არა ნულიდან გადაწერა, ამიტომაც არის მიგრაცია საერთოდ შესაძლებელი. მოთამაშის ობიექტს ისევ აქვს PlayerData, citizenid, charinfo, money, job და gang. players ცხრილი სახელს და სვეტების უმეტესობას ინარჩუნებს. ბირთვის გარშემო მყოფი ყველაფერი გადაინაცვლა.

ბოლო სამ რიგში იმალება შენი სამუშაოს უმეტესი ნაწილი. Qbox-ს ასევე სჭირდება, რომ ox_lib და oxmysql ჯერ გაშვებული იყოს, OneSync ჩართული და FXServer-ის ახალი build. მიმდინარე qbx_core-ის manifest დამოკიდებულებად ასახელებს /server:10731-ს, ანუ ძველ artifact-ზე ის არ ჩაირთვება. ეს ნომერი ვერსიებთან ერთად იცვლება, ამიტომ წაიკითხე fxmanifest.lua იმ ვერსიაში, რომელსაც ჩამოტვირთავ, და თუ შენი სერვერი ჩამორჩება, იხილე FiveM server updates and artifacts.

როგორ მუშაობს qb-core bridge და სად მთავრდება მისი შესაძლებლობები#

Bridge არის ფაილების ერთობლიობა qbx_core/bridge/qb/-ში, რომელიც Qbox-ის საკუთარი ფუნქციებისგან აგებს ძველ QBCore ობიექტს. რადგან qbx_core თავის manifest-ში აცხადებს provide 'qb-core'-ს, resource, რომელსაც დამოკიდებულებად qb-core აქვს, კმაყოფილდება და exports['qb-core']:GetCoreObject() აბრუნებს QBCore ობიექტის მსგავს რამეს. Bridge ნაგულისხმევად ჩართულია და ერთი convar-ით იმართება:

setr qbx:enableBridge "true"

რა აგრძელებს მუშაობას bridge-ის მეშვეობით:

• QBCore.Functions.GetPlayer(source) და მასზე მიბმული მოთამაშის მეთოდები: AddMoney, RemoveMoney, SetJob, SetMetaData და დანარჩენი.
• ჩვეულებრივი server და client event-ები, რომლებსაც სამუშაოს resource უსმენს, მაგალითად QBCore:Client:OnPlayerLoaded.
• QBCore.Shared.Jobs, Gangs და Vehicles, რომლებიც Qbox-ის საკუთარი ფაილებიდან იკითხება.
• ძველი drawtext export-ები, exports['qb-core']:DrawText() და HideText(), რომლებიც ახლა ox_lib-ის text UI-ზეა მიბმული.
• მოთამაშის item-ის ფუნქციები, მაგალითად Player.Functions.AddItem და RemoveItem, რომლებსაც bridge ox_inventory-ს გადასცემს და ორ item-ფორმატს შორის თარგმნის.

Qbox-ის დოკუმენტაცია framework-ს QB სკრიპტებთან დაახლოებით 99%-ით თავსებადად აღწერს და ბირთვის ობიექტისთვის ეს სამართლიანია. მთავრდება ყველაფერი, რაც ბირთვს მიღმა სწვდება:

• ყველაფერი, რაც პირდაპირ `qb-inventory`-ს იძახებს. exports['qb-inventory']:..., inventory:server:OpenInventory event-ს და qb-inventory-ის stash event-ებს არავინ პასუხობს. Bridge-ის საკუთარი ინვენტარის ფუნქციები ამოწმებს, რომ qb-inventory გაშვებული არ არის, და იშლება შეტყობინებით qb-inventory is not compatible with qbx_core. use ox_inventory instead.
• `Player.Functions.SetInventory` პირდაპირ მხარდაუჭერელია და შეცდომას აგდებს. სკრიპტები, რომლებიც მთელ ინვენტარს თავიდან წერენ, უნდა შეიცვალოს: ჯერ გაწმენდა, შემდეგ დამატება.
• Resource-ები, რომლებიც QBCore-ის ცხრილებზე წერენ SQL-ს, რომელთა მნიშვნელობაც აღარ არის იგივე: ძველი stash ცხრილები, job სვეტი, რომელსაც multijob ჩრდილავს, player_vehicles-ის ჩანაწერები, რომლებსაც garage resource გარკვეული ფორმით ელოდება.
• გარე multijob და multigang resource-ები. Qbox-ს საკუთარი აქვს და დოკუმენტაცია აფრთხილებს, რომ დაუდასტურებელმა resource-ებმა შეიძლება მონაცემები დააზიანოს. პირველ გაშვებამდე ამოიღე ისინი.
• `qb-target`-ის export-ები. ox_target უზრუნველყოფს თავსებადობას qtarget-თან და არა qb-target-თან. Resource-ს, რომელიც exports['qb-target']:AddBoxZone-ს იძახებს, ან qb-target სჭირდება გაშვებული, ან ox_target-ზე გადაყვანა.

Bridge მიგრაციის ინსტრუმენტია და არა მუდმივი სახლი. მისი ფუნქციები წყაროში deprecated-ად არის მონიშნული, ახალმა კოდმა კი პირდაპირ exports.qbx_core და ox_lib უნდა გამოიძახოს. Resource-ების გადაყვანა შეგიძლია სათითაოდ, რადგან bridge-ის და ნატიური გამოძახებები გვერდიგვერდ მუშაობს.

რესურსების სიის აუდიტი, სანამ რამეს შეეხები#

გახსენი resources/ და ყველა საქაღალდე სამ ჯგუფად დაყავი. ეს ერთი საათია ტექსტურ ფაილთან და ის განსაზღვრავს, რამდენი დრო წავა დანარჩენზე.

1. მუშაობს უცვლელად. Resource-ები, რომლებიც მხოლოდ ბირთვის ობიექტს, მოთამაშის ფულს, სამუშაოებსა და event-ებს იყენებს. HUD-ების, მარტივი სამუშაოების, AddItem-ით მოქმედი მაღაზიების, emote-ების, ამინდისა და ხმის უმეტესობა.
2. აქვს Qbox-ის ან ox-ის შემცვლელი. ჩვეულებრივ ეს patch-ზე უკეთესი გზაა. Qbox მხარს უჭერს ხშირად გამოყენებული QB resource-ების qbx_ ვერსიებს.
3. საჭიროებს რედაქტირებას ან მოცილებას. ყველაფერი, რაც qb-inventory-თან ურთიერთობს, ბევრს იყენებს qb-menu-ს ან qb-input-ს, ან საკუთარ SQL-ს წერს ინვენტარისა და მანქანების ცხრილებზე.

შემცვლელები, რომლებიც თითქმის ყველა სერვერზე ჩნდება:

ox_inventory-ის Qbox ინტეგრაცია ასევე ამოწმებს, რომ qbx_vehicles გაშვებულია, ამიტომ დაამატე ის, თუნდაც საკუთარი garage resource შეინარჩუნო. ფასიანი სკრიპტებისთვის ვარაუდამდე შეამოწმე ავტორის გვერდი: ბევრი Qbox-ის მხარდაჭერას config-ის გადამრთველით აცხადებს, ხოლო escrow-ით დაცული სკრიპტი, რომლის რედაქტირებაც არ შეგიძლია, ან უჭერს Qbox-ს მხარს, ან არა. FiveM escrow and asset licensing განმარტავს, რის შეცვლა შეგიძლია და რის არა.

მესამე ჯგუფის ასაგებად ყველაზე სწრაფი გზა ძებნაა. გაუშვი ეს სერვერის ასლზე resources/ საქაღალდიდან და წაიკითხე ყველა შედეგი:

$ grep -rn --include=*.lua -e "qb-inventory" -e "qb-target" -e "SetInventory" .$ grep -rn --include=*.lua -e "stashitems" -e "trunkitems" -e "gloveboxitems" .$ grep -rn --include=*.lua -e "QBCore.Shared.Items\[" .

ბოლო მნიშვნელოვანია, რადგან ზოგი resource item-ებს გაშვების დროს ამატებს QBCore.Shared.Items-ში ჩაწერით. Qbox-ზე item-ები ox_inventory-ს ეკუთვნის და ასეთი დამატებები არაფერს აკეთებს.

ჯერ ტესტ სერვერი ააგე#

ცოცხალი სერვერი ადგილზე არ გადაიყვანო. ააგე მეორე სერვერი, მიეცი ბაზის ასლი და resources/-ის ასლი და ქვემოთ აღწერილი ყველა ნაბიჯი ჯერ იქ გააკეთე. ზოგადი მეთოდი - რა უნდა დაკოპირდეს, რა უნდა განსხვავდებოდეს, რამდენად პატარა შეიძლება იყოს - აღწერილია პოსტში running a test server beside production. ამ მიგრაციისთვის კონკრეტულად:

• ყოველთვის ცალკე ბაზა. ტესტ სერვერის mysql_connection_string ასლზე უნდა მიუთითებდეს და არასოდეს production სქემაზე. ქვემოთ მოცემული SQL ნაბიჯები ცხრილებს ცვლის და მათი შემთხვევით ცოცხალ მონაცემებზე გაშვება ერთადერთი შეცდომაა, რომელიც საღამოს შაბათ-კვირად აქცევს.
• Production-ის ახალი dump მის ასავსებად. გამოიყენე mysqldump --single-transaction-ით, რომ მოთამაშეები არ გამოაგდო სანამ გადის, როგორც ეს აღწერილია პოსტში mysqldump backup and restore.
• დახურე საჯაროსგან. დააყენე დაბალი sv_maxclients, დაამატე პაროლის მსგავსი შემოწმება Discord whitelist-ით ან უბრალოდ ნუ გამოაქვეყნებ და მიეცი საკუთარი hostname, რომ არავინ არასწორ სერვერზე შევიდეს.
• შედი რეალური პერსონაჟით. ახალ პერსონაჟზე ტესტი გადაყვანის შესახებ არაფერს ამტკიცებს. აირჩიე რამდენიმე პერსონაჟი სავსე ინვენტარით, იარაღით, მანქანით, რომლის ბარგაჟნიკშიც item-ებია, და ნულზე მაღალი job grade-ით, და გადაყვანის შემდეგ თითოეული შეამოწმე.

RE:NODE-ზე თითოეული სერვერი ცალკე container-ია საკუთარი ბაზის სლოტით, ამიტომ ტესტ სერვერის ასლი production ბაზას ვერ ხედავს, თუ იმ credentials-ს არ მისცემ. Dump-ი შეიტანე ტესტ სერვერის ბაზის ჩანართიდან "Open in phpMyAdmin"-ით ან command line-იდან გენერირებული host-ითა და მომხმარებლით.

ცვლილებები, რომლებსაც Qbox ბაზაში ახდენს#

ჯერ backup გააკეთე. ამ განყოფილების ყველა ნაბიჯი ადვილად გამოიყენება და ძნელად უკუქცევადია.

$ mysqldump --single-transaction --routines -h DB_HOST -u DB_USER -p qbcore \    > qbcore-before-qbox.sql

შემდეგ შეიტანე qbx_core.sql იმ qbx_core release-იდან, რომელსაც აყენებ. არსებულ QBCore ბაზაზე ის სამ მნიშვნელოვან რამეს აკეთებს. players-ს ამატებს last_logged_out სვეტს (მიმდინარე ვერსიებში userId სვეტსაც). players-ს ცვლის ისე, რომ ცხრილი და მისი ძირითადი სვეტები utf8mb4_unicode_ci collation-ს იყენებს. და ქმნის player_groups-ს, რომელიც ინახავს ყველა job-სა და gang-ს, რომელშიც პერსონაჟი არის, citizenid-ზე foreign key-ით players-თან.

სწორედ ეს foreign key არის ადგილი, სადაც მიგრაციების უმეტესობა ჩერდება. Foreign key-ს ორივე სვეტზე ერთი და იგივე collation სჭირდება, ბევრი QBCore ბაზა კი utf8mb4_general_ci-ით შეიქმნა. თუ შეტანა foreign key-ის შეცდომით ჩავარდა, შეამოწმე და შეასწორე collation:

SELECT TABLE_NAME, COLUMN_NAME, COLLATION_NAMEFROM information_schema.COLUMNSWHERE TABLE_SCHEMA = 'qbcore' AND COLUMN_NAME = 'citizenid';ALTER TABLE players  MODIFY citizenid VARCHAR(50) NOT NULL COLLATE utf8mb4_unicode_ci;

იგივე MODIFY გაუშვი ყველა სხვა ცხრილზე, რომლის citizenid სვეტიც ისევ utf8mb4_general_ci-ს აჩვენებს, თითოეული სვეტის არსებული ტიპისა და nullability-ის შენარჩუნებით, შემდეგ qbx_core.sql ისევ შეიტანე. რატომ ეჯახება collation-ები საერთოდ, განმარტულია პოსტში MySQL utf8mb4 and collations.

შემდეგ, სამუშაოები და gang-ები. Qbox-ს shared/jobs.lua-სა და shared/gangs.lua-ში grade-ის გასაღებები რიცხვებად უნდა, QBCore კი სტრიქონებს იყენებდა:

police = {    label = 'LSPD',    defaultDuty = true,    grades = {        [0] = { name = 'Recruit', payment = 50 },      -- QBCore had ['0']        [1] = { name = 'Officer', payment = 75 },        [4] = { name = 'Chief', isboss = true, payment = 150 },    },},

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

convertjobs

ის თითოეული პერსონაჟის მიმდინარე job-სა და gang-ს players ცხრილიდან player_groups-ში აკოპირებს, მხოლოდ სერვერის კონსოლიდან გადის და ორჯერ გაშვება უსაფრთხოა. ორი convar განსაზღვრავს, როგორ იქცევა multijob შემდეგ: qbx:max_jobs_per_player და qbx:max_gangs_per_player, ორივე ნაგულისხმევად 1.

player_vehicles ხელუხლებელი რჩება: qbx_vehicles მას მხოლოდ მაშინ ქმნის, თუ არ არსებობს. ox_inventory მას პირველივე გაშვებისას ამატებს trunk და glovebox სვეტებს, players-ს კი inventory სვეტს, თუ აკლია.

qb-inventory-ის ox_inventory-ზე გადაყვანა#

ეს ყველაზე ფრთხილ მიდგომას საჭიროებს და სწორედ აქ ეწინააღმდეგება ერთმანეთს ინსტრუქციები ყველაზე ხშირად, რადგან ინსტრუმენტები 2024 წელს შეიცვალა. სამი ცალკე რამ გადაინაცვლებს: item-ების აღწერები, მოთამაშეების ინვენტარები და დანარჩენი ყველაფერი (stash-ები, ბარგაჟნიკები, სახელური ყუთები).

Item-ების აღწერები

ჩასვი შენი QBCore item-ების ცხრილი qbx_core/shared/items.lua-ში. შემდეგ გაშვებაზე bridge ყველა item-ს, რომელიც ox_inventory-მ ჯერ არ იცის, ox_inventory-ის ფორმატში გარდაქმნის და წერს qbx_core/converted.lua-ში, კონსოლში კი გაფრთხილებას ბეჭდავს, რამდენი დაამატა. ის გამოტოვებს სახელებს, რომლებიც იარაღს, დამატებით ნაწილებსა და ტყვიამარაგს ჰგავს, რადგან ox_inventory-ს საკუთარი იარაღის აღწერები აქვს. გადახედე ფაილს, ჩანაწერები გადაიტანე ox_inventory/data/items.lua-ში, shared/items.lua ისევ დააცარიელე და გადატვირთე. გარდაქმნილი ჩანაწერი ასე გამოიყურება:

['sandwich'] = {    label = 'Sandwich',    weight = 200,    stack = true,    close = true,    description = 'Nice bread for your stomach',    client = {        status = { hunger = 200000 },        image = 'sandwich.png',    },},

გამოყენებადი item-ები bridge-ის CreateUseableItem-ით კვლავ მუშაობს, მაგრამ შენი consumables resource-ის შიმშილისა და წყურვილის მნიშვნელობები თავისით არ გამოიყენება; თითოეული საკვები item ერთხელ თამაშში შეამოწმე. დააკოპირე item-ების სურათები qb-inventory/html/images-იდან ox_inventory/web/images-ში, თორემ ყველა გარდაქმნილი item ცარიელ კვადრატად გამოჩნდება.

მოთამაშეების ინვენტარები

QBCore და ox_inventory ორივე ინახავს მოთამაშის ინვენტარს JSON-ის სახით players.inventory-ში, მაგრამ ველები განსხვავდება:

{"name": "water_bottle", "amount": 3, "info": {}, "slot": 1, "type": "item"}{"name": "water_bottle", "count": 3, "metadata": {}, "slot": 1}

პირველი ხაზი QBCore-ია, მეორე ox_inventory. როცა ox_inventory გადაუყვანელ პერსონაჟს ტვირთავს, ჩერდება შეტყობინებით Inventory for player.X contains invalid data. Ensure you have converted inventories to the correct format. ახალ ox_inventory release-ებს მოყვება convertinventory კონსოლის ბრძანება, მაგრამ მისი ერთადერთი ვარიანტებია esx და esxproperty; გაუშვი არგუმენტის გარეშე და ეს სია დაიბეჭდება. QBCore-ის გადამყვანი 2024 წლის აგვისტოში ამოიღეს და v2.41.0 არის ბოლო release, რომელსაც convertinventory qb აქვს. ის amount-ს count-ად, info-ს metadata-დ ანაცვლებდა, QBCore-ის ნაღდ ფულს money item-ად აქცევდა და იარაღს ძველი quality-ის მიხედვით serial-სა და durability-ს აძლევდა.

პრაქტიკული გზებია: ის ძველი release ერთხელ ტესტ სერვერზე მხოლოდ გადასაყვანად გაუშვა და შემდეგ მიმდინარე ox_inventory-თი ჩაანაცვლო, ან იგივე ველების შესაბამისობა თვითონ დაწერო SQL-ში ან Lua-ში. ორივე შემთხვევაში შეადარე რამდენიმე პერსონაჟი გადაყვანამდე და მის შემდეგ. გადაყვანის შემდეგ ნაღდი ფული ორ ადგილას ცხოვრობს, რომლებსაც ox_inventory სინქრონში ინახავს: money item-ში და PlayerData.money.cash-ში.

Stash-ები, ბარგაჟნიკები და სახელური ყუთები

ეს არის ადგილი, სადაც მონაცემები ყველაზე ხშირად იკარგება. qb-inventory-ის ძველი ვერსიები მათ ინახავდნენ stashitems, trunkitems და gloveboxitems-ში; ძველმა გადამყვანმა ბარგაჟნიკები და სახელური ყუთები player_vehicles-ში გადაიტანა, მაგრამ stash-ები არასოდეს დაუმუშავებია. მიმდინარე qb-inventory (2.x) ყველაფერს ერთ inventories ცხრილში ინახავს identifier სტრიქონის გასაღებით, რომელსაც არც ერთი ოფიციალური გადამყვანი არ კითხულობს. Qbox-ზე ox_inventory stash-ებს საკუთარ ox_inventory ცხრილში ინახავს, ბარგაჟნიკებსა და სახელურ ყუთებს კი player_vehicles-ში, მანქანის id-ის გასაღებით.

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

გადართვის დღე, თანმიმდევრობით#

როცა ტესტ სერვერმა მთელი პროცესი გაიარა და რეალურ ტესტერებთან სესიას გაუძლო, ცოცხალი გადართვა checklist-ია:

1. გამოაცხადე ტექნიკური სამუშაოების ფანჯარა და დახურე სერვერი txAdmin-ის whitelist-ით ან გაჩერებით.
2. გააკეთე საბოლოო mysqldump და სერვერის ფაილების panel backup. ორივე ჩამოტვირთე.
3. გაუშვი SQL ნაბიჯები იმ თანმიმდევრობით, რომელიც ტესტ სერვერზე მუშაობდა.
4. ჩაანაცვლე resources/ გამოცდილი საქაღალდით და მისგან გადმოიტანე server.cfg, ox.cfg და permissions.cfg.
5. გაუშვი ღია კონსოლით. ensure oxmysql, ox_lib, qbx_core და ox_inventory უნდა ამოვიდეს ყველაფერზე ადრე, რაც მათზეა დამოკიდებული. რას უყურო, წერია პოსტში Reading the console.
6. გაუშვი convertjobs და ინვენტარის გადაყვანა, რომელიც გაიმეორე.
7. შედი სამი პერსონაჟით, რომლებიც ტესტ სერვერზე შეამოწმე. გახსენი ინვენტარი, stash და ბარგაჟნიკი.
8. გახსენი მოთამაშეებისთვის და პირველი საათი უყურე კონსოლს და resmon-ს.

Rollback გეგმა#

Rollback-ის გეგმა დაწერე დაწყებამდე, რადგან მისი საჭიროების მომენტში ნათლად ვერ იფიქრებ. მიგრაცია მხოლოდ მაშინაა შექცევადი, თუ ძველი სერვერის ორივე ნახევარი ხელუხლებლად არსებობს.

• ფაილები. შეინახე ძველი resources/ საქაღალდე და server.cfg არქივად და არა გადაწერილი. უკან დაბრუნება ამ საქაღალდის აღდგენაა.
• ბაზა. აღადგინე qbcore-before-qbox.sql ბაზაში. წინ გასწორება rollback არ არის - გარდაქმნილი ინვენტარის JSON, ახალი collation და player_groups თავისით არ გაუქმდება.
• გადაწყვეტილების ვადა. აირჩიე მომენტი, რის შემდეგაც უკან აღარ ბრუნდები და წინ ასწორებ. მოთამაშეებს, რომლებიც Qbox-ზე ერთი დღე ითამაშეს, აქვთ მონაცემები, რომელსაც აღდგენა წაშლიდა. გონივრული წესი: ტექნიკური სამუშაოების ფანჯარაში თავისუფლად დაბრუნდი, მის შემდეგ კი მხოლოდ მონაცემების დაკარგვის გამო.

RE:NODE-ზე panel backup ფაილებს ფარავს, dump კი ბაზას, ამიტომ ორივე გააკეთე. Backup-ის დაბლოკვა შეიძლება rotation-ისგან, რომ მიგრაციამდელი ასლი დაგეგმილ backup-ებს გადაურჩეს, მაგრამ სანამ მას ენდობი, test the restore ტესტ სერვერზე.

Troubleshooting#

შეცდომები, რომლებიც თითქმის ყველა მიგრაციაში ჩნდება:

კიდევ ორი უფრო ჩუმია. Resource, რომელიც ჩუმად არაფერს აკეთებს, ჩვეულებრივ QBCore.Shared.Items-ს იძახებს item-ის არსებობის შესამოწმებლად; ეს გამოძახება ჩაანაცვლე exports.ox_inventory:Items()-ით. ხოლო დუბლირებული საქაღალდეები - ძველი qb-inventory ფრჩხილებიან საქაღალდეში, რომელიც დაგავიწყდა - ჩართავს იმას, რასაც FXServer პირველად იპოვის, ამიტომ ძველი წაშალე და არ დატოვო ensure-ს გარეშე.

FAQ#

შეიძლება Qbox-ის გაშვება qb-core bridge-ის გარეშე?

დიახ, დააყენე qbx:enableBridge false-ზე, მაგრამ მხოლოდ მაშინ, როცა სერვერზე აღარაფერი იძახებს qb-core-ს. სერვერების უმეტესობა მას თვეების განმავლობაში ჩართულს ტოვებს და resource-ებს ნელ-ნელა აქცევს.

დავკარგავ პერსონაჟის მონაცემებს Qbox-ზე გადასვლისას?

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

შემიძლია qb-inventory-ის შენარჩუნება Qbox-ზე?

არა. qbx_core უარს ამბობს მუშაობაზე, თუ qb-inventory გაშვებულია, და ox_inventory ერთადერთი ინვენტარია, რომელსაც Qbox უჭერს მხარს.

იმუშავებს ჩემი ფასიანი QBCore სკრიპტები Qbox-ზე?

ბევრი bridge-ის მეშვეობით მუშაობს და ბევრი ავტორი Qbox-ის ვარიანტსაც აწვდის. ისინი ირღვევა, რომლებიც პირდაპირ qb-inventory-ს ან qb-target-ს იძახებენ. შეამოწმე ავტორის შენიშვნები და გამოსცადე ასლზე.

რამდენ ხანს გრძელდება მიგრაცია?

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

შემიძლია QBCore-ზე დაბრუნება გადასვლის შემდეგ?

მხოლოდ მიგრაციამდელი ბაზის dump-ისა და ძველი resources/ საქაღალდის აღდგენით, რაც წაშლის ყველაფერს, რაც მოთამაშეებმა გადართვის შემდეგ გააკეთეს. Rollback-ის ვადა დაწყებამდე გადაწყვიტე.