modded Minecraft სერვერი crash-ების გარეშე

Vanilla სერვერი, რომელიც ვარდება, თითქმის ყოველთვის მეხსიერებას ამოეწურა. Modpack, რომელიც ვარდება, შეიძლება მეხსიერებას ამოეწურა, dependency აკლია, არასწორ Java-ზე მუშაობს, client-only mod-ი უჭირავს, რომელიც არასოდეს უნდა ენახა, ან ორი mod ერთსა და იმავე მეთოდზე დაობს. გამოსწორება მეტი RAM არ არის. გამოსწორება ისაა, რომ წაიკითხო, ამ ხუთიდან რომელი მოხდა, და სერვერი ამას ლოგის პირველ ოც სტრიქონში გეუბნება - თუ იცი, სად უყურო და რომელ loader-ზე ხარ. ეს პოსტი ფარავს პაკის დაყენებას dedicated სერვერზე, Java-ს ვერსიების ცხრილს, რომელიც ყველას ეჭირება, crash report-ის უკუღმა წაკითხვას და იმ პარამეტრებსა და mod-ებს, რომლებიც დანარჩენის უმეტესობას განაპირობებს.

Forge, NeoForge და Fabric და რომელი crash-ები რომელს ეკუთვნის#

სამი loader, ერთი საქმე: აიძულო კოდი, რომელიც Minecraft არ არის, Minecraft-ის შიგნით იმუშაოს. ისინი საკმარისად სხვადასხვანაირად ვარდებიან, ამიტომ loader პირველი რამ არის, რაც უნდა დადგინდეს.

• Forge ყველაზე ძველია და დღესაც მასზეა აგებული უმეტესი დიდი 1.12 და 1.16 პაკი. 1.17-დან installer-ი აღარ ქმნის ერთ გასაშვებ jar-ს; ის წერს libraries/ ხეს, run.sh-ს, run.bat-ს და user_jvm_args.txt-ს, და გაშვების ბრძანება არის სკრიპტი და არა java -jar.
• NeoForge Forge-ის fork-ია, რომელიც 1.20.1-ზე დაიწყო და სადაც 1.20.2-დან ცხოვრობს Forge-ის შტოს უმეტესი ახალი პაკი. იგივე installer-ის ნიმუში, იგივე ფაილების განლაგება, სხვა Maven კოორდინატები. Forge 1.20.1-ის mod ჩვეულებრივ NeoForge 1.21-ზე ხელახალი build-ის გარეშე არ ჩაიტვირთება.
• Fabric მსუბუქია, Minecraft-ის ახალ ვერსიებზე თვეების ნაცვლად დღეებში განახლდება და თითქმის ყველა mod-ისგან ელის, რომ ცალკე Fabric API mod-ზე იყოს დამოკიდებული. Fabric-ის საკუთარი შეცდომები ჩვეულებრივ პირდაპირი და წასაკითხია; Forge-ისა - ჩვეულებრივ stack trace.

პრაქტიკული განსხვავება სერვერის ოპერატორისთვის ვერსიების ტემპია. Fabric-ის პაკები თამაშს ახლოს მისდევენ, ანუ შენი სერვერი იშვიათად რჩება ძველ ვერსიაზე, მაგრამ mod-ები ხშირად განახლდება. Forge და NeoForge პაკები ჩამორჩებიან, ანუ პაკი თვეების განმავლობაში სტაბილურია და შემდეგ ერთი განახლება ყველაფერს ერთდროულად ამოძრავებს. Paper, Fabric თუ vanilla თავად არჩევანს ფარავს; ეს პოსტი ვარაუდობს, რომ არჩევანი უკვე გაკეთებული გაქვს და რაღაც იწვის.

პაკის სერვერზე მიღება#

Modpack-ი ინსტალაციის ღილაკი არ არის. სერვერს სჭირდება პაკის სერვერის ფაილები, რომელიც კლიენტის პაკისგან განსხვავებული ჩამოტვირთვაა. სამი გზა, იმ თანმიმდევრობით, რამდენ საქმეს მოითხოვს:

