[main/2026-08-19-1803] drop_select_unit_selection:49

[EttyKitty]

Game version

main/2026-08-19-1803

Operating System

N/A

Description

System Details:

Date-Time: 19-8-2026 22:27:27
Game Version: main
Build Date: 2026-08-19-1803
Commit Hash: 13ba280

Save Details:

Chapter Name: Red Bastions
Current Turn: 255
Game Seed: 53551416

Error Details:

index out of bounds request 4 maximum size is 2

Stacktrace:

• drop_select_unit_selection:49
• drop_select_draw:398
• scr_DataSlate:draw:129
• obj_drop_select_Draw_64:20

Steps to reproduce

Changed the Defend formation and then tried to attack, might also be I created more formations but then deleted them, but those are still counting, I don't know.

Upload screenshots

No response

[EttyKitty]

/triage

[github-actions]

Investigation - drop_select_unit_selection:49 OOB crash

Crash site

Stacktrace points here (scripts/scr_drop_select_function/scr_drop_select_function.gml:49):

var _formation_str = $"Formation: {obj_controller.bat_formation[formation_possible[formation_current]]}";

Error index out of bounds request 4 maximum size is 2 means formation_current is 4 while formation_possible has length 2 (valid indices 0-1). This is a double-index: formation_possible[formation_current] fails before bat_formation[...] is even reached.

The call chain (DataSlate:draw:129 -> drop_select_draw:398 -> drop_select_unit_selection:49) is just the slate invoking its inside_method; no bug there.

Root cause: stale formation id is used as an array index

objects/obj_drop_select/Create_0.gml:31,119-138:

formation_current = -1;
// ...
formation_possible = [];
// ... filled only with non-empty formations of the matching type ...
if (attack == 0) {
    formation_current = obj_controller.last_raid_form;   // raw formation id, e.g. 4
    for (var i = 0; i < array_length(formation_possible); i++) {
        if (formation_possible[i] == formation_current) {
            formation_current = i;   // raw id -> index into formation_possible
            break;
        }
    }
} else if (attack == 1) {
    formation_current = obj_controller.last_attack_form; // same pattern
    // ... same loop ...
}
if (formation_current == -1) {
    formation_current = 0;
}

The fallback only handles -1. If the stored last_attack_form / last_raid_form (e.g. 4) is no longer present in formation_possible, the loop never matches and formation_current keeps the raw id value 4. Then line 49 does formation_possible[4] on a length-2 array -> exact error in the report.

This matches the reporter's repro: "Changed the Defend formation and then tried to attack" / "created more formations but then deleted them". Changing a formation's type (attack 1 <-> raid 2) or clearing its name removes that slot from formation_possible for the current attack mode, but last_attack_form / last_raid_form still holds the old slot id. Same for a deleted custom formation slot. Old save + turn 255 makes a stale stored id very likely.

Secondary edge: if formation_possible is empty (all formations deleted/renamed to empty), even formation_current = 0 is OOB (request 0 maximum size is 0). Same unguarded pattern is also used at lines 225/228/251 (formation_possible[formation_current] when starting combat).

Proposed fixes

Fix 1 (required, minimal): resolve id -> index with a real fallback in Create_0.gml.

Use a separate index variable so a miss cannot leak the raw id through:

formation_current = 0;
var _stored_form = (attack == 1) ? obj_controller.last_attack_form : obj_controller.last_raid_form;
for (var i = 0; i < array_length(formation_possible); i++) {
    if (formation_possible[i] == _stored_form) {
        formation_current = i;
        break;
    }
}
if (array_length(formation_possible) > 0) {
    formation_current = clamp(formation_current, 0, array_length(formation_possible) - 1);
}

This fixes both attack and raid paths and removes the fragile == -1 check.

Fix 2 (recommended, belt-and-braces): guard the draw/confirm paths against empty or out-of-range state.

In drop_select_unit_selection(), before line 49 and before the btn_attack.clicked() block:

if (array_length(formation_possible) == 0) {
    // show "Formation: None" and disable ATTACK/RAID, or fall back to default formation 1/2/3
    exit; // or skip formation-dependent drawing
}
formation_current = clamp(formation_current, 0, array_length(formation_possible) - 1);

This guarantees no future OOB even with corrupt save data, and gives a place to show "No valid formation" instead of crashing.

Fix 3 (optional, prevents recurrence): sanitize stored ids at the source.

When a formation is cleared/has its type changed in the settings UI (scr_ui_settings / scr_draw_formation_settings), or in default_bat_formation() / save-load, reset last_attack_form / last_raid_form if they point at an empty slot or a slot whose type no longer matches. E.g. validate bat_formation[id] != "" and bat_formation_type[id] matches the expected mode, else reset to 1 (Attack) / 3 (Raid). This stops stale ids persisting across turns.

I recommend landing Fix 1 + Fix 2 together; Fix 3 is nice-to-have hardening.

[EttyKitty]

/oc Implement all three fixes. Sequentially, verify each before proceeding to the next one. Commit each of them as separate commits. Follow the existing convention for commit names (under 50 symbols total). Open a PR when done. Note that it closes this issue in the body.

[opencode-agent]

Created PR #1536

github run