Troubleshooting

This guide covers common issues GMs and players encounter when setting up or using Fabricate, with step-by-step checks for each.

Recipes Not Appearing in the Crafting App

Symptom: A recipe exists in the GM admin panel but does not appear in the player crafting app.

Likely causes:

The recipe is disabled. Disabled recipes do not appear in the player crafting app (they remain in the GM admin panel with a grey “Disabled” badge).
The recipe is restricted to specific users and the current player is not on the allow-list (restricted recipe visibility mode).
The system uses knowledge mode and the player has not learned the recipe or does not own a matching recipe item.
The recipe belongs to a crafting system that no longer exists.
The crafting system has a blocker, or this individual recipe is broken. Fabricate hides recipes that players could not use because of a setup problem, while still showing them to the GM.

Step-by-step checks:

Open the Crafting Admin panel, select the system, and open the Overview. A blocker means players see none of the system’s recipes until you fix it. An issue listed against the recipe itself hides only that recipe. Use the Open button on an issue to jump to the editor that owns it.
Go to the Recipes tab. Is the recipe’s enable toggle (checkbox) in the Actions column checked? Disabled recipes show reduced opacity and a grey “Disabled” badge.
Check the Visibility column in the recipe list. Does it show “Restricted” with a user count? If so, make sure the affected player is in the allow-list.
Check the Recipe Visibility card on the Systems tab. If the system is set to knowledge mode:
- Does the player’s actor own the item linked to the recipe?
- Has the player learned the recipe? Confirm this in the player’s knowledge list.
Confirm the recipe still belongs to an existing crafting system. If its system was deleted, the recipe will not show for players.

See also: Recipes for enabling and disabling recipes. Visibility & Knowledge for list modes and knowledge access. Crafting Systems for the System Overview and how broken systems and recipes are hidden.

Recipes Disappeared After Changing the Resolution Mode

Symptom: After changing a crafting system’s recipe resolution mode, some or all recipes are no longer present.

What to expect: Changing the resolution mode is no longer delete-all. Fabricate migrates each recipe to the new mode wherever it can, and only deletes a recipe whose structure cannot be made to fit. The confirmation prompt runs a dry run first and tells you exactly what will happen: how many recipes will be migrated, and, only when some cannot be migrated, how many will be deleted and their names. It also names any ingredient sets a recipe will lose when it is collapsed into Alchemy mode, and any recipe that will lose its failure result set when you move into Progressive mode.

Likely causes for a recipe being deleted:

You narrowed into Simple or Progressive mode (which each expect exactly one ingredient set and one result set) from a recipe that had more than one of either. A failure result set does not count toward that limit.
You moved a multi-step recipe into Alchemy mode, which does not support multi-step recipes.

Step-by-step checks:

Read the confirmation prompt before confirming. It names the recipes that cannot be migrated and will be deleted. It also names the ingredient sets and failure result sets that will be dropped from recipes that are kept. Cancel if you are not ready to lose them.
Export the system first to keep a backup if you are unsure. You can re-import it to recover deleted recipes.
If a recipe simply vanished from players but is still in the admin panel, the cause is a system or recipe problem, not deletion. Open the Overview to find and fix it.

See also: Crafting Systems for the migration-first mode change and the System Overview.

Crafting Check Not Running

Symptom: The crafting check never fires. Recipes resolve immediately with no skill check, even though the Routed by check mode or Progressive mode is configured.

Likely causes:

The crafting check has no roll formula authored for the system’s active resolution mode. Routed by check mode and Progressive mode each need a roll formula before their check can run. A required check with no roll formula now fails loudly with a validation error rather than being silently skipped.
The resolution mode is Simple, or Routed by ingredients. In these configurations a crafting check is optional. The check runs if a roll formula is configured but is not required for success.
For an optional Simple check, the check is turned off. When it is off, the check is skipped entirely.
The check returns something the current mode does not understand (for example, no named outcome in Routed by check mode, or a missing numeric value for Progressive mode).

Step-by-step checks:

Open the Crafting Admin panel, select the system, and open Checks › Crafting. On The roll section, is a roll formula configured for the system’s resolution mode?
Check the system’s Resolution Mode. If the resolution mode is Routed by check or Progressive, a crafting check is required. Fabricate reports a validation error when its roll formula is missing. For Simple mode or Routed by ingredients, the check is optional and simply does not run when no roll formula is configured.
For an optional Simple check, confirm the check is turned on. When it is off, the check is skipped.
Attempt a craft and watch for any error or warning notifications from Fabricate about the check.

See also: Crafting Checks for crafting check configuration.

Per-Recipe Check Modifier Control Missing

Symptom: A recipe’s Overview tab offers no Eligible modifiers control, so you cannot choose which check modifiers that recipe uses.

Likely causes:

The system’s Combination rule is not By recipe. That is the one rule that hands the selection to the recipe author, so it is the only rule under which the control appears. Under Apply all, Highest, and Player picks the system decides, and the tab shows nothing rather than a control the system would ignore.
The system’s modifier library is empty, so there is nothing to pick from.
The system’s active crafting check cannot use a modifier right now. Either the resolution mode rolls no check at all, or the check has no roll formula authored yet. Under By recipe the recipe’s Overview tab shows a banner naming which of these applies in place of the control.