1. პაკი სერვერ-პაკს აქვეყნებს. დიდი CurseForge პაკების უმეტესობა აქვეყნებს. ეს არის zip, რომელიც შეიცავს mods/-ს, config/-ს, ზოგჯერ kubejs/-ს ან scripts/-ს და გაშვების სკრიპტს. ატვირთე, ადგილზე გახსენი და შენი გაშვების ბრძანება სკრიპტის მოქმედებას მოარგე.
2. პაკი მხოლოდ manifest-ია. Modrinth-ის .mrpack არის zip, რომლის modrinth.index.json ფაილებს კი არა, ჩამოტვირთვის URL-ებს ჩამოთვლის. გახსენი და სია გადაწყვიტე, ხელით ან community-ის ერთ-ერთი ხელსაწყოთი, რომელიც index-ს კითხულობს და სერვერის საქაღალდეს აგებს.
3. პაკს თავად აგებ. დააყენე loader, შემდეგ დაამატე mod-ები სათითაოდ. უფრო ნელია, მაგრამ ბოლოს იცი, რისთვის არის საქაღალდეში თითოეული jar, რაც ძალიან ღირებულია პირველ ჯერზე, როცა რამე გაფუჭდება.

თავად loader-ის დაყენება შენს მანქანაზე:

# Forge / NeoForge - writes run.sh, libraries/ and user_jvm_args.txt$ java -jar forge-1.20.1-47.3.0-installer.jar --installServer# Fabric - writes a launch jar and downloads the vanilla server jar$ java -jar fabric-installer-1.0.1.jar server -mcversion 1.21.1 -downloadMinecraft

ამის შემდეგ განლაგება ყველა loader-ზე ერთნაირია: mods/ jar-ებს ინახავს, config/ პირველი გაშვების შემდეგ მათ პარამეტრებს, logs/latest.log და logs/debug.log მტკიცებულებას, crash-reports/ კი ავარიის შემდგომ ანგარიშებს.

პანელზე დაფუძნებულ ჰოსტზე ყოველივე ამას file manager-ით ან SFTP-ით ტვირთავ - SFTP და file manager შეიცავს დაკავშირების დეტალებს, და 200 mod-იანი პაკი ბევრად სწრაფად შედის, როცა ერთ არქივად ათრევ და ადგილზე ხსნი, ვიდრე 200 ცალკე ატვირთვით. საკუთარ თავს გულწრფელად უპასუხე, რას აკეთებს და რას არა ჰოსტი აქ: RE:NODE-ზე Minecraft-ის ხაზი აწვდის Paper-ს შესაბამის Java-სთან ერთად, ხოლო modpack-ს შენ თავად აყენებ. არ არსებობს modpack-ის ერთი დაწკაპუნებით installer და არავითარი ინტეგრაცია mod-ების საიტებთან; ფაილები შენია ასატვირთად და startup ცვლადები შენია დასაყენებლად.

Java-ს ვერსია წვრილმანი არ არის#

Modpack-ები Java-ს ბევრად უფრო მკაცრად აფიქსირებენ, ვიდრე vanilla, და შეცდომა არასწორ ვერსიაზე ერთხელ ნანახის შემდეგ ცალსახად ამოსაცნობია:

java.lang.UnsupportedClassVersionError: com/example/Mod has been compiled by amore recent version of the Java Runtime (class file version 61.0), this versionof the Java Runtime only recognizes class file versions up to 52.0

Class file ვერსია 52 არის Java 8, 61 არის Java 17 და 65 არის Java 21. ეს შეტყობინება ნიშნავს, რომ პაკს უფრო ახალი Java უნდა, ვიდრე მუშაობს. საპირისპირო - 1.12 პაკის გაშვება Java 17-ზე - ჩვეულებრივ უფრო ადრე და უფრო არეულად ვარდება, სუფთა ვერსიის საჩივრის ნაცვლად მიუწვდომელი შიდა პაკეტების შესახებ reflection შეცდომებით.

