Bug: Crop field “Paste Field Settings” corrupts schedule editing on multi-crop years
Game: Farthest Frontier · Version: v1.1.2a · Platform: Windows (Steam) · Mods: none required — base-game Copy/Paste Field Settings
Summary
Using Copy Field Settings → Paste Field Settings to clone a crop rotation onto another field produces a field that looks correct but breaks when edited. If a year contains two or more plantings, dragging or deleting any one crop in that year makes the crops jump to the end of the year and stack on top of each other — usually unrecoverable without deleting and re-entering every crop in that year.
Steps to reproduce
- Set up Field A with a rotation where at least one year has 2+ plantings (e.g. Year 1: Turnip → Clover ).
- Select Field A → Copy Field Settings.
- Select Field B → Paste Field Settings. Schedule displays correctly.
- On Field B, in a multi-crop year, click or drag the first crop to move it, or delete a crop.
Expected: editing one crop affects only that crop (same as a hand-entered field).
Actual: The crop jumps to the end of that year’s schedule and actually overlaps any crop at the end of the year cycle. Basically pile up at the end of the year; the year’s schedule becomes unusable.
Scope / notes
- Only fields populated via Paste Field Settings; hand-entered fields are fine.
- Only years with 2+ plantings; single-crop-per-year rotations are fine.
- Saved data is not corrupted — save/reload shows the schedule intact. It’s purely an edit-time UI issue.
Likely cause (decompiled analysis — please verify)
BuildManager.ClonerPasteCropfield constructs each pasted item with its schedule ID set to the year-loop index rather than a unique ID, so every planting in a year shares the same scheduleID. The drag handler (CropInfoWindowDataHandler.AttemptDrag) matches items by scheduleID == dragItemData.id, so a drag matches all same-ID crops and moves them together. The normal add path (CropfieldScheduler.AttemptToAddCropToSchedule) assigns unique IDs from scheduleIdCounter, which is why hand-entered fields are unaffected. Fix: have the paste path allocate unique IDs the same way.
