Homebrew and Content Authoring

Homebrew and Content Authoring

TLDR

• start from the closest built-in example
• author reloadable blasters with the current item uses and activity workflow in mind
• use the documented power bonus, discount, override, and starship paths instead of inventing your own
• keep Cybernetic Augmentations and Droid Customizations separate
• compare older copied items to fresh compendium examples before assuming the module is broken
• canonical path catalog: Attribute and Active Effect Keys

This page explains how to create and adapt custom SW5e content for use with the SW5e Module for FoundryVTT.

If you are a GM, this page is here to help you make good decisions before you start building your own classes, features, items, powers, NPC content, or starship-adjacent content. If you are a player or advanced user, this page can help you understand how to create homebrew that behaves more predictably inside the module.

This is not a developer page. You do not need to understand the codebase to use this guide. The goal here is practical: help you author content in a way that fits the module’s structure, respects the DND5e system underneath it, and avoids the most common setup mistakes.

What this page covers

This page will help you understand:

• when to start from existing content instead of building from nothing
• how to author homebrew that fits current SW5E workflows
• what to know about reloadable blasters and itemUses
• how power bonus Active Effects and save-target DC bonuses fit in
• how body-mod routing works for cybernetics and droid customizations
• why older copied world content may not behave like newer compendium examples

The most important idea first

The best way to build homebrew for the SW5e Module is to treat it as SW5e content living inside a DND5e framework, not as completely freeform custom data.

That means good homebrew usually works best when it does one of these things:

• starts from an existing SW5E compendium item and modifies it
• follows the shape of a working item or feature that already exists
• uses the same kind of setup the module already expects for that content type

In plain English: copy smart, then customize carefully.

Start from existing content whenever you can

This is the most important practical advice on the page.

Because the module includes structured compendium content for many SW5E categories, the safest and fastest authoring workflow is usually:

1. find the closest existing item, feature, or actor in the compendium
2. duplicate it
3. rename it
4. change only what you actually need to change
5. test it before using it in a live game

That approach is usually better than building from a blank item sheet, because existing content already tends to reflect the module’s expected data shape, terminology, and category usage.

Think in content types, not just ideas

When people create homebrew, they often start with a concept like:

• “I want a custom lightsaber form”
• “I want a new Tech power”
• “I want a species variant”
• “I want a ship upgrade”
• “I want a custom blaster with special properties”

That is a good creative starting point, but it is not yet a good authoring starting point.

A better next question is:

What kind of thing is this supposed to be inside the module?

Before you begin editing, decide whether your idea is really:

• a power
• a feature
• a maneuver
• a weapon
• a piece of equipment
• a starship item
• a cybernetic augmentation
• a droid customization

That one decision will prevent many future problems.

Reloadable blasters and itemUses

For reloadable blasters, the 1.3.8 workflow matters a lot.

If you want a homebrew blaster to behave like the current managed reload workflow, author it with the current magazine model in mind:

• use the current item uses workflow for the weapon magazine
• make sure the ammo typing matches the supported managed paths
• set up the weapon’s activities so Attack, Rapid, and Burst can read the expected shot cost

Do not assume that typing reload flavor text into the description is enough.

If you want the player-facing behavior described in full, use Blaster Reload and Ammo Use. If you want the broader property behavior context, use Weapon Properties Support.

Starship weapons and stock activities

Starship homebrew should follow the same rule as everything else on this page:

start from starship content, not from ordinary character content.

For starship weapons in particular:

• start from a real starship weapon example
• keep the weapon inside the starship item workflow
• expect some interactions to still rely on stock DND5e activity behavior rather than a completely custom starship-only use path

If you force starship ideas into ordinary character item patterns, the result may look correct on the surface while still behaving poorly in play.

Power bonus Active Effects

1.3.8 added clearer power bonus support that matters to homebrew authors.

This is especially useful if you create:

• class or subclass features
• feats
• items with passive casting bonuses
• temporary effects that should increase power attack rolls or save DCs

Examples of useful bonus families include:

