Lasertower

A Lasertower is a stationary autonomous combat platform — players deploy them from inventory to add point-defence to a sector. Despite appearing in the deployables menu alongside Satellites and Mines, lasertowers are technically class.ship with the .islasertower=true flag.

This dual identity (deployable UX + ship class) is the source of several modder gotchas.

Inheritance: component → destructible → object → controllable → defensible → container → ship → (lasertower).

There is no dedicated lasertower datatype — it’s a Ship with a flag.

Properties

There are no lasertower-specific properties beyond the inherited Ship. The discriminator:

Property	Value
`.isclass.ship`	true
`.islasertower`	true
`.iscapitalship`	false

.islasertower is the only safe discriminator. .isclass.ship matches all ships; checking purpose/macro is unreliable.

Vanilla variants

Vanilla has multiple lasertower macros — ship_gen_xs_lasertower_01_a_macro, etc. Each has different damage / range / hull but the same .islasertower=true flag.

Deployment

Lasertowers go through the ammostorage path like other deployables — see Satellite for the pattern.

Player-side

<add_ammo object="player.ship"
    macro="macro.ship_gen_xs_lasertower_01_a_macro"
    amount="3"/>

Player deploys via UI. Each tower becomes a separate class.ship object in the sector.

NPC-side

Vanilla PlaceLasertowerfield library handles bulk deployment:

<run_actions ref="md.LIB_Generic.PlaceLasertowerfield">
    <param name="SelectedTarget" value="$Zone"/>
    <param name="MinSpawn" value="5"/>
    <param name="MaxSpawn" value="10"/>
    <param name="LasertowerOwner" value="$Faction"/>
</run_actions>

Pattern from lib_generic.xml:680. NPCs use this for static defence.

Finding lasertowers

<find_ship_by_true_owner name="$Towers"
    space="$Sector"
    faction="$Faction"
    multiple="true"/>

<create_list name="$LasertowersOnly"/>

<do_for_each name="$ship" in="$Towers">
    <do_if value="$ship.islasertower">
        <append_to_list name="$LasertowersOnly"
            exact="$ship"/>
    </do_if>
</do_for_each>

find_ship_by_true_owner returns all ships — filter by .islasertower after.

Why the dual identity

The “deployable but actually a ship” design comes from engine constraints:

Has weapons + AI — needs ship-class behaviour (target acquisition, fire control)
Has crew (1 pilot) — needs controllable / NPC integration
Deployable like a satellite — player UX inventory deployment

The engine couldn’t unify “autonomous combat thing” without making it a ship. Class.ship + .islasertower flag is the compromise.

Common gotchas

⚠ Lasertower is class.ship, not class.deployable. find_object class="class.deployable" does NOT return lasertowers. find_ship_by_true_owner does.
⚠ .iscapitalship=false — lasertowers are ship_xs class. Don’t filter “all small ships” expecting to exclude them.
⚠ Player ship-list UIs may show them. Lasertowers count as the player’s ship inventory. Vanilla menus filter them out via .islasertower; custom UIs may not.
⚠ Stationary but movable in theory. Lasertowers don’t normally move, but the engine doesn’t forbid issuing movement orders. Setting .defaultorder to something other than Wait may cause odd behaviour.
⚠ add_ammo macro= for deployment. Same as other deployables — NOT add_inventory ware=. See Satellite for the pattern.

Cross-references

Ship — parent datatype
Satellite — sibling deployable
Mine — sibling deployable
Defence module — station-side equivalent
PlaceLasertowerfield library — bulk NPC deployment