Related symptom: The control is there, but the Add modifier button is greyed out. The recipe has reached the system’s Maximum picks. Raise that limit, or clear it entirely for no limit, on the How they combine card of Checks › Crafting › Modifiers.

What is and is not lost: Switching a system away from By recipe, or lowering Maximum picks, never deletes what a recipe picked. The picks stay stored and stop being applied, and restoring the rule or the limit applies them again immediately with nothing to re-enter. A lowered limit rolls only the first few picks, up to the limit, and keeps the rest.

Step-by-step checks:

Open the Crafting Admin panel, select the system, and open Checks › Crafting › Modifiers.
Confirm the library has at least one modifier. The Named modifiers card lists them, and it is read-only. If it is empty, follow its Edit in system settings link to World › Rules & Resources › Modifiers and choose Add modifier there.
Check the Combination rule on the How they combine card. If it is anything other than By recipe, that is why no recipe has a control. Choose By recipe to hand the selection to your recipes.
If the rule is already By recipe, open the recipe’s Overview tab and read the banner in place of the control. It names whether the system’s active check has no roll formula, or rolls no check at all for the current resolution mode.
Fix whichever of those applies on Checks › Crafting, then return to the recipe’s Overview tab.

See also: Check modifiers covers the library, the four combination rules, and the pick limit in full.

Routed Recipe Produces Nothing on a Successful Check

Symptom: A recipe that routes by skill-check outcome rolls a success, but no result is produced.

Likely causes:

A success outcome tier is not wired to any result set. When the check rolls that tier, there is nothing to produce.
A result set is assigned only to an outcome tier that was later deleted from the routed crafting check. The stale assignment no longer points at a real outcome, so that result set can never be selected.
The recipe mixes explicit outcome assignment with name matching, and the rolled outcome’s name does not match any result set name.

Step-by-step checks:

Open the recipe in the recipe editor and go to the Validation tab. Look for the warning that a result set is not assigned to any check outcome, and the warning that a check success outcome produces no result set.
On the Results tab, check each result set’s Produced by line. Make sure every success outcome tier you expect to use is assigned to a result set, and that no result set shows Nothing — unreachable (a reserved failure set never shows it). A struck-through tier on the line no longer routes, so remove it or assign a current tier.
If you removed an outcome tier from the routed crafting check, Fabricate strips that tier from any recipe result set that referenced it and posts a notification saying how many result sets were updated. Re-open the affected recipes and assign the result sets to a current outcome tier.
If you rely on name matching instead of explicit assignment, confirm each result set name matches the outcome tier name once case and surrounding spaces are ignored.

See also: Routed Modes for how outcomes match results, including explicit outcome assignment and name matching. Crafting Checks for how a routed check rolls and resolves its difficulty.

A Result Set Is Never Produced in Routed by Ingredients

Symptom: A recipe in Routed by ingredients mode has a result set that is never produced, whatever ingredients a player uses. The recipe’s Validation tab shows the warning No ingredient set reaches a result set, so it will never be produced. The system’s Overview lists the same warning under Recipes as A result set is not reached by any ingredient set.

Likely causes:

The recipe has no ingredient sets yet, so no result set has a source.
No ingredient set is assigned to the result set, and every ingredient set reaches a different one.
Every ingredient set is assigned to another result set, so even the recipe’s first result set has no source. An ingredient set you have not assigned anywhere reaches the first result set by default.

Step-by-step checks:

Open the recipe in the recipe editor and go to the Overview tab. In the Routing card, look for a result set that no row’s dropdown has chosen.
Re-point an ingredient set to the result set from its row’s dropdown. You can also open the Results tab and choose Assign on the result set’s card. A result set that no ingredient set leads to shows Nothing — unreachable on its line, the reserved failure result set included, because this mode never awards it on a failed check.
If you do not need the result set, remove it from the Results tab.
A result set that is reached only by default raises no warning.

See also: Routed Modes for the routing overview, and System Overview for where system-wide warnings appear.

A Failed Check Produces Nothing, or Suddenly Produces Something

Symptom: A recipe, salvageable item or gathering task has a failure result authored, but a failed check hands the crafter nothing — or the reverse, a failed check has started producing something it never used to.

Likely causes:

The activity’s Produce a result on a failed check setting is Never. Every system that existed before Fabricate 1.25.0 was set to Never by the upgrade, deliberately, so that nothing about it changed when you upgraded.
The record authors no failure output at all. The setting SELECTS a failure output you wrote; it never invents one, so Always on a recipe with no failure result still produces nothing. A single-step simple recipe does not have a failure set until you turn on Award results on a failed check on its Results tab. Steps of a multi-step recipe do not offer that toggle yet.
The resolution mode has no failure outcome to produce. Routed by ingredients and Progressive have no failure tier or reserved failure result set, and a gathering d100 task has no failure outcome to produce, so the setting is inert there and the section says so.
On a Routed by check system, the failure-marked outcome tier is not assigned to any result set. A failing tier routes exactly like a succeeding one: it has to be bound to a result set.