ორი წესი, რომელიც მთელ საღამოებს გიხსნის. პირველი, დაამთხვიე პაკის დასახელებულ Java-ს ზუსტად და არა "რაღაც უფრო ახალს" - Forge 1.16.5 და უფრო ძველი ნამდვილად არ დაიწყება Java 17-ზე. მეორე, Java-ს შეცვლა restart-ია და არა ხელახალი ინსტალაცია, ამიტომ ეს გამორიცხვისთვის ყველაზე იაფი რამაა. პანელზე ვერსია startup ცვლადია; შენს მანქანაზე - რომელი java არის path-ში. JVM flag-ები და Java-ს ვერსიები შეიცავს თითოეულთან ერთად მიმავალ flag-ების ნაკრებებს.

წაიკითხე crash report-ი და არა ბოლო ხაზი#

Crash-ის ბოლო ხაზი სიმპტომია. მიზეზი მის ზემოთაა, stack-ის პირველ ფრეიმში, რომელიც net.minecraft-ისგან განსხვავებულ რამეს ასახელებს. ასვლა გააგრძელე, სანამ პაკეტს არ იპოვი, რომელიც რომელიმე mod-ს ეკუთვნის; ამ mod-იდან დაიწყე. ძველი Forge ანგარიშები ბეჭდავენ Suspected Mods ველს და ხშირად მართლები არიან. თანამედროვე Forge და NeoForge ანგარიშები ამის ნაცვლად ყველა mod-ს -- System Details ---ის ქვეშ ჩამოთვლიან, Fabric კი Fabric Mods: ბლოკს ბეჭდავს, ამიტომ დასამცირებლად მხოლოდ stack trace რჩება.

ბოლო სტრიქონი საკუთარ აბზაცს იმსახურებს. რენდერინგის mod-ებს - Sodium, Iris, OptiFine, Embeddium, Rubidium, Oculus, მინირუკები, shader loader-ები - სერვერის მხარე საერთოდ არ აქვთ და dedicated სერვერი, რომელიც რომელიმეს ტვირთავს, კვდება იმ class-ის მოსაპოვებლად, რომელიც მხოლოდ client jar-შია. როცა კლიენტის პაკის mods საქაღალდეს სერვერზე აკოპირებ, ეს პირველია, რაც უნდა ამოიღო.

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

მეხსიერება: heap, metaspace და kill stack trace-ის გარეშე#

Modded Minecraft-ს მეხსიერების ამოწურვის სამი განსხვავებული გზა აქვს და მხოლოდ ერთი იძლევა იმ შეცდომას, რომელსაც ხალხი ელოდება.

• Heap-ის ამოწურვა გაძლევს OutOfMemoryError: Java heap space-ს, stack trace-ს და ჩვეულებრივ crash report-ს. ეს არის ის, სადაც -Xmx-ის გაზრდა ეხმარება, თუ container-ის ლიმიტის ქვეშ ადგილი არის.
• Metaspace-ის ამოწურვა modded-ის სპეციალობაა. სამასი mod ნიშნავს ათიათასობით ჩატვირთულ class-ს, და metaspace heap-ის გარეთ ცხოვრობს. პაკი, რომელიც "6 GB-ში უნდა ეტეოდეს", 6 GB გეგმაზე -Xmx6G-ით კვდება, რადგან heap-ი კარგად იყო და პროცესმა მაინც გადააჭარბა.
• Container-ის გაჩერება საერთოდ არაფერს ტოვებს. ლოგი წინადადების შუაში წყდება, გამონაკლისი არ არის და crash report არ არის, რადგან პროცესი გარედან მოკლეს მეხსიერების ლიმიტის გადაჭარბებისთვის. RE:NODE-ზე ეს განზრახ არის - ლიმიტზე სერვერი ჩერდება და სუფთად იწყება თავიდან და swap-ზე არ რჩება - მაგრამ დიაგნოსტიკური ნიშანი ყველგან ერთნაირია: სიჩუმე.

