Extends #76 and #29. Instead of mapping mob/item ID -> distributions we create a set of filters. Mobs/items that satisfy the filters are given the distribution specified.
For example: mobs in dimension -1 (Nether) get Fire immunity, undead mobs get 30% Necrotic resistance, mobs with certain NBT tags get double their physical resistances, etc.
The highest priority filter is used, and all others are ignored even if they are applicable. However, for mob resistances, armor distributions and shield distributions, additional modifier filters can be created to alter existing distributions, such as giving all mobs that spawn in the Nether double their base Necrotic resistance. The existing config system is viewed as highest priority. Entries listed in the current config override all base filters but still accept modifier filters. (maybe)
Predicates for filtering entities could include, DDD's creature type, creature attribute (Undead, Arthropod), mod ID, registry name (perhaps with regex support), boss status, and specific NBT tag comparisons.
Predicates for filtering items could include mod ID, registry name, item type (Sword, Shield, Axe, Hoe, Pickaxe, Shovel, Generic) and specific NBT comparisons.
NBT comparisons need a type (less than, greater than, etc. for numerical comparisons, and matches for regex comparison), a key and a value. Examining from the root node, if the key is found with the value specified, then the comparison is a success. I may require the full path from the root node. This would prevent having to search the entire NBT structure every time.
This would be ideal design wise as it extends the config in a very usable way but implementation is likely going to be a nightmare.
Extends #76 and #29. Instead of mapping mob/item ID -> distributions we create a set of filters. Mobs/items that satisfy the filters are given the distribution specified.
For example: mobs in dimension -1 (Nether) get Fire immunity, undead mobs get 30% Necrotic resistance, mobs with certain NBT tags get double their physical resistances, etc.
The highest priority filter is used, and all others are ignored even if they are applicable. However, for mob resistances, armor distributions and shield distributions, additional modifier filters can be created to alter existing distributions, such as giving all mobs that spawn in the Nether double their base Necrotic resistance. The existing config system is viewed as highest priority. Entries listed in the current config override all base filters but still accept modifier filters. (maybe)
Predicates for filtering entities could include, DDD's creature type, creature attribute (Undead, Arthropod), mod ID, registry name (perhaps with regex support), boss status, and specific NBT tag comparisons.
Predicates for filtering items could include mod ID, registry name, item type (Sword, Shield, Axe, Hoe, Pickaxe, Shovel, Generic) and specific NBT comparisons.
NBT comparisons need a type (less than, greater than, etc. for numerical comparisons, and matches for regex comparison), a key and a value. Examining from the root node, if the key is found with the value specified, then the comparison is a success. I may require the full path from the root node. This would prevent having to search the entire NBT structure every time.
This would be ideal design wise as it extends the config in a very usable way but implementation is likely going to be a nightmare.