• system.bonuses.force.attack
• system.bonuses.tech.attack
• system.bonuses.force.dc
• system.bonuses.tech.dc
• save-target ability DC bonuses such as system.bonuses.force.save.str.dc

If you are building advanced effects, use Attribute and Active Effect Keys for the focused reference — including Force/Tech discounts, Powers Known caps, starship token resource IDs, and Role movement keys.

Powercasting override flags

Some actors need more control than the default powercasting setup provides.

That means homebrew authors may need to know that the module supports override paths such as:

• Light and Dark Force-school ability overrides
• points-ability overrides
• Universal Force mode selection

This matters if your content expects a specific powercasting ability model instead of the actor’s normal default.

Use Powercasting Configuration and Overrides and Attribute and Active Effect Keys for the exact user-facing and key-reference details.

Cybernetics vs droid customization routing

The module treats Cybernetic Augmentations and Droid Customizations as separate systems.

That means body-mod homebrew should start by answering:

• is this for a non-droid actor?
• or is this for a droid actor?

In general:

• non-droid body modifications should follow the Cybernetic Augmentations workflow
• droid body modifications should follow the Droid Customizations workflow

If you author a body-mod item against the wrong system, it may appear in the wrong place, fail validation, or be ignored by the manager you expected to use.

Older copied items may need refresh or re-import

This is one of the most important practical warnings for homebrew authors.

Older items copied into a world do not automatically gain every newer compendium improvement.

That matters especially for:

• reloadable blasters
• activity setup
• powercasting-related expectations
• starship content
• body-mod routing

If a fresh compendium example works and your older copied version does not, compare them directly before assuming you found a module bug.

Good authoring habits

If you only remember a few things from this page, make them these:

1. Build from the closest real example

This is almost always the safest route.

2. Change one layer at a time

If you duplicate a working item, avoid changing everything at once. Change the name first. Then the description. Then the mechanical fields you actually need. Then test it.

3. Test on a real actor

If the content is meant for a Force user, Tech user, maneuver user, droid, or starship, test it on a real example of that kind of actor.

4. Compare against a known-good item

If your custom content behaves strangely, compare it to a similar item from the module compendiums.

Common homebrew mistakes

“I created the right idea, but as the wrong kind of item.”
This is probably the most common issue.

“I typed the rules into the description, so I thought that was enough.”
Descriptions matter, but structured item data matters too.

“I built from scratch, and now I do not know what is wrong.”
Starting from a working example usually gives you a better baseline than starting from a blank item.

“I changed too many things at once.”
That makes troubleshooting much harder.

“I thought older copied items would automatically pick up new setup.”
They often do not.

Light troubleshooting

If your custom content is not behaving the way you expected, try these checks first:

• confirm your Foundry, DND5e, and SW5e Module versions are compatible
• compare your content to the nearest built-in compendium example
• make sure you created the right kind of content item for what you are trying to build
• if the content uses properties, check the property and activity setup carefully
• if the content is a power, test it on a real power-using actor
• if the content is starship-related, compare it to built-in starship content rather than ordinary actor items
• if the content is body-mod-related, confirm it is routed to the correct system
• use Troubleshooting if the issue continues

When to move to the developer docs

This page is for creating content within the module’s expected workflows.

If you need to:

• change how the module behaves
• alter templates or sheet structure
• adjust compendium source files directly
• rebuild packs
• understand repo layout or contributor workflow

then this page has taken you as far as it should. Move to:

• Developer Guide
• Developer Reference
• Testing & Contribution

Where to go next

Use the next page based on what you need:

• Weapon Properties Support if you are working on custom weapons or property-driven gear
• Blaster Reload and Ammo Use if you are working specifically on managed blasters
• Attribute and Active Effect Keys if you need exact attribute / effect paths
• Cybernetic Augmentations if your content is a non-droid body modification
• Droid Customizations if your content is droid-specific
• Starship Sheet Guide if your homebrew is starship-focused
• Troubleshooting if custom content is not behaving correctly
• Developer Guide if your work is moving beyond normal content authoring