<commit_before># TODO list

***
## Easy to do
#### Render script
Rename CONFIG field to SCRIPT field.
Add \_\_check\_field function to ensure a field exists. Act accordingly (\_\_error out when required)

***

## Planned features
#### Allow pack variants. 
Will require a field named VARIANT, which describes what variants it belongs to.  
This feature will be tricky to implement gracefully, and will certainly require major restructuring of xml splitting (though, hopefully, minimal changes to XML). XML will be split per-variant, into their own folders. Non XML files (that is, listings, tsort, optimization, etc.) should go into their own folder/s - the XML folder should just be XML.  

Variants should stack, and calling order will dictate variant combination. Definition order, however, does not matter.

Examples where allowing variants will be useful:  
* **most** importantly, size specific variants. For example in Angl, wool sizes 32 and below are a blurred blob, due to the way the stripes run (half pixel). Allowing a size variant would afford me the opportunity to do differently spaced striped for 32, and few stripes for lower textures.
* animated/non-animated pack (non-animated would be default)
* themed/non-themed pack (Halloween, Candy Land, whatever sets your pants on fire)

To define variants, the field VARIANT will be used.

The planned calling syntax for this would be like so:

smelt 32 --variant all,animated,32,halloween

Would render size 32, using base textures, some of which might be overridden by animated texture variants, some of which might be overridden by size 32 specific variants, some of which might be overridden by halloween variants.
<commit_msg>Changed and elaborated on variant calling syntax.<commit_after># TODO list

***
## Easy to do
#### Render script
Rename CONFIG field to SCRIPT field.
Add \_\_check\_field function to ensure a field exists. Act accordingly (\_\_error out when required)

***

## Planned features
#### Allow pack variants. 
Will require a field named VARIANT, which describes what variants it belongs to.  
This feature will be tricky to implement gracefully, and will certainly require major restructuring of xml splitting (though, hopefully, minimal changes to XML). XML will be split per-variant, into their own folders. Non XML files (that is, listings, tsort, optimization, etc.) should go into their own folder/s - the XML folder should just be XML.  

Variants should stack, and calling order will dictate variant combination. Definition order, however, does not matter.

Examples where allowing variants will be useful:  
* **most** importantly, size specific variants. For example in Angl, wool sizes 32 and below are a blurred blob, due to the way the stripes run (half pixel). Allowing a size variant would afford me the opportunity to do differently spaced striped for 32, and few stripes for lower textures.
* animated/non-animated pack (non-animated would be default)
* themed/non-themed pack (Halloween, Candy Land, whatever sets your pants on fire)

To define variants, the field VARIANT will be used.

The planned calling syntax for this would be like so:

smelt 32.all,animated,32,halloween

The first part is the size used, which is separated by a period. This means different sizes may be called with different variants in the same pass, and defaults may be declared in a config (and by smelt itself if all else fails)

Would render size 32, using base 'all' textures, some of which might be overridden by animated texture variants, some of which might be overridden by size 32 specific variants, some of which might be overridden by halloween variants. Any animated 32 specific variants will override the previous mix of animated and 32, then any 32 halloween variants will override any previous mix of 32 halloween, then any animated 32 halloween variants will override any previous variants from all others.

{'fraction_non_alphanumeric': 0.053265044814340586, 'fraction_numerical': 0.008706786171574905, 'mean_word_length': 4.556187766714083, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1471540', 'n_tokens_mistral': 1007, 'n_tokens_neox': 923, 'n_words': 587}