You are viewing a potentially older version of this package. View all versions.
PartGhost-FATECapes-0.1.13 icon

FATECapes

PartGhost's cape physics, standalone: capes, cloaks and wings get a three-link rig and swing with momentum instead of staying rigid. Cosmetic only, with an on/off setting.

Date uploaded a day ago
Version 0.1.13
Download link PartGhost-FATECapes-0.1.13.zip
Downloads 5
Dependency string PartGhost-FATECapes-0.1.13

This mod requires the following mods to function

BepInEx-BepInExPack-5.4.2305 icon
BepInEx-BepInExPack

BepInEx pack for Mono Unity games. Preconfigured and ready to use.

Preferred version: 5.4.2305

README

FATE Capes

Capes, cloaks and wings that move with you. PartGhost's cape rig gives the game's back items a short chain of bones so they swing, trail and settle instead of staying rigid.

Cape physics by PartGhost, released on its own so it can be installed without the co-op suite.

What it does

  • Any flowing back item gets a rig. When the game builds your appearance, the cape, cloak or wing mesh is copied and given a three-link bone chain driven from the spine.
  • It moves like cloth. Each link carries momentum with drag, stiffness and damping, so a turn swings the hem out and walking makes it trail behind you. A jump or teleport resets it instead of snapping.
  • Rigid items are left alone. Quivers, backpacks, shields and the two-handed weapons that sit on the back stay exactly as the game draws them.
  • Nothing is baked. The original mesh asset is never modified: each back item's mesh is copied once per model and the copy is rigged, so other characters and the inventory preview keep the stock mesh.
  • Shared models share a rig. The copy is cached per mesh, so party members and NPCs wearing the same back item cost nothing extra.

Config

BepInEx/config/local.fatecoop.capes.cfg

Section Key Default Meaning
General Enabled true Cape physics on flowing back items. false leaves every back item rigid, the way the game ships it.

Changing it takes effect immediately: the current appearance is rebuilt with the rig added or removed.

Install

  1. Install BepInEx 5 Windows x64 (the FATE BepInExPack uses 5.4.23.5).
  2. Extract the archive and merge its BepInEx folder beside FateReawakened.exe. The plugin belongs at BepInEx/plugins/FateCoop.Capes/FateCoop.Capes.dll.
  3. Load a character and equip a cape, cloak or wings.

Notes

  • It keeps PartGhost's plugin GUID local.fatecoop.capes and config path, so do not install it beside the co-op suite, which ships the same plugin — BepInEx would load only one of them.
  • The co-op build's automated test command (test-back) and its capeBend telemetry are not part of this release.
  • Cosmetic only: it changes how back items are drawn, not their stats, saves or inventory layout.

Removal

Uninstall with the game closed and remove only BepInEx/plugins/FateCoop.Capes and, if you want your setting gone, BepInEx/config/local.fatecoop.capes.cfg. No game save is touched.

CHANGELOG

0.1.13

  • Back slots are rigged again, whatever their mesh is called. A session log showed the player's back renderer (.../SKM_Player_Fate4_Complete/backshield01.MDL) drawing a mesh called brownsolid.MDL with 23 bones - a plain cape whose mesh name says nothing about capes - and no rig was ever built, because the name match only knows cape, cloak and mantle and the old path match was dropped in 0.1.8. The slot is recognised by its own object name now: every character's back renderer is backshield01, so a cape keeps its physics no matter what the item's mesh is called. This is how 0.1.7 found it.
  • The slot no longer waits for SetBack. The same log showed SetBack never being called during play, so the remembered-item list stayed empty and the 0.1.11 back-slot pass had nothing to work on. A slot the game has not named is rigged anyway; only a known rigid item, or a mesh that is a quiver, pack, wing or shield, is left alone.
  • One line per back renderer now says which way it went: ... backshield01.MDL -> rigid item, no rig or -> rigged bones=26 ....

0.1.12

  • A cape change now always ends with a live rig. The attached rig is checked on every scan, not just when its mesh looks different: it counts only while its mesh is on show, its three links are still the tail of the renderer's bone array, and the chain still hangs from the spine bone it was built on. Anything else - a switched-in cape, a rebuilt bone array, a destroyed chain - is rigged again from what the renderer now shows.
  • The respawned mesh is rigged from the item, not its name. The back slot's remembered item decides whether the slot flows, so a switched-in cape is rigged even when its mesh name is not one of the recognised words. Rigid items still stay rigid.
  • Taking a rig off no longer touches the game's own bone array. Only the three links the rig added are trimmed, instead of writing the whole recorded array back over whatever the game has assigned since, and the game's mesh is only restored while the mod's copy is the one on show.
  • Cached rigs are keyed by spine bone as well as mesh. The same cape on a skeleton that orders its bones differently would previously hang its chain off a cached index, which reads as a cape that does not move.
  • Destroyed characters are dropped from the back-slot list, so a long session can no longer fill it with dead entries and stop noticing new ones.

0.1.11

  • The back slot is now followed by identity, not by name. The game's back renderer is called backshield01.MDL no matter what is worn in it, and the old filter dropped anything whose path said "shield" - which was every cape. Each character the game dresses is remembered from SetBack, and its back renderer is checked directly: a cape change swaps the mesh under the same object, and that is now noticed within a couple of seconds.
  • The shield test is about the mesh only, so a back item that is genuinely a shield stays rigid and a cape in the same slot does not.
  • The log says which way each back slot went: back:Item_X -> kept, -> rigged bones=10 mesh=cape01 or -> rigid item.

