- Provide an unified api that can accept all data point to crack or reduce to a set of seeds
- Provide metrics and insights about the seed cracking process at each steps even during gathering
- Be easy to use in any configuration and accross versions
Data points will be defined by 4 main categories :
- Features : could be any of the features available in FeatureUtils (will add a lot of them so we cover most of the useful one)
- Decorator: Could be any of the standard decorators: ores, trees, (dungeons)...
- Terrain: terrain shape can be used to reduce structure seeds
- Biomes: can be used to crack the full world seed
What would a feature data point looks like?
- A cpos or bpos
- A set of bpos for loot positions + loot contents
- A set of block positions and block states for non premade structure (eg dungeon, stronghold patterns or flowers)
- A version
- A salt or a hint of non regular salt
What would a decorators data looks like ? Same as above but with bpos and no cpos
What would a terrain data looks like? A bpos and a block state, or a column data states +version + dimension
What would a biome data looks like? A bpos and a biome id + version +dimension
- Set of initial seeds to reduce from
- Hashed seed if available
- Pillar seed if available (we can provide an utility to crack it but we consider it intrisics)
- Hint if random salts
- World general offset of positions?
- Should use gpu?
- How many threads/cores to use
- Missing step in the 4 categories, for instance, no biome given, not enough structure/features....
- Number of missing bits
- Non usability of a data point due to rule conflicts
- Standard deviation to Minecraft vanilla rules (out of bound region, impossible patterns/loot...)
- Basic percentage progress
- Stage progress
- Basic estimates of candidates number
- If data is corrupted/missing, callback should be called and provide way go feed or rectify data.