Desync issue with Loot boxes.

[simonlsp]

Summary

The loot from storage cages are only synced in item type, but not item info.
For example, the host and client both observed a blueprint, but of different tech.

Environment

• RimWorld: 1.6.4871
• Build: Dev branch commit ZhangZh331177@c9fb555
• DLC: All DLC, Anomaly activated as DLC, but disabled in story teller.
• OS: Win11 X64

Reproduce

1. Attack a stronghold.
2. Open an loot box.
3. If the item is a blueprint, the tech could be not same, which could cause desync later.

Reproduce details:

1. Only one player opened and observed the map before the box was opened, we don't know whether this is required for reproducing the bug or not.
2. We don't know that whether this bug affect other items with info (like special weapon) or not.

[ZhangZh331177]

Yes, I have also encountered this problem. I am not sure if it is caused by item generation mechanism.

[cmlee119]

I ran into this from a different angle (gravship landing on an ancient complex) and traced it to a concrete root cause. It explains the "same item type, different tech" symptom exactly, so I'm posting the full analysis.

TL;DR

FactionContext.Set only assigns Find.FactionManager.ofPlayer, but the per-faction data (research, history, storyteller, policies) is swapped in a different method, MultiplayerWorldComp.SetFaction. On the map-generation path only the former runs, so during generation Faction.OfPlayer is pinned to the same value on every peer while Find.ResearchManager silently stays whatever the local player's faction had.

Crate contents are rolled at map-generation time, and the techprint maker filters its candidates by research state — so each peer rolls from a different candidate list.

The two methods

// Client/Factions/FactionContext.cs
public static void Set(Faction newFaction)
{
    Find.FactionManager.ofPlayer = newFaction;   // only this
}

// Client/Comp/World/MultiplayerWorldComp.cs
public void SetFaction(Faction faction)
{
    if (!factionData.TryGetValue(faction.loadID, out FactionWorldData data))
        return;

    Game game = Current.Game;
    game.researchManager = data.researchManager;   // ← never happens via FactionContext
    game.drugPolicyDatabase = data.drugPolicyDatabase;
    ...
    game.history = data.history;
    game.storyteller = data.storyteller;
}

Measured

3 players, async time + multifaction, RimWorld 1.6.4871 rev591, MP 0.11.5+a481546.

I patched ThingSetMaker_Techprints.CanGenerateSub to dump the research state at the exact moment it runs during generation of the landing map:

	IsFinished count	TechprintRequirementMet count	candidates
host	42	3	10
client A	34	0	13
client B	34	0	13

At that point Faction.OfPlayer was identical on all three (chilgok's faction#16) and Rand.StateCompressed was identical as well (6914381630754). Only the research context differed.

Why that desyncs

TechprintUtility.TryGetTechprintDefToGenerate_NewTemp ends in TryRandomElementByWeight. Since GetResearchProjectsNeedingTechprintsNow returns a LINQ Where (not an IList), it takes the enumerable path, which is reservoir sampling — one Rand.Range per candidate after the first:

while (enumerator.MoveNext())
{
    T current = enumerator.Current;
    float num5 = weightSelector(current);
    ...
    if (Rand.Range(0f, num4 + num5) >= num4)   // ← one draw per candidate
        result = current;
    num4 += num5;
}

And the candidate filter reads research state directly:

// TechprintUtility.GetResearchProjectsNeedingTechprintsNow
if (p.IsFinished || p.TechprintRequirementMet) return false;   // both read Find.ResearchManager

So a mismatched research context produces two distinct failure modes:

1. different candidate list → a different techprint is selected — this is the symptom in the report ("both observed a blueprint, but of different tech")
2. different candidate count → a different number of Rand draws — 10 vs 13 candidates meant the clients drew 3 extra times

What the 3 extra draws did in my case

Everything downstream of that point shifted. The reward crates (LayoutWorkerComplex.SpawnRoomRewards → ThingSetMaker_RandomOption → ThingSetMaker_StackCount) rolled completely different contents:

• host: MealSurvivalPack ×4, MedicineHerbal, Luciferium
• clients: Hyperweave ×3, Genepack, Novel, …

The Novel then ran Verse.Book.GenerateBook, which generates a throwaway pawn for the book's fictional author:

using (Rand.Block(Gen.HashCombineInt(thingIDNumber, generations++)))
{
    ...
    (author == null) ? TaleData_Pawn.GenerateRandom(humanLike: true) : ...
}

That threw-away Drifter consumed 4 thing IDs on the clients only (host Human1881897 vs client Human1881901). Thing IDs are not isolated by Rand.Block, so the ID counter stayed apart permanently — and because GenerateBook seeds itself with HashCombineInt(thingIDNumber, generations), every later book compounded the divergence.

Final symptom was trace hashes don't match, not Wrong random state — the RNG stream itself never diverged, only the execution path did. That may be worth noting for triage generally: this class of bug surfaces as a trace-hash mismatch.

Also worth flagging: because crate contents are decided during map generation, the item is already wrong before anyone opens the box. The "only one player had observed the map" detail in the report is probably incidental.

Fix

Wrapping MapGenerator.GenerateMap so the per-faction data is swapped to match Faction.OfPlayer for the duration of generation (restored in a Finalizer, so an exception during generation can't leave another faction's research active) makes all three peers converge: research state becomes 42 / 3 / 10 everywhere, the crates roll identical contents, and the divergent book/pawn never happens. My instrumentation logs from the three peers came out byte-identical after the change, where before they diverged at a specific line.

I've been running it as a standalone mod so it stays toggleable, but I'm happy to open a PR against dev if that's useful. Two possible shapes:

1. Conservative — wrap MapGenerator.GenerateMap and swap/restore the per-faction data there. Narrow blast radius, matches what I've already verified.
2. Root — make FactionContext.Set (or Push/Pop) swap the faction data as well, so the two stay consistent everywhere. Cleaner, but it touches every other call site, so it would need a careful pass over them.

Let me know which you'd prefer and I'll put it up. Happy to share the raw instrumentation logs too if they'd help.

[notfood]

RNG was consumed somewhere else. Something else is causing the issue and it can affect anything, from loot, to quests, to hediffs. It needs more precise reproduction steps.