მეორისა და მესამის გამოსწორება ერთია და საპირისპირო ინტუიციისაა: შეამცირე `-Xmx`. 10 GB გეგმაზე 200 mod-იანი პაკით -Xmx8G 2 GB-ს ტოვებს metaspace-ისთვის, thread stack-ებისთვის, JIT code cache-ისთვის და Netty-ის direct buffer-ებისთვის, და სერვერი კვდომას წყვეტს. რამდენი RAM სჭირდება Minecraft სერვერს შეიცავს headroom-ის ცხრილს და მსჯელობას.

კლიენტის mod-ები, სერვერის mod-ები და შეუსაბამობის ეკრანი#

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

Forge და NeoForge ამას კავშირის დამყარებისას ამოწმებენ და გამოაქვთ ეკრანი სათაურით Connection Closed - Mismatched Mod Channel List, სადაც ჩამოთვლილია channel-ები, რომლებიც სერვერს აქვს და კლიენტს არა, და პირიქით. ის უხეშია, მაგრამ პატიოსანი: ამ ეკრანზე სია შენი diff-ია. Fabric უფრო მოქნილია - ის კლიენტს პირდაპირ მხოლოდ მაშინ აგდებს, როცა mod ქსელურ channel-ს არეგისტრირებს და კლიენტს არ აქვს - ამიტომ Fabric-ის შეუსაბამობა ხშირად უფრო გვიან ჩნდება, როგორც გაუჩინარებული ბლოკები, მოჩვენებითი ნივთები ან desync-ებული ინვენტარი, სუფთა გაგდების ნაცვლად.

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

• მხოლოდ სერვერის: მწარმოებლურობის mod-ები, spawn-ის კონტროლი, ბლოკების ლოგირება, backup mod-ები, Discord bridge-ები, permission-ები. მოთამაშეები არაფერს აყენებენ.
• მხოლოდ კლიენტის: რენდერინგი, shader-ები, მინირუკები, ინვენტარის მორგება, ინტერფეისის mod-ები. ესენი არასოდეს უნდა მოხვდნენ სერვერის mods საქაღალდეში.
• ორივესი: ყველაფერი, რაც შინაარსს ამატებს ან წესებს ცვლის. ყველა მოთამაშეს ერთი და იგივე jar სჭირდება ერთსა და იმავე ვერსიაზე, რაც პრაქტიკაში ნიშნავს პაკის launcher-ით გავრცელებას და არა ჩატის შეტყობინებით.

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

როცა პაკი ჩაირთვება და ხალხი შეძლებს შესვლას, lag-ის უმეტესობასა და "გუშინ კარგად იყო" ტიპის ანგარიშებს ოთხი რამ განაპირობებს.

view-distance=8simulation-distance=6max-tick-time=60000

1. View distance. ის დატვირთულ chunk-ებს მოთამაშეებზე ამრავლებს, და modded chunk-ები vanilla-ზე მძიმეა. პაკი view distance 12-ზე თხუთმეტი მოთამაშით სხვა სერვერია, ვიდრე იგივე პაკი 8-ზე. დაიწყე 8-დან, ხოლო დიდ tech პაკზე სცადე 6.
2. Chunk-ების გენერაცია თამაშისას. ახალი რელიეფის მოთხოვნისამებრ გენერაცია, სანამ ხალხი თამაშობს, არის ადგილი, საიდანაც "შემთხვევითი" ნახტომების უმეტესობა მოდის, და worldgen mod-ები მას რამდენჯერმე ამძიმებენ. სანამ ვინმე შემოვა, წინასწარ დააგენერირე ის ტერიტორია, რომლის გამოყენებასაც ელი, Chunky-ით (/chunky radius 3000, /chunky start) და გარშემო world border დადე. World border-ები და pregeneration მთელი პროცედურაა.
3. Entity-ების დაგროვება. ფერმები, mob spawner-ები და chunk-ის მჭამელი quarry-ს დაგდებული ნივთები არის ჩვეულებრივი მიზეზი სერვერისა, რომელიც კვირას კარგად მუშაობს და შემდეგ აღარ. Vanilla-ის maxEntityCramming gamerule (ნაგულისხმევი 24) და randomTickSpeed (ნაგულისხმევი 3) ორი ბერკეტია, რომელიც ყველა პაკს აქვს; უმეტეს პაკს ასევე მოჰყვება spawn-კონტროლის mod უკეთესებით.
4. Chunk loader-ები. Tech პაკები მოთამაშეებს chunk-ების მუდმივად დატვირთულად შენახვის საშუალებას აძლევენ - quarry-ები, კონსტრუქციები, განზომილებრივი chunk loader-ები. ოცი ასეთი და შენი სერვერი ოც დამატებით არეალს ასიმულირებს, სადაც არავინ არის. გაარკვიე, რომელი mod გაძლევს ამას შენს პაკში და პირველი კვირის დასრულებამდე შეზღუდე.

