Logy BepInEx ve Valheimu: čtení LogOutput.log a oprava módů

Když se Valheim server s módy chová divně, odpověď je téměř vždy v BepInEx/LogOutput.log v kořeni serveru, a téměř vždy v první chybě, ne v poslední. Čti ho ve třech průchodech. Za prvé, je tam vůbec banner BepInEx - pokud ne, Doorstop loader nikdy nevložil a na žádném módu zatím nezáleží. Za druhé, řádky Loading [...] a cokoli, co říká Could not load nebo Skipping - to je tvůj skutečný seznam pluginů a chybějící závislosti jsou pojmenované otevřeně. Za třetí, první Error po startu se jménem módu v jeho stack trace. Když je log stěna výjimek bez jasné první příčiny, přestaň číst a půl: přesuň polovinu pluginů pryč, restartuj na kopii světa a půl znovu. Třicet módů zabere pět kol.

Kde jsou logy#

Instalace Valheimu s módy zapisuje na víc než jedno místo a to správné závisí na tom, která strana selhala.

Dvě vlastnosti LogOutput.log lidi nachytají:

• Ve výchozím stavu se při každém startu přepíše. Restart spadlého serveru, abys „viděl, jestli se to stane znovu“, zničí důkazy o prvním pádu. Soubor si nejdřív stáhni nebo zkopíruj. Logy, které stojí za to uchovat to obecně obhajuje.
• Je tak podrobný, jak je nastavená úroveň v `BepInEx.cfg`. Výchozí hodnoty zaznamenávají chyby, varování, zprávy a info, což na většinu diagnostiky stačí.

Nastavení logování loaderu je v BepInEx/config/BepInEx.cfg. V současných vydáních BepInEx 5 vypadá takhle:

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

Přidání Debug do LogLevels (nebo nastavení na All) udělá některé módy mnohem upovídanější, což pomáhá, když autor požádal o debug log. Potom to vrať; debug log na vytíženém serveru rychle roste. AppendLog = true drží starší běhy ve stejném souboru místo přepisování, což se hodí při hledání pádu, který se děje jen přes noc. Názvy klíčů jsou napříč BepInEx 5 stabilní, ale porovnej je se svým souborem, nevkládej naslepo.

Na RE:NODE konzole ukazuje výstup serveru živě od prvního řádku a správce souborů otevře LogOutput.log v prohlížeči, takže ho můžeš číst bez stahování - ale kopii si před restartem stejně udělej.

Jak vypadá zdravý start#

Neobvyklé nepoznáš, když neznáš obvyklé. Čistý start s módy projde preloaderem, pak chainloaderem a pak jeden řádek na 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

Skutečné logy mají mezi těmito řádky víc - detaily běhu, řádky patcherů, vlastní zprávy každého pluginu - a čísla verzí se budou lišit. Důležitý je tvar:

• Banner jmenuje proces. Na serveru říká valheim_server; na klientovi valheim.
• Počet v N plugins to load by měl odpovídat počtu módů, o kterých si myslíš, že jsi je nainstaloval.
• Každý mód má řádek Loading s verzí. Mód bez řádku se nenačetl.
• Objeví se Chainloader startup complete. Po něm pokračuje vlastní start Valheimu, který končí načtením světa a řádkem relace.

Každý řádek má tvar [Level : Source] text. Zdroj je BepInEx pro loader, název pluginu pro zprávy módu, Unity Log pro zprávy, které vytvořila samotná Unity, a někdy HarmonyX pro patchovací knihovnu, kterou módy používají. Úroveň je jedna z Fatal, Error, Warning, Message, Info nebo Debug.

Žádný banner: Doorstop a preloader#

Pokud LogOutput.log chybí nebo má časovou značku z doby před posledním startem, BepInEx nikdy neběžel. Server se spustil jako čisté vanilla Valheim. Každý příznak týkající se módů je z toho odvozený, takže to oprav jako první.

Doorstop je malý injektor, který způsobí, že Unity načte BepInEx před hrou. Na Linuxu funguje přes proměnné prostředí nastavené skriptem start_server_bepinex.sh; na Windows jsou to winhttp.dll a doorstop_config.ini v kořeni serveru. Celé rozložení ukazuje Valheim módy s BepInEx na serveru. Selhání podle zprávy, kterou vidíš v konzoli:

`ERROR: ld.so: object 'libdoorstop_x64.so' from LD_PRELOAD cannot be preloaded` - knihovna není tam, kam ukazuje LD_LIBRARY_PATH. Obvykle se zkopírovala obalová složka archivu, takže v kořeni je BepInExPack_Valheim/doorstop_libs místo doorstop_libs.

`/bin/bash^M: bad interpreter` - startovací skript má konce řádků z Windows, typicky po úpravě na PC a nahrání. Převeď ho zpět:

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

