이 모드는 어떤 조합으로 설치해도 안전합니다. 위 모드들이 없어도 해당 패치만 조용히 비활성화될 뿐, 나머지 패치는 그대로 작동합니다.

같은 프레임 안에서 어떤 ZNetView의 GameObject가 다른 경로로 먼저 파괴되면, 바닐라 ZNetScene.RemoveObjects가 그 오브젝트를 내부 추적 딕셔너리(m_instances)에서 제거하기도 전에 NullReferenceException을 던집니다. 이 예외 때문에 문제의 entry가 딕셔너리에서 끝내 제거되지 못하고 남아버리고, 그 결과 다음 프레임에도 똑같은 예외가 또 발생 — 이 과정이 세션이 끝날 때까지 매 프레임 무한 반복됩니다.

이건 특정 모드가 만든 버그가 아니라 발헤임 엔진 자체의 오래된 결함입니다. 모드를 하나도 설치하지 않아도 발생할 수 있으며, 몬스터 스폰/디스폰이 잦은 상황(전투, 대규모 소환 등)일수록 더 쉽게 걸립니다.

이 모드가 하는 일: ZNetScene.RemoveObjects에 Harmony Finalizer 패치를 추가해 해당 예외만 정확히 잡아내고, 이미 파괴된(fake-null) ZNetView entry를 m_instances에서 직접 제거합니다.

AzuCraftyBoxes는 근처에서 본 모든 제작함을 HashSet<Container>에 정적으로 계속 쌓아둡니다. 상자가 철거될 때는 Container.OnDestroyed 패치로 항목을 지우지만, 일부 파괴 경로(구역/청크 언로드 등)는 이 메서드를 거치지 않고 GameObject를 바로 파괴해버려서, 이미 죽은(fake-null) Container가 세트에 그대로 남습니다. 이후 제작 메뉴가 열려 있는 동안 매 프레임 실행되는 재료 확인 로직이 이 죽은 항목의 GetPrefabName()을 호출하면서 NullReferenceException이 반복 발생합니다 — 제작 메뉴를 닫기 전까지 계속됩니다.

이 모드가 하는 일: AzuCraftyBoxes가 설치되어 있을 때만 활성화되는 패치로, 해당 예외를 잡아내고 파괴된 Container 항목들을 세트에서 직접 제거합니다.

일부 팩션/마켓플레이스 계열 모드는 자체 EnemyHud.LateUpdate 패치 안에서 EnemyHud.ShowHud를 직접 강제로 재호출해 HUD를 즉시 새로고침하려 합니다. 그런데 이 재호출이 이미 로그아웃했거나 디스폰된 캐릭터를 대상으로 발생하면, 그 캐릭터의 HUD 항목(m_huds)이 아직 정리되지 않은 채 남아있을 수 있고, 이걸 전제로 동작하는 다른 모드의 ShowHud 패치(예: EpicMMOSystem의 PvP 플레이어 이름 색상 표시 패치 DataMonsters.MonsterColorTexts)가 죽은 참조를 건드리면서 NullReferenceException이 반복 발생합니다.

이 모드가 하는 일: EpicMMOSystem이나 특정 모드를 콕 집어 패치하지 않고, 발헤임 기본 EnemyHud.ShowHud에 Finalizer를 걸어서 어떤 모드의 postfix에서 터지든 잡아내고, 문제의 오래된 m_huds 항목과 남은 HUD GameObject를 직접 정리합니다. 그러면 다음 프레임에 정상적인 새 항목이 만들어집니다.

발헤임 바닐라·TMP 내장 폰트(예: Valheim-Prstartk, LiberationSans SDF)는 라틴 문자만 커버하고, 한글·일본어·중국어·아랍어·히브리어·태국어 등 비라틴 스크립트 글리프는 자체 글리프 테이블과 폴백 체인에 포함하지 않습니다. 플레이어 닉네임·길드명처럼 사용자가 직접 입력한 비라틴 텍스트가 이런 폰트로 렌더링되는 TMP_Text 오브젝트(예: EpicMMOSystem의 네임플레이트/ 길드명/정보 패널)를 통해 표시될 때마다 "The character with Unicode value ... was not found in the [...] font asset..." 경고가 반복 출력되고, 해당 글자는 공백이나 네모(□)로 대체됩니다. 발헤임은 자체 다국어 로컬라이제이션을 위해 스크립트별 Noto 계열 폰트(NotoSansKR, NotoSansJP, NotoSansSC, NotoSansArabic 등 11개 스크립트 + 이모지)를 이미 게임 파일에 내장하고 있지만, 플레이어가 직접 입력하는 텍스트용 TMP 전역 폴백 목록에는 연결되어 있지 않습니다.

이 모드가 하는 일: 발헤임이 지원하는 각 언어의 폰트를 찾아 세션당 한 번 TMP의 전역 폴백 목록(TMP_Settings.fallbackFontAssets)에 전부 등록합니다. 새 폰트를 번들링하지 않고 발헤임이 이미 갖고 있는 리소스만 사용하며, 어떤 모드가 만든 TMP 텍스트든 상관없이 어떤 언어의 텍스트든 공백/네모 대신 정상적으로 표시되도록 합니다.