იმის დასანახად, რომელი ოთხიდან გაქვს, პროფილირება გააკეთე და ნუ გამოიცნობ. spark მუშაობს Fabric-ზე, Forge-სა და NeoForge-ზე, ისევე როგორც Paper-ზე: /spark profiler start, ითამაშე რამდენიმე წუთი, /spark profiler stop, წაიკითხე ბმული. 1.20.3-სა და უფრო ახალზე vanilla-საც აქვს /tick query, რომელიც tick time-ს გაძლევს რამის დაყენების გარეშე. spark ანგარიშის წაკითხვა განმარტავს, რას ამბობს flame graph-ი.

მწარმოებლურობის mod-ები, რომლებიც უსაფრთხოა#

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

დაამატე სათითაოდ, გადატვირთე და უყურე ლოგს. განსაკუთრებით C2ME ცვლის worldgen-ის მუშაობას და ნამდვილ სამყაროსთან მიახლოებამდე სამყაროს ასლზე უნდა გამოსცადო. და სერვერს ნუ დაუმატებ კლიენტის მხარის "ოპტიმიზაციის" mod-ს იმიტომ, რომ სახელი მართებულად ჟღერს - Sodium და მისი fork-ები რენდერერებია და სერვერზე დასარენდერებელი არაფერია.

პაკის განახლება სამყაროს დაკარგვის გარეშე#

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

1. გააკეთე სამყაროს, `mods/`-ისა და `config/`-ის backup ერთად. ისინი ერთი ერთეულია; სამყარო, აღდგენილი არასწორი mod-ვერსიების გვერდით, აღდგენა არ არის. Backup slot-ები ყველა გეგმას აქვს, backup-ები ინახება იმ მანქანის გარეთ, რომელსაც იცავენ, და ერთი შეგიძლია დაბლოკო, რომ rotation-მა ვერ წაშალოს - განახლებამდე ეს გააკეთე.
2. ჩაიწერე ვერსიები, რომლებზეც ხარ. Loader-ის ვერსია, Minecraft-ის ვერსია, პაკის ვერსია, Java-ს ვერსია. ეს არის მდგომარეობა, რომელზეც უკან ბრუნდები.
3. განაახლე, როცა ონლაინ არავინ არის, გაუშვი სერვერი და წაიკითხე logs/latest.log თავიდან და ნუ უყურებ ბოლოს. საინტერესო ხაზები პირველ ოცდაათ წამშია.
4. ელოდე registry prompt-ს, როცა mod-ს ამოიღებ. Forge ამჩნევს, რომ სამყარო ბლოკებსა და ნივთებზე მიუთითებს, რომლებიც აღარ არსებობს, და ჩუმად წაშლის ნაცვლად ჩატვირთვაზე უარს ამბობს. დანაკარგი შეგნებულად შეგიძლია მიიღო JVM არგუმენტებში -Dfml.queryResult=confirm-ის დამატებით - და ეს დანაკარგია, ამიტომ ჯერ backup გააკეთე.
5. შედი და გაიარე ადგილები, რომლებიც ხალხმა ააშენა, სანამ გამოაცხადებ, რომ დაბრუნდა. გაუჩინარებული ბლოკები მაშინვე ჩანს და მათზე საუბარი გაცილებით ადვილია, სანამ ოცდაათმა ადამიანმა არ დაინახა.

