diff --git a/README.md b/README.md index d3c4d86..da9f8ad 100644 --- a/README.md +++ b/README.md @@ -41,13 +41,25 @@ Similar to the integer node, it generates a random float in the range and return There are two nodes for random input so far. Both can handle {...|...|...} as well as wildcards in from of txt, yaml and json files. For txt files, it can find them in subfolders and can handle the * for selecting all files in a folder. The nodes searches for wildcards in the standard wildcard folder under the root directory of ComfyUI. Json and yaml files can be used if they are inside that folder, nesting them inside subfolders is planned for future releases. +Both nodes handle complex prompts and have the functionality of add multiple results for a selection with the syntax of {numberOfItterations$$choice1|choice2...}, so a {2$$blue|red|green|yellow} would pick two of those choices and display them. the Nodes include an option of join style, so there you can pick if the results are separated by comma, dot, "and" or just an empty space. +Both nodes also have a debug toggle to display debug output in the console. can be quite helpful to see how the results were chosen and in what order. +### Random Prompts There is a simple node that just handles normal random operations. This mode just gathers all possible options for the expression and picks a random result. image +The node has a history function that remembers (only in the current session, not persistent over restarts of the UI) a specified number of used options, so if you have a long list of option in your wildcards it should not pick the same option in a row, the number set here gives the pool size after which the options are allowed again. For a wildcard with 30 entries and no repetitions the number can be set to 30 to get only unique results. + +### Sequential Prompts There is also the node that can a sequencial setup: image -This mode tries to pick results in order of all possible options. In case of nested terms "a {{blue|red} car|{yellow|green} bike}" it will create results like: "a blue car", "a red car", "a yellow bike" and "a green bike" before starting from the beginning in the same order. !Note: this mode has some problems with too many nestings and just get the first result in wildcard categories (for yaml files). The mode on the top determents the algorithm for sorting. It uses a gear system that locks one part and only advances the other. +This mode tries to pick results in order of all possible options. In case of nested terms "a {{blue|red} car|{yellow|green} bike}" it will create results like: "a blue car", "a red car", "a yellow bike" and "a green bike" before starting from the beginning in the same order. + +The mode on the top determents the algorithm for sorting. It uses a gear system that locks one part and only advances the other. On an prompt of {blue|red|yellow|green} {car|cat|tree} the first option will fix "blue" and go through all second options before switching to "red". The second option will do the opposite, fix "car" and go through the colors first before switching to "cat". + +The "sequential passes" option is a number of passes in the internal system that should be sequential. This is a failsafe option for complex prompts with many wildcard references so that only the specified number of passes will be sequential and the rest just random as normal. Useful for character descriptions with leading categories like "game characters", "female"/"Male" and then a detailed descriptions but with some random elements there. So for a passes set to 2, it would go through all female and then all male characters but if the individual results have nested wildcards or choices, those will be handles randomly. best way here is to check the log with debug mode enabled. + +The "index offset" is used to not start at 0 for the list. All possible choices will be put in a list and that usually starts at index 0, if we want to get results of index 3 and onwards, we can change the index offset to 3 and it will start with index 3. Keep in mind that the index persists on the same session, so if one run goes from index 0 to index 3, the next run without a restart will be at index 3. Every active and not deactived node will run even if it not connected, so some indicies can be off if the node was just disconnected from the workflow but not deactivated (turns purple on standard settings if deactivated). Debug will also run for nodes that are part of the workflow but not connected with cables, so either deactivate debug on disconnected nodes or disable them.