`Permission denied` při spuštění skriptu - při přenosu přišel o příznak spustitelnosti. Spraví to chmod výše.

Žádná chyba, žádný banner - server byl spuštěn běžným příkazem místo příkazu pro BepInEx, nebo nebyly nastaveny proměnné prostředí. U hostingu s panelem zkontroluj startovací příkaz nebo proměnné, které host pro BepInEx používá.

Windows: žádný banner - winhttp.dll chybí ve složce s valheim_server.exe, nebo ho doorstop_config.ini má vypnutý. Názvy klíčů v ini se mezi Doorstop 3 a 4 liší; otevři soubor a hledej přepínač zapnutí a cestu k cílové assembly, která by měla mířit na BepInEx\core\BepInEx.Preloader.dll.

Když se banner objeví, ale start se zastaví mezi Preloader started a Chainloader ready, problém je v patcheru, ne v pluginu. Patchery leží v BepInEx/patchers a běží před načtením herního kódu. HookGenPatcher, který potřebuje Jotunn, je obvyklý na Valheim serverech. Patcher sestavený pro jinou verzi hry tady selže, stejně jako patcher umístěný do plugins, kam nepatří - chyba obvykle jmenuje assembly.

Chybějící závislosti a přeskočené pluginy#

Jakmile chainloader běží, BepInEx ti jasně řekne o každém pluginu, který odmítl. Tyto řádky jsou nejlevnější diagnostika v celém logu.

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

Řádek o chybějící závislosti jmenuje závislost jejím GUID, ne zobrazovaným názvem, a často s minimální verzí:

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

To GUID je to, co závislý mód požadoval. Najdi ho na stránce módu na Thunderstore nebo v jeho seznamu závislostí a přiřaď k balíčku. Dvě situace vytvoří tento řádek, i když jsi si jistý, že závislost je nainstalovaná. Buď selhala dříve v logu sama závislost - najdi její vlastní řádek Could not load nebo Error loading - nebo je nainstalovaná starší verze, než je minimum. A protože Jotunn potřebuje HookGenPatcher, HookGenPatcher ve špatné složce může způsobit selhání Jotunn a každý další mód na Jotunn pak hlásí chybějící závislost. Oprav první článek řetězu a zbytek se obvykle vyjasní.

Řádek o filtru procesu je ten, který říká, že mód je jen klientský. Módy, které dávají smysl jen s obrazovkou, často deklarují, že běží v valheim.exe. Na valheim_server se s varováním přeskočí, což je neškodné; odeber je ze serveru, ať je log klidnější.

Výjimky: nalezení zodpovědného módu#

Výjimka v logu je blok: řádek hlavičky s typem výjimky, pak stack trace volání metod, nejnovější první. Většina vypadá hůř, než je.

