რა უნდა გააკეთო, როცა mod-ის განახლება სერვერს ფუჭად აქცევს

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

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

ათი წუთი სამუშაო სერვერამდე#

თანმიმდევრობით, და პირველს ნუ გამოტოვებ.

1. სერვერი სწორად გააჩერე. გაფუჭებული სერვერი გადაიტვირთება, გაფუჭდება, გადაიტვირთება, და ყოველი ციკლი მტკიცებულების კიდევ ერთ ნაწილს წაშლის. ამან შეიძლება პრობლემაც შეგიქმნას: RE:NODE-ის crash watcher ყოველ ორ წუთში ამოწმებს, არ დაიკლო თუ არა uptime-მა, და საათში სამი რესტარტი გაფრთხილებას იწვევს და ავტომატურად ხსნის ticket-ს, საათში ექვსი კი შეჩერებამდე მიდის. შენ მიერ მოთხოვნილი რესტარტები არ ითვლება, ამიტომ თავად გაჩერება ერთდროულად სწორი დიაგნოსტიკური ნაბიჯია და ისიც, რომელიც სერვერს ციკლში არ აგდებს. რატომ რესტარტდება შენი გეიმ სერვერი განუწყვეტლივ იმავე სიმპტომის სხვა მიზეზებს განიხილავს.
2. აიღე მტკიცებულება, სანამ არ დაიშლება. ჩამოტვირთე უახლესი ფაილი crash-reports/-იდან, ან BepInEx/LogOutput.log, ან კონსოლის გამოტანა ბოლო წარმატებული გაშვებიდან მარცხამდე. შეინახე, პრობლემის გასწორების შემდეგაც.
3. crash report წაიკითხე თავიდან, და არა ბოლოდან. პირველი ხაზი, რომელიც არა თამაშს ან loader-ს, არამედ სხვა რამეს ასახელებს, შენი ეჭვმიტანილია.
4. შეამოწმე დროის ნიშნულები. ls -lt mods ან plugins საქაღალდეში, ან დაალაგე თარიღით ფაილების მენეჯერში. უახლესი ფაილი თითქმის ყოველთვის სწორედ ის არის.
5. დააბრუნე წინა ვერსია. შეინახე ძველი jar; ამიტომაც ინახავ. თუ არ შეგინახავს, mod-ის საკუთარ release გვერდზე ყველა წინა ვერსიაა.
6. გაუშვი და წაიკითხე გაშვების banner. დარწმუნდი, რომ ჩაიტვირთა ის ვერსია, რომელიც დააბრუნე, და რომ mod-ების რაოდენობა გუშინდელის ტოლია.
7. განახლების შესახებ ცალკე გადაწყვიტე, ხვალ, ასლზე. ახლა ეს გადაუდებელი არ არის.

crash report-ის კითხვა#

Minecraft crash report-ებს წერს crash-reports/crash-2026-09-21_18.30.11-server.txt-ში და ასევე კონსოლშიც. სტრუქტურა თანმიმდევრულია და მისგან მხოლოდ სამი ნაწილია მნიშვნელოვანი.

ზედა Description ხაზი ამბობს, რას აკეთებდა თამაში, როცა მოკვდა: entity-ს tick-ავდა, world-ს ტვირთავდა, mod-ების სისტემას აინიციალიზებდა. ეს გეუბნება, რომელმა ფაზამ ჩავარდა, რაც ეჭვმიტანილთა სიას ძალიან ავიწროებს - mod-ების ჩატვირთვისას crash dependency-ის ან ვერსიის პრობლემაა, entity-ის tick-ისას crash კი კონკრეტული mod-ის გეიმფლეის ბაგი.

მის ქვემოთ მდებარე stack trace ზემოდან ქვემოთ იკითხება. ეს არის მიმდინარე მეთოდების გამოძახებების სია, ყველაზე ახალი პირველი, და სასარგებლო ნაწილი package-ების სახელებია:

java.lang.NoSuchMethodError: 'void com.example.lib.Registry.register(...)'    at com.someone.theirmod.ModInit.onInitialize(ModInit.java:44)    at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(...)    at net.minecraft.server.Main.main(Main.java:112)

