[ifBars]

Linked issue

Fixes #366

Contributor checklist

• Linked an issue opened before this PR.
• Checked existing issues and PRs for duplicate or overlapping work.
• This PR addresses one focused problem.

Summary

Loading a save can restore a custom supplier's unlock before native Supplier.Start subscribes to the unlock event. When no message history was saved, the conversation-loading path also does not create its phone UI. The supplier stays unlocked but disappears from Messages, blocking orders.

Ensure the conversation exists before applying the supplier category, then create its phone entry when the restored relationship is unlocked. This recovers affected saves without editing them or adding greeting messages. Locked suppliers remain hidden.

Targets stable for the next release. No version bump or publication is included.

Compatibility

• Public/protected API: no symbols or signatures changed; source and binary compatibility are unchanged.
• Existing defaults and behavior: locked suppliers remain absent from Messages. Existing conversations and history are retained. The intentional behavior correction is restoring phone entries for already-unlocked suppliers with no saved history; native unlocking and ordering remain unchanged.
• Stable IDs, saves, and network payloads: unchanged. No migrations or new messages are introduced. Multiplayer was not exercised for this change.

Validation

Mono

• Matching restore and solution build with AutomateLocalDeployment=false: passed.
• Focused NPC/supplier contract tests: 76 passed.
• Full MonoMelon suite: 798 passed.
• Live Mono feature verification is not claimed: the initial affected-save attempt crashed in native employee initialization before the supplier scenario completed.

IL2CPP

• Matching restore and solution build with AutomateLocalDeployment=false: passed.
• Full Il2CppMelon suite: 772 passed.
• Live single-player reproduction and fix validation on Schedule I 0.4.7f12 with Drug Expansion 1.0.4 and S1MAPI 2.0.1: passed.

Runtime evidence

The original affected save was copied into an isolated install. With published S1API 3.2.1, Disco Davey was unlocked at relationship 3.18175 and had a conversation object with three supplier actions, but no phone entry or active Messages registration.

With the fix:

• Initial load and two save/exit-to-menu/load cycles retained a listed, visible entry, the same relationship, zero message history, and all three supplier actions.
• The native phone shop exposed all four precursors and accepted an $80 order; debt increased and the dead-drop preparation timer became positive.
• A separate locked control stayed absent from Messages and became available through normal relationship unlocking with notify=false.

Entry visibility, UI opening, and ordering were checked programmatically. Hidden-window screenshots were black and are not visual evidence. Native UI/weather/shroom cleanup exceptions occurred during scene exit and shutdown, outside the supplier assertions. An initial probe incorrectly expected the native supplier Status enum to change during order preparation; the corrected probe checked debt and the preparation timer. No production order code changed.

Both build configurations were validated serially; existing xUnit analyzer warnings remain. git diff --check passed. Game assemblies, private saves/logs, generated wrappers, and runtime probes are excluded from the PR.

All launched game processes stopped. Automatic approval review blocked deletion of the disposable test directory, which remains locally; live installs and the original supplied save were not modified.

Documentation

No public API, sample, or migration documentation changes are needed for this internal restoration fix.

Summary by CodeRabbit

• Bug Fixes
  • Phone entries now reflect whether an NPC relationship is already unlocked when initialized.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 13549203-5906-4819-a4d9-5e743cdf89dc

📥 Commits

Reviewing files that changed from the base of the PR and between c843c9d and 8da60f2.

📒 Files selected for processing: 1

• S1API/Entities/NPCSupplier.cs

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Walkthrough

Supplier initialization now prepares the conversation before setting its Supplier category. It ensures a phone entry when the NPC relationship is unlocked.

Changes: Supplier Contact Initialization

Layer / File(s)	Summary
Reconcile supplier conversation and phone entry S1API/Entities/NPCSupplier.cs	EnsureSupplier prepares the conversation before assigning the Supplier category. It sets ensureUi based on whether the NPC relationship is unlocked.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 8da60

The load path restores the saved unlock before supplier initialization and requests UI setup for unlocked suppliers. Whether that setup alone guarantees Messages visibility is unverified, but no concrete failure is established to block merging.

Pre-merge checks: 5

Passed checks: 5 passed

Check name	Status	Explanation
Title check		The title clearly and concisely identifies the main fix: restoring unlocked supplier conversations after loading a save.
Description check		The description follows the required template, links issue #366, documents the focused change, compatibility impact, Mono and IL2CPP validation, runtime evidence, limitations, and documentation status…
Linked Issues check		Issue #366 requires restoration of an unlocked supplier contact when no conversation history exists, while preserving locked-supplier behavior and native ordering. NPCSupplier.EnsureSupplier now cal…
Out of Scope Changes check		The reviewed change is limited to supplier message initialization in S1API/Entities/NPCSupplier.cs. The change creates the conversation before category application and reconciles the phone entry wit…
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}