Step-by-step checks:

Open the activity’s check route — Checks › Crafting, Checks › Salvage or Checks › Gathering — and go to its On failure section. Read the Produce a result on a failed check card: Never, Decided per recipe or Always. Each activity has its own copy of this setting, so a crafting system set to Always says nothing about what its salvage does.
If the section shows a note saying the setting does not apply in this mode, that is the answer: the mode has no failure outcome, and the note names why.
In simple mode, open the record and confirm the failure output exists. For a recipe that is the reserved failure result set on the Results tab. On a recipe that has none, it appears only after you turn on Award results on a failed check, and it is drawn locked with a reserved role badge. For a salvageable item it is the reserved failure result set on the component’s Salvage panel.
In Routed by check mode, set the check route’s Produce a result on a failed check to Decided per recipe or Always first — the failure-marked tiers only appear in a result set’s Assign list on a result set’s Produced by line while failure results are permitted — then assign a result set to the failing tier. Nothing you have already assigned is deleted when you set it back to Never; those assignments simply stop being offered and stop routing, and they come back when you permit failure results again.

See also: Crafting Checks for the setting and its three values, and Salvage for salvage’s own On failure section.

Tools Not Breaking or Tracking Usage

Catalysts were retired in version 0.6.0. Required-but-reusable equipment is now modelled by Tools. Existing catalyst data migrates to Tools automatically.

Symptom: A tool is used during crafting or gathering but its usage counter does not increment, or the tool never breaks when you expect it to.

Likely causes:

The tool’s breakage mode is not limited uses. Only limited-uses tools track per-item usage. Tools that roll a chance to break each attempt do not keep a usage count.
The maximum number of uses is blank (unlimited). A limited-uses tool still increments its counter but never breaks because there is no maximum.
The tool’s on-break action is set to flag the tool as broken (the default for migrated tools), so it is marked broken rather than destroyed. This may be intentional (for example, a forge that needs repair rather than replacement).
On a failed crafting or salvage check, tools are not broken or degraded by default.
The owned tool item cannot be identified as the Tool by a durable link. Presence is matched broadly, but breakage and usage are not. In a world that has not been repaired, a copy that was duplicated from another item, or that merely shares the Tool’s name, is recognised as present but is never consumed, broken, or usage-counted. Fabricate spares it deliberately, so it never destroys the wrong item.

Step-by-step checks:

Open the system’s Tools page and select the tool. Is the breakage mode set to limited uses?
If so, is Max uses set to a positive number (rather than left blank)?
Use the tool a few times and confirm its usage count goes up on the owned item. If it never increases, the breakage mode is not limited uses.
If a broken tool should be removed instead of flagged, set its on-break action to Destroy item (or Replace with…). A tool that has been flagged as broken cannot be used again until a GM clears that broken state.
If tools should break even on a failed check, open the system settings and enable the option to consume tools on failure (there are separate options for recipes and for salvage).
If the tool is present but never breaks or tracks usage, and the owned copy was duplicated from another item or shares its name with another item, run Repair Item Data from the Fabricate module settings, or delete the copy and re-issue the tool from its source item. This gives the item a durable identity link, after which it breaks and tracks usage normally.

See also: Tools covers the system-owned Tool model, including the requirement gate, breakage modes, and on-break actions. Crafting Checks covers consumption on failure settings. Repairing Item Data covers the maintenance action that gives duplicated copies a durable identity link.

Effect Transfer Not Applying

Symptom: Crafting completes successfully but the result item does not receive active effects from essence source items.

Likely causes:

Effect transfer is an opt-in feature with three separate switches. All three of the following must be turned on before any effects are transferred:

The Essences feature must be enabled on the crafting system.
The Effect Transfer feature must be enabled on the crafting system.
The individual recipe must opt in to effect transfer.

If any one of these is off, effect transfer is silently skipped.

Additional causes:

An essence has no source item selected, or its source item no longer exists. Essences without a valid source item are silently skipped.
The source item has no active effects defined on it (nothing to transfer).
The consumed ingredients do not contribute any essence quantities. If no essences are contributed, there is nothing to transfer.

Step-by-step checks:

Open the Crafting Admin panel, go to the Systems tab, and check the Features card. Are both the Essences toggle and the Effect Transfer toggle enabled?
Open the recipe in the recipe editor. Is Transfer Effects checked?
In the system settings, open the Essences feature card. Does each essence have a Source item selected?
Open the source item linked to the essence. Does it have active effects defined? (Check the item sheet’s Effects tab.)
Check the components used as ingredients in the recipe. Do they have non-zero essence quantities assigned for the relevant essence?

See also: Effect Transfer covers effect transfer configuration and the triple-flag pipeline. Essences covers essence definitions and source items.

Salvage Configuration Rejected

Symptom: Salvage fails with a validation error, or attempting to salvage a component produces an error instead of results.

Likely causes:

