Compatibility & Limitations

Compatibility & Limitations

This page explains how to think about compatibility, version expectations, and practical limitations when using the SW5e Module for FoundryVTT.

The goal of this page is not to scare you away from updates or make the module sound fragile. It is here to help you set realistic expectations. The SW5e Module is actively developed, and that means compatibility can change over time. It also means some behavior comes from the module itself, while other behavior comes from the DND5e system or from FoundryVTT core.

What this page covers

This page will help you understand:

• where to check current compatibility information
• why version matching matters so much
• what behavior belongs to the SW5e Module versus DND5e or Foundry
• why older content may behave differently from newly created content
• what kinds of limitations are normal in a module like this
• how to decide whether you should update right away or wait

The most important rule

Always treat the project README and Release Notes as the source of truth for current compatibility.

If this wiki and your world do not appear to match, do not assume the wiki is wrong or that your world is broken. Check your versions first.

Current target runtime

For the current development version and the upcoming 1.4.0 release, the project targets:

• FoundryVTT v13.x
• DND5e system v5.2.5

This page explains how to think about that target. The README and release notes remain the final authority.

Why compatibility matters so much

The SW5e Module is not a standalone game platform. It sits on top of the DND5e system inside FoundryVTT, so compatibility is always layered.

That means a working setup depends on at least these parts lining up:

• your FoundryVTT version
• your DND5e system version
• your SW5e Module version
• sometimes additional expectations such as dependency versions or migration state

Stable releases vs prerelease builds

Not every user should treat every build the same way.

A practical rule is:

• if you want the most predictable experience, use the latest stable public release
• if you want newer features or want to help test active changes, you may choose a prerelease
• if you use a prerelease, expect documentation and behavior to move more often

What behavior belongs to the module, and what does not

One of the easiest ways to get confused is to treat every behavior you see as if it comes from the SW5e Module alone.

In reality, your experience may come from one of three places:

• FoundryVTT core
• the DND5e system
• the SW5e Module

The SW5e Module is responsible for Star Wars 5e-oriented adaptation and support, such as SW5e terminology, powercasting support, maneuver support, property support, starship workflows, retained branding, and SW5e-specific content structure.

But general questions about scenes, tokens, permissions, ordinary actor management, or stock Foundry workflows usually belong to Foundry help instead.

Appearance compatibility note

In the 1.4.0 feature set, selectable SW5E theme modes are removed. Application chrome follows stock Foundry / DND5e presentation. Core SW5E branding remains. Stale world themeMode values are ignored. See Themes and Appearance.

This is not a compatibility failure. It is the intended appearance model.

Why older content may behave differently

This is one of the most important limitations for users to understand.

Older actors, items, powers, or starships may not behave exactly like newly created content, especially after major updates. That does not always mean something is broken. It often means the project has moved the preferred content structure forward while still carrying older content along.

World-copied items and refresh guidance

Actor-owned items or older items copied into a world may not automatically pick up every newer compendium improvement.

This matters especially for workflows such as:

• weapon activities
• reloadable blasters
• starship setup
• flat Damage Reduction and starship AC calculation data
• newer effect-key or item-data expectations

If a fresh compendium example works and your older copied version does not, a refresh or re-import may be the right next step.

Runtime-driven behavior vs content-driven behavior

Some important SW5E workflows happen at runtime on existing actors and items. Others depend on the underlying content setup.

A useful rule of thumb is:

• starship sheet routing, starship conditions, System Damage, Destruction Saves, token status sync, space-station variant rules, flat DR automation, and appearance/branding behavior are mainly runtime-driven
• item activity setup, copied world documents, Drake’s Shipyard AC-calc or armor DR source updates, and compendium-backed examples are often more content-driven

That means a code update can improve some existing documents immediately, while other changes may only be visible when the underlying item or actor data is current.

Migration notes for 1.3.9 and later

1.3.9 includes migration work that can matter for older worlds.

At a high level:

• 0.39 remaps legacy droid class effect image paths
• 0.40 clears stale powercasting known.max overrides written as 0 when there is no active powercasting progression
• 0.41 continues blaster migration cleanup and starship tier sync behavior

Builds that include later 1.4.0-era migrations may also:

• fold orphan PHB wallet keys into Galactic Credits (gc) — migration 1.3.4
• rewrite recognized obsolete Maneuver heal/temp-HP formulas to 1d@superiority.die + @mod — migration 1.3.5