[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 výše je vymyšlený, ale typický. Jak ho číst:

1. Typ. MissingMethodException, MissingFieldException a TypeLoadException znamenají, že mód byl zkompilován proti jiné verzi hry a volá kód, který se změnil. Po patchi Valheimu se jich dá čekat, dokud autoři neaktualizují. Konfigurace v tom nic nespraví.
2. Mód. Dívej se v trace dolů po jmenném prostoru, který není vlastní třídou Valheimu ani UnityEngine - tady ExampleMod.Patches. To je mód, jehož kód běžel.
3. Patchovaná metoda. Řádky s DMD<...> jsou herní metody, které mód patchnul přes Harmony. Název metody říká, co hráč dělal - použití předmětu, stavění kousku - což pomáhá, když potřebuješ chybu reprodukovat.

NullReferenceException je nejvágnější. V trace módu obvykle znamená, že mód očekával něco, co tam nebylo: chybějící hodnotu konfigurace, předmět z módu, který se nenačetl, nebo objekt, který klientský mód čekal na bezhlavém serveru. Než začneš podezírat mód samotný, zkontroluj, zda se načetly jeho závislosti.

Jedna výjimka při startu, po které následuje normální Chainloader startup complete a funkční server, může být kosmetická. Stejná výjimka opakující se každých pár sekund ne - stojí CPU a plní disk a mód, který jmenuje, by měl být odstraněn nebo opraven. Víc o oddělování šumu od signálu obsahuje vysvětlení logů herních serverů.

Šum, který můžeš ignorovat#

Bezhlavý server loguje věci, které znějí alarmujícím dojmem a nic neznamenají. Na Valheim serveru jsou běžně neškodné tyto:

• Zprávy o shaderech, grafických zařízeních nebo zvuku. Server nemá GPU ani zvuk; Unity to říká.
• Řádky Fallback handler could not load library na Linuxu, pro knihovny, které bezhlavý server nikdy nepoužívá.
• Varování od módu, že nebyla nalezena volitelná integrace - například mód poznamená, že jiný mód, se kterým umí spolupracovat, není nainstalovaný.
• Řádky Steamu o vlastním ID serveru a relaci, které patří Valheimu, ne BepInEx.

Nauč se, co tvůj server vypisuje v dobrý den. Po úspěšném startu si stáhni jeden čistý LogOutput.log a ulož ho. Když se něco rozbije, porovnej nový log se známým dobrým; první řádek, který se liší, bývá začátkem problému.

Půlení rozbité sestavy módů#

Někdy log neukazuje na jediný mód. Server, který spadne po dvaceti minutách, chyba bez módu v trace, svět, který se divně chová jen se vším nainstalovaným. Tehdy přestaneš číst a začneš půlit: odeber polovinu módů, otestuj a půl dál tu polovinu, která obsahuje chybu.

Postup:

1. Zálohuj svět a celou složku BepInEx.
2. Nasměruj server na kopii světa (jiný název -world s okopírovanými soubory .db a .fwl) nebo na čerstvý testovací svět, pokud chyba na něm nezávisí.
3. Vytvoř složku mimo plugins, například BepInEx/plugins_off. Musí být mimo: BepInEx načítá soubory .dll i z podsložek plugins, takže složka plugins/disabled nezakáže nic.
4. Přesuň do ní polovinu módů. Knihovny jako Jotunn nech na místě a každý mód drž spolu s jeho závislostmi - mód přesunutý pryč od své knihovny vyrobí jen řádek o chybějící závislosti a nic tě nenaučí.
5. Spusť server a chybu reprodukuj.
6. Pokud chyba zmizela, je v polovině, kterou jsi přesunul: prohoď poloviny. Pokud zůstává, je v polovině, která je stále načtená. V obou případech podezřelou skupinu znovu rozpůl.
7. Zastav, když je podezřelá skupina jeden mód. Potvrď to tím, že vrátíš všechno kromě něj.

Počet potřebných kol je dvojkový logaritmus počtu módů, zaokrouhlený nahoru.

Chyby způsobené dvěma módy dohromady jednoduchou verzi rozbijí: chyba zmizí v obou polovinách. Když se to stane, nech jednu polovinu načtenou a půl druhou proti ní. Konflikty a závislosti módů jdou do interakcí mezi módy hlouběji a co dělat, když aktualizace módu něco rozbije pokrývá případ, kdy spouštěčem byla aktualizace.

U hostingu, kde se server po pádu restartuje automaticky, může sestava módů padající při startu zacyklit. Na RE:NODE tři restarty po pádu za hodinu zobrazí varování na stránce serveru a otevřou ticket, takže před začátkem půlení server zastav, místo abys ho nechal točit dokola - proč se tvůj herní server pořád restartuje vysvětluje tu smyčku.

Sdílení logu kvůli pomoci#

Autoři módů a pomocníci z komunity budou chtít celý LogOutput.log, ne screenshot posledních řádků. Užitečná verze:

• Celý soubor, od prvního řádku. Příčina je poblíž začátku; viditelný konec jsou důsledky.
• Z neúspěšného běhu, vzatý dřív, než ho přepsal nějaký restart.
• Obě strany, když je klient vyhozen nebo padá při připojení: log serveru i vlastní LogOutput.log hráče z jeho profilu.
• Seznam módů s verzemi, což řádky Loading už jsou:

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

Logy obsahují jména hráčů a ID platforem z řádků o připojení a adresu serveru. Než log vložíš do veřejného kanálu, tyto údaje odstraň.

FAQ#

Proč je LogOutput.log prázdný nebo chybí?

BepInEx nenastartoval. Buď byl server spuštěn bez Doorstop - špatný startovací příkaz, chybějící proměnné prostředí na Linuxu, chybějící winhttp.dll na Windows - nebo byl BepInExPack rozbalen do podsložky. Oprav vložení; log se objeví při dalším startu.

Log neukazuje žádné chyby, ale mód nic nedělá. Co teď?

Zkontroluj, že má řádek Loading. Pokud ano, mód se načetl a příčina je jinde: je klientský a nainstalovaný jen na serveru, je ve své konfiguraci ve výchozím stavu vypnutý, nebo se jeho nastavení synchronizují odněkud, co jsi neupravil.

Je bezpečné LogOutput.log smazat?

Ano. BepInEx při dalším startu vytvoří nový. Pokud právě hledáš chybu, nejdřív ho zkopíruj.

Jak zjistím, který mód server zpomaluje?

Log pomůže, jen pokud mód vyhazuje chyby, viditelné jako opakující se stejná výjimka. Jinak půl s testovacím světem a stopkami, nebo sleduj CPU v grafech serveru při odebírání podezřelých.

Co zahrnuje počet v řádku N plugins to load?

Každý plugin, který BepInEx našel v plugins a podsložkách, včetně těch, které pak přeskočí nebo se nenačtou. Číslo vyšší než počet tvých módů znamená duplicity nebo zapomenuté soubory.