რა უნდა გააკეთო, როცა mod-ის განახლება ტეხავს ფარავს rollback-ს დეტალურად, backup-ები, რომლებიც მართლა აღდგება ფარავს, რატომ არ არის გაუტესტავი backup backup-ი, ხოლო modded სერვერის სისუფთავე ფარავს სხვისი კოდის გაშვების უსაფრთხოების მხარეს.

FAQ#

რამდენი RAM სჭირდება modded Minecraft სერვერს?

გათვალე პაკისთვის და არა მოთამაშეების რაოდენობისთვის: mod-ების, registry-ებისა და worldgen-ის ფასი ისედაც იხდება, ონლაინ ერთი ადამიანია თუ რვა. 30-დან 80 mod-იანი Fabric პაკი 6 GB-ში მუშაობს, 150-ზე მეტი mod-იანი Forge ან NeoForge პაკს 8-დან 10 GB-მდე უნდა, და ძველ 1.12 "ყველაფერი ერთში" პაკებს 10 GB და Java 8. შემდეგ დატოვე container-ის 20-25% შენი -Xmx-ის ქვემოთ metaspace-ისთვის.

რატომ ვარდება ჩემი modpack მაშინვე, მაგრამ vanilla მუშაობს?

იმიტომ, რომ გაშვების ჩავარდნები საქაღალდეში მყოფ jar-ებზეა და არა მეხსიერების ლიმიტზე. ალბათობის მიხედვით: არასწორი Java-ს ვერსია, client-only mod სერვერზე, დაკარგული dependency, mixin კონფლიქტი. ოთხივე დასახელებულია logs/latest.log-ის პირველ ოცდაათ წამში.

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

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

შემიძლია plugin-ების გაშვება Forge ან Fabric სერვერზე?

პირდაპირ - არა: plugin-ები Bukkit-ისა და Paper-ის API-ს მიემართებიან, რომელსაც არცერთი loader არ იძლევა. ჰიბრიდული სერვერები, როგორიცაა Mohist და Arclight, ორივეს ერთმანეთს მიაბამენ და შესამჩნევად ნაკლებ სტაბილურია, ვიდრე ნებისმიერი ნახევარი; თუ plugin-ები გჭირდება, გაუშვი Paper და შეეგუე, რომ ახალ ბლოკებს ვერ დაამატებ. Fabric-ს აქვს ზოგიერთი ნაცნობი ხელსაწყოს სერვერული პორტი, მათ შორის permission-ის იმპლემენტაცია.

რას ნიშნავს "Mixin apply failed"?

mod-მა სცადა მეთოდის დაფატჩვა, რომელიც არ იყო იმ ფორმის, როგორსაც ელოდა - ჩვეულებრივ იმიტომ, რომ სხვა mod-მა ის ადრე დააფატჩა, ან იმიტომ, რომ mod Minecraft-ის სხვა ვერსიისთვის იყო აგებული. ლოგი ასახელებს mixin-ს და სამიზნე class-ს; mod, რომელსაც ეს mixin ეკუთვნის, არის ის, რომელიც უნდა განაახლო ან ამოიღო.

უსაფრთხოა პაკის config ფაილების შეცვლა?

დიახ, და სერვერზე ხშირად აუცილებელიც - პაკები single player-ისთვისაა მორგებული. ერთდროულად ერთი ფაილი შეცვალე, დაიტოვე ორიგინალი და გახსოვდეს, რომ ზოგი mod config-ს მხოლოდ გაშვებისას კითხულობს. config/-ში მყოფი config-ები წაშლის შემთხვევაში თავიდან გენერირდება, რაც გატეხილის გადასაყენებლად სასარგებლო გზაა.