Back up the world before the first GM load on builds that include those wallet/formula migrations — those writes are not reversible by reverting module code alone.

Practical advice:

• open the world after updating so migration can run
• if one older actor looks wrong and a fresh example looks right, migration or content age is often part of the story
• flat DR and space-station behavior can apply at runtime, but packed Drake’s Shipyard source updates still need a normal rebuild/import path to appear in packed data
• Hull/Shield token bars are opt-in only; existing tokens are not auto-migrated
• Active Crew UI removal does not require deleting stale active.value flags

Compatibility is not only about “does it load?”

A setup can load successfully and still have meaningful compatibility problems.

For example, the world can open while one or more of these still need attention:

• powercasting UI or point behavior
• item property or activity behavior
• appearance or branding expectations after theme removal
• starship routing, conditions, status sync, Damage Reduction, crew membership, or station variant setup
• older copied content that no longer matches current compendium expectations

That means “the world opens” is not the same as “everything is fully working as intended.”

Practical limitations to expect

No module like this can promise that every part of Star Wars 5e will always be fully automated in every version.

A realistic expectation is that support may fall into a few categories:

• strong structured support, where the module clearly supports a workflow
• partial support, where the module helps with display, organization, or data structure but not every rule interaction
• version-sensitive support, where behavior changes as the project evolves
• legacy-sensitive support, where older content may need migration or manual review

Limitation: not every rules concept is equally automated

Some users expect “supported” to mean “fully automated.”

That is not always the right expectation.

Support in the module can mean different things in different contexts, including:

• terminology and localization support
• compendium content and corrected data
• sheet or dialog support
• editable values and structured resources
• targeted automation for selected behaviors

Weapon properties are a good example of this. Some properties are mostly about display and data quality. Some have real behavior support. Some depend on the activity or item being set up the expected way.

Flat Damage Reduction is another example. The module can automate attack-damage reduction when the world setting is enabled, but tables can also turn that automation off and handle DR differently if they prefer.

Limitation: major feature areas can still evolve

Some feature areas are especially active and may continue to change more than others.

That is especially true for areas like:

• starships
• powercasting and point handling
• migration and legacy content support
• compatibility with newer DND5e versions

That does not mean those systems are unreliable. It just means users should expect those areas to evolve more visibly than a static, unmaintained project would.

Limitation: local content can outgrow simple documentation

The more custom your world becomes, the less any general wiki page can guarantee exact behavior.

This is especially true if you use:

• a lot of homebrew
• older migrated content
• custom item edits
• prerelease builds
• local development changes

When to update right away, and when to wait

There is no single right answer for every table, but here is a practical way to think about it.

Update sooner if:

• you are comfortable testing changes
• you want access to newer features or fixes
• you are already tracking project updates closely
• you are willing to inspect older content after migration

Wait a bit if:

• you are in the middle of an active campaign
• your world contains a lot of older content
• you rely heavily on custom homebrew
• you want the most predictable experience possible
• you do not have time to test after updating

That is simply good operational caution for any actively developed module.

A safe update habit

A very practical habit is:

1. read the latest release notes
2. check the README for supported versions
3. back up your world
4. test important actors, items, and starships first
5. only then move fully into live play

What to do if you are unsure whether your issue is compatibility-related

If you are not sure whether the problem is a compatibility problem, ask these questions:

1. Did this begin after updating Foundry, DND5e, or the module?
2. Does the problem affect one thing or many things?
3. Does newly created content behave better than older content?
4. Does a built-in example work while your custom or older example does not?
5. Does the latest README or release history mention the area that changed?

If the answer to several of those is “yes,” compatibility or migration is probably part of the story.

Related pages

Depending on what you need, these pages may help next:

• Troubleshooting
• Starship Sheet Guide
• Blaster Reload and Ammo Use
• Powercasting Configuration and Overrides
• Themes and Appearance

Practical summary

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

• the SW5e Module is an SW5E implementation for DND5e, so compatibility is always layered across Foundry, DND5e, and the module itself
• the README and Release Notes are the best place to verify current supported versions
• older content may behave differently because the project has real migration and normalization history across powers, items, references, images, and starships
• “supported” does not always mean “fully automated in every situation”; some support is structural, some is behavioral, and some is version-sensitive
• if your campaign depends on stability, read the notes, back up first, and test before updating live

---

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.