Cybernetic Augmentations

Cybernetic Augmentations

This page explains how Cybernetic Augmentations work in the SW5E Module from a user perspective.

Cybernetic Augmentations are handled as an actor-level body modification system for appropriate non-droid characters. They are separate from:

• normal equipment
• starship systems
• droid customization
• species editing

What this page covers

This page focuses on:

• who can use augmentations
• where the UI appears
• how installation and removal work
• what derived and effective side effects mean
• what kinds of install sources are supported
• what the current system supports

What Cybernetic Augmentations are

Cybernetic Augmentations represent installed body modifications on a character.

The module treats them as a dedicated system rather than as ordinary gear. This allows the sheet to track:

• installed augmentations
• body-slot usage
• augmentation count or capacity
• derived and effective side effects
• install and remove management flows

In practical use, augmentations are intended to feel like a distinct character progression or customization system, not just another item list.

Who can use Cybernetic Augmentations

Cybernetic Augmentations are intended for non-droid actors.

In general:

• organic or non-droid characters use Cybernetic Augmentations
• droid characters use Droid Customizations

If you are on a droid actor and do not see the augmentations interface, that is usually intentional.

For droid-specific body modification support, see Droid Customizations.

Where the Augmentations UI appears

When the actor is a valid augmentation host, the sheet should display a Cybernetic Augmentations section and or manager entry point.

Typical behavior:

• it appears on the actor sheet for valid actors
• it opens a dedicated manager UI
• the manager allows you to review installed augmentations and interact with the system

If you do not see it, check:

• whether the actor is actually a valid augmentation target
• whether the actor is being routed as a droid instead
• whether the sheet is in the appropriate state or mode for the interaction you expect

Install sources

In practical play, augmentations can enter the workflow through more than one path.

Common examples include:

• browser-backed install flows from the augmentation manager
• actor-owned or world-item install sources
• drag-and-drop or other normal item attachment paths when the content is authored correctly

The important rule is not which path you used first. The important rule is whether the content is authored in a way the augmentation system recognizes.

Installation

The module supports an install workflow for augmentations.

In practice, this usually means:

• choosing an augmentation item
• validating whether the actor can receive it
• checking slot or capacity rules
• adding it to the actor’s installed augmentation state

That does not necessarily mean every lore or rules edge case is fully automated. Some install-related logic may still be intentionally partial or require GM judgment.

Removal

Installed augmentations can also be removed through the augmentation system.

What to expect:

• installed entries are shown in the manager
• removal is available when appropriate
• the system updates the actor’s augmentation state when removal succeeds

If a confirmation flow is present, that is intentional and helps prevent accidental destructive changes.

Body slots and capacity

Cybernetic Augmentations are not intended to be unlimited.

The augmentation system tracks some form of capacity or body-slot logic so that augmentation use has structure and limits.

Why this matters:

• it prevents augmentations from behaving like ordinary inventory clutter
• it prevents them from feeling like infinitely stackable passive upgrades

Instead, the actor’s body-mod state is something the sheet can manage and validate.

What derived and effective side effects mean

This is one of the most useful ideas on the page.

Derived side effects are things the augmentation system can summarize or calculate from the installed state.

Effective side effects are the changes that actually matter on the actor in play, such as bonuses, penalties, thresholds, or other practical consequences.

That distinction matters because:

• some augmentation consequences may be fully automated
• some may be tracked and surfaced clearly, but still need table judgment
• some may be represented for visibility even when every edge case is not enforced in code

So if a property appears on the sheet, do not automatically assume every edge case is fully automated.

GM overrides

The augmentation system may include GM-facing override or force behavior.

Why this exists:

• to bypass a validation edge case
• to test a build
• to support unusual content
• to resolve a custom or homebrew situation

Overrides are powerful and should be used intentionally. If something only works when forced, that may indicate:

• actor setup is incomplete
• the content is not authored correctly
• or the rule edge case is not fully automated

Routing and droid distinction

One of the most important things to understand is that Cybernetic Augmentations and Droid Customizations are separate systems.

If the actor is routed as a droid, you should expect Droid Customizations, not augmentations.

If the actor is not routed as a droid, you should expect Cybernetic Augmentations, assuming the actor otherwise qualifies.

This distinction is intentional and helps keep body modification rules clearer.

Homebrew support

Homebrew augmentations can work with the module, but they need to be authored in a way the system recognizes.

Common requirements may include:

• the correct item type
• the correct custom label or routing signal
• the correct item flags or metadata
• data that matches the current augmentation workflow

If you are authoring homebrew content, continue to Homebrew and Content Authoring.

Common questions

Why do I not see Cybernetic Augmentations on this actor?
Usually because the actor is not a valid augmentation host, or the actor is being routed as a droid and should use Droid Customizations instead.

Why does this actor show Droid Customizations instead?
Because the actor is being treated as a droid for body-modification purposes.

Why won’t an augmentation install?
Possible reasons include invalid actor routing, slot or capacity limits, or content that is not authored in a recognized way.

Light troubleshooting

If Cybernetic Augmentations are not behaving as expected, check:

• whether the actor is actually a valid non-droid host
• whether the item is authored as a recognized augmentation
• whether the actor is already at capacity
• whether the issue is a display problem, a routing problem, or a deeper automation gap

If needed, continue to Troubleshooting.

Related pages

• Droid Customizations
• Homebrew and Content Authoring
• Active Effect Keys
• Troubleshooting

Practical summary

If you want the shortest useful summary of this page, it is this:

• Cybernetic Augmentations are the non-droid body-mod system
• they are separate from Droid Customizations
• the manager tracks install state, capacity, and side effects
• augmentations can come from several install-source paths, but the content still has to be authored correctly
• “derived” and “effective” side effects are related but not identical ideas