-
Notifications
You must be signed in to change notification settings - Fork 18
Droid Customizations
This page explains how Droid Customizations work in the SW5E Module.
Droid Customizations are the module’s body-modification system for droid actors. This system is separate from Cybernetic Augmentations and is designed specifically for droid characters.
This page explains:
- who uses Droid Customizations
- where the UI appears
- how motor slots work
- how Parts, Protocols, and Motor Upgrades differ
- what install sources are supported
- what is currently supported and what may still be partial
Droid Customizations represent installed upgrades, modifications, and internal systems on a droid body.
The module treats them as an actor-level customization system, which allows it to track:
- installed customizations
- motor slot capacity
- Parts and Protocols counts
- install and remove workflows
- droid-specific limits and upgrades
This is not intended to be the same system as standard equipment or inventory.
Droid Customizations are intended for droid actors.
Current routing model:
- droid actors use Droid Customizations
- non-droid actors use Cybernetic Augmentations when appropriate
If you are on a normal humanoid or non-droid character and do not see Droid Customizations, that is usually expected.
For valid droid actors, the sheet should include a Droid Customizations section.
Typical behavior:
- a summary block appears on the actor sheet
- a Manage action opens the Droid Customizations manager
- installed customizations and capacity information are visible there
The exact placement may vary depending on the current sheet version, but it is intended to feel like a native actor-sheet subsystem rather than a random extra item list.
In practical play, Droid Customizations can enter the workflow through more than one path.
Common examples include:
- browser-backed install flows from the customization manager
- actor-owned or world-item install sources
- drag-and-drop or normal attachment paths when the content is authored correctly
As with augmentations, the main question is not “which path did I use?” The main question is whether the item is authored in a way the customization system recognizes.
Motor slots are the primary capacity system for Droid Customizations.
What they do:
- they determine how many customizations the droid can support overall
- they create real limits instead of letting the system behave like an infinite inventory sink
The manager should make it clear:
- how many slots the droid currently has
- how many are used
- how many remain available
The system also supports increasing motor-slot capacity.
This matters because droids are not intended to start with unlimited customization space.
The current practical ceiling to keep in mind is:
- motor upgrades can raise the total toward a maximum of 6
That means if a droid already feels “full,” the next question is often whether it still has room for a motor upgrade path rather than whether it can ignore capacity entirely.
One of the easiest ways to understand this system is to separate it into three ideas.
Parts are the more physical or hardware-like side of Droid Customizations.
At-table examples:
- an installed chassis or hardware enhancement
- a physical subsystem upgrade
- a structural modification
Protocols are the more software, logic, or integrated-behavior side of the system.
At-table examples:
- a specialized behavior package
- an internal logic routine
- a protocol-driven support function
Motor Upgrades are about increasing the droid’s overall customization capacity rather than only adding one more ordinary installed feature.
At-table example:
- a capacity upgrade that expands how much the droid body can support overall
This distinction matters because the module tracks Parts, Protocols, and motor-slot capacity as related but not identical concerns.
The system supports installing Droid Customization items onto a valid droid actor.
Installation workflow typically includes:
- choosing a valid customization item
- checking whether the actor is a valid droid host
- checking motor slot capacity
- checking category limits such as Parts and Protocols
- adding the customization to the actor’s installed state
The install workflow is structured and validated, but that does not necessarily mean every lore or edge-case rule is fully automated.
Installed customizations can also be removed.
What to expect:
- installed entries appear in the manager
- removal is performed through the manager workflow
- the actor’s customization state updates when removal succeeds
If a confirmation step appears, that is intentional and helps prevent accidental changes.
The Droid Customizations system currently focuses on:
- droid-specific UI
- install and remove flow
- actor-level storage
- motor slots
- Parts and Protocols limits
- customization visibility and management
This makes the system useful for:
- tracking what is installed
- validating limits and capacity
- managing upgrades
- supporting droid-specific customization workflows
Not every possible Droid Customization edge case is guaranteed to be fully automated.
Depending on the system version, some areas may still be:
- partially automated
- display or tracking focused
- GM-guided for unusual edge cases
Examples of possible partial areas:
- very custom content behavior
- edge-case item interactions
- unusual homebrew combinations
- any customization logic that goes beyond the current capacity and management rules
Why do I not see Droid Customizations on this actor?
Usually because the actor is not currently being routed as a droid.
Why do I see Cybernetic Augmentations instead?
Because the actor is being treated as a non-droid body-modification host.
Why can’t I install this customization?
Common reasons include invalid actor routing, no available motor slots, Parts or Protocols limits already reached, or content not authored in a recognized way.
Why is this droid at capacity?
Because the current installed Parts, Protocols, and motor slots already meet or exceed the actor’s current limits.
If Droid Customizations are not behaving as expected, check:
- is the actor actually a droid?
- is the actor using the droid routing path rather than augmentation routing?
- does the item qualify as a Droid Customization?
- does the actor have available motor slots?
- are Parts or Protocol limits already reached?
- is the issue a current automation gap rather than a data problem?
If needed, continue to Troubleshooting.
If you want the shortest useful summary of this page, it is this:
- Droid Customizations are the droid-only body-mod system
- motor slots are the main capacity rule
- Parts, Protocols, and Motor Upgrades are related but distinct ideas
- motor upgrades can raise capacity toward a ceiling of 6
- correct item authoring still matters even when the manager UI is present
SW5e Module Wiki
Start here: Home · Getting Started · Feature Overview · Sheets & Features
Popular topics: Blaster Reload and Ammo Use · Themes and Appearance · Starship Sheet Guide · Powercasting Configuration and Overrides
Need help? Troubleshooting · FAQ · Compatibility & Limitations
Working on the module? Developer Guide · Developer Reference · Local Setup and Workflow · Testing & Contribution
For general FoundryVTT help, please use the Foundry VTT Discord, Baileywiki’s Foundry VTT playlist, or Encounter Library’s Foundry VTT Basics playlist.