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

같은 프레임 안에서 어떤 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를 직접 정리합니다. 그러면 다음 프레임에 정상적인 새 항목이 만들어집니다.

발헤임의 사운드 재생 컴포넌트 ZSFX는 재생이 끝나도 스스로 소멸하는 로직이 아예 없습니다. ZNetView가 붙어 네트워크로 동기화되는 오브젝트는 자기 생명주기(죽음, 디스폰 등)에 따라 정리되지만, 발헤임 기본 사운드를 로컬에서 즉석으로 재생하는(ZNetScene.GetPrefab + Instantiate) 패턴을 쓰는 모드는 재생이 끝난 뒤에도 아무도 그 오브젝트를 파괴해주지 않아 세션 내내 계속 쌓입니다. 게다가 발헤임 자체의 MonoUpdaters.Update()가 살아있는 ZSFX 전체를 매 프레임 순회하기 때문에, 새어나간 오브젝트 하나하나가 영구적인 프레임당 비용을 추가합니다 — 사운드가 화려한 마법사 계열 스킬/무기 모드를 반복 사용할 때 특히 두드러지며, 플레이 시간이 길어질수록 점점 느려지다 결국 Resources.UnloadUnusedAssets() 시점에 게임이 멈추기도 합니다(리접속하면 씬이 강제로 재로드되어 일시적으로 나아짐). 특정 모드가 아닌 발헤임 엔진 자체의 결함입니다.

이 모드가 하는 일: ZSFX.CustomUpdate에 Postfix 패치를 걸어, 재생이 끝났고·반복재생이 아니고·초기 재생 지연 구간도 지났고·ZNetView가 없는 인스턴스만 자동으로 파괴합니다 — 네트워크로 동기화되는 오브젝트는 절대 건드리지 않습니다.

발헤임 바닐라·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 텍스트든 상관없이 어떤 언어의 텍스트든 공백/네모 대신 정상적으로 표시되도록 합니다.

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.

Valheim's sound-playback component, ZSFX, has no self-destruct logic at all once it finishes playing. Objects tracked by a ZNetView get cleaned up as part of their own lifecycle (death, despawn, etc.), but any mod that instantiates a vanilla sound effect locally (e.g. ZNetScene.GetPrefab + Instantiate to play a one-off sound) leaves nothing to ever destroy it — it just sits there for the rest of the session. Worse, Valheim's own MonoUpdaters.Update() iterates the entire live ZSFX list every single frame, so each leaked instance adds a permanent per-frame cost — most noticeable with sound-heavy Mage-class skill/weapon mods that cast repeatedly, causing progressively worse lag that can eventually freeze the game during Resources.UnloadUnusedAssets() (relogging force-reloads the scene and temporarily fixes it). This is vanilla engine behavior, not something any particular mod causes.

What this patch does: adds a Postfix to ZSFX.CustomUpdate that destroys an instance only once it has finished playing, isn't looping, is past its initial play-delay window, and has no ZNetView — never touching anything that could be network-synced.

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.

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.