Replies: 4 comments 5 replies
-
Same. I reported this a few days back and was inexplicably told it was an "upstream issue" and that I should report it on the A1111 Github page, which doesn't make a lick of sense given the issue is a Forge interpretation issue as you rightly point out, not an A1111 one. |
Beta Was this translation helpful? Give feedback.
-
Use symbolic links. Both my installations (A1111 and Forge) have their "models" folder linked to same folder on another drive. |
Beta Was this translation helpful? Give feedback.
-
I store models in a common folder, share to other UI I have these in webui-user.bat for Forge
hope this help someone |
Beta Was this translation helpful? Give feedback.
-
I create symbolic links (symlinks). I have a main folder called "Models" (I got the structure from the Stability Matrix), and inside it, I create symlinks for some folders that different UIs use with different names (e.g., StableDiffusion -> checkpoints or Lora -> Loras). Then, in the web UI folders, I just create a symlink to my main "Models" folder, usually naming it "models." And I create the symlinks using a simple program I made to make the process easier. |
Beta Was this translation helpful? Give feedback.
-
I'm encountering a challenge with organizing my checkpoints into folders for use with Forge. The issue arises because Forge only automatically recognizes folders that are in its installation directory. However, when I attempt to use checkpoints stored in a different folder by employing the command --ckpt-dir E:/models/, Forge does detect the checkpoints. Unfortunately, it does not maintain the organization of these checkpoints in the same folder structure as they are stored on my system.
To elaborate, my checkpoints are meticulously organized in various subfolders under E:/models/ to keep them systematically arranged. This organization is crucial for my workflow as it allows me to manage a large number of checkpoints efficiently. Each folder represents a different model or a specific version of a model, making it easier for me to navigate through them.
When I direct Forge to this external directory using the --ckpt-dir command, it successfully accesses the checkpoints, indicating that the command itself is functioning as intended. However, Forge seems to disregard the folder hierarchy within E:/models/. Instead of presenting the checkpoints in an organized manner that reflects their original folder structure, Forge treats all checkpoints as if they were in the same directory level. This flattening of the folder structure makes it challenging to locate specific checkpoints quickly, especially when dealing with a large assortment that I have categorized for ease of use.
Ideally, I'm looking for a solution that allows Forge to recognize and respect the folder organization of the checkpoints when specified through the --ckpt-dir command or any other method. Maintaining the original folder structure within Forge would significantly enhance my ability to manage and utilize the checkpoints efficiently. If there's a way to configure Forge or a workaround to achieve this level of organization, I would greatly appreciate guidance on how to implement it.
Beta Was this translation helpful? Give feedback.
All reactions