Weapon Properties Support

Weapon Properties Support

TLDR

The SW5e Module supports weapon properties in more than one way.

Some support is about:

• correct labels
• correct compendium data
• reference material
• editable numeric values

Other support is about behavior, including examples like:

• Keen
• reloadable blaster workflows
• activity-driven Rapid/Burst handling when the weapon is set up correctly

If a property is not working the way you expected, check the item setup first, then check version compatibility, and only then assume you have found a module bug.

This page explains how the SW5e Module for FoundryVTT handles weapon properties.

If you are a GM, player, or homebrew author, this is one of the most useful “how does this actually behave?” pages in the wiki. Weapon properties matter because they often carry a large part of a weapon’s rules meaning in Star Wars 5e. A weapon is not just its damage die or its name. Many of the important differences between weapons live in their properties.

The SW5e Module includes support for SW5e-oriented weapon properties, but it is important to understand that not every property works in exactly the same way. Some properties mainly affect display and rules clarity. Some properties support usable sheet behavior. Some properties depend on the weapon being set up correctly in the first place.

What this page covers

This page will help you understand:

• what “weapon property support” means in the SW5e Module
• the difference between display support and behavior support
• how numeric properties fit into the workflow
• how the 1.3.8 blaster reload and activity consumption workflow fits into property support
• why item setup matters
• how to troubleshoot property behavior that does not look right

If you are looking for general Foundry item-sheet help, drag-and-drop basics, or DND5e activity setup that is not specific to the SW5e Module, use the Foundry Discord, Baileywiki, or Encounter Library instead.

The big idea

The safest way to think about weapon properties is this:

Weapon properties are part rules text, part item data, and sometimes part automation.

That matters because users often expect every property to behave the same way. In practice, the module supports weapon properties in several different ways, including:

• SW5E property terminology and labels
• correct property values on compendium weapons
• support for numeric item properties
• automation for some specific behaviors such as Keen
• reload and ammo workflows for supported managed blasters
• activity-driven Rapid and Burst cost behavior when the weapon is set up correctly

In other words, weapon properties are supported, but the support is not just one thing. It is a mix of data quality, UI support, and selected gameplay behavior.

Display support vs behavior support

This is the single most important distinction on this page.

Display support means the property appears correctly, uses the right label, and helps communicate the weapon’s rules meaning. That matters because a lot of table clarity comes from correct data and readable presentation even when the property is not fully automated.

Behavior support means the property affects how the weapon behaves on the sheet or during use. That can include:

• activity consumption
• reload controls
• ammo tracking
• attack or save behavior

That means a property being present on a weapon does not automatically mean it will receive full mechanical automation in every context.

Numeric properties

Some SW5E weapon properties are not just on-or-off tags. They also carry a value.

From a practical standpoint, this means:

• if a property includes a number, the value matters
• editing that value is part of the intended workflow
• if the number cannot be edited or looks wrong, that may be a sheet or UI problem rather than a problem with the property concept itself

Blaster reload and activity consumption

One of the most important 1.3.8 behavior upgrades is the blaster reload and ammo UX for supported managed blasters.

What this workflow does

On supported managed blasters:

• the magazine is tracked through item uses
• Attack, Rapid, and Burst can consume shots through the item’s activity setup
• the weapon row shows a Reload control for supported actors
• if the weapon is empty, or does not have enough shots for the selected activity, the activity is stopped before it consumes anything
• the actor’s owners and GMs receive a private Reload card in chat

This is one of the clearest examples of a property-adjacent workflow that mixes item data, activity setup, sheet controls, and chat behavior.

Compatible ammo types

The current supported managed-ammo types for this workflow are:

• Power Cell
• Slug Cartridge

What “managed blaster” means here

In practical terms, the weapon must be set up in a way the current runtime recognizes:

• it must be a supported blaster-style weapon
• it must use the current item uses magazine workflow
• it must have compatible ammo typing
• its activities must be set up so the expected shot cost can be read during use

Older copied items may need review

If you copied a weapon into your world a long time ago, do not assume it automatically inherited the newest reload and activity setup.

A very common troubleshooting step is:

1. open a fresh compendium example
2. compare the copied world item to it
3. refresh or re-import the older item if the setup differs

Rapid and Burst

Rapid and Burst are especially useful examples because they remind users that behavior often depends on how the activity is configured, not only on the property existing on the weapon.

If your Rapid or Burst use is not behaving the way you expected, do not check only the property label. Check the item’s actual activity setup as well.

Item setup matters more than many users expect

A weapon property can only help you if the weapon itself is set up in a way the module can use.

That means if a property is not behaving the way you expected, the problem may not be the property by itself. The issue may be:

• the property is missing
• the property value is wrong
• the activity or action is set incorrectly
• the item came from older content and needs review
• the release you are using changed how that property is handled

A practical lesson follows from that:

When a property looks wrong, always check the item before assuming the module is broken.

Compendium weapons and reference material

The module includes several equipment and weapon-related packs, including packs for Blasters, Lightweapons, Vibroweapons, Starship Weapons, and a Weapon Properties journal pack.

That tells users two important things:

• the module expects you to work with structured SW5e weapon content
• the module includes a rules-reference layer for weapon properties in addition to the weapons themselves

For many groups, that means the best starting point is not building a weapon from scratch. It is often easier to start with a known compendium weapon or property reference, then adjust from there if needed.

What this means for homebrew authors

If you are creating custom SW5E weapons, do not think of properties as only flavor text.

Properties are part of the weapon’s usable data. A custom weapon that lists the right property name but uses the wrong setup underneath may look correct while still behaving incorrectly.

A good homebrew workflow is:

• start from an existing SW5e weapon when possible
• confirm the property list is correct
• check whether a property expects a numeric value
• check the activity setup if the property affects use behavior
• test the weapon before putting it into a live game

That will save time and reduce false bug reports.

Common misunderstandings

“If a property appears on the weapon, it must be fully automated.”
Not necessarily. Some properties are mainly about correct display, labels, and rules clarity. Others have specific behavior support.

“A property problem always means the sheet is broken.”
Not always. It may be an item-data issue, a numeric-value issue, or an activity-setup issue.

“Rapid and Burst should always just work on their own.”
They depend on the item being set up in the expected way.

“Reloadable blasters all work the same no matter how old the item is.”
Be careful there. Older copied world items may need review or refresh to match the current compendium setup.

Light troubleshooting

If a weapon property is not behaving the way you expect, try these checks first:

• confirm that your Foundry version, DND5e version, and SW5e Module version are compatible
• confirm that the weapon actually has the property you think it has
• check whether the property expects a numeric value
• check whether the weapon’s activity setup matches the behavior you expect
• compare the item to a known compendium weapon if possible
• if the issue involves reload or activity ammo use, compare it to a fresh managed blaster example
• use Troubleshooting if the issue continues

A simple testing habit that helps a lot

If you are unsure whether a problem is with the property or with the item, do this:

1. find a similar weapon from a module compendium
2. compare the properties side by side
3. compare the activity setup side by side
4. test the compendium weapon first
5. then test your edited or homebrew version

That process often tells you very quickly whether the issue is:

• a property-support limitation
• a setup mistake
• or a real bug worth reporting

Where to go next

Use the next page based on what you need:

• Blaster Reload and Ammo Use if your question is specifically about reloadable blasters
• Sheets & Features if you want the broader actor and item-sheet context
• Homebrew and Content Authoring if you are creating custom weapons or gear
• Troubleshooting if property behavior still does not look right
• FAQ if you want quick answers to common questions
• Starship Sheet Guide if the item in question is part of a ship workflow rather than ordinary character equipment