Valheim BepInEx ლოგები: LogOutput.log-ის კითხვა მოდების გასასწორებლად

როცა მოდიანი Valheim სერვერი უცნაურად იქცევა, პასუხი თითქმის ყოველთვის სერვერის ძირში მდებარე BepInEx/LogOutput.log-შია, და თითქმის ყოველთვის პირველ შეცდომაში და არა ბოლოში. წაიკითხე სამ გავლაში. პირველი: არის თუ არა საერთოდ BepInEx-ის ბანერი - თუ არა, Doorstop-მა loader-ი არ ჩატვირთა და მოდებს ჯერ მნიშვნელობა არ აქვს. მეორე: Loading [...] ხაზები და ყველაფერი, რაც ამბობს Could not load ან Skipping - ეს არის შენი რეალური plugin-ების სია, დაკარგული dependency-ები პირდაპირ დასახელებულია. მესამე: პირველი Error გაშვების შემდეგ, რომლის stack trace-შიც მოდის სახელია. როცა ლოგი exception-ების კედელია და პირველი მიზეზი არ ჩანს, კითხვა შეწყვიტე და ბისექცია გააკეთე: plugin-ების ნახევარი გადაიტანე, გადატვირთე სამყაროს ასლზე და ისევ განახევრე. ოცდაათი მოდი ხუთ რაუნდს მოითხოვს.

სად არის ლოგები#

მოდიანი Valheim ინსტალაცია ერთ ადგილზე მეტში წერს და რომელი გჭირდება, იმაზეა დამოკიდებული, რომელი მხარე გაფუჭდა.

LogOutput.log-ის ორი თვისება ადამიანებს ატყუებს:

• ნაგულისხმევად ის ყოველ გაშვებაზე გადაიწერება. დაკრაშებული სერვერის გადატვირთვა "ვნახოთ, გაიმეორებს თუ არა" პირველი კრაშის მტკიცებულებას ანადგურებს. ჯერ ფაილი ჩამოტვირთე ან დააკოპირე. ლოგები, რომლებიც ინახავს ღირს ზოგადად ამას ასაბუთებს.
• ის იმდენად დეტალურია, რამდენსაც `BepInEx.cfg`-ში დონე ადგენს. ნაგულისხმევი ჩანაწერები ინახავს შეცდომებს, გაფრთხილებებს, შეტყობინებებსა და ინფორმაციას, რაც დიაგნოსტიკის უმეტესობისთვის საკმარისია.

loader-ის ლოგირების პარამეტრები BepInEx/config/BepInEx.cfg-შია. BepInEx 5-ის მიმდინარე რელიზებში ისინი ასე გამოიყურება:

[Logging.Disk]WriteUnityLog = falseAppendLog = falseEnabled = trueLogLevels = Fatal, Error, Warning, Message, Info

LogLevels-ში Debug-ის დამატება (ან All-ზე დაყენება) ზოგ მოდს გაცილებით ლაპარაკას ხდის, რაც ეხმარება, როცა ავტორი debug ლოგს ითხოვს. შემდეგ უკან დააბრუნე; დატვირთულ სერვერზე debug ლოგი სწრაფად იზრდება. AppendLog = true ძველ გაშვებებს იმავე ფაილში ინახავს გადაწერის ნაცვლად, რაც გამოსადეგია კრაშის დევნისას, რომელიც მხოლოდ ღამით ხდება. გასაღებების სახელები BepInEx 5-ში სტაბილური იყო, მაგრამ ბრმად ჩასმის ნაცვლად საკუთარ ფაილს შეადარე.

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

როგორ გამოიყურება ჯანმრთელი გაშვება#

ნორმის ცოდნის გარეშე გადახრას ვერ დაინახავ. სუფთა მოდიანი გაშვება preloader-ს გადის, შემდეგ chainloader-ს, შემდეგ ერთი ხაზია თითო plugin-ზე:

[Message:   BepInEx] BepInEx 5.4.2202 - valheim_server[Message:   BepInEx] Preloader started[Message:   BepInEx] Preloader finished[Message:   BepInEx] Chainloader ready[Message:   BepInEx] Chainloader started[Info   :   BepInEx] 4 plugins to load[Info   :   BepInEx] Loading [Jotunn 2.20.1][Info   :   BepInEx] Loading [ServerDevcommands 1.70][Info   :   BepInEx] Loading [EpicLoot 0.10.3][Info   :   BepInEx] Loading [DiscordConnector 3.1.0][Message:   BepInEx] Chainloader startup complete

რეალურ ლოგებში ამ ხაზებს შორის მეტია - გაშვების დეტალები, patcher-ის ხაზები, თითოეული plugin-ის საკუთარი შეტყობინებები - და ვერსიის ნომრები განსხვავდება. მნიშვნელოვანია ფორმა:

• ბანერი პროცესს ასახელებს. სერვერზე წერია valheim_server; კლიენტზე - valheim.
• N plugins to load-ში რიცხვი უნდა ემთხვეოდეს იმ მოდების რაოდენობას, რაც გგონია, რომ დააყენე.
• ყველა მოდს აქვს Loading ხაზი ვერსიით. მოდი ხაზის გარეშე არ ჩატვირთულა.
• Chainloader startup complete ჩნდება. მის შემდეგ Valheim-ის საკუთარი გაშვება გრძელდება და სამყაროს ჩატვირთვითა და სესიის ხაზით მთავრდება.

თითოეულ ხაზს აქვს ფორმა [Level : Source] text. წყარო loader-ისთვის არის BepInEx, მოდის საკუთარი შეტყობინებებისთვის - plugin-ის სახელი, თავად Unity-ის შეტყობინებებისთვის - Unity Log, და ზოგჯერ HarmonyX - patching ბიბლიოთეკა, რომელსაც მოდები იყენებენ. დონე არის Fatal, Error, Warning, Message, Info ან Debug.

ბანერი არ არის: Doorstop და preloader#

თუ LogOutput.log არ არსებობს ან მისი დროის ანაბეჭდი უახლეს გაშვებამდეა, BepInEx არ გაშვებულა. სერვერი ჩვეულებრივ vanilla Valheim-ად ჩაირთო. ყველა მოდთან დაკავშირებული სიმპტომი ამის შედეგია, ამიტომ ჯერ ეს გაასწორე.

Doorstop პატარა ინჟექტორია, რომელიც Unity-ს თამაშამდე BepInEx-ის ჩატვირთვას აიძულებს. Linux-ზე ის start_server_bepinex.sh-ის მიერ დაყენებული გარემოს ცვლადებით მუშაობს; Windows-ზე ეს არის winhttp.dll და doorstop_config.ini სერვერის ძირში. სრულ განლაგებას აჩვენებს Valheim-ის მოდები BepInEx-ით სერვერზე. პრობლემები კონსოლში ნანახი შეტყობინების მიხედვით:

`ERROR: ld.so: object 'libdoorstop_x64.so' from LD_PRELOAD cannot be preloaded` - ბიბლიოთეკა იქ არ არის, სადაც LD_LIBRARY_PATH მიუთითებს. ჩვეულებრივ არქივის შემფუთავი საქაღალდე დაკოპირდა და ძირში doorstop_libs-ის ნაცვლად BepInExPack_Valheim/doorstop_libs დარჩა.

`/bin/bash^M: bad interpreter` - გაშვების სკრიპტს Windows-ის ხაზის დასასრულები აქვს, ჩვეულებრივ კომპიუტერზე რედაქტირებისა და ატვირთვის შემდეგ. უკან გადააქციე:

$ sed -i 's/\r$//' start_server_bepinex.sh$ chmod +x start_server_bepinex.sh

`Permission denied` სკრიპტის გაშვებისას - გადატანისას შესრულების ბიტი დაკარგა. ზემოთ მოცემული chmod ასწორებს.

