[main/2026-09-05-1426] scr_company_struct:draw_squad_unit_sprites:235

[lyra-the-bot]

Your game just encountered and caught an error!

System Details:

• Date-Time: 6-9-2026 10:52:04
• Game Version: main
• Build Date: 2026-09-05-1426
• Commit Hash: 0c83037

Save Details:

• Chapter Name: Red Bastions
• Current Turn: 251
• Game Seed: 2230754951

Error Details:

index out of bounds request 10 maximum size is 10

Stacktrace:

• scr_company_struct:draw_squad_unit_sprites:235
• scr_company_struct:draw_squad_view:634
• scr_ui_manage:1041
• obj_controller_Draw_0:3

Reporter:

Dem Avalon

User Message:

Kept trying to get a squad that was garrisoned to appear on the squad list (was not showing up) they would flash momentarly so I started rapid clicking to switch betwen squads.

[lyra-the-bot]

Investigation - Issue #1520: draw_squad_unit_sprites:235 index out of bounds

Thanks for the detailed report (Red Bastions, Turn 251, rapid squad switching with a garrisoned squad flashing in/out). I traced the stacktrace:

• scr_company_struct:draw_squad_unit_sprites:235
• scr_company_struct:draw_squad_view:634
• scr_ui_manage:1041
• obj_controller_Draw_0:3

Root cause

In scripts/scr_company_struct/scr_company_struct.gml, draw_squad_unit_sprites() caches one surface per squad member in squad_draw_surfaces, but only rebuilds the cache on two conditions (line 224):

var _cur_squad = grab_current_squad();
var _reset_surface = false;
var _member = _cur_squad.fetch_member(0);
if (array_length(squad_draw_surfaces) == 0 || (squad_draw_surfaces[0][0] != _member.uid)) {
    reset_squad_surface();
    _reset_surface = true;
}
for (var i = 0; i < array_length(_cur_squad.members); i++) {
    _member = _cur_squad.fetch_member(i);
    if (_reset_surface) {
        array_push(squad_draw_surfaces, [_member.uid, _member.draw_unit_image()]);
    }
    var _mem_draw_data = squad_draw_surfaces[i];  // <- line 235, crashes here

The loop assumes squad_draw_surfaces is always 1:1 with _cur_squad.members. It is not. The cache goes stale whenever the member count changes while the first member uid stays the same:

• a squad gains/loses a member (reinforcement, casualty, transfer, invalid-entry cleanup in determine_leader() / squad_loci() / update_fulfilment(), all of which array_delete non-struct entries in place),
• or the viewed squad changes size between frames without the first uid changing.

Then _reset_surface stays false, the loop runs past the end of the cache, and GML throws index out of bounds request 10 maximum size is 10 (i.e. 11 members vs a 10-entry cache -- exactly the reported message).

Two contributing factors match the user message ("garrisoned squad not showing, flashing momentarily, rapid clicking"):

1. Two sources of truth for "current squad": draw_squad_view() resolves the header/assignment UI from selected_unit.get_squad() (line 527), but draw_squad_unit_sprites() re-fetches grab_current_squad() (line 221, i.e. company_squads[current_squad]). Rapid next_squad() clicks plus the auto-resync block (lines 494-520, which rewrites current_squad from selected_unit.squad) can thrash between squads frame-to-frame -- the "flash".
2. next_squad() (lines 376-387) reads grab_current_squad().members[0] raw instead of fetch_member(0) and only updates unit_focus when it is already a struct. If entry 0 is a uid/int, focus stays on the old squad while current_squad advances, leaving current_squad and selected_unit out of sync.

Proposed fixes (pick one, or combine 1+2)

Option 1 (minimal, defensive -- recommended): invalidate the cache on length mismatch and guard the index.

var _cur_squad = grab_current_squad();
var _member_count = array_length(_cur_squad.members);
var _member = _member_count > 0 ? _cur_squad.fetch_member(0) : undefined;
var _first_uid = is_struct(_member) ? _member.uid : undefined;
if (array_length(squad_draw_surfaces) != _member_count || ((_first_uid != undefined) && (squad_draw_surfaces[0][0] != _first_uid))) {
    reset_squad_surface();
    _reset_surface = true;
}
// ... inside the loop, before line 235:
if (_reset_surface || i >= array_length(squad_draw_surfaces)) {
    // (re)build missing entry
}
var _mem_draw_data = squad_draw_surfaces[i];
if (!is_array(_mem_draw_data)) {
    continue;
}

Pros: one-condition change, fixes the crash for all size-change paths. Cons: does not fix the header/sprites squad mismatch (cosmetic).

Option 2 (single source of truth): draw the same squad object the view resolved.

Change draw_squad_unit_sprites() to accept the squad (e.g. draw_squad_unit_sprites(_cur_squad)) and call it from draw_squad_view() with the already-resolved _cur_squad (line 527, from selected_unit.get_squad()), instead of re-calling grab_current_squad() internally. Combine with Option 1's length check.

Pros: eliminates the flash/mismatch, makes rapid clicking safe. Cons: slightly larger diff, need to verify all callers (only draw_squad_view:634 calls it today).

Option 3 (harden navigation): clamp + reset on squad switch.

• In next_squad(), use fetch_member(0) with an is_struct check, and call reset_squad_surface() whenever current_squad changes.
• In grab_current_squad(), clamp current_squad to 0..array_length(company_squads)-1 so a shrunk/filtered company_squads (e.g. garrison/squad_location filtering in squad_search()) can never yield an out-of-range squad.

Pros: fixes the sync bug at the source. Cons: does not by itself protect against in-place member add/remove, so it should accompany Option 1.

Separately, the "garrisoned squad not appearing in the list" symptom is worth a follow-up: squad_search() drops squads when squad_location != "" and the squad loci system differs (lines 90-99). If a garrisoned squad reports a different squad_loci().system, it will vanish/flash from the list. That filter may need a garrison exception, but it is distinct from this crash.

My recommendation: implement Option 1 immediately (crash fix), plus Option 2 to stop the view/draw mismatch. Happy to open a PR if that helps.

[EttyKitty]

/oc Implement the proposed fixes 1 and 2. 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 #1537

github run