0.1.10

  • The mod now reports into LogOutput.log. Its lines went through Unity's log, which is switched off in BepInEx.cfg (UnityLogListening = false), so every diagnostic it printed was invisible. They go through BepInEx now: one line per cape renderer when its state changes, the scene dump, and every rig it builds.
  • A rig can no longer stack on top of an earlier one. If a renderer arrives with links from a previous rig still in its bone array, they are dropped before the new rig is built, instead of the array growing again and the cape being skinned against bones nothing drives.
  • Detaching only hands the game's mesh back when the real mesh was recorded, so a rig that never finished building cannot blank the renderer.

0.1.9

  • Changing cape keeps the physics. The game keeps one renderer per category and swaps its mesh in place, so the rig from the old cape was left attached to the new one: it held a mesh it was never built for and the new cape stayed rigid, looking like the mod had reset. A rig now only counts while its own mesh is the one on show, and anything else is rigged afresh within a scan.
  • Detaching a rig hands the game's own mesh back instead of leaving the readable copy with three extra bones behind it.

0.1.8

  • Cloaks and capes only. Matching required the word back, cape, cloak, wing, quiver, pack or mantle, so backshield01.MDL was rigged along with real cloaks and a shield on the back bent when it should stay rigid. It now matches cape, cloak and mantle, and skips anything named a shield, which is how PartGhost classifies these items.

0.1.7

  • Distance no longer gates the rig. 0.1.6 matched within six metres of the camera, which sits behind the character, so the player own back item was never in range. Name matching now covers the whole scene; distance only shortens the dump.
  • Failed rigs report the bone names. A mesh that matches but cannot be rigged now logs its bone count and the first six bone names, which says whether the skeleton simply has no spine bone.
  • Added mantle to the name keywords.

0.1.6

  • The scene dump is repeated per scene. 0.1.5 spent its one dump in Scene_Startup, which has a single skinned mesh, so the town and dungeon were never listed. Each scene now dumps once, within thirty metres of the camera, up to eighty meshes.
  • A heartbeat every ten scans reports the scene and how many skinned meshes exist, so a scene that is scanned but empty is distinguishable from a watcher that stopped.
  • The rig attempt still only matches back, cape, cloak, wing, quiver or pack within six metres.

0.1.5

  • No player lookup. Two sessions logged the watcher starting and nothing else, so Player.PlayerChar was never dependable; the scan now uses the camera as its reference point and no longer needs the player object.
  • A heartbeat every second scan reports the scene and the number of skinned meshes, so a watcher that stops running is visible instead of silent.
  • The watcher is remade on every scene load, so the game destroying objects at startup cannot leave the mod inert.
  • The first dump lists every skinned mesh within eight metres of the camera with its path, mesh name, bone count and visibility.

0.1.4

  • The rig now targets the drawn mesh, not the character-creation component. A 0.1.3 session proved CharacterCustomizationDefaults is not present in the game scene at all, so every earlier entry point was unreachable during play.
  • Every skinned mesh within four metres of the player is scanned; one whose object path or mesh name contains back, cape, cloak, wing, quiver or pack is rigged.
  • The first scan dumps the scene name, the counts of the creation components, and up to forty nearby skinned meshes with their paths, mesh names, bone counts and visibility.

0.1.3

  • The back slot is scanned in the whole scene instead of being looked up under the player. A 0.1.2 session loaded the watcher but never found a back mesh, so the component was not where the hierarchy walk expected it. Every customization in the scene is now scanned once a second and rigged from the mesh it shows.
  • One-time scene dump. On the first scan the log lists every back slot it finds, its mesh name, whether it is shown, its object path, and every skinned mesh under the player, so a slot that stays rigid says why.

0.1.2

  • Capes now rig from the back renderer, not only from the character-appearance path. A test session showed the plugin loading but no cape, because the game did not call the patched appearance setter during normal play. A watcher now notices when the back slot shows a mesh and rigs it, whether that came from loading a save, equipping, or the creator.
  • The log now names the back mesh and the key it was rigged with, so a slot that stays rigid is visible in LogOutput.log instead of silent.

0.1.1

  • The log says what the hook did: the mesh name and the back item when a cape is rigged, or that a mesh has no spine bone or no vertices when it is skipped.
  • A mesh that cannot be rigged no longer throws out of the appearance rebuild. The error is logged and the rest of the appearance still applies.
  • No change to the rig or its constants.

0.1.0

First standalone release of PartGhost's cape physics, separated from the FATE Co-Op suite.

  • The three-link cape chain, the eight rig constants and the mesh copy are unchanged from the suite: capes, cloaks and wings swing with momentum, spring back, and reset on a jump or teleport.
  • Quivers, backpacks, shields and two-handed weapons on the back stay rigid, as in the suite.
  • The co-op core dependency is gone, so the plugin loads on its own.
  • Added one setting, General / Enabled, which rebuilds the current appearance with the rig added or removed. The suite had no way to turn it off.
  • Kept PartGhost's plugin GUID local.fatecoop.capes and config file local.fatecoop.capes.cfg.
  • Dropped the co-op suite's test channel (test-back and its capeBend status field), which only existed for automated runs.