Jumbo collection wildcards not working if kept in jumbo folder, and directory matching not working

[Jonseed]

I use Dynamic Prompts all the time, and it is fantastic! Thank you for your great work on this.

The jumbo collection isn't working if the entire jumbo folder is put into the wildcards folder. For example, putting __jumbo/people/nationalities/all-nationalities__ in my prompt would usually get a single nationality from one of the wildcard files in all-nationalities, but now it just goes one layer deep, and puts one of the lines in all-nationalities, like __people/nationalities/europe__, for example. It's not recursively going deeper to into the wildcards. In the console it says this sort of thing:

No values found for wildcard people/nationalities/central-america
No values found for wildcard people/nationalities/african
No values found for wildcard people/nationalities/europe

Is it not finding them because it doesn't have the "jumbo/" folder at the beginning of those lines in all-nationalities? I noticed in the readme that it says full path is currently required. Most of the wildcards in the jumbo collection don't have jumbo/ at the beginning of their lines, and so won't work unless I put all the folders in the jumbo collection directly in the wildcards folder. Then I would just use __people/nationalities/all-nationalities__, and that seems to work. But it makes my wildcards folder messy to have all the subfolders from jumbo in there.

Also, directory matching like __nsp/nsp-body/**/*__ doesn't seem to be working. Now it just puts that string literally in my prompt, and the console reads:

No values found for wildcard nsp/nsp-body/**/*

2.10.4 of the WebUI extension
0.21.2 of the dynamicprompts library

[adieyal]

Thanks for pointing this out. It's due to some changes in the wildcard manager.
@akx - what do you think? should we update the wildcard manager to allow relative paths, or update the existing wildcard collections to use an absolute path?

[akx]

I'm pretty sure the old system didn't resolve wildcard references relatively either...? Or at least I can't think of a mechanism with which it would have done that.

But yeah, it would make intuitive sense for references to be implicitly relative by default and fall back to absolute lookup if that fails.

[adieyal]

It wasn't true relative resolution although it gave similar results. https://github.com/adieyal/dynamicprompts/blob/34e06bba272e82a44cfe991fa4c2ab971d74ff8d/src/dynamicprompts/wildcardmanager.py#L97

[akx]

Ah, so it actually matched any similarly named wildcard file from any directory...

I'd like to say that was a bug 😁

Either way, the immediate workaround is to qualify the reference to contain the full folder path - but I do think we'll want to implement relative lookups soon enough. I likely can't do it this weekend, unfortunately...

[adieyal]

:) it's a matter of perspective. I think that rationale was that if you wanted to target a specific file, then you would provide an absolute path. In any case, it was used to achieve relative lookups.

I'm also short on time this weekend but I'll see if I can have a look. Otherwise, I might update the collection so that it isn't broken

[tusharbhutt]

Right now, any wildcard files in a subfolder are not being read my Windows PCs

[akx]

Ugh, relative lookups turned out to be a bit hairier to implement than I first thought since we don't have an immediate reference to the collection whence a line came from... Looking into it anyway 😄

[adieyal]

Ugh, relative lookups turned out to be a bit hairier to implement than I first thought since we don't have an immediate reference to the collection whence a line came from... Looking into it anyway smile

perhaps we should implement your suggestion of a wildcard entry which can then store metadata including source collection. It would also open up the possibility for additional metadata in future, e.g. matching wildcards with negative wildcards.

[tusharbhutt]

It seems that if the wildcard file is in a subfolder, you have to use "parent/wildcard" as already noted. Wildacard manager even lists the filename as such:

The interesting thing is that if the wildcard itself references another wildcard, then that will be used as the literal prompt ("superpet" in the case above), the same as a prompt without another wildcard (e.g. "a female superhero" works fine).

Turning off the wraparound string has no effect but it seems that the wrapping string is causing issues. I'm sure you already know all this :)