Simple Item Forge Integration
Simple Enemy Forge has optional integration with Simple Item Forge (SIF), sold separately. When both packages are installed in the same project, the Enemy Forge automatically detects SIF and unlocks loot table linking on enemies. No manual configuration is required — just import both packages and the features appear.
Features Enabled by SIF
When SIF is detected, two additional fields appear on each enemy:
Loot Table Code
A string field with a dropdown populated from your SIF loot database. Select which loot table
this enemy should use for drops. Example: GOBLIN_LOOT, BOSS_DRAGON_LOOT.
The code is stored as a plain string, so it remains valid even if SIF is removed.
Loot Table Reference
A direct ScriptableObject reference to the SIF loot table asset. Drag the loot table
.asset file directly from your project. This gives your game code direct access to
the loot table object at runtime without needing to look it up by code.
Where SIF Features Appear
| Location | What Changes |
|---|---|
| Enemy Forge — Step 1 (Setup) | A “Simple Item Forge Integration” section appears, confirming SIF is detected. An ObjectField lets you assign your SIF Loot Database, which populates the loot table code dropdown in Step 3. |
| Enemy Forge — Step 3 (Enemies) | Each enemy gets a Loot Table section with two fields: a dropdown for loot table code (populated from the linked SIF database) and an ObjectField for direct loot table asset reference. |
| Generated Custom Editors | The generated Inspector editor shows loot table fields for each enemy. The code field uses
a dropdown when SIF is available; the ObjectField uses runtime Type.GetType() to
filter the picker to SIF loot data source assets, automatically adapting when SIF is
installed or uninstalled without requiring regeneration. |
Detection Lifecycle
SIF detection follows the same automatic pattern as SAF detection. An [InitializeOnLoad]
detector runs on every domain reload and uses reflection only — no hard assembly
references.
Installing SIF
Import Simple Item Forge into your project (Asset Store or .unitypackage). Unity detects new scripts and triggers compilation.
After compilation, Unity performs a domain reload. The
[InitializeOnLoad] attribute on
ItemForgeDetector causes it to run automatically. It calls
Type.GetType("SimpleItemForge.ISimpleLootDataSource, SimpleItemForge.Runtime")
to probe for SIF’s loot types.
SIF types are found. The detector adds
SIMPLE_ITEM_FORGE to
Player Settings → Scripting Define Symbols. It also populates
SIFBridge with the resolved LootDataSourceType,
ItemDataSourceType, and reflection-built delegates for GetLootTableCodes
and GetItemCodes.
The new define triggers another compilation. Editor code gated behind
SIFBridge.IsAvailable checks now activates. The loot table fields appear in
the Enemy Forge wizard and generated editors.
Removing SIF
Remove Simple Item Forge from your project. Unity detects the missing scripts and triggers compilation.
The same
[InitializeOnLoad] detector runs. This time,
Type.GetType() returns null — SIF types are no longer present.
The detector removes
SIMPLE_ITEM_FORGE from the scripting defines. It also clears
all SIFBridge properties (sets types and delegates to null).
The removed define causes another compilation. All SIF-gated editor code is excluded. The loot table sections disappear from the wizard. No compilation errors occur because the runtime fields use plain types (see below).
The SIFBridge Pattern
Simple Enemy Forge never has a hard assembly reference to Simple Item Forge. Instead, all editor code accesses SIF through a static bridge class:
| Component | Role |
|---|---|
ItemForgeDetector |
[InitializeOnLoad] class that probes for SIF types via
Type.GetType(). If found, populates SIFBridge with resolved types and
reflection-built delegates. If not found, clears everything. Also manages the
SIMPLE_ITEM_FORGE define symbol. |
SIFBridge |
Static class with properties: LootDataSourceType (System.Type),
ItemDataSourceType (System.Type), GetLootTableCodes (delegate that
returns string[] of loot table codes from a loot database SO), GetItemCodes
(delegate that returns string[] of item codes), and IsAvailable (bool).
All wizard and editor code checks SIFBridge.IsAvailable before showing loot table UI. |
This pattern means:
- No
using SimpleItemForge;statements in the main editor code - No assembly definition references to SIF assemblies
- No conditional assemblies that might fail to recompile
- Clean compilation in both directions (install and remove)
Runtime Fields
The SimpleEnemyDefinition struct always includes these loot-related fields,
regardless of whether SIF is installed:
| Field | Type | Purpose |
|---|---|---|
lootTableCode |
string |
The code identifying which loot table to use (e.g., "GOBLIN_LOOT").
Plain string — always compiles. |
lootTable |
ScriptableObject |
Direct reference to the SIF loot table asset. Stored as a generic
ScriptableObject — always compiles. |
Because both fields use plain Unity types (string and ScriptableObject),
the generated database class always compiles regardless of whether SIF is present. This is what
makes the install/remove cycle error-free.
enemy.lootTableCode
(a string) and enemy.lootTable (a ScriptableObject). If SIF is installed, you can cast
enemy.lootTable to ISimpleLootDataSource for full loot table API access.
If SIF is not installed, the string is still available for your own loot system to interpret.
Generated Database Behavior
Understanding how generated databases behave across SIF install/remove cycles:
Generated With SIF Installed
When you generate an Enemy Database while SIF is available and loot tables are assigned:
- Each enemy’s
lootTableCodeis set to the selected code string - Each enemy’s
lootTableholds a reference to the SIF loot table.assetfile - The generated custom editor shows a dropdown for code selection and an ObjectField for direct reference
After Removing SIF
- The generated database still compiles — both fields are plain Unity types
- Loot table codes are preserved — strings survive regardless of SIF status
- Loot table asset references are preserved if the
.assetfiles still exist - The custom editor hides loot table UI — the dropdown and ObjectField disappear, but the data remains in the serialized asset
- Asset references become null if the loot table
.assetfiles were removed along with SIF
Regenerating Without SIF
If you open the Enemy Forge wizard and regenerate without SIF installed:
- The wizard has no loot table UI, so no loot table codes or references can be assigned
- Generated enemies will have empty lootTableCode and null lootTable
- The previous
.assetdata is overwritten - If you want to preserve loot table data, do not regenerate after removing SIF
Troubleshooting
SIF features not appearing after import
- Check installation — Ensure Simple Item Forge is imported in the same project (not a different project or a Package Manager reference to a missing path)
- Check the define symbol — Open
Player Settings → Scripting Define Symbolsand verifySIMPLE_ITEM_FORGEis listed. If not, the detector may not have run yet. - Force a recompile — Try
Assets → Reimport Allor make a trivial edit to any script to trigger compilation and a domain reload. - Check the Console — If SIF itself has compilation errors, the detector cannot find its types. Fix any SIF errors first.
Loot table dropdown is empty
- Assign the loot database — In Enemy Forge Step 1, the SIF Integration section has an ObjectField for your loot database. Assign a generated SIF loot database asset. The dropdown in Step 3 is populated from this linked database.
- Generate the SIF loot database first — The SIF Loot Forge wizard must have been used to generate at least one loot database with loot table entries before the dropdown can be populated.
SIF features not disappearing after removal
- Check the define symbol — If
SIMPLE_ITEM_FORGEis still inScripting Define Symbolsafter deleting SIF, remove it manually and recompile. - Force a domain reload — The detector runs on domain reload. If Unity didn’t trigger one, reimport a script or restart Unity.
Compilation errors after removing SIF
This should never happen if Simple Enemy Forge is the only package using SIF. If you see errors:
- Check that
SIMPLE_ITEM_FORGEwas removed from Scripting Define Symbols - Check for other packages or custom scripts that may have hard references to SIF types
- Ensure you deleted the entire SIF package, not just parts of it (partial deletion can leave broken assembly definitions)