პირველი ხაზი შეცდომას ასახელებს. მეორე ხაზი ასახელებს com.someone.theirmod-ს, რომელიც არც თამაშია და არც loader, ესე იგი, ეს არის mod, რომელსაც უნდა შეხედო. მის ქვემოთ ხაზები მექანიზმია, რომელმაც ის გამოიძახა, და იშვიათად არის საინტერესო. Forge-სა და NeoForge-ზე report ხშირად ზემოთაც ბეჭდავს ეჭვმიტანილ mod-ს; ეს აღიქვი მინიშნებად და არა განაჩენად, რადგან mod, რომელმაც crash-ი გამოიწვია, ხშირად იმ ბიბლიოთეკის მსხვერპლია, რომელიც მის ქვეშ შეიცვალა.

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

Fabric ამ loader-ებს შორის ყველაზე მეგობრულია. როცა პრობლემა კოდი კი არა, ვერსიებია, Fabric Loader გაშვებაზე უარს ამბობს და უბრალო ენით ბეჭდავს გადაწყვეტის შეცდომას, სადაც დასახელებულია mod, dependency და ვერსია, რომელიც უნდოდა. წაიკითხე პირდაპირ; ის ჩვეულებრივ სწორია და ჩვეულებრივ ზუსტ გამოსწორებას გეუბნება.