The salvage resolution mode is set to a mode that is not valid for salvage. Only Simple, Routed, and Progressive are valid.
Routed salvage mode requires:
- a salvage check roll formula is configured
- at least one outcome is declared (such as critical, pass, and fail)
- the component maps every declared outcome to an existing result set
Progressive salvage mode requires:
- a progressive salvage check roll formula is configured
- every result component has a valid positive difficulty value
Simple salvage mode requires exactly one result set per component. Having none, or two or more, is rejected.
Salvage is disabled on the component.

Step-by-step checks:

Check the system’s salvage resolution mode. If it is not Simple, Routed, or Progressive, change it to one of those.
For Routed mode:
- Is a routed salvage check roll formula configured?
- Are the outcomes defined (such as critical, pass, and fail)?
- Does the component map every declared outcome to an existing result set?
For Simple mode: does the component have exactly one salvage result set?
For Progressive mode: does each result component have a valid positive difficulty value?
Is salvage enabled on the component you are trying to salvage?
Is the salvage feature enabled on the crafting system?

See also: Salvage covers salvage configuration, salvage resolution modes, and salvage crafting checks.

Character Missing From the Character Bar or Rosters

Symptom: A player’s character does not appear in the character-selection bar at the top of the unified Fabricate window, in the GM’s gathering stamina roster, in the Access or Knowledge rosters in the Crafting Admin panel, in the party member picker, or in a party’s travel-actor picker. The player owns the actor, and it is otherwise a normal player character for the game system.

Likely cause:

Fabricate only recognises certain actor types as player characters. By default, only the “Character” actor type counts.
Some game systems use more than one actor type for a player character. For example, a game system might use one actor type for an ordinary character sheet and a separate actor type for a robot or vehicle sheet. Fabricate does not know about an additional type until a GM adds it.

Step-by-step checks:

Open Foundry’s Game Settings, choose Configure Settings, and open the Fabricate module settings.
Find Player Character Actor Types and click Choose Actor Types.
Confirm the missing actor’s type is ticked in the list. “Character” is always ticked and cannot be unticked.
Click Save. The change takes effect for every connected player immediately, without a reload.

What this setting does and does not change: Adding an actor type here only changes which actors are offered in the character bar, the gathering stamina roster, the Access and Knowledge rosters, the party member picker, and a party’s travel-actor picker. It does not change who is allowed to attempt a craft or a gathering task. That always depends on who owns or controls the actor. An actor of an unconfigured type remains fully usable for crafting and gathering. It is simply not offered as a choice in those five lists.

Note that these lists share one setting. Adding an actor type so that a group, vehicle or caravan actor can be chosen as a party’s travel actor also makes actors of that type eligible party members. If you would rather not widen both, drag the actor onto the travel-actor panel instead: a drop assigns any actor directly and ignores the type list.

See also: Gathering Environments covers the character bar from the player’s side.

Crafting, Salvage, or Alchemy Deletes a Whole Stack Instead of Reducing It

Symptom: Crafting, salvage, or an alchemy attempt consumes an entire stack of an ingredient or component at once instead of reducing it by the amount actually used. Using one unit from a stack of twenty destroys all twenty.

Likely cause:

Fabricate reads and writes how many units are in an item’s stack through a single game-system-specific field, configured as the Item Stack Quantity Field setting. Fabricate already ships a working default for most game systems, matching the same field the system itself displays as an item’s quantity, so this rarely needs to change. If the field is set to point at something other than the number of units itself, Fabricate can no longer tell how large a stack is. It then treats every stack as though it holds only one unit and deletes the whole item the moment any amount is consumed.

Step-by-step checks:

Open Foundry’s Game Settings, choose Configure Settings, and open the Fabricate module settings.
Find Item Stack Quantity Field. Its hint text names the field your game system is expected to use.
Confirm the configured value matches that expected field, unless you know your game system stores stack counts somewhere else. Fabricate ships a correct default for most systems and documents a small number of known exceptions.
Make sure the field points at the number of units itself, not at a section, table, or category the number happens to live inside. Pointing at a container instead of the number is the most common way this setting is misconfigured, and it produces exactly the destructive symptom described above.
If Fabricate detects a problem, it posts a standing warning naming how many of your world’s items resolve a usable number at the configured field, compared with your system’s expected field, and stating plainly that crafting, salvage, and alchemy will delete whole stacks until the field is corrected. Follow the warning back to Item Stack Quantity Field in the Fabricate module settings and correct it there. That check only looks at your world’s Items directory, so a world that keeps everything in compendia and on character sheets is never warned even when the field is wrong. Silence is not a clean bill of health: if stacks are being destroyed, work through the checks above rather than waiting for a warning.

See also: Recipe Appears Uncraftable Despite Owning Recipe Item or Components covers a related but different craftability problem.

Recipe Appears Uncraftable Despite Owning Recipe Item or Components

Symptom: A recipe shows as “Cannot craft” or is excluded from the “Craftable only” filter even though the player’s actor owns a copy of the linked recipe item and all required components. This is most common after upgrading to Foundry v12 or after importing items from a compendium.

Likely causes:

The owned item was duplicated from a world item rather than dragged directly from the compendium, so Fabricate cannot link it back to the recipe’s linked item.
The owned item is a very old copy with no link to its original compendium entry.
Fabricate is out of date. Recent versions recognise the compendium link recorded by both Foundry v11 and Foundry v12 and later, but older versions may only recognise the v11 link.

Step-by-step checks:

Open the Crafting Admin panel, find the recipe, open the editor, and check the Linked Recipe Item field. Note which compendium item it points to.
On the actor’s sheet, confirm the owned copy of that recipe item (and the required components) came from the same compendium entry. The most reliable way to be sure is to delete the owned copy and drag a fresh one directly from the compendium browser onto the actor’s sheet.
Make sure Fabricate is up to date. Recent versions recognise copies made under both Foundry v11 and Foundry v12 and later.
Reload the Foundry page (F5) and re-open the crafting app. Craftability is re-evaluated each time, so a reload is enough. No data migration is required.

Expected behaviour after the fix: A player who owns an actor copy of a compendium item will have that item recognised by Fabricate’s recipe matching, whether the copy was made under Foundry v11 or Foundry v12 and later. The “Craftable only” filter will include the recipe once all required items are matched.

See also: Visibility & Knowledge covers how owned compendium copies are matched on Foundry v12 and later. Recipes covers linking recipe items in the editor.

Repairing Item Data

Fabricate can reconcile the items behind your crafting components and recipe items so copies in players’ inventories match reliably. This is the Repair Item Data maintenance action.

Where to find it: Open Foundry’s Game Settings, choose Configure Settings, and open the Fabricate module settings (the same panel as the theme selector). Click Repair Item Data and confirm. The action is available to GMs only.

It does two jobs, because both are projections of the same thing — the source item behind a component or recipe item.

What it does — item identity:

It scans your world items, your unlocked compendiums, and every actor’s inventory.
It tags each component and each recipe item (book or scroll) source with a durable identity link, so future copies always resolve to the right one.
It clears misleading duplicate-source metadata that a copied item inherited from the item it was copied from.
A copy renamed from a compendium entry that a component still claims is tagged as that component if it is not registered itself, because Repair Item Data does not tell a renamed copy from the entry; register it as its own component first if that is not what you want.
It re-points an owned copy that a duplicate mislabelled, but only when the copy’s name clearly identifies a single book or scroll.
Locked (system and module) compendiums are skipped by this scan, because Fabricate cannot write to them.
It never teaches or removes a recipe.

What it does — descriptions:

It rewrites the stored description of every component and recipe item from that entry’s own source item.
Content links in the source description are resolved, so @UUID[...] renders as the linked item’s name instead of raw link text.
Inline @Embed[...] references to other Items or text Journal pages are expanded to plain-text descriptions, without rendering interactive embedded HTML.
To avoid recursion and oversized descriptions, embedded content is depth- and size-limited; an unavailable embed keeps its original directive, while cyclic or oversized resolved embeds fall back to a document name.
Unlike the identity scan above, this does reach locked system and module compendiums, because it only reads those items rather than writing to them.
Any description you edited by hand for a component or recipe item will be replaced by the source item’s text.
Tools are not affected; they carry no description.

After it runs, Fabricate reports how many items were tagged, cleaned, unlinked, and re-pointed, and separately how many descriptions were refreshed, were already current, or were skipped. When a copy’s name matched more than one book or scroll, it is left as-is and counted separately, with a note to fix it by hand. A description is skipped rather than refreshed when its source item cannot be read — the item, its compendium, or the module that provided it may have been removed — or when that source item has no description of its own. A skipped description is never emptied; the text you already had is kept.

When to run it:

When a description shows raw link text such as @UUID[Compendium...] instead of the linked item’s name, or Fabricate tells you at startup that some descriptions do.
After a game system or module ships new content, if you want components linked to its compendium items to pick up the revised descriptions.
After updating to a version of Fabricate that added durable item identity, if players hold copies that were duplicated in an older world.
When a player’s duplicated copy of a book or scroll shows the wrong title in their inventory, or auto-learned the wrong recipes when it was dropped on the actor.
When a duplicated component is confused with the item it was copied from.
After you duplicate items to author new content in a world that predates the durable identity.

What it cannot fix:

A copy that can no longer be identified. If a copy was duplicated before the fix, and its only remaining link points at a different book or scroll, Fabricate can re-point it only when its name uniquely matches one book or scroll. When the name matches more than one, or matches none, the copy is left untouched. Delete that copy and drag a fresh one from the correct source item to restore it.
A book, scroll, or component whose original details were already overwritten. In older versions, registering a duplicate of a compendium-linked item could overwrite the original entry’s own name, image, and description with the duplicate’s. Those original details are gone and cannot be reconstructed. The repair flags the affected entry so you can spot it, but you must restore its name, image, description, and linked recipes by hand, or re-import it from a backup or its compendium.
A link to a document that is no longer installed. A description is resolved once, when it is stored — not every time it is displayed. If it references an item from a module you have since disabled, the reference is dropped from the text rather than resolved, and re-enabling the module does not bring it back on its own. Run the repair again after re-enabling it.
A referenced item that was renamed later. A stored description holds the names the referenced items had when it was resolved. Renaming one of those items does not update the descriptions that quote it; run the repair to bring them back into line.

