Condition displays are ambitious but they're pretty overwhelming outside of packs that aren't already expert-tier.

Some stuff in branched table displays is wonky or redundant - A few examples and thoughts:

---

• "Needs a block that is [input block]"
  
  Table checks block_state_property internally, but because that isn't display, this is noise.
  Could say "Depending on block state", or just be hidden.

---

• Order of conditions randomizes on reload.
  
  Do loot tables lose their json order once parsed? Can some static order be established by the mod itself?

---

• "Drops when this is an entity INVALID"
  
  Just an entity: this condition. I believe that actually translates to "Must be broken directly"? Or could just be hidden.

• I couldn't put this in the "don't sync" config, either, it doesn't parse. Would help if the displays showed their IDs with advanced tooltips enabled, but I don't think mistyping is the issue - i nicked the ID from code.

• Actually as a general note I couldn't successfully hide things like survives explosion / killed by player / looting affects despite trying. Does it work in singleplayer?

---

• "NOT: Needs item with Silk Touch"
  
  Might be able to special case this to display as a positive silk touch condition on the other branches.

---

• I could disable block drops entirely, but it'd be great if i could just disable blockdrop branches that drop their own BlockItem. I'd like to be able to see that diamond ore drops diamonds and is affected by fortune and that grass drops wheat seeds, but i really don't need these, as WAILA harvestability covers them fine:
  
  
  

---

• "No conditions"
  
  This drop type feels like it should display like plain - without all the extra bells. Especially as not syncing certain conditions increases the chances of this appearing.

---

• As a moonshot, it would be nice if EmiRecipes were made for each in-table loot pool / condition set, instead of for entire tables.
  This would mean one set of conditions per EmiRecipe (easier to display), and usage context would work like it does in the rest of EMI: searching sources of cobblestone won't show "stone drops stone with silk touch", but searching usages of stone will.
  Would need IDs generated on the fly, so static ordering is probably a prereq.

The blockstate condition doens't always just say that, it will display the properties it needs

the INVALID return implies that the drop is using an entity condition that I either haven't captured, or that isn't in the base game.

JSON does not define ordering on its elements, so there's really no way around the reordering on reload.

If you are trying to skip certain key parsing, make sure it looks like this

I don't think there would be a reliably deterministic way to "invert inversions", they might be part of another condition etc. And I'm not making a "prettier" version of everything that might be inverted. Showing a Not state is plenty intuitive IMO.

I'll consider a config setting for skipping "simple" block tables that just drop themselves.

No conditions is shown like that on purpose. Explicit reinforcement that nothing special is needed. See note below to tuck these away.

Loot pools and conditions don't have IDs (in a loot table), and "hot generating them" wouldn't be super meaningful. A loot table is the smallest unit of drop-generation used by the game mechanics.

---

General note: You can add in Symbols and Stuff if you want the simplicity of the "Plain" interface while still having condition info. This pushes conditions out of "direct" line of site if they aren't generally important to you.