refactor: Fixing some misc bugs.

[carys-the-weed-cloud]

The first commit was more like a chore/fix but still felt more appropriate to call it a refactor. A little cleaning of combat code, and fixing a bug where by your unit tries to fight an empty battlefield. Bot, analysis.

---

Summary by cubic

Fixes units and ships acting without a valid target, centralizes force/star globals in __init(), and streamlines allied ship combat with clearer targeting and shield logic.

• Bug Fixes

  • obj_pnunit/Alarm_0: Disengage when enemy is missing; add early-exit checks after each veh/medi/men block (ranged/melee) to stop acting on destroyed enemies.
  • Initialize unit = undefined in obj_pnunit/obj_enunit, set cm_block = noone in obj_enunit/Alarm_0, and clean up scr_culture_visuals overlays to avoid invalid states.

• Refactors

  • Move force_strength_descriptions and star_name_colors to scripts/__init/__init.gml, removing duplicates from scr_PlanetData and obj_star.
  • obj_al_ship: run only when obj_fleet.start == 5, target nearest obj_en_ship and exit if none, sync image_angle to direction, default owner = eFACTION.IMPERIUM, use eFACTION/noone consistently, and keep faster shield regen for eFACTION.ELDAR.

^{Written for commit 93520a7. Summary will update on new commits.}

[cubic-dev-ai]

6 issues found across 9 files

Confidence score: 2/5

• In objects/obj_pnunit/Alarm_0.gml, the infantry and medic targeting fallthrough paths can read enemy.men/enemy.medi after a prior shot destroys enemy, creating a concrete runtime error risk during combat resolution—restore instance_exists(enemy) guards (or equivalent early exit) before those reads before merging.
• In objects/obj_pnunit/Alarm_0.gml, the new exit path can skip the later instance_activate_object(obj_enunit) cleanup, leaving flanked enemy units deactivated for the rest of combat—route this branch through shared cleanup or reactivate obj_enunit before exiting.
• In scripts/__init/__init.gml, duplicate subcomponents keys in Cataphractii struct literals silently overwrite earlier values, which can mask intended equipment composition and make behavior/config harder to trust—deduplicate each struct key so only the intended array is defined once before merge.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="objects/obj_pnunit/Alarm_0.gml">

<violation number="1" location="objects/obj_pnunit/Alarm_0.gml:148">
P1: A ranged AP shot that kills the first target can now fall through into the medic targeting block and read `enemy.medi` on a destroyed instance. Keeping the `instance_exists(enemy)` guard here preserves the intended post-shot safety check that this refactor removed.</violation>

<violation number="2" location="objects/obj_pnunit/Alarm_0.gml:175">
P1: A shot in the earlier ranged targeting blocks can destroy `enemy` and still let execution reach infantry targeting, where `enemy.men` is read without the removed existence check. Re-adding `instance_exists(enemy)` to this condition would prevent intermittent combat exceptions after a target dies mid-weapon.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="objects/obj_pnunit/Alarm_0.gml">

<violation number="1" location="objects/obj_pnunit/Alarm_0.gml:146">
P2: When a volley destroys the final enemy inside one of these branches, remaining ranged weapons now skip the existing `report_held_fire` path and the battle log omits their “held fire” message. Consider reporting held fire before these new `break`s, or setting a flag so the loop-level empty-target handler still runs.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

4 issues found across 11 files

Confidence score: 3/5

• In objects/obj_pnunit/Alarm_0.gml, the new break can exit the weapon loop as soon as one targeted enemy dies, so remaining enemies may stop receiving fire for that tick and combat behavior can regress — only skip/reacquire when the current target is invalid instead of breaking the full weapon iteration.
• In objects/obj_al_ship/Step_0.gml, the new early-exit path can bypass the owner == eFACTION.ELDAR hp <= 0 cleanup when the last enemy is gone, leaving destroyed allied Eldar ships unprocessed — ensure death/cleanup logic still runs even when no enemies remain.
• Also in objects/obj_al_ship/Step_0.gml, duplicated targeting/firing logic across Eldar and non-Eldar branches raises drift risk, where future fixes land in one branch but not the other — extract the shared loop into one code path before or immediately after merge to reduce regression risk.
• In scripts/__init/__init.gml, the “12 is skipped” comment is inaccurate and could mislead future maintenance, though runtime risk is low — update the comment to match the actual index assignment.

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

No issues found across 11 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}