The repair scans the actors in your world’s Actors directory. It does not reach unlinked token copies that were never saved as world actors, or actors stored inside a compendium.

See also: Visibility & Knowledge covers duplicating books and scrolls as an authoring workflow. Crafting Systems covers duplicating items to author components.

Every Item I Import Updates the Same Component

Symptom: You import several different items, such as spell scrolls of the same level, and each one updates the component the first one created. You end up with one component carrying the last item’s name and image, and matching every one of those items.

Cause: The items were built from the same compendium entry and then changed into something else. Older versions treated them all as copies of that entry. Fabricate now tells a copy of an entry from something built from it by name: a copy that keeps the entry’s name is the same thing, and a differently named one is its own component, recipe item, or tool.

Fix for a component that is already merged:

Open the Crafting Admin panel and find the merged component.
Remove the merged component from every crafting system that holds it. Check what uses it first, because removing it rewrites the recipes that name it. The Systems using this component card on its entry in the Component catalogue and the bulk remove both do this.
Open the Component catalogue in the World section of the Crafting System Manager and delete the merged component’s entry there too. Removing the component from a system does not delete its entry, and the entry can only be deleted once no crafting system holds the component. If you leave it, one of the items you import adopts it and the others are left without a catalogue entry.
Import the items again, by dropping them or by using the bulk import. Each one now registers its own component and its own catalogue entry.
Re-add the component to any recipes that used the merged one.

Repair Item Data does not un-merge a component. A merged component keeps matching every item it absorbed until you delete it and import the items again.

Things to know:

A renamed copy of a compendium entry is registered as its own component and does not claim the entry. An item a player drags straight from the compendium does not match it, so hand out copies from the item you registered.
Items that share a compendium entry which can no longer be found, because the pack is missing or disabled or the entry was deleted, are registered separately as components, recipe items, and tools. The first import of each item still warns about the broken link. The split is permanent once made, so restoring the entry later does not rejoin the items. To remove an unwanted split, delete the extra component, recipe item, or tool, then restore the entry and import the item again. For a component, once the extra one is deleted, you can instead use Replace Source on the original component to link it to the item.
Editing an item’s name, image, or description refreshes only the component linked to that item.

See also: Adding Components covers importing items. Repairing Item Data covers the maintenance action for copies players already hold.

An Imported Component Has No Catalogue Entry

Symptom: A component you imported into a crafting system does not appear in the world Component catalogue, or its rules editor says its name, image, and description are the system’s own. You may also have seen the warning “The items were imported, but the world Component catalogue could not be updated. Import them again to add them to it.”

Cause: Importing an item now also registers a world component that the system holds. A component imported before that was added has none. The same is true when the catalogue could not be written during an import, which is what the warning reports.

Fix: Import the items again, by dropping them, importing the folder or pack, or using the Compendium Directory action. Each component without a catalogue entry gets one, and keeps all of its own values.

Things to know:

If the world component for that item has a different id from this system’s component, this system’s component is left without one. This is typically because another system imported the item first. Linking it would mean renumbering a component that recipes already reference. To recover, check what uses the other system’s component for that item, because removing it rewrites the recipes that name it. Then remove that component from every system that holds it, delete its entry in the catalogue, which is only possible once no system holds it, and import the item again.
In a world where several systems hold the same item, import it again first in the systems that already hold it. Importing it into a new system first gives that system a world component that the older components cannot adopt.
An item that belongs to an actor is imported but never becomes a world component.

An Item Stopped Contributing an Essence After Updating

Symptom: After updating Fabricate, one particular item no longer counts towards an essence requirement, while other copies of the same component still do. You may also have seen a standing notice saying Fabricate merged sets of essences that were the same essence in more than one crafting system.

What to expect: Fabricate now keeps one shared record per essence instead of one per crafting system, and on first load after updating it consolidated the duplicates and rewrote every reference to the records it retired. See Upgrading from a version before 1.34.0. An ordinary component is fine, because its essence values were rewritten along with everything else. The exception is an individual item carrying its own essence values, set on that item rather than on the component, which Fabricate could only rewrite on items your characters were carrying at the time. Essence values on that item that still name a retired essence count for nothing, so the item contributes less than it did, or nothing at all. Nothing resolves to the wrong essence, because a retired essence is never reused.

Likely causes:

The item is a world item in the Items directory, or lives in a compendium, or belongs to a token copy that was never saved as a world actor. None of those are reached.
The item lives in a locked compendium and refused the update. Fabricate counts how many items refused, in the notice. A refusal like this is not retried, because unlocking the pack later is not something Fabricate goes back to check.
The repair could not finish at all, which Fabricate says plainly. It keeps its record of what to change and retries on the next reload.
The essence is part of a set Fabricate refused to merge, in which case nothing changed for it and the cause is elsewhere.