Valheim-ისა და სხვა Unity თამაშებისთვის შესაბამისი ფაილია BepInEx/LogOutput.log და იგივე წესი მოქმედებს: იპოვე პირველი [Error ან [Warning ხაზი, რომელიც plugin-ს ასახელებს და არა თავად BepInEx-ს. Valheim-ის mod-ები BepInEx-ით სერვერზე გიჩვენებს სტრუქტურას.

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

Java-ს შეცდომების სახელები ურთიერთშემცვლელად გამოიყურება და არ არის. თითოეული სხვა გამოსწორებაზე მიუთითებს.

Paper-სა და Spigot-ზე ფორმულირება განსხვავებულია, მაგრამ ლოგიკა იგივეა. org.bukkit.plugin.UnknownDependencyException: Unknown dependency Vault ნიშნავს, რომ plugin-მა plugin.yml-ში depend: [Vault] გამოაცხადა, Vault კი არ არის ან პირველმა ჩავარდა. გაფრთხილება, რომ plugin უფრო ძველი api-version-ისთვისაა აგებული, ჩვეულებრივ გადასატანია; ჩატვირთვის პირდაპირი შეცდომა - არა.

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

ექვსი გზა, რომლითაც mod-ის განახლება სერვერს ფუჭად აქცევს#

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

dependency გადაინაცვლა. mod განახლდა და ახლა ბიბლიოთეკის მე-5 ვერსია უნდა, შენ კი მე-4 გაქვს, ან პირიქით. ეს NoSuchMethodError-ის ტერიტორიაა და ყველაზე გავრცელებული მიზეზი. გამოსწორება ბიბლიოთეკის განახლება ან დაბრუნებაა იმ ვერსიაზე, რასაც mod-ის release notes ითხოვს.

loader-ის ან თამაშის ვერსია შეიცვალა. modpack, რომელმაც Forge-ის, NeoForge-ის ან Fabric Loader-ის ვერსია თავისით განაახლა, ან თამაშის განახლება, რომელიც ღამით გავიდა. ყველაფერი ერთდროულად ფუჭდება და crash ხდება ჩატვირთვისას და არა თამაშისას.

კლიენტი და სერვერი ერთმანეთს გაცდნენ. სერვერი განახლდა და მოთამაშეები - არა, ან პირიქით. სიმპტომი საერთოდ crash არ არის: სერვერი მშვიდად მუშაობს და ყველა დაკავშირებისას გაგდებულია, ან მალევე desync-დება. ყველა მოთამაშეს ერთი და იგივე mod ერთსა და იმავე ვერსიაზე უნდა ჰქონდეს, და ამიტომ მოდიფიცირებული სერვერი თამაშის patch-ის დღეს არ უნდა განახლდეს.

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

Workshop-ის კონტენტი თავისით განახლდა. Steam Workshop-ის თამაშებისთვის ეს კლასიკაა. Project Zomboid, Garry's Mod, DayZ და Arma workshop-ის ელემენტებს გაშვებისას ჩამოტვირთავენ, ამიტომ "არაფერი შეცვლილა" უბრალოდ მცდარია: სერვერმა სხვისი mod-ის ახალი ვერსია ჩამოტვირთა, სანამ ეძინა. Steam Workshop-ის mod-ები dedicated სერვერებზე ხსნის, როგორ მუშაობს ეს ჩამოტვირთვები სინამდვილეში.

ორ mod-ს ახლა ერთი და იგივე უნდა. Mixin-ების კონფლიქტები, ორი mod, რომელიც ერთსა და იმავე block ID-ს არეგისტრირებს, ორი ჩატის plugin, რომელიც ორივე ერთსა და იმავე მოვლენას აუქმებს. ესენი განახლების შემდეგ ჩნდება, რადგან განახლებამ შეეხო კოდს, რომელიც მეორე mod-მა უკვე შეცვალა. ეს ერთადერთი კატეგორიაა, სადაც ერთი ფაილის დაბრუნება შეიძლება საკმარისი არ იყოს.

ძველი ვერსიის დაბრუნება#

სად ცხოვრობს ფაილები და რა უნდა გადაინაცვლოს მათთან ერთად:

შეცვლილი ფაილის პოვნა ორივე მიმართულებით ერთი ხაზია:

$ ls -lt mods/ | head -10$ find mods plugins -name "*.jar" -newermt "-2 days" -printf "%T+ %p\n" | sort

პანელის ფაილების მენეჯერში შეცვლის თარიღით დახარისხება იგივეს shell-ის გარეშე აკეთებს, და ეს ამ ცხრილში ყველაზე სასარგებლო სვეტია.

დაბრუნება თავად ფაილის გაცვლაა, ერთი წესით: ნუ წაშლი, გამორთე. შექმენი mods.disabled საქაღალდე mods-ის გვერდით და ფაილები წაშლის ნაცვლად იქ გადაიტანე, რომ არასწორ ვარაუდს გადათრევა დაჯდეს და არა ხელახალი ჩამოტვირთვა. jar, რომელსაც აბრუნებ, შენი საკუთარი არქივიდან მოდის, თუ ინახავ ერთს, თუ არა - mod-ის release ისტორიიდან: ყველა მსხვილი გავრცელების პლატფორმა ძველ ფაილებს ინახავს და ვერსიის ნომერი ფაილის სახელში ჩვეულებრივ საკმარისია სწორის ამოსაცნობად.

Factorio-სთვის მექანიკა ოდნავ განსხვავებულია და ღირს მისი ცოდნა, რადგან save იმახსოვრებს mod-ებს და ვერსიებს, რომლითაც შეიქმნა, და არასწორი ნაკრებით ჩატვირთვაზე უარს იტყვის. დაბრუნება ნიშნავს სწორი name_version.zip-ის დაბრუნებას mods/-ში და mod-list.json-ის შემოწმებას:

{  "mods": [    { "name": "base", "enabled": true },    { "name": "even-distribution", "enabled": true },    { "name": "squeak-through", "enabled": false }  ]}

Steam-ით მიწოდებული კონტენტისთვის ვერსიის ფიქსაცია SteamCMD-ის დონეზე beta branch-ით კეთდება და არა საქაღალდეში:

$ steamcmd +login anonymous +app_update 380870 -beta <branch> validate +quit

380870 აქ Project Zomboid-ის dedicated სერვერია; ჩაანაცვლე შენი თამაშის app id-ით. Branch-ების სახელები თამაშზეა დამოკიდებული, ბევრი თამაში საერთოდ არცერთს არ აქვეყნებს, სია კი იცვლება, ამიტომ სახელის გამოცნობის ნაცვლად თამაშის დოკუმენტაცია შეამოწმე. SteamCMD ახსნილი app id-ებსა და branch-ებს სათანადოდ განიხილავს.

როცა განახლებამ save-ს შეახო ხელი#

ეს ის შემთხვევაა, რომელიც ათწუთიან გამოსწორებას საღამოდ აქცევს, და ღირს მისი ადრე ამოცნობა. ზოგი mod-ის განახლება ცვლის მონაცემებს, რომლებიც world-ში იწერება: ახალი block-ის ან item-ის ID-ები, ახალი NBT სტრუქტურა, მიგრირებული ბაზის ცხრილი. როცა world ახალმა ვერსიამ ჩატვირთა და შეინახა, ძველი mod-ის დაბრუნება ამას არ აუქმებს. მაშინ ძველი ვერსია ან world-ის ჩატვირთვაზე უარს ამბობს, ან ტვირთავს და ჩუმად წაშლის ყველაფერს, რასაც ვერ ცნობს.

ნიშნები, რომ ამ შემთხვევაში ხარ და არა მარტივში:

• სერვერი ახალი ვერსიით მინიმუმ ერთხელ წარმატებით გაიშვა, სანამ რამე გაფუჭდებოდა.
• მარცხი არის დაკარგული block-ები, დაკარგული item-ები ან დაზიანებული chunk-ები და არა crash ჩატვირთვისას.
• mod-ის changelog ახსენებს მიგრაციას, data fixer-ს ან world-ის ფორმატის ცვლილებას.

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

კონფლიქტის bisect, რომლის წაკითხვაც არავის შეუძლია#

ხანდახან crash არაფერს ასახელებს სასარგებლოს: mixin-ის კონფლიქტი, stack trace, რომელიც მთლიანად თამაშის შიგნითაა, ან სერვერი, რომელიც იწყება და ოთხი წუთის მერე კვდება. როცა კითხვა არ გვშველის, bisect გამოიყენე. 40 mod-ის დროს ორობითი ძიება დამნაშავეს ექვს რესტარტში პოულობს და არა ორმოცში.

1. გადააკოპირე მთელი mods საქაღალდე უსაფრთხო ადგილას.
2. გადაიტანე ნახევარი mods.disabled-ში. გაუშვი. თუ თამაშს ძირითადი ბიბლიოთეკა ან API mod სჭირდება, რომ საერთოდ იმუშაოს, ის ორივე გაშვებაში დატოვე.
3. თუ მაინც ფუჭდება, დამნაშავე დარჩენილ ნახევარშია. თუ მუშაობს, დამნაშავე იმ ნახევარშია, რომელიც ამოიღე.
4. ეჭვმიტანილი ჯგუფი ისევ გაანახევრე. გაიმეორე.
5. როცა ერთამდე დარჩები, დაადასტურე ყველაფრის უკან დაბრუნებით და მხოლოდ იმ mod-ის ამოღებით.

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

ორი mod-ის ორ მიმდინარე ვერსიას შორის კონფლიქტი ერთადერთი შემთხვევაა, სადაც დაბრუნება მხოლოდ დროებითი გამოსავალია. შეატყობინე ორივე ავტორს crash report-ის დართვით, ამასობაში ერთის გარეშე იმუშავე და ორ კვირაში ისევ შეამოწმე. მოდიფიცირებული სერვერის სისუფთავეში შენახვა განიხილავს, რომელი mod-ებია საერთოდ ტარების ღირსი.

როგორ არ განმეორდეს#

დააფიქსირე ვერსიები და ნუ მისდევ უახლესს, და ყოველი mod-ის ბოლო სამუშაო ასლი შეინახე საქაღალდეში, რომელიც სამუშაოს გვერდით დგას. მოხერხებულობა, რომელსაც შენი საღამოს დასრულება შეუძლია, მოხერხებულობა არ არის. კონკრეტულად:

• შეინახე `mods.backup` საქაღალდე, რომელიც ზუსტად იმ ნაკრებს შეიცავს, რომელიც ახლა მუშაობს, და ყოველი წარმატებული განახლების შემდეგ განაახლე. ის დისკს ჭამს და სხვას არაფერს.
• ჩაიწერე სამუშაო ნაკრები. გაშვების log უკვე შეიცავს მას; ყოველი კარგი განახლების შემდეგ ამოიღე ტექსტურ ფაილში სერვერის საქაღალდეში. ორი ასეთი ფაილის შედარება ხუთ წამში პასუხობს კითხვას "რა შეიცვალა".
• გამორთე ავტომატური განახლებები, სადაც თამაში ამის საშუალებას გაძლევს, და სადაც - არა, ძირითადად Steam Workshop-ის კონტენტი - განახლება დაგეგმილ მოვლენად მიიღე და არა სიურპრიზად. გააკეთე ისეთ დროს, როცა უყურებ.
• გქონდეს განახლების ფანჯარა. ფიქსირებული საღამო, backup წინასწარ აღებული და დაბლოკილი, სხვა არავინ დაკავშირებული, და წესი, რომ თამაშის patch-ის დღეს არ განაახლებ. Mod-ის ავტორებს კვირა სჭირდებათ.
• გატესტე ასლზე. პატარა მეორე სერვერი იგივე ვერსიებით ერთადერთი ადგილია, სადაც განახლება მაყურებლის გარეშე შეიძლება ჩავარდეს. Staging და production ერთ ანგარიშზე ამის იაფ ვერსიას განიხილავს და ის გეიმ სერვერებისთვის უფრო ხელმისაწვდომია, ვიდრე ხალხი ფიქრობს.
• განაახლე ერთი რამ ერთდროულად. ერთდროულად განახლებული ექვსი mod ექვს ეჭვმიტანილს და bisect-ს ნიშნავს. ორი ერთდროულად უფრო ნელია და თითქმის არასოდეს გიჯდება საღამო.

არაფერი აქედან არ მოითხოვს ჰოსტისგან რაიმე უჩვეულოს. RE:NODE-ზე mod-ებსა და plugin-ებს შენ ტვირთავ ფაილების მენეჯერით ან SFTP-ით, ან მოდის თამაშის საკუთარი workshop მხარდაჭერით, და დაშვებული mod-ების სია არ არსებობს - ამიტომ ვერსია, რომელსაც ინახავ, ის ვერსიაა, რომელსაც უშვებ. კონსოლი ფილტრის გარეშე ცოცხალ გამოტანას აჩვენებს, სადაც გაშვების banner-ს წაიკითხავ, ხოლო ფაილების მენეჯერი ცვლილების დროის ნიშნულებს აჩვენებს, რითაც შეცვლილ ფაილს ამოიცნობ. კონსოლის კითხვა დანარჩენს განიხილავს, რასაც ეს ხაზები ნიშნავს.

FAQ#

როგორ ვიპოვო, რომელმა mod-მა გააფუჭა ჩემი სერვერი?

ჯერ შეამოწმე ცვლილების დროის ნიშნულები mods საქაღალდეში, რადგან უახლესი ფაილი ათიდან დაახლოებით ცხრა შემთხვევაში ეჭვმიტანილია. თუ ეს არაფერს გვიმტკიცებს, წაიკითხე crash report თავიდან და იპოვე პირველი package-ის სახელი, რომელიც არც თამაშია და არც loader. თუ ესეც არ დაგეხმარა, bisect გააკეთე mod-ების ნახევრის ერთდროულად გამორთვით.

შემიძლია უბრალოდ mod დავაბრუნო და გავაგრძელო?

ჩვეულებრივ დიახ, თუ სერვერს world-ის მონაცემები ახალ ფორმატში ჯერ არ ჩაუწერია. თუ ახალი ვერსიით წარმატებით გაეშვა და ხალხი თამაშობდა, დაბრუნებამდე შეამოწმე mod-ის changelog მიგრაციისთვის და, თუ განახლებამდე backup გაქვს, მისგან აღადგინე.

რატომ განაახლა ჩემმა სერვერმა mod თავისით?

Steam Workshop-ის კონტენტი გაშვებისას იტვირთება, ამიტომ ნებისმიერ workshop mod-ს შეუძლია რესტარტებს შორის შეიცვალოს შენი მონაწილეობის გარეშე. ზოგი launcher და modpack-ის ინსტრუმენტიც ნაგულისხმევად უახლეს release-ს მისდევს. დააფიქსირე ვერსიები, სადაც თამაში იძლევა ამის საშუალებას, და ივარაუდე, რომ რესტარტი მესამე მხარის კონტენტის ცვლილების შესაძლებლობაა.

უნდა განვაახლო თუ არა mod-ები იმავე დღეს, როცა თამაში განახლდება?

არა. Mod-ის ავტორებს თამაშის patch-ის შემდეგ დღეები ან ორი კვირაც კი სჭირდებათ, და ორივეს ერთდროულად განახლება ნიშნავს, რომ ვერ გაარკვევ, რომელმა გააფუჭა. მოდიფიცირებულ სერვერზე გამორთე თამაშის ავტომატური განახლებები, დაელოდე, სანამ mod-ებმა, რომლებზეც დამოკიდებული ხარ, თავსებადი build არ გამოუშვეს, და მერე ყველაფერი ერთ დაგეგმილ ფანჯარაში გადაიტანე.

crash report ასახელებს mod-ს, რომელიც დარწმუნებული ვარ, რომ კარგადაა. რა ვქნა?

ეს ხშირია. mod crash-ს განიცდის, რადგან ბიბლიოთეკა, რომელზეც ის დამოკიდებულია, მის ქვეშ შეიცვალა, ამიტომ trace-ში სახელი მსხვერპლისაა და არა მიზეზის. ნახე, კიდევ რა განახლდა იმავე დროს, განსაკუთრებით რაც API-ად, core-ად ან ბიბლიოთეკად არის აღწერილი, და შეამოწმე ვერსია, რომელსაც დასახელებული mod ითხოვს.

მჭირდება backup, თუ ძველი jar-ების ასლები მაქვს?

დიახ, ისინი სხვადასხვა პრობლემას წყვეტს. ძველი jar-ები ასწორებს mod-ს, რომელიც არ იტვირთება. Backup ასწორებს world-ს, რომელიც შეცვალა mod-მა, რომელიც ჩაიტვირთა. მეორე ძვირადღირებული მარცხია და ის ჩნდება საათების მერე და არა მაშინვე.