스탯·효과를 많이 추가하는 모드(스킬트리, 마법 효과 모드 등)를 쓰면 아이템 툴팁이 화면 높이보다 길어질 수 있습니다. 바닐라 UITooltip은 매 프레임 Utils.ClampUIToScreen으로 툴팁을 화면 안으로 밀어 넣는데, 이 함수는 "위가 화면 밖" 보정과 "아래가 화면 밖" 보정을 연달아 적용합니다. 화면보다 큰 툴팁에서는 두 조건이 모두 참이라 위로 밀었다가 다시 아래로 되밀리고, 마우스가 조금만 움직여도 결과가 뒤집혀 화면이 반복적으로 흔들립니다. 게다가 화면에 들어가지 않는 부분은 읽을 수 없습니다.

이 모드가 하는 일: UITooltip.LateUpdate에 Postfix 패치를 추가해, 툴팁이 화면보다 클 때만 본문을 두 열로 나눕니다. 첫 번째 열은 화면에 들어가는 만큼의 줄을, 두 번째 열은 그 오른쪽에 나머지 줄을 표시하고, 두 열을 한 묶음으로 화면 상단에 고정합니다. 색상 등 리치텍스트 태그는 나뉘는 지점에서 자동으로 닫고 다시 엽니다. 화면에 들어가는 일반 툴팁은 전혀 건드리지 않습니다.

Azumatt의 AAA_Crafting은 제작창 오른쪽 아이템 목록(제작/업그레이드 탭)에 마우스를 올리면 뜨는 호버 툴팁을 바닐라 UITooltip이 아닌 자체 클래스(RecipeHoverTooltip)로 처리합니다. 이 툴팁은 마우스 위치에 뜨는데 목록이 화면 오른쪽 끝에 있어, 스탯·효과가 많은 아이템은 툴팁이 화면 밖으로 밀려 흔들리고 내용이 잘립니다. 버그 5의 패치는 UITooltip만 대상이라 여기에는 적용되지 않습니다.

이 모드가 하는 일: RecipeHoverTooltip.LateUpdate에 Postfix 패치를 추가해, 이 툴팁을 항상 화면 가운데에 고정합니다. 툴팁이 화면보다 크면 버그 5와 같은 방식으로 두 열로 나눕니다(첫 번째 열은 화면 높이를 가득 채우고, 넘친 줄은 오른쪽 두 번째 열에 아래쪽 기준으로 채움). AAA_Crafting이 설치되어 있지 않으면 아무 일도 하지 않습니다.

KeenCombat은 ItemDrop.ItemData.GetTooltip의 모든 오버로드 끝에 무기 스킬 설명(예: "BLINK STRIKE", 설명, 쿨타임)을 덧붙입니다. 다른 모드가 재료·음식·모드 추가 아이템에 무기용 스킬 타입을 지정해 두면 무기가 아닌 아이템에도 같은 스킬 툴팁이 붙습니다. KeenCombat에는 이 툴팁을 끄는 설정이 없습니다.

이 모드가 하는 일: KeenCombat의 패치 뒤에 실행되는 Postfix로, 무기(한손/양손/활·석궁)가 아닌 아이템에서만 덧붙은 스킬 블록을 제거합니다. 실제 무기의 스킬 툴팁은 그대로 유지됩니다. KeenCombat이 설치되어 있지 않으면 아무 일도 하지 않습니다.

1. 권장: r2modman/Thunderstore에서 자동 설치
2. 수동: NullReferenceFix.dll을 BepInEx/plugins/ 폴더에 복사

이 버그들은 네트워크로 동기화되지 않는 로컬 상태 문제라서, 서버와 각 클라이언트가 각자 독립적으로 겪을 수 있습니다. 한쪽에만 설치하면 그쪽만 고쳐집니다 — 멀티플레이 환경이라면 서버 + 접속하는 모든 클라이언트에 설치하는 것을 권장합니다.

Safe to install in any combination. If a mod above isn't installed, its corresponding patch just stays inactive; the rest still work normally.

If a ZNetView's GameObject is destroyed by something else in the same frame that vanilla ZNetScene.RemoveObjects tries to clean it up, the method throws a NullReferenceException before it can reach the line that removes the stale entry from its internal tracking dictionary (m_instances). Because that entry never gets removed, the exact same exception fires again on the very next frame — and every frame after that, for the rest of the session.

This is vanilla engine behavior, not something any particular mod causes. It can happen with zero mods installed; busier games (more monster spawns/despawns, heavy combat) simply hit the underlying race condition more often.

What this patch does: adds a Harmony Finalizer to ZNetScene.RemoveObjects that catches only that specific exception and removes the already-destroyed (stale) ZNetView entry from m_instances directly.