Step-by-step checks:

Read the standing notice Fabricate posted on load. It is deliberately short: it names up to five of the sets it merged or refused, says how many more there were, and counts the items that refused the update. The full explanation is in the browser console, which you open with F12. It lists every set, why each refused set was refused, and the ids involved.
Open the item and set its essence values again, choosing the essence that survived the merge. Re-saving it is what replaces the retired reference.
Unlock the compendium first if the item lives in one, so that setting its values again can save.
If the notice said the repair was incomplete, reload your world once the cause is fixed. Fabricate runs the repair again on its own.
Check in-progress crafting runs. Where Fabricate could not record a merge against a character’s in-progress runs, it says so in a notice, and the browser console names the essences involved. Finishing or cancelling those runs clears it.

See also: Essences covers what the shared record holds and what each crafting system keeps for itself. Protecting Your Worlds covers how Fabricate runs and aborts an upgrade pass.

Crafting App Fails to Open

Symptom: Clicking Craft Item from the Items sidebar does nothing, or the Crafting App opens briefly then closes.

Cause:

This was caused by corrupted crafting-run history on the actor, which could make the same run appear twice in the app’s run list and prevent the list from rendering.

Fix: This is resolved in the current version, which guards against duplicate runs. Make sure Fabricate is up to date.

If you are still seeing this after updating:

The actor’s stored crafting-run history may be corrupted. Ask your GM to clear that actor’s crafting run history (this removes the run history only, not your recipes or crafting systems), then reload the page (F5) and re-open the Crafting App.

See also: Quickstart covers opening the Crafting App for the first time.

Fabricate Asks You to Reload Your Browser

Symptom: A notification appears saying Fabricate is installed at a different version than the one your browser is running, or clicking Manage Crafting Systems shows a notification blaming an earlier version of the module and the window does not open.

Cause:

Your browser can keep an out-of-date copy of Fabricate cached from before the module was last updated on the server. When that happens your browser is still running yesterday’s Fabricate, and the window you tried to open only exists in today’s version.

Fix:

Reload your browser.
If the notification comes back, reload again, this time bypassing the cache: Ctrl+Shift+R on Windows and Linux, or Cmd+Shift+R on macOS.
Try Manage Crafting Systems again.

See also: Quickstart covers the Manage Crafting Systems button.

Completed Simple Craft Still Shows as In-Progress

Symptom: After a single-step (simple) craft completes successfully or fails, the Crafting App still shows the recipe as in-progress. Reloading the page clears the stale state, but it reappears on the next craft.

Cause:

This was caused by a timing issue where the Crafting App could read the actor’s run list before the completed run had finished saving, so it kept showing the run as active.

Fix: This is resolved in the current version, which keeps the displayed run list in step with the saved state. Make sure Fabricate is up to date.

If you are still seeing this after updating:

Ask your GM to clear that actor’s crafting run history (this removes the run history only, not your recipes or crafting systems), then reload the page (F5) and re-open the Crafting App.

See also: Quickstart covers opening the Crafting App for the first time.

Dropping an Actor, Folder, or Non-Item Document onto the Items Tab Shows a Warning

Symptom: Dragging something onto the Items tab drop zone in the Crafting Admin panel produces a warning notification such as “Only Item documents can be added as crafting components” or a message that the folder contains no Item documents, and nothing is added.

Cause:

Fabricate only accepts Item documents as crafting components. When the dropped entity is an Actor, JournalEntry, Scene, or any other non-Item document type, Fabricate rejects it with a warning. Actors in particular cannot be components because they represent characters, not inventory objects.

Folder drops are a special case. Fabricate expands the folder and imports any Item documents it contains. If the folder holds no Items (for example, it contains only Actors), a notification says so and nothing is written.

What each notification means:

Notification	Meaning
“Only Item documents can be added as crafting components. Dropped: Actor.”	You dragged a character or NPC sheet onto the drop zone. Use an Item from the sidebar or a compendium instead.
Folder “{name}” contains no Item documents.	The folder you dropped holds no Items. It may contain Actors, JournalEntries, or other document types.
“Drop an Item document from sidebar or compendium.”	The drag data could not be resolved to any UUID. This can happen when dragging something that does not emit standard Foundry drag data.
“Fabricate could not finish importing that drop, so some items may not have been added. Details are in the console (F12).”	A compendium or folder import failed partway through. Some items may not have been added. Check the console (F12) for the details, then drop again.

Step-by-step checks:

Confirm the drag source is an Item document (check the Items sidebar or open an items compendium). Fabricate does not accept Actors, Journal Entries, Scenes, Roll Tables, or Macros as components.
If you want to import everything in a folder, make sure the folder contains Item documents. Open the folder in the sidebar and check the document icons. Item documents show the items bag icon, not the actor or journal icon.
If you dropped a compendium pack header and received no items, verify the compendium type. Only Items compendiums contain importable components. Actor or Journal Entry compendiums are silently filtered.

See also: Crafting Systems covers adding components via drag-and-drop.

Dropping Items onto the Recipe Manager or Crafting App Does Nothing

