Locusta from Fate Grand Order
For this I have to warn, the proportions for the second ascension feel kind of odd. It looks like she is two dwarves disguising as a normal person. But eh, third ascension works fine.
2nd ascension: short hair, multicolored hair, green hair, purple hair, purple eyes, sharp teeth, pointy hat, hood, hood up, cloak, long skirt, feathers, boots
3rd ascension: short hair, multicolored hair, green hair, purple hair, purple eyes, sharp teeth, hat, feater-trimmed cape, detached sleeves, jewelry, Thighhighs, feathers, CRISS-CROSS HALTER
Description
FAQ
Comments (11)
Np6 locusta, Np1 Draco
I hate this game so much.
Use more distingushed file names please. Simple filenames like "locusta.safetensors" will have a lot of naming conflicts if others do the same. Renaming locally invalidates existing prompts from samples and others. Lora names should be globally unique, so using "<title>_<character>_<creator>_v<version>.safetensors" is a safe was to ensure that
That is not correct at all, Renaming locally does not invalidate existing prompts or samples since the lora is added to the prompt acording to the lora metadata, NOT the file name.
For example, if I rename "titoria.safetensors" to "artoria_lancer_fate_grand_order_illustrious.safetensors" on my folder, when I search for "artoria" or "lancer" on the lora tab on the ui, "artoria_lancer_fate_grand_order_illustrious" will be displayed on the list, but when I click on the lora to add it, the name displayed on the prompt will still be "<lora:titoria:1> " it won't be "<lora:artoria_lancer_fate_grand_order_illustrious>".
The name in the prompt doesn't change if you change the name of the file. If that was the case it would cause HUGE problems to absolutely everyone. Would be a nightmare XD
Changing the safetensors name of the file to your liking will never affect the prompt or carriying from samples or cause any sort of conflict with other lora, since the lora name displayed on the prompt will always be the same, the one embedded in the metadata not the name of the file that can be whatever you desire to find it more easily on your computer or the ui.
First off, this is completely wrong. Just tested it myself right now. Maybe you should use UI for generation mor eoften. i.e. I had to rename one of this LoRAs to from "locusta.safetensors" to "locusta-neclordx.safetensors" and when I click it the prompt gets added as " <lora:locusta-neclordx:1>", not " "<lora:locusta:1>".
But all the prompts from the samples have "<lora:locusta:1>" on their image metadata. When I copy these (or load them in PNG Info in Automatic1111, it will read it as is in the image meta data which is " <lora:locusta:1>". When I run this, I will get a different image, due to an older LoRA named "locusta.safetensors" I had previously.
All of this causes a fucking mess when one try to reproduce either an image from here or one older one had.
You probably haven't reloaded your UI or the lora test is saved in your activation text section, but then it should add <lora:locusta-neclordx:1><lora:locusta:1>, trigger1, trigger2.
I can guarantee you its not working the way you think, try it out. Automatic1111 v1.10.1.
Loras are loaded by filename and triggered by keyword, unless its an style LoRA. I had nightmares trying to get some prompts to work, because some embeddings were missing or wrong lora with that name was there, which are also file name sensitive. Don't believe me? Here some more samples of auto renamed LoRAs by browser which I didn't even notice at that time:
<lora:lactationIllustrious (2):0.8> lactation, projectile lactation
<lora:milking_machinePony (2):0.8> milking machine
All of them by just clicking on the LoRa itself.
But if I take an image on Civitai that was generated using this Loras it will have
<lora:lactationIllustrious:0.8> lactation, projectile lactation
<lora:milking_machinePony:0.8> milking machine
in their image meta data. If you run this, you will get completely different image, because it uses that other LoRA with that name. And that's the whole core of that issue with non-unique/amigious names.
And you know what's even worse? When you have two LoRAs with the same filename in different folders, then you have a completely unpredictable/undefined behavior. I really suggest you to use the UI more often. And its not just with your LoRAs, there are 2 or 3 other people who do the same, sometimes the names aren't even unique accross a title, cause you get something like "mordred.safetensors" and 10 titles using the same name
@TScitai I don't know how did you set your ui, but you are the first person ever that mentioned this as an issue. And, I'm being honest here, I never thought it could be even be an issue because if renaming the file altered the lora name on the prompt, no one could ever use examples easily because you wouldn't be able to change the file name without risking the lora stop working and should be something you had to worry about.
And everyone uses prompts from images easily just by copiying them.
You dont need to believe me, just look:
https://imgur.com/a/tHnz6sD.png
I renamed "kama" file to "kama neclord" and when I click on it, on the prompt it authomatically adds it as "kama"
I'm at lost here, truly. I don't even know what to tell you. I didn't even knew it was possible what you are mentioning without altering the metadata of the file.
It surely has been probably hard for you if you if renaming your files affect your prompts. Never had that issue. I rename often files I download and never affected it for the prompting, because when I select them the original name of the metadata is still there.
When I by error trained a lora with the wrong name, I had to go and edit the safetensors file metadata with a program to fix it because simply changing the name of the file wouldn't change the lora name on the prompt.
@neclordx No, no no no. That's not how it works. Here the evidence
https://civitai.com/images/72019428
I took this exact LoRa here, renamed it to "locusta-neclordx.safetensors" started my automatic1111, copied the prompt from here and got the second image, which is nothign related to the character because THE LORA WAS NOT LOADED because of file misatch. Prmopt contains <lora:locusta:1> but the file name on the file system is locusta-neclordx.safetensors, hence its NOT FOUND and its weights not loaded.
Look at the image metadata. It's the exact same prompt as from the first sample of the Illustrious version of this LoRA.
The first of the two images uses <lora:locusta-neclordx:1> to load the LoRA and works, although its different from the first image in the LoRAs sample, but the prompt is exactly the same (probably the model loaded is different as these don't get automatically applied when applying an LoRA)
The situation gets ONLY WORSE, when I have a locusta.safetensors from CreatorA and i.e. locusta-neclordx.safetensors (because of being forced to rename), then using the prompt from this image. This ends up in a complete mess, because then the LoRA of CreatorA is loaded but with the prompt from an image generated with your LoRA and the results then get COMPLETELY different.
And then trying to find out which option is different, which embedding or LoRA is missing is a pure nightmare.
The problem with a lot of creators is, they don't generate images themselves, at BEST they test their own LoRA in isolation and that's it. You don't work daily on generating images, you creators just mass produce/train them. But the issue with the namings are the power users which get hit most by this issues.
Also dunno what UI you are using, but automatic1111, which is basically what 90% of people use, always uses the <lora:filename-without-extensions:1> format. When file is renamed so the load instruction needs to be changed too. This has always been the case with Automatic1111, ever since I started using it mid 2023 when 1.4 or 1.5 was the most recent version.
Ambigious LoRA (and embeddings) file names is one of the biggest issues possible. To a lower degree its also with checkpoints, but these are generally unique (Havent seen one with naming conflict though)
@TScitai I...really wish I could help you, but each new message leaves me more speechless than the previous one.
Spending more time generating? I do nothig but generating. According to my profile there are 5700 images I generated (and that's only the ones I posted on civitai), and each and every single one of them were created individually, not batches, and each one of them have concrete particular prompts, with setting, position and even face expresions, nothing left at random.
I've been downloading lora from other people for more than a year an a half and first thing I always do is change the filename to something I can remember and I never faced a problem like the one you are mentioning.
I'm afraid I cant help you more here because as much as I want to do it I cant quite understand a problem I have not ever faced.
I do have one advice/tip though if you are willing to listening about the part about "everyone using auto111" which is...bold to say the least.
First, believe it or not, more people uses onsite generator or another generator services than people generating locally.
But well it doesn't matter, anyway, the important thing is you using a111. I used to use auto111 as well, like "everyone" did...until like one year ago, when "everyone" stopped using a111 and jumped into Forge. And in this year since then even Forge became obsolete and its been like a good 6 months if not more since "everyone" jumped to ReForge.
Forge was basically a111, the exact same UI, but faster, eats less resources, and you dont need to set any commands on the starter since it basically autosets itself to match your computer. Its so good and optimized that it allowed people with toasters to do XL generations with ease.
And ReForge is basically an upgrade of reforge. You are using an extremely outdated ui that has already "new versions of new versions".
Of course, you don't have to feel obligued to change, if you are happy with it you can continue using it, but I would suggest/recommend to jump to ReForge. Or Forge at the very least.
@neclordx Just look at the uploaded two images. The first one is the one which uses the new LoRA name and triggers it properly. The second image is generated with the original LoRA name and its not triggering the LoRA.
This is because Filename is used in the <lora:xyz:weight> instruction. These instructions get removed from the final prompt, its only there to tell the UI/Generator which LoRA to load.
And like I said initally, its easy to fix, when you as creator give them unique name which are unique on the plplatform and "<title>_<character>_<creator>_v<version>.safetensors" is a very easy way to guarantee this uniqueness.
the <creator> ensures its unique per LoRA content creator, the title ensures its unique among different titles (i.e. one creator creating a LoRA of "Mordred" from two different franchises) and the version ensures that the file name is unique even when a newer/improved version of the LoRA is made.
This is NOT something the users can fix, due to the provided arguments, because A user can't change all previously generated and embedded fronts in images.
Another examples of this are, lets asume I generate the image today and in 3 weeks I download the LoRA with same name in different directory or I overwrite the existing LoRA when downloading it. When I go back using the old image, load it in PNGInfo to extract the prompt and regenerate it (i.e. because I want a higher resolution, or adjustment of the prompt or just to use that as a starting point), I won't get the same result.
There is also no technical way to solve this issue. Using hashes instead of LoRA name would in theory but not be applicable in practice, because in Order to know the Hash of every LoRA one would have to calculate all hashes, with a lot of LoRAs that would mean hours of start up time (which btw is the reason I am not having Civitai extension active anymore. It would calculate the hashes of all new models and LoRAs on startup to fetch the information, which at some poind would had taken 3 days to do so - I wrote my own tool which did that file by file instead of hashing all files and then fetching and it took me over 3 days to index them all)
As for the UI, I think you overerstimate how many people use on-site generation. This is something casuals do, to quickly toy around it or people who lack the hardware. Anyone whos serious about it, uses it localls (which basically what I called "power users" earlier) and its still the UI thats easiest to use and where most extensions work for.
I tried SD.next some time ago (around August?) for its "so called performance" advantage and surely while it was a little bit faster, its way more complicated to use, way too overloaded with options. Stuff thats super easy to find in automatic1111, its super annoying and complicated in SDnext, i.e. "High Res Fix"/"Upscaling".
On top of that it has something different about generation, i.e. its pretty hard to reproduce existing prompts on it. Using the exact same settings (sampler, model, cfg, steps, rng source, etc.) from an existing image generates a completely different image.
@TScitai And like I said initally, its easy to fix, when you as creator give them unique name which are unique on the plplatform and "<title>_<character>_<creator>_v<version>.safetensors" is a very easy way to guarantee this uniqueness.
Let's say I start using that short of naming. Are you going to go around and ask to every lora creator to change to an "standarized" file naming? Because if you think my naming is simple you should see the stuff around there, there are lot of people that names their files with codes or have added the epoch number and things like that.
Do you consider that a "fix"? You still would face the same issue whenever you found a lora not named "properly".
Wouldn't be more effecient and easy to just find the way of not depending on how other people names their files?
As I explained I change the filenames and never affects because when I add to the prompt the it sets authomatically the metadata name in the file, not the file name so I have never have to worry about they matching. I don't know how it works since it was set like that by default (it works like this in reforge but I have gens from the times I used a1111 and worked like that as well), but I'm really glad it works that way.
@neclordx I already do whenever I encounter double names.
@duongve13112002 is one of these. Also what really sucks about badly named LoRAs is, you have lets say 10 or 15 LoRAs of a character and want to use lets say Illustrious model to generate it. The file name often has NO indication whether it was trained on SD 1.5, SDXL, Flex, Pony, or AnimagineXL, Illustrios or NoobAI. In a lot of case you just have "charname-42.safetensors", "charname-51.safetensors" or "charname-66.safetensors" (read: epoch names, smoething the above mentioned does a lot) as file names.
How you have no fucking idea which one to pick. SD 1.5 vs SDXL based one is rather easy, since iirc automatic1111 only shows LoRAs that mathches the currently loaded model (i.e. when an SD 1.5 model is loaded only 1.5 LoRAs will be shown in the LoRA tab). But for SDXL, everything else is show, since all of them (Pony, ILL, NoobAI, AnimagineXL) are based of SDXL but the LoRAs don't really give a good result if you use a SDXL trained LoRA on Pony or Pony on ILL.
Theres an endless list other issues I could go on, like why people publish 217 MB LoRAs when other LoRA trainers can do with same Quality at 26 or 52 MB. For one LoRA or 10 or 100 the size doesn't matter. If we talk about 15000, things change. The difference then is 3.13 TB vs 0.39/0.78 TB.
Sometimes I get the feeling people here just compete who can toss in most amount of LoRA rather than selected few at high technical level (where also size matters). You know like talk with others, exchange techniques and knowledge.
I do that all the time, in Software development though. You ask some, or tell some how you do stuff, they tell you how they do. You get the best of both approaches and both increase their skill.
As for the issue, then go on. Pick an LoRA, rename the file on the file system, start your UI. The copy a prompt from Cititai made with that LoRA and paste it in. Most likely won't work. If it works while clicking for you, it may be cause your UI manages LoRAs differently, i.e. when selecting LoRA it tracks it hidden from the UI and adds the LoRA load instruction to the prompt when you generate, because the <lora:...> get removed from the prompt when the image is generate. Its only there to tell the UI (i.e. Automatic) which LoRA to load.
There is simply no way to fix that w/o the creators doing it. Its how these UIs work. For LoRAs to work you need two things: Load instruction and for non-style LoRAs one or more Trigger words. Trigger words aren't affected, because thats within the weights/training data/metadata inside the safetensors file. But the UI must know how to load a LoRA.
The <lora:xyz:0.8> doesn't affect the generation as its not part of the prompt, even if it appears so. Easy to test. Use the Prompt of a LoRA which you HAVE NOT downloaded.
Run it with <lora:xyz:0.5> and generate the image. Then remove <lora:xyz:0.5> and generate another one. Image is exactly same, because the UI removes <lora:xyz:0.5>when it runs the generation. The <lora:xyz:0.5> is only used by (some?) UIs to know which LoRA to load when the prompt is pasted or typed out in the positive prompt input box.
I know how this works, I use a lot of prompts from civitai as starting point, especially with newly downloaded models as each models has its own twists and quirks when it comes to trigger words. So a good starting point is always to pick an existing prompt, replacte the exact same image then start your own ideas by keeping the relevant trigger words responsible for certain quality or styles you were looking for.
Also if you want a more simplified explaintain of Lora file names. Imagine Internet domains would work like LoRA loading right now.
Imagine you open "google.com" and get google webseite when you are int he US, Bing when you arfe in Europe and Yandex Page opend when you are in Russia. Wouldn't make much sense right when domains wouldn't be unique. For same reason, LoRA filenames have to be unique too