What would you like to see?
Add a first-class way to create custom furniture variants from existing native furniture, for example a FurnitureCreator.CloneFrom(...) builder path.
The API should let a mod safely customize an isolated clone of the donor furniture's visual hierarchy and materials without mutating the native prefab or shared material assets. S1API should then use the customized visual consistently for the placed object, placement ghost, stored item, and generated icon.
A possible shape could be:
var couch = FurnitureCreator.CloneFrom("couch-id")
.WithBasicInfo("my-mod:blue-couch", "Blue Couch", "A blue couch.")
.ConfigureModel(model => ApplyBlueMaterials(model))
.WithPricing(250f)
.WithGeneratedIcon()
.Build();The exact API shape is open, but the customization callback or model accessor should only expose a mod-owned clone.
Why would this help?
A common furniture-mod use case is reusing Schedule One's existing couch, chair, table, or decoration models with different materials. S1API 3.1.12 supports composing furniture from a supplied GameObject, but it does not currently provide a public path for safely extracting and customizing a native furniture model.
BuildableItemCreator.CloneFrom(...) copies the native buildable definition and its BuiltItem reference. It does not expose a safe placed/stored model replacement path, and WithGhostVisual(...) only customizes the placement ghost. Mods therefore have to inspect game types directly, locate the correct visual hierarchy, clone every shared material that will be changed, and reconstruct the remaining furniture representations themselves.
A dedicated API would make native furniture recolors and visual variants straightforward while preventing accidental changes to every object that shares the donor prefab or materials.
Extra Context
This is a follow-up to #232 and the furniture API released in S1API 3.1.12.
Suggested behavioral requirements:
- Preserve the donor's native grid or surface placement configuration by default, including its footprint and supported surfaces.
- Clone the donor's visual hierarchy and any materials a mod changes; never mutate shared native assets.
- Apply the customized visual to placed, ghost, stored-item, and generated-icon representations.
- Require a new stable item ID and retain the native save/load and multiplayer registration behavior used by
FurnitureCreator.
- Keep this scoped to presentation-oriented furniture variants. Cloning gameplay-specific machines or stations would require separate runtime behavior support.
What would you like to see?
Add a first-class way to create custom furniture variants from existing native furniture, for example a
FurnitureCreator.CloneFrom(...)builder path.The API should let a mod safely customize an isolated clone of the donor furniture's visual hierarchy and materials without mutating the native prefab or shared material assets. S1API should then use the customized visual consistently for the placed object, placement ghost, stored item, and generated icon.
A possible shape could be:
The exact API shape is open, but the customization callback or model accessor should only expose a mod-owned clone.
Why would this help?
A common furniture-mod use case is reusing Schedule One's existing couch, chair, table, or decoration models with different materials. S1API 3.1.12 supports composing furniture from a supplied
GameObject, but it does not currently provide a public path for safely extracting and customizing a native furniture model.BuildableItemCreator.CloneFrom(...)copies the native buildable definition and itsBuiltItemreference. It does not expose a safe placed/stored model replacement path, andWithGhostVisual(...)only customizes the placement ghost. Mods therefore have to inspect game types directly, locate the correct visual hierarchy, clone every shared material that will be changed, and reconstruct the remaining furniture representations themselves.A dedicated API would make native furniture recolors and visual variants straightforward while preventing accidental changes to every object that shares the donor prefab or materials.
Extra Context
This is a follow-up to #232 and the furniture API released in S1API 3.1.12.
Suggested behavioral requirements:
FurnitureCreator.