Symptom: Dragging an item from the sidebar or a compendium and dropping it onto a Fabricate drop zone (such as the Items tab in the Recipe Manager) produces no result. The item is not added, no error or notification appears from Fabricate, and in some cases Foundry displays its own “Drop an Item document from sidebar or compendium.” message.

Cause:

In some Foundry versions and environments, Fabricate could not read the drag-and-drop data at the moment of the drop, so it silently ignored the dropped item. Control then returned to Foundry, which produced the generic error message.

On the Component Rules page, an earlier version accepted drops only on the drop zone at the top of the page. A drop anywhere else on the page was silently ignored. Now the whole components list accepts drops, including the empty “No components yet” area. The toolbar above the list and the page controls below it still do not. If a drop on the list still does nothing, make sure a crafting system is selected; with none selected the page ignores drops.

Fix: This is resolved in the current version, which reads the drag data more robustly across Foundry versions. Make sure Fabricate is up to date.

If you are still seeing silent drop failures after updating:

Confirm the drag source is a world item or compendium item. Fabricate drop zones only accept Item documents. Other document types (Actors, Journal Entries, and so on) are rejected.
If you are dragging from a compendium, confirm the compendium is not locked or from a module that restricts access.
Make sure Fabricate is updated to the latest version, which includes the more robust drag-data handling.

See also: Crafting Systems explains adding components via drag-and-drop.

A Tab Added by Another Module Will Not Display

Symptom: The Fabricate window shows a tab that another module added, and choosing it displays This section could not be displayed instead of that module’s content.

Cause:

Another installed module can add its own tabs to the Fabricate window. Fabricate supplies the tab and the space beneath it, and the other module draws everything inside that space. When that module fails while drawing its content, Fabricate shows the message in place of the panel rather than leaving a blank or half-drawn section. The message names the section that failed.

Fix:

Close the Fabricate window, open it again, and choose the tab again. Fabricate tries the section afresh on every new window, which is enough when the failure was a one-off. Bringing an already-open window back to the front does not retry it.
If the message comes back every time, report it to the author of the module that added the tab rather than to Fabricate, and quote the section name the message gives.
Disabling that module removes its tabs from the Fabricate window altogether. Fabricate puts nothing in their place.

Fabricate’s own tabs keep working throughout. The message covers the whole section rather than one tab of it, so every tab belonging to that section shows it until the section is retried.

See also: Downtime Preview covers installed companion modules that replace the GM downtime preview.

Environments Will Not Save After a Realm Was Deleted

Symptom: After deleting a gathering realm, every gathering environment save fails with an error saying the environment references an unknown realm. Environments you never edited fail too, so no environment in the world can be saved.

Cause:

Fabricate 1.9.6 and earlier removed the realm from the world realm library but left its id on every environment that listed it. Environments are stored as one world list, and a single id that names no realm made the whole list invalid, so every environment save was rejected rather than only the saves of environments that cited the deleted realm.

Fix: Update to 1.9.7 or later. The next successful environment save removes the stale realm ids from every environment carrying one, and logs once what it removed. That repair is not limited to editing an environment in the Manager: any write that persists environments does it, including the ordinary play writes that deplete, restock or respawn a resource node or change an environment’s conditions, so a world usually repairs itself without a GM touching anything. An environment left with no realm ids is no longer restricted to a realm; it is not disabled or deleted.

From 1.9.7 on, deleting a realm removes it from the realm membership of every environment that listed it as part of the delete, so the problem cannot recur. A party whose current-realm override named the deleted realm still shows it as Unknown realm; clear that override from the party card.

See also: Gathering Realms & Travel covers realm deletion and what it does to referencing environments.

Importing a System With Realm-Gated Environments Fails

Symptom: Importing a crafting system whose gathering environments are restricted to realms fails with an error saying an environment references an unknown realm. The same bundle imports cleanly back into the world it was exported from.

Cause:

Fabricate 1.9.6 and earlier wrote the imported environments before the realms those environments name. Environments are checked against the world realm library as they are written, so the check ran while the realms were still waiting to arrive and rejected the whole import.

Fix: Update to 1.9.7 or later, which brings the realm library in before the environments that name it, and import the bundle again. Realms the destination world already has keep their own definitions; only realms it does not have are added.

See also: Import & Export covers what a system bundle carries.

Before filing an issue

If the steps above do not resolve your problem, work through this checklist before opening a bug report:

Is the Fabricate module enabled in the world? (Setup > Add-on Modules > Fabricate should be checked.)
Is the crafting system saved without errors? Open the Crafting Admin panel and check for red validation warnings.
Are components properly linked? Each component should link to an existing world or compendium item. Open the component in the editor and confirm its linked item is still present.
Does the recipe pass validation? Open the recipe in the editor and click Save. Check for validation error messages.
Is the correct actor selected in the crafting app? The crafting app uses the selected actor for ingredient checks and result delivery.
Are component source actors configured? If ingredients should come from multiple actors, make sure they are all selected in the crafting app.
Try refreshing the browser (F5) and re-opening the crafting app. Some state is cached and a refresh clears it.