როცა მოდიანი Valheim-ის სერვერი რამის დამატების ან განახლების შემდეგ ირღვევა, მიზეზი თითქმის ყოველთვის ოთხიდან ერთია: დამოკიდებულება, რომელიც არ არის დაყენებული ან ძალიან ძველია; ორი მოდი, რომლებიც თამაშის ერთსა და იმავე კოდს შეუთავსებლად ცვლიან; ორი მოდი, რომლებიც ერთსა და იმავე საქმეს აკეთებენ; ან კლიენტი და სერვერი, რომლებზეც სხვადასხვა ვერსიაა. პირველი და ბოლო ლოგში თავად ჩანს. შუა ორი უფრო ჩუმია და მათი პოვნის ერთადერთი საიმედო გზაა მოდების სიის შუაზე გაყოფა და ტესტირება, სანამ ერთი მოდი არ დარჩება. ეს გიდი გიჩვენებს, როგორ გაარჩიო ეს ოთხი ერთმანეთისგან, რას წერს BepInEx თითოეულ შემთხვევაში და როგორ იპოვო ბრალეული ორმოცი მოდიდან ორმოცი რესტარტის ნაცვლად ექვსი რესტარტით.
კონფლიქტის ოთხი სახეობა#
პრობლემას სახელი ჯობია დაარქვა, სანამ მას ეძებ, რადგან თითოეულ სახეობას თავისი ნიშანი და თავისი გამოსწორება აქვს.
| სახეობა | ტიპური სიმპტომი | სად ჩანს | გამოსწორება |
|---|---|---|---|
| დაკარგული ან ძველი დამოკიდებულება | მოდი უბრალოდ არ იტვირთება | LogOutput.log გაშვებისას | დააყენე ან განაახლე ბიბლიოთეკა |
| patch-ების შეჯახება | შეცდომები ფუნქციის გამოყენებისას, უცნაური ქცევა | exception-ები ლოგში თამაშის დროს | მოაშორე ერთი მოდი ან მოძებნე თავსებადობის patch |
| ორი მოდი, ერთი საქმე | გაორმაგებული ეფექტები, გაფუჭებული UI, desync | ხშირად ლოგში არაფერი ჩანს | დატოვე ორიდან ერთი |
| ვერსიების შეუსაბამობა | შესვლისას გაგდება | კავშირის შეტყობინება, სერვერის ლოგი | შეუსაბამე კლიენტისა და სერვერის სიები |
მეოთხე სინამდვილეში მოდებს შორის კი არა, მანქანებს შორის კონფლიქტია და მას საკუთარი გიდი აქვს: მოდის ვერსიის შეუსაბამობით გაგდება დეტალურად განმარტავს Jotunn-ისა და ServerSync-ის შეტყობინებებს. ეს პოსტი პირველ სამზეა ორიენტირებული - ისინი ერთ მანქანაზე ხდება და სერვერს ან თამაშს ამახინჯებს, ვინც არ უნდა დაუკავშირდეს.
სასარგებლო პირველი კითხვა ისაა, პრობლემა სერვერზეა, კლიენტებზე თუ ორივეგან. თუ სერვერის კონსოლი შეცდომებს აჩვენებს მანამ, სანამ ვინმე შეუერთდება, ეს სერვერის მოდების სიაა. თუ სერვერი სუფთად ადგება და მხოლოდ ერთი მოთამაშის თამაშია გაფუჭებული, პრობლემა იმ მოთამაშის სიაშია. თუ ყველა მოთამაშე ერთსა და იმავე გაფუჭებულ ფუნქციას ხედავს, ჩვეულებრივ ეს მოდია, რომელიც ორივე მხარეზეა დაყენებული, და მისი გასწორება იმ მანქანაზე შეგიძლია, რომლის გადატვირთვაც უფრო მარტივია - ჩვეულებრივ ესაა კლიენტი.
დამოკიდებულებათა ჯაჭვები და რას ამბობს BepInEx#
Valheim-ის ძალიან ცოტა მოდი მუშაობს დამოუკიდებლად. კონტენტ-მოდები Jotunn-ს ეყრდნობა - საერთო მოდინგ ბიბლიოთეკას; ბევრი პოპულარული მოდი ServerSync-ს ათავსებს, რომ კონფიგურაცია კლიენტებს გადასცეს; თავად Jotunn-ს HookGenPatcher სჭირდება. მოდის Thunderstore პაკეტი ამას თავის manifest.json-ში აცხადებს, როგორც Author-Name-Version ფორმის დამოკიდებულების სტრიქონებს:
{ "name": "ExampleMod", "version_number": "1.4.0", "dependencies": [ "denikson-BepInExPack_Valheim-5.4.2202", "ValheimModding-Jotunn-2.20.0" ]}ამ სტრიქონში ვერსია ის ვერსიაა, რომელზეც ავტორმა ააგო მოდი და არა მკაცრი მითითება. r2modman და სხვა მოდ-მენეჯერები მას კითხულობენ და დამოკიდებულებას თავად აყენებენ, ჩვეულებრივ უახლესი ვერსიით. ხელით დაყენება ამას არ აკეთებს: თუ ერთ .dll-ს ბიბლიოთეკის გარეშე დააკოპირებ BepInEx/plugins-ში, BepInEx მის ჩატვირთვაზე უარს ამბობს. სერვერზე ეს ყველაზე გავრცელებული გზაა იმისკენ, რომ მოდი ყველა მოთამაშესთან მუშაობს, სერვერზე კი უჩუმრად არაფერს აკეთებს, რადგან სერვერი ხელით აიგო, კლიენტები კი მენეჯერით. Thunderstore და r2modman ჯგუფებისთვის გიჩვენებს, როგორ დაიცვა ორივე მხარე სინქრონში.
.dll-ის შიგნით plugin იმავე ურთიერთობებს BepInEx-ს ატრიბუტებით აცხადებს და BepInEx-ის chain loader მათ გაშვებისას ასრულებს:
- მკაცრი დამოკიდებულება (hard dependency) ნიშნავს "ამის გარეშე ნუ ჩამტვირთავ". თუ ის არ არის, მოდი გამოტოვებულია.
- რბილი დამოკიდებულება (soft dependency) ნიშნავს "თუ ეს არის, ჯერ ის ჩატვირთე". თუ არ არის, არაფერი ირღვევა; მოდი უბრალოდ კარგავს იმ ინტეგრაციას, რაც ჰქონდა.
- შეუთავსებლობა (incompatibility) ნიშნავს "თუ ეს არის, ნუ ჩამტვირთავ". ავტორები მას მაშინ ამატებენ, როცა იციან, რომ ორი მოდი ვერ თანაარსებობს.
- მინიმალური ვერსია მკაცრ დამოკიდებულებაზე ნიშნავს, რომ ბიბლიოთეკა მინიმუმ ამ ვერსიის უნდა იყოს, ამიტომ ძველი Jotunn შემოწმებას ვერ გაივლის, თუნდაც დაყენებული იყოს.
თითოეული ეს შემთხვევა ლოგში კონკრეტულ სტრიქონს წარმოშობს. BepInEx 5-ით, რომელიც Valheim-ის პაკეტთან მოდის, ისინი ასე გამოიყურება (სახელები მაგალითია):
[Info : BepInEx] Loading [Jotunn 2.20.0][Error : BepInEx] Could not load [ExampleMod 1.4.0] because it has missing dependencies: com.jotunn.jotunn (v2.21.0 or newer)[Error : BepInEx] Could not load [OtherMod 2.0.1] because it is incompatible with: some.other.mod[Warning: BepInEx] Skipping [ExampleMod 1.3.0] because a newer version exists (ExampleMod 1.4.0)დამოკიდებულება დასახელებულია plugin-ის GUID-ით და არა Thunderstore-ის სახელით, ამიტომაა, რომ ჩანს com.jotunn.jotunn და არა ValheimModding-Jotunn. GUID-ის გამოცნობა ჩვეულებრივ შესაძლებელია; თუ არა, მოძებნე მოდის Thunderstore გვერდზე ან README-ში. სტრიქონი "Skipping" ნიშნავს, რომ ერთი და იგივე მოდის ორი ასლია დაყენებული - ჩვეულებრივ ერთი plugins-შია, მეორე კი ქვედირექტორიაში, ადრინდელი ხელით დაყენებიდან დარჩენილი. BepInEx უფრო ახალს ტვირთავს, რაც კარგია მანამ, სანამ ახალს არ წაშლი და ძველი ასლი ისევ არ გაცოცხლდება. როცა ეს სტრიქონი გაჩნდება, დუბლიკატები მოაშორე.
patch-ების შეჯახება#
Valheim-ის თითქმის ყველა მოდი მუშაობს იმით, რომ თამაშის საკუთარ მეთოდებს გაშვებისას Harmony-ით ცვლის (BepInEx-თან მოდის HarmonyX ფორკი). patch-მა შეიძლება კოდი გაუშვას თამაშის მეთოდამდე (prefix), მის შემდეგ (postfix) ან უშუალოდ გადააწეროს მეთოდის ინსტრუქციები (transpiler). ბევრ მოდს შეუძლია ერთსა და იმავე მეთოდზე patch-ის გაკეთება და ჩვეულებრივ ისინი თანაარსებობენ, რადგან თითოეული postfix უბრალოდ ცოტა ქცევას ამატებს. პრობლემა სამ სიტუაციაში იწყება:
- prefix, რომელიც ორიგინალს გამოტოვებს. prefix-მა შეიძლება Harmony-ს უთხრას, საერთოდ არ გაუშვას თამაშის მეთოდი. თუ A მოდი ამას აკეთებს კრაფტინგის შემოწმების ჩასანაცვლებლად, B მოდის postfix კი ვარაუდობდა, რომ ორიგინალი შესრულდა, ახლა B მოდი ისეთ მნიშვნელობებზე მუშაობს, რომლებიც არასოდეს დაყენებულა.
- ორი transpiler ერთ მეთოდზე. transpiler ეძებს ინსტრუქციების კონკრეტულ თანმიმდევრობას და ხელახლა წერს მას. თუ სხვა transpiler-მა ეს თანმიმდევრობა უკვე გადააწერა, მეორე ვერ პოულობს, რასაც ეძებდა, და ან ვერ ვრცელდება, ან არასწორ ადგილას ვრცელდება.
- patch შეცვლილ კოდზე. თამაშის განახლების შემდეგ მეთოდი შეიძლება გადარქმეულიყო, წაშლილიყო ან გადაწერილიყო. მასზე patch-ები ვერ სრულდება და ყველა მოდი, რომელიც ამ patch-ს ეყრდნობოდა, ამ ფუნქციას კარგავს.
გაშვებისას მომხდარ patch-ის შეცდომებს HarmonyX ლოგავს იმ მეთოდის სახელით, რომლის patch-ებაც ვერ მოხერხდა, და stack trace-ით. თამაშისას მომხდარი patch-ის პრობლემები ჩანს როგორც exception-ები, რომელთა stack trace-ში მოდის namespace შედის - SomeAuthor.SomeMod.Patches.InventoryGui_Patch-ში გაჩენილი NullReferenceException გეუბნება, რომელი მოდი მუშაობდა, როცა რაღაც შეფერხდა, თუნდაც ის ბრალეული არ იყოს. წაიკითხე მთელი trace: ზედა მოდი ის არის, რომელმაც ჩაიშალა, მაგრამ უფრო დაბლა სხვა მოდის frame ხშირად სწორედ ის არის, რომელმაც შეცვალა მდგომარეობა, რომელზეც ზედა წააბორძიკდა.
არ არსებობს ჩაშენებული ანგარიში იმის შესახებ, რომელი მოდი რომელ მეთოდს ამუშავებს. პრაქტიკაში ამ შეჯახებებს იმით პოულობ, რომ ამჩნევ: გაფუჭებული ფუნქცია ისეთ სფეროს ეკუთვნის, რომელსაც შენი ორი მოდი ორივე ეხება - ინვენტარი, კრაფტინგი, მშენებლობის განთავსება, რუკა - და ერთ-ერთის მოშორებით ამოწმებ.
ორი მოდი ერთსა და იმავე საქმეზე#
ყველაზე ჩუმი კონფლიქტი ისაა, როცა ორი მოდი თითოეული შესანიშნავად მუშაობს და არასოდეს უნდა დაყენდეს ერთად. შეცდომა არსად ჩანს; უბრალოდ გაორმაგებულ ან ურთიერთგამომრიცხავ ქცევას იღებ. ეს გადაფარვები ჯგუფური მოდ-სიებისას ისევ და ისევ ჩნდება:
| სფერო | რა ფარავს ერთმანეთს | რას ხედავ |
|---|---|---|
| ინვენტარის ზომა | ორი გაფართოებული ინვენტარის მოდი, ან ერთი და ერთი all-in-one | დაკარგული რიგები, ნივთები, რომლებიც დამალულ სლოტებში ქრება |
| კონტეინერებთან მუშაობა | quick stack, sort და trash მოდები | გაორმაგებული ღილაკები, ნივთები ორჯერ გადაადგილებული |
| საერთო ყუთები | multi-user chest და stacking მოდი, რომელსაც ის არ უჭერს მხარს | desync, უარყოფილი გადატანები |
| ყუთებიდან კრაფტინგი | ორი craft-from-containers მოდი | რესურსები ორჯერ ან საერთოდ არ ითვლება |
| დასტის ზომები, ტვირთის წონა | all-in-one და სპეციალიზებული მოდი | ერთი კონფიგურაცია უჩუმრად გადაფარავს მეორეს |
| რუკა | რამდენიმე pin ან minimap მოდი | დუბლირებული pin-ები, ერთმანეთზე გადაფარული პანელები |
ზოგი ავტორი ამ შეჯახებებს აფიქსირებს დოკუმენტაციაში. MultiUserChest-ის გვერდზე წერია, რომ QuickStore, QuickStack და SimpleSort desync-ს იწვევს და მასთან ერთად არ ეშვება, და რეკომენდებულია Quick Stack Store Sort Trash Restock; ეს მოდი კი თავს Trash Items-თან შეუთავსებლად აცხადებს, რადგან trash-ს უკვე შეიცავს. ყოველი მოდის დამატებამდე წაიკითხე მისი გვერდის "Incompatible" ან "Known issues" სექცია და შეადარე არსებულ სიას. კომფორტის მოდები ჯგუფებისთვის განიხილავს გავრცელებულ კონტეინერისა და რუკის მოდებს და იმას, რომელი რომელთან ერთად მუშაობს.
all-in-one მოდები საკუთარ გაფრთხილებას იმსახურებს. Valheim Plus-ის ფორკები და მსგავსი პაკეტები ერთბაშად ათეულობით სისტემას ცვლიან - დასტის ზომები, მშენებლობა, კრაფტინგი, რუკის გაზიარება, ინვენტარი. მათ თავზე ნებისმიერი სპეციალიზებული მოდის დამატება ლატარიაა, რადგან all-in-one ალბათ უკვე ამუშავებს იმ სფეროს. თუ შენი ჯგუფი ერთს იყენებს, მიიჩნიე ის სიის საფუძვლად და ყოველი დამატება შეამოწმე მის ფუნქციების სიასთან.
LogOutput.log-ის სწორად კითხვა#
ყველაფერი ზემოთქმული ერთი ფაილის კარგად წაკითხვაზეა დამოკიდებული. BepInEx ყოველ გაშვებაზე წერს BepInEx/LogOutput.log-ს და წინას გადაწერს, ამიტომ თუ გაშვებების შედარება გინდა, გადატვირთვამდე დააკოპირე. სერვერზე იგივე სტრიქონების გადახვევა კონსოლშიც შეგიძლია ნახო, თუმცა ფაილში ძებნა უფრო მოხერხებულია.
ჯანსაღი გაშვება დაახლოებით ამ თანმიმდევრობით მიდის:
- preloader-ისა და Doorstop-ის სტრიქონები. თუ ლოგი აქ ჩერდება, თავად BepInEx არის გატეხილი - ეს განხილულია პოსტში სერვერი გაშვებისას ითიშება.
Loading [Name Version]სტრიქონი ყოველი plugin-ისთვის, დამოკიდებულების თანმიმდევრობით.Chainloader startup complete, რის შემდეგაც თამაში იღებს კონტროლს.- თამაშის სტრიქონები: სამყაროს ჩატვირთვა, სერვერის რეგისტრაცია, join code crossplay სერვერზე.
ყველაფერი მე-2 და მე-3 ნაბიჯებს შორის თავად მოდების გაშვებაა. მოდი, რომელიც იტვირთება, მაგრამ შემდეგ საკუთარ Awake-ში exception-ს აგდებს, ჩატვირთულად აღინიშნება და მაინც არ მუშაობს, ამიტომ Could not load-ის ძებნაზე ნუ გაჩერდები - მოძებნე აგრეთვე Exception და [Error. გაფრთხილებების უმეტესობა ხმაურია; შეცდომები ყოველთვის წასაკითხია. BepInEx ლოგების კითხვა უფრო ღრმად განიხილავს preloader-ისა და Doorstop-ის ჩავარდნებს.
კლიენტზე იგივე ფაილი თამაშის საქაღალდეში კი არა, r2modman-ის პროფილის საქაღალდეშია, რაც ხალხს ხშირად ააბნევს. r2modman-ის პარამეტრებში არის ღილაკი პროფილის საქაღალდის გასახსნელად; ლოგი მის BepInEx ქვესაქაღალდეშია.
გატეხილი მოდ-სიის bisect#
როცა ლოგი ბრალეულს არ ასახელებს, სია შუაზე გაყავი. ნელი ჩანს, მაგრამ ყველაზე სწრაფი მეთოდია: 40 მოდით ექვსი რაუნდი ერთ ეჭვმიტანილს გიტოვებს. ნაბიჯები:
- იმუშავე ასლზე. ჯერ გააკეთე სამყაროსა და მთელი
BepInExსაქაღალდის backup. კონტენტ-მოდების ნახევრის მოშორებით ტესტირებამ შეიძლება შენახვისას სამყაროდან მათი ნივთები და ნაგებობები წაშალოს, ამიტომ bisect-ს ცოცხალ სამყაროზე ნუ გააკეთებ. სწორი ადგილია სატესტო სერვერი ან სამყაროს ლოკალური ასლი. - გახადე პრობლემა განმეორებადი. ზუსტად ჩაიწერე მოქმედება, რომელიც ფუჭდება: "სამჭედლოში კრაფტინგი exception-ს აგდებს", "სერვერი chain loader-ზე ჩერდება". თუ მოთხოვნისამებრ ვერ გამოიწვევ, ვერც bisect-ს გააკეთებ.
- ბიბლიოთეკები დატოვე. Jotunn, HookGenPatcher და სხვა ბიბლიოთეკები ყოველ რაუნდში რჩება. შენ ამოწმებ მოდებს, რომლებიც მათ იყენებენ.
- მოაშორე ნახევარი. დარჩენილი მოდების ნახევარი გადაიტანე
BepInEx/plugins-იდან მის გარეთ არსებულ საქაღალდეში, მაგალითადplugins-disabled-შიBepInEx-ის გვერდით. r2modman-ში ამის ნაცვლად გამორთე ისინი. - შეამოწმე. თუ პრობლემა გაქრა, ბრალეული მოშორებულ ნახევარშია: დააბრუნე ის ნახევარი და მოაშორე მეორე. თუ პრობლემა დარჩა, ის ისევ დაყენებულ ნახევარშია.
- გაიმეორე ეჭვმიტანილ ნახევარზე, სანამ ერთი მოდი არ დარჩება.
# On a Linux server, park half the mods outside the plugins folder$ mkdir -p ~/server/plugins-disabled$ mv ~/server/BepInEx/plugins/{ModA,ModB,ModC,ModD}* ~/server/plugins-disabled/$ ls ~/server/BepInEx/pluginsორი გართულება. პირველი, კონფლიქტს ორი მოდი სჭირდება, ამიტომ პრობლემა შეიძლება ორივე ნახევარში გაქრეს. ასეთ შემთხვევაში თითო ეჭვმიტანილი თითო ნახევარშია: ერთი ნახევარი სრულად დატოვე დაყენებული და მეორე გაყავი, სანამ პრობლემა არ დაბრუნდება - ასე პირველ მოდს იპოვი; მერე იგივე საპირისპირო მხრიდან გაიმეორე მისი წყვილის საპოვნელად. მეორე, მოშორებული მოდი, რომელზეც სხვები არიან დამოკიდებული, თავისთან ერთად მათაც გამორთავს. ყოველი რაუნდის შემდეგ შეამოწმე ლოგი ახალი Could not load სტრიქონებისთვის, რომ იცოდე, რა მუშაობდა სინამდვილეში.
RE:NODE-ზე ფაილ-მენეჯერს შეუძლია BepInEx/plugins-ში ფაილების გადატანა ან გადარქმევა SFTP კლიენტის გარეშე, კონსოლი კი BepInEx-ის სტრიქონებს ჩნდებისთანავე აჩვენებს, ასე რომ bisect-ის ერთი რაუნდი არის გადატანა, რესტარტი და გადახვევა. პირველ რაუნდამდე Backups ჩანართიდან გააკეთე backup და ჩაკეტე, რომ ტესტირებისას rotation-მა ვერ წაშალოს - ჩაკეტვის შესახებ იხილე backup-ები.
კონფიგურაციის კონფლიქტები და სინქრონიზებული პარამეტრები#
ზოგი კონფლიქტი კოდში კი არა, კონფიგურაციაშია. ორი მოდი, რომელთაგან ორივე დასტის ზომის ან ტვირთის წონის პარამეტრს ხსნის, თითოეული საკუთარს გამოიყენებს და ის გაიმარჯვებს, ვინც ბოლოს მუშაობს. გამოსწორება ისაა, რომ მნიშვნელობა მხოლოდ ერთში დააყენო, მეორე კი ნაგულისხმევზე დატოვო ან გამორთო.
სინქრონიზებული კონფიგურაციები კიდევ ერთ ფენას ამატებს. მოდები, რომლებიც ServerSync-ს ან Jotunn-ის config sync-ს იყენებენ, სერვერის მნიშვნელობებს კავშირისას ყოველ კლიენტს უგზავნიან და კლიენტის საკუთარ ფაილს გადაფარავენ, სანამ ის დაკავშირებულია. ამიტომ მოთამაშე, რომელიც ლოკალურ კონფიგურაციას ცვლის და ცვლილებას ვერ ხედავს, bug-ს კი არა, სერვერის გამარჯვებულ მნიშვნელობას ხედავს. საპირისპიროც სწორია - სინქრონიზებული პარამეტრის ყველასთვის შესაცვლელად სერვერის ფაილის რედაქტირებაა ერთადერთი გზა. სინქრონიზებულად არამონიშნული პარამეტრები თითოეულ მოთამაშესთან ცალკე რჩება და ორ მოთამაშეს კანონიერად შეიძლება განსხვავებული მნიშვნელობები ჰქონდეს. დეტალები, დაკეტილი კონფიგურაციებისა და მხოლოდ ადმინისთვის განკუთვნილი პარამეტრების ჩათვლით, არის პოსტში ServerSync და კონფიგურაციის იძულება.
bisect-ისას კონფიგურაციის ფაილები ხაფანგია. მოშორებული მოდის .cfg რჩება BepInEx/config-ში, რაც უვნებელია, მაგრამ მოდი, რომელიც სხვა მოდის პარამეტრებს კითხულობს, შეიძლება სხვანაირად მოიქცეს იმის მიხედვით, რომელი კონფიგურაციებია. თუ პრობლემა ყველა bisect რაუნდს გადაურჩა, სცადე მთელი BepInEx/config განზე გადაიტანო, რომ ყველა მოდი ნაგულისხმევით დაიწყოს. თუ ეს ასწორებს, ბრალეული მოდი კი არა, პარამეტრია.
კონფლიქტების თავიდან აცილება ჯგუფურ სერვერზე#
ჯგუფურ სერვერებზე კონფლიქტების უმეტესობა იქიდან მოდის, რომ რამდენიმე რამეს ერთდროულად ცვლიან. რამდენიმე ჩვევა უმეტესობას აჩერებს:
- ერთი ცვლილება ერთ რესტარტზე. დაამატე ან განაახლე ერთი მოდი, გადატვირთე, შეამოწმე, მერე შემდეგი. თუ რამე გაფუჭდა, უკვე იცი, რომელმა ცვლილებამ.
- განახლებამდე წაიკითხე changelog. ავტორები იქ აფიქსირებენ ახალ დამოკიდებულებებს და გაუქმებულ თავსებადობას. ახალი მკაცრი დამოკიდებულება ბიბლიოთეკაზე, რომელიც შენ არ გაქვს, ხელით მოვლილ სერვერზე მოდს გატეხავს.
- შეინახე სამუშაო ასლი. ყოველი სამუშაო მდგომარეობის შემდეგ დააარქივე
BepInEx/pluginsდაBepInEx/config. უკან დაბრუნება მაშინ საქაღალდის დაკოპირებაა და არა ორმოცი ვერსიის ნომრის გახსენება. - უპირატესობა მიანიჭე სპეციალიზებულ მოდებს გადაფარვადებზე. ერთი მოდი ერთ საქმეზე. თუ ორივე მოდი ერთსა და იმავე ფუნქციას გთავაზობს, ერთში გამორთე.
- patch-ის დღეს განახლებებს ნუ აჩქარებ. თამაშის patch-მა შეიძლება ბევრ მოდში ერთდროულად დააზიანოს patch-ები და ეს ასი კონფლიქტივით გამოიყურება, სინამდვილეში კი ერთი მიზეზია - რა ვქნა, როცა მოდის განახლება გატყდება განიხილავს ლოდინის თამაშს.
თუ სიას ნულიდან აგებ, BepInEx სერვერის გიდში დაყენების საფუძვლებია.
FAQ#
როგორ გავიგო, რომელი მოდი ანგრევს ჩემს Valheim სერვერს?
გახსენი BepInEx/LogOutput.log და მოძებნე Could not load, შემდეგ Exception. exception-ის stack trace ჩვეულებრივ შეიცავს მოდის namespace-ს, რომელიც მუშაობდა. თუ ლოგი არაფერ სასარგებლოს არ ასახელებს, გააკეთე bisect: მოაშორე მოდების ნახევარი, შეამოწმე და ისევ გაყავი ის ნახევარი, რომელშიც პრობლემაა.
სერვერზე დამოკიდებულებები ხელით უნდა დავაყენო?
დიახ, თუ სერვერის მოდები არ დაგიყენებია მენეჯერით, რომელიც მათ თავად აგვარებს. მოდის Thunderstore გვერდზე ჩამოთვლილი ყოველი მკაცრი დამოკიდებულება BepInEx/plugins-ში უნდა იყოს მოთხოვნილ ან უფრო ახალ ვერსიაზე, თორემ BepInEx გაშვებისას მოდს გამოტოვებს.
შეიძლება ორმა მოდმა, რომლებიც ერთსა და იმავეს ცვლიან, ერთად იმუშაოს?
ხშირად დიახ. patch-ების უმეტესობა ქცევას მხოლოდ თამაშის მეთოდის შესრულების შემდეგ ამატებს და რამდენიმე ასეთი თანაარსებობს. პრობლემები მაშინ ჩნდება, როცა ერთი მოდი ორიგინალ მეთოდს მთლიანად ცვლის ან მის ინსტრუქციებს ხელახლა წერს, ამიტომ მოდები, რომლებიც ერთ სფეროს ეხება - ინვენტარი, კრაფტინგი, მშენებლობა - შესამოწმებელი პირველი წყვილია.
რატომ მუშაობს მოდი ჩემს მეგობრებთან, სერვერზე კი არა?
ჩვეულებრივ იმიტომ, რომ სერვერი ხელით აიგო და მას აკლია ბიბლიოთეკა, რომელიც მეგობრების მოდ-მენეჯერმა მათთვის დააყენა, ან იმიტომ, რომ სერვერზე მოდის ძველი ასლი ქვესაქაღალდეში რჩება. შეამოწმე სერვერის ლოგი Could not load და Skipping სტრიქონებისთვის.
დააზიანებს თუ არა ტესტირებისას მოდის მოშორება ჩემს სამყაროს?
შეიძლება. როცა კონტენტ-მოდი აკლია, სამყარო ვერ ტვირთავს მის ნივთებსა და ნაგებობებს და შენახვისას ისინი იკარგება. bisect ყოველთვის სამყაროს ასლზე გააკეთე და შემდეგ აღადგინე backup, იმის ნაცვლად რომ იმ სამყაროზე ტესტირება გააკეთო, რომელზეც შენი ჯგუფი თამაშობს.