საერთოდ შეცდომის გარეშე, ბანერიც არ არის - სერვერი ჩვეულებრივი ბრძანებით გაეშვა და არა BepInEx-ისით, ან გარემოს ცვლადები არ დაყენებულა. პანელის ჰოსტზე შეამოწმე გაშვების ბრძანება ან ცვლადები, რომლებსაც ჰოსტი BepInEx-ისთვის იყენებს.

Windows: ბანერი არ არის - winhttp.dll არ არის საქაღალდეში, სადაც valheim_server.exe დევს, ან doorstop_config.ini-ში ის გამორთულია. ini-ს გასაღებების სახელები Doorstop 3-სა და 4-ს შორის განსხვავდება; გახსენი ფაილი და მოძებნე ჩართვის გადამრთველი და სამიზნე assembly-ის გზა, რომელიც BepInEx\core\BepInEx.Preloader.dll-ზე უნდა მიუთითებდეს.

როცა ბანერი ჩნდება, მაგრამ გაშვება Preloader started-სა და Chainloader ready-ს შორის ჩერდება, პრობლემა patcher-შია და არა plugin-ში. patcher-ები BepInEx/patchers-შია და თამაშის კოდის ჩატვირთვამდე მუშაობს. HookGenPatcher, რომელიც Jotunn-ს სჭირდება, Valheim სერვერებზე ჩვეულებრივი მაგალითია. თამაშის სხვა ვერსიისთვის აგებული patcher აქ ვარდება, ისევე როგორც plugins-ში ჩადებული, სადაც არ ეკუთვნის - შეცდომა ჩვეულებრივ assembly-ს ასახელებს.

დაკარგული dependency-ები და გამოტოვებული plugin-ები#

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

$ grep -nE "Could not load|Skipping|Error loading" BepInEx/LogOutput.log

დაკარგული dependency-ის ხაზი dependency-ს მისი GUID-ით ასახელებს და არა საჩვენებელი სახელით, ხშირად მინიმალური ვერსიითაც:

[Error  :   BepInEx] Could not load [EpicLoot 0.10.3] because it has missingdependencies: com.jotunn.jotunn (v2.20.0 or newer)

ეს GUID არის ის, რასაც დამოკიდებულმა მოდმა მოითხოვა. მოძებნე მოდის Thunderstore-ის გვერდზე ან მისი dependency-ების სიაში, რომ პაკეტს დაუკავშირო. ორი სიტუაცია ამ ხაზს იძლევა მაშინაც, როცა დარწმუნებული ხარ, რომ dependency დაყენებულია. ან თავად dependency დაფეილდა ლოგში უფრო ადრე - მოძებნე მისი საკუთარი Could not load ან Error loading ხაზი - ან დაყენებულია მინიმუმზე ძველი ვერსია. და რადგან Jotunn-ს HookGenPatcher სჭირდება, არასწორ საქაღალდეში მყოფმა HookGenPatcher-მა შეიძლება Jotunn დააფეილოს და ყველა Jotunn-ის მოდმა შემდეგ dependency-ის არარსებობა დააფიქსიროს. გაასწორე ჯაჭვის პირველი რგოლი და დანარჩენი ჩვეულებრივ გასწორდება.

process filter-ის ხაზი ისაა, რომელიც გეუბნება, რომ მოდი მხოლოდ კლიენტისაა. მოდები, რომლებსაც აზრი მხოლოდ ეკრანით აქვთ, ხშირად აცხადებენ, რომ valheim.exe-ში მუშაობენ. valheim_server-ზე ისინი გაფრთხილებით გამოიტოვება, რაც უვნებელია; ლოგის სიწყნარისთვის ამოიღე ისინი სერვერიდან.

Exception-ები: პასუხისმგებელი მოდის პოვნა#

ლოგში exception ბლოკია: ხაზი, რომელიც exception-ის ტიპს ასახელებს, შემდეგ მეთოდების გამოძახების stack trace, ყველაზე ახალი პირველი. უმეტესობა უარესად გამოიყურება, ვიდრე არის.