AzuCraftyBoxes keeps a static HashSet<Container> of every crafting container it has ever seen nearby. Container.OnDestroyed is patched to remove an entry when a box is demolished, but some destroy paths (e.g. a zone/chunk unload) destroy the GameObject without going through that method, leaving a Unity-destroyed (fake-null) Container sitting in the set. The next recipe check that walks nearby containers calls GetPrefabName() on the dead entry and throws NullReferenceException — every frame the crafting menu stays open.

What this patch does: only activates when AzuCraftyBoxes is installed; catches that exception and removes the destroyed Container entries from the set directly.

Some factions/marketplace-style mods call EnemyHud.ShowHud directly from their own EnemyHud.LateUpdate patch to force an immediate HUD refresh. If that re-entrant call targets a Character that already logged out or despawned, its HUD entry (m_huds) can still be sitting around uncleaned, and another mod's ShowHud patch that assumes a live entry — e.g. EpicMMOSystem's PvP player name-color patch, DataMonsters.MonsterColorTexts — dereferences the dead reference and throws NullReferenceException repeatedly.

What this patch does: instead of targeting EpicMMOSystem or any specific mod, it patches vanilla EnemyHud.ShowHud itself with a Finalizer, so it catches the exception no matter which installed mod's postfix throws it, then clears the stale m_huds entry (and its leftover HUD GameObject) so the next call rebuilds a clean one.

Vanilla/TMP-bundled fonts (e.g. Valheim-Prstartk, LiberationSans SDF) only cover Latin glyphs — Korean, Japanese, Chinese, Arabic, Hebrew, Thai, and other non-Latin scripts aren't in their own glyph table or fallback chain. Whenever player-authored non-Latin text — a nickname or guild name, for example — is rendered through a TMP_Text object using one of these fonts (e.g. EpicMMOSystem's nameplate/guild-name/info-panel objects), Unity logs a repeating "The character with Unicode value ... was not found in the [...] font asset..." warning and replaces the character with a blank space or a missing-glyph box (□). Valheim already ships a Noto-family font asset for every non-Latin script its own localization supports (NotoSansKR, NotoSansJP, NotoSansSC, NotoSansArabic, and 7 more, plus an emoji set) in its own game files, but none of them are wired into TMP's fallback list for arbitrary player-authored text.

What this patch does: finds each of Valheim's bundled per-language fonts and registers all of them into TMP's global fallback list (TMP_Settings.fallbackFontAssets) once per session. No new font is bundled — it reuses resources Valheim already ships — and it fixes rendering for any mod's TMP text in any of those languages, not just Korean and not just one specific mod's.

Mods that add a lot of stats and effects (skill trees, magic-effect mods, ...) can make an item tooltip taller than the screen. Vanilla UITooltip pushes the tooltip back on-screen every frame with Utils.ClampUIToScreen, which applies the "top is off-screen" correction and then the "bottom is off-screen" correction in the same call. For a tooltip taller than the screen both are true, so it is pulled down and pushed back up, and the result flips with the slightest mouse movement - the screen shakes repeatedly. The part that does not fit is also unreadable.

What this mod does: a postfix on UITooltip.LateUpdate that, only when the tooltip is taller than the screen, splits the body into two columns: the first column holds as many lines as fit the screen, the second opens to its right with the remaining lines, and the pair is pinned to the top of the screen. Rich-text tags such as colors are closed and re-opened at the split point. Tooltips that already fit are left completely untouched.

Azumatt's AAA_Crafting shows the hover tooltip of the crafting window's item list (Craft/Upgrade tabs, on the right side) with its own class (RecipeHoverTooltip) instead of vanilla UITooltip. That tooltip follows the mouse, and since the list sits at the right edge of the screen, an item with many stats/effects gets pushed off-screen, shakes and is cut off. The Bug 5 patch only targets UITooltip, so it does not apply here.

What this mod does: a postfix on RecipeHoverTooltip.LateUpdate that pins this tooltip to the center of the screen. If the tooltip is taller than the screen it is split into two columns the same way as Bug 5 (the first column fills the screen height, the overflow goes to a second column on the right, aligned to the bottom). Does nothing if AAA_Crafting is not installed.

KeenCombat appends a weapon skill block (e.g. "BLINK STRIKE", description, cooldown) to the end of every ItemDrop.ItemData.GetTooltip overload. When another mod gives materials, food or mod-added items a weapon skill type, those non-weapon items get the same skill tooltip too. KeenCombat has no setting to turn this tooltip off.

What this mod does: a postfix that runs after KeenCombat's own and removes the appended skill block only from items that are not weapons (one-handed / two-handed / bow-crossbow). Real weapons keep their skill tooltip. Does nothing if KeenCombat is not installed.

1. Recommended: Install via r2modman/Thunderstore
2. Manual: Copy NullReferenceFix.dll into BepInEx/plugins/

These bugs are local state, not something synced over the network — the server and each client can hit them independently. Installing on only one side only fixes that side. In multiplayer, install it on the server and every connected client to be safe.