[beverage]

With Ideology, the styling station's Recolor apparel order was refused for a colonist on shift. Pawn_JobTracker.TryTakeOrderedJob logged TryMakePreToilReservations() returned false right after TryTakeOrderedJob(), and nothing happened. This branch lets the order through, as the README's rules promise ("Right-click orders execute immediately"), and adds a harness case for it. It also carries the draft change note and Workshop comment for v1.5.3 (media/changelog-v1.5.3.bbcode, media/comment-v1.5.3.txt).

The bug

Patch_RecolorExecutionGuard prefixes JobDriver_RecolorApparel.TryMakePreToilReservations and failed it for every pawn on shift. The guard exists for recolor jobs the wardrobe optimizer queued before a colonist went on shift, which survive in the job queue across a load: the driver dyes whatever its apparel queue names, so such a job would dye the stand's uniform, or the colonist's own clothes after a swap had parked them in the stand. The station's order passes through the same method, because TryTakeOrderedJob asks for reservations before it queues a job, so it was refused as well.

The fix

The on-shift refusal now skips a job with playerForced set. TryTakeOrderedJob sets the flag before it asks for reservations, and Job.ExposeData saves it, so a queued order keeps it across a load.

The other refusal is unchanged and applies to orders too: a job whose apparel queue names a garment parked in an outfit stand still fails, since the colonist no longer wears it. The optimizer pause (Patch_OptimizeApparelOnShift) is untouched, so a colonist on shift never starts a recolor of their own.

What players see

On shift, the order dyes what the colonist wears in the colours set for it in Change style. When that includes the stand's outfit, the outfit goes back to the stand in its new colours, and the next colonist to borrow it wears them.

Testing

HarnessRecolor.RecolorOrderGoesThroughOnShift uses the default fixture (a colonist on shift, their own garment parked in the stand) and puts a styling station and dye on the pad.

• On shift, the optimizer gives no job, and a recolor job the player did not order fails its reservations. The station's order, built and taken the way Building_StylingStation does it, is taken and started, with the colonist still in uniform. An order naming the parked garment fails.
• Off shift, as the control, the optimizer gives the recolor job and its reservations succeed, while a job naming the parked garment still fails.

The job and the station are Ideology's, so the case is a known gap on a mod list without it.

Results on 270018b, RimWorld 1.7.4984 rev1242:

Build	Mod list	Result
this branch	Harmony, Core, Ideology, Odyssey, Shift Change	126 passed, 0 failed, 6 known gaps
this branch	Harmony, Core, Odyssey, Shift Change	125 passed, 0 failed, 7 known gaps; the seventh is this case
the guard without the playerForced exemption	Harmony, Core, Ideology, Odyssey, Shift Change	125 passed, 1 failed: the order is refused, and the log carries the warning above

The last row ran on an earlier draft of the same change, with only that line reverted. The branch was then rebased onto main's rewrite of the harness comments. Built with the commit stamp off (-p:IncludeSourceRevisionInInformationalVersion=false), the rebased head and 270018b give byte-identical dlls, the shipping build and the harness build alike, so the results above carry over. One run of the second row also failed VacsuitStandStillDresses, a vacuum case that runs long before this one, and passed when run again.

check-invariants.py passes, and check-shipped-dll.py passes on the Release build the runner leaves behind.

Not covered

The case stops the order once it has started. Pawns do not walk under the harness, so it never shows the uniform being dyed. A recolor job that was already running when the game saved resumes without asking for reservations, so neither the old guard nor this one reaches it.

Left out on purpose

The dll is not in this branch; it is built and committed at the release merge.

🤖 Generated with Claude Code