[Error  : Unity Log] MissingMethodException: Method not found:void Humanoid.UseItem(Inventory,ItemDrop/ItemData,bool)Stack trace:ExampleMod.Patches.Humanoid_UseItem_Patch.Prefix (Humanoid __instance) ...(wrapper dynamic-method) Humanoid.DMD<Humanoid::UseItem>(Humanoid, ...)

ზემოთ მოცემული trace გამოგონილია, მაგრამ ტიპური ფორმისაა. მისი კითხვა:

1. ტიპი. MissingMethodException, MissingFieldException და TypeLoadException ნიშნავს, რომ მოდი თამაშის სხვა ვერსიაზე იყო აგებული და კოდს იძახებს, რომელიც შეიცვალა. Valheim-ის patch-ის შემდეგ ისინი მოსალოდნელია, სანამ ავტორები არ განაახლებენ. config-ში ვერაფერი გაასწორებს.
2. მოდი. trace-ში დაიხარე ქვემოთ და მოძებნე namespace, რომელიც არც Valheim-ის საკუთარი კლასის სახელია და არც UnityEngine - აქ ExampleMod.Patches. ეს არის მოდი, რომლის კოდიც სრულდებოდა.
3. დაპატჩებული მეთოდი. ხაზები DMD<...>-ით თამაშის მეთოდებია, რომლებიც მოდმა Harmony-ით დააპატჩა. მეთოდის სახელი გეუბნება, რას აკეთებდა მოთამაშე - ნივთს იყენებდა, ნაგებობას აყენებდა - რაც გეხმარება, როცა პრობლემის გამეორება გჭირდება.

NullReferenceException ყველაზე ბუნდოვანია. მოდის stack trace-ში ის ჩვეულებრივ ნიშნავს, რომ მოდი რაღაცას ელოდა, რაც არ იყო: config-ის დაკარგულ მნიშვნელობას, მოდის ნივთს, რომელიც არ ჩატვირთულა, ან ობიექტს, რომელიც კლიენტის მოდს headless სერვერზე ეგონა. სანამ თავად მოდს დაადანაშაულებ, შეამოწმე, ჩაიტვირთა თუ არა მისი dependency-ები.

ერთი exception გაშვებისას, რომელსაც ჩვეულებრივი Chainloader startup complete და მომუშავე სერვერი მოჰყვება, შეიძლება კოსმეტიკური იყოს. იგივე exception, რომელიც ყოველ რამდენიმე წამში მეორდება, არა - ის CPU-ს ხარჯავს და დისკს ავსებს, და მასში დასახელებული მოდი უნდა ამოიღო ან გაასწორო. Game server-ის ლოგების განმარტება ხმაურისა და სიგნალის გამიჯვნაზე მეტს ამბობს.

ხმაური, რომელსაც უგულებელყოფ#

headless სერვერი ისეთ რამეებს წერს, რაც საგანგაშოდ ჟღერს და არაფერს ნიშნავს. Valheim სერვერზე ეს ჩვეულებრივ უვნებელია:

• შეტყობინებები shader-ებზე, გრაფიკულ მოწყობილობებზე ან აუდიოზე. სერვერს GPU და ხმა არ აქვს; Unity ამას ამბობს.
• Fallback handler could not load library ხაზები Linux-ზე, ბიბლიოთეკებისთვის, რომელსაც headless სერვერი არასდროს იყენებს.
• მოდის გაფრთხილებები, რომ არასავალდებულო ინტეგრაცია ვერ მოიძებნა - მაგალითად, მოდი აღნიშნავს, რომ სხვა მოდი, რომელთანაც მუშაობა შეუძლია, დაყენებული არ არის.
• Steam-ის ხაზები სერვერის საკუთარ ID-სა და სესიაზე, რომლებიც Valheim-ს ეკუთვნის და არა BepInEx-ს.

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

გატეხილი მოდების ნაკრების ბისექცია#

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

პროცედურა:

1. სამყარო და მთელი BepInEx საქაღალდე შეინახე backup-ში.
2. სერვერი სამყაროს ასლზე მიუთითე (სხვა -world სახელი დაკოპირებული .db და .fwl ფაილებით) ან სუფთა სატესტო სამყაროზე, თუ ხარვეზი მასზე არ არის დამოკიდებული.
3. plugins-ის გარეთ შექმენი საქაღალდე, მაგალითად BepInEx/plugins_off. ის გარეთ უნდა იყოს: BepInEx .dll ფაილებს plugins-ის ქვესაქაღალდეებიდანაც ტვირთავს, ამიტომ plugins/disabled საქაღალდე არაფერს ათიშავს.
4. მოდების ნახევარი მასში გადაიტანე. ბიბლიოთეკები, როგორიცაა Jotunn, ადგილზე დატოვე და თითოეული მოდი მისი dependency-ებით შეინახე - ბიბლიოთეკისგან მოშორებული მოდი მხოლოდ დაკარგული dependency-ის ხაზს გამოიწვევს და არაფერს გასწავლის.
5. გაუშვი სერვერი და ხარვეზი გაიმეორე.
6. თუ ხარვეზი გაქრა, ის გადატანილ ნახევარშია: ნახევრები გაცვალე. თუ დარჩა, ის ჯერ კიდევ ჩატვირთულ ნახევარშია. ნებისმიერ შემთხვევაში საეჭვო ჯგუფი ისევ განახევრე.
7. შეჩერდი, როცა საეჭვო ჯგუფი ერთი მოდია. დაადასტურე ყველაფრის უკან დამატებით, გარდა ამ ერთისა.

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

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

ჰოსტზე, სადაც სერვერი კრაშის შემდეგ ავტომატურად გადაიტვირთება, მოდების ნაკრებმა, რომელიც გაშვებისას კრაშდება, ციკლი შეიძლება შექმნას. RE:NODE-ზე საათში სამი კრაშ-გადატვირთვა სერვერის გვერდზე გაფრთხილებას ჩამოკიდებს და ticket-ს გახსნის, ამიტომ ბისექციის დაწყებამდე სერვერი გააჩერე და ციკლში ნუ დატოვებ - რატომ გადაიტვირთება შენი game server განუწყვეტლივ ციკლს განმარტავს.

ლოგის გაზიარება დახმარებისთვის#

მოდების ავტორები და საზოგადოების დამხმარეები სრულ LogOutput.log-ს მოგთხოვენ და არა ბოლო ხაზების ეკრანის სურათს. სასარგებლო ვერსია:

• მთელი ფაილი, პირველი ხაზიდან. მიზეზი თავთან ახლოსაა; ხილული ბოლო შედეგებია.
• ჩავარდნილი გაშვებიდან, სანამ გადატვირთვა მას გადაწერდა.
• ორივე მხარე, როცა კლიენტი გამოიგდება ან კრაშდება შესვლისას: სერვერის ლოგი და მოთამაშის საკუთარი LogOutput.log მისი პროფილიდან.
• შენი მოდების სია ვერსიებით, რომელიც Loading ხაზებშივე არის:

$ grep -o 'Loading \[[^]]*\]' BepInEx/LogOutput.log | sort

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

FAQ#

რატომ არის LogOutput.log ცარიელი ან არ არსებობს?

BepInEx არ გაშვებულა. ან სერვერი Doorstop-ის გარეშე გაეშვა - არასწორი გაშვების ბრძანება, Linux-ზე გარემოს ცვლადების არარსებობა, Windows-ზე winhttp.dll-ის არარსებობა - ან BepInExPack ქვესაქაღალდეში გაიხსნა. გაასწორე ინჟექცია; ლოგი შემდეგ გაშვებაზე გაჩნდება.

ლოგში შეცდომები არ არის, მაგრამ მოდი არაფერს აკეთებს. რა ვქნა?

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

უსაფრთხოა LogOutput.log-ის წაშლა?

დიახ. BepInEx შემდეგ გაშვებაზე ახალს შექმნის. თუ ხარვეზს დევნი, ჯერ დააკოპირე.

როგორ ვიპოვო, რომელი მოდი ამუხრუჭებს სერვერს?

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

რას მოიცავს ლოგის ხაზი N plugins to load?

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