Currently EMI Loot will display some entries correctly depending on their real loot chance determined by KJS script. While the script works, EMIL will not pick up on it and still displays removed or otherwise modified items as their default.

For example, I can remove black_steel_sword from all loot tables, and I can reliably test that it never ever drops from its loot tables, but it still appears in the menu. Other times I remove a piece of loot and it properly displays as gone, or even updates for totally new loot from KubeJS script.

There may need to be a KJS specific addon for this, I really don't know, but I wager if that needs to happen you'd be aware of the necessity just because I told you this problem exists.

One persistent issue with my quick fix was that it would work, but never on the very first load of the instance (and the first world load). I always had to /reload for the changes to show. I don't remember if this issue was always present or if it only started to show up after I forced my KJS scripts to /reload with ServerEvents.Loaded() (for unrelated tags shenanigans). Nevertheless, here is a further fix for people with the same problem and/or in the hopes of helping close the overall issue.

After some dreadful testing through tying the mod's reload timing to JEI or EMI to find the problem, the best fix I found was seemingly unrelated to my tests: to have both the original AND the delayed parseTables() be present. The timing on the delayed one doesn't seem to matter that much since for me it works with even a 1 second delay (though that was the shortest amount of delay I tested with). I have no idea why it works since the solution probably involves understanding the sorcery that is reloading loot table registries or whatever, but hey, it works.

I cannot currently interact with LootJs (easily) because it modifies loot in an entirely separate manner from Vanilla or Loader loot systems.

This request has been made several times before, but at this time I'm unsure of a clean way to work around this.

My apologies, I couldn't find the topic elsewhere, glad to know my own suspicions about their compatibility are warranted. <3

I found this issue odd considering that the 1.21 update/wiki of LootJS specifically states that the new lootTables() event changes should reflect on recipe viewers (Wiki). I also had the impression that the EMI Loot tables were shifting around at times, appearing sometimes with less numbers than previous scans, yet returning to their old behavior afterwards, but this was relatively rare.

What baffled me was that Just Enough Resources (JER) could correctly and precisely show LootJS changes that affected vanilla loot tables, but not EMI Loot, which has access to modded loot tables and is more verbose and elegant than JER. This was so frustrating since I was so close to having one of the best modpack balancing tools ever made at my disposal. I went looking into the source files to find that this mod announces when it begins and ends parsing loot tables, and I also noticed that when looking at logs, those statements were sandwiched by... Wait, the solution can't be that simple, no?

No it wasn't, dear readers. I had to open the gates of pandemonium that were minecraft modding source files and I hit roadblock after roadblock, crashing left and right just to attempt to insert a slight modification into a single file, cursing the miscreants that invented Gradle, Architectury API, and Kotlin for Forge (fml_loader more like fml straight up). Turns out that Fzzy Config was also giga trolling me in the shadows because WHAT THA HECK IS A TRANSITIVE DEPENDENCY AND HOW DO I KILL IT FOR GOOD!?
>:((

I felt like I was marching on the corpses of unfortunate souls who managed to get their issues answered by the divine intervention of their local gods (the mod devs) so that I could find the light... But it was so so dark. The thought of giving up crept up several times. How was it possible that the source files fresh off the repository would crash on my device? This was madness I tell you! AND IT TURNS OUT THAT EVEN IF IT CRASHES IN THE MODDING ENVIRONMENT, IT WORKS WHEN SLOTTED INTO PACKS!? The world was upside-down, but it was within the madness that I found...
...
Uhhh, that if you put like a 2-3 second delay on stuff in ReloadableRegistriesMixin.java using ScheduledExecutorService, EMI Loot picks up on the changes made in LootJS' lootTables() if you wait that long after a reload (I swear it took me a whole day to add a goddamn timer :(( Elephants have definitively gone down in my inner tier list of animals cause of Gradle). I found this fix because the parsing strings were literally sandwiched between the KubeJS Server's start and end lines, which would explain the behavior of sometimes showing some modified loot tables correctly. It was my intention to attempt to not modify code that allegedly both Fabric and Neoforge use, but the sorcery of whatever the Neoforge section of the code is doing is beyond me since I saw no direct link with the parsing messages to them.

I was inspired by JEI, which always ran after KubeJS's code in the logs somehow. If I understand correctly, EMI Loot currently starts parsing as soon as some method in ReloadableRegistries is fired, whilst JEI runs around when onRecipesUpdated() observed by their StartEventObserver is fired. If the dear EMI Loot mod author could look into that, it would be much appreciated since with my simple timer-bound delay, the results are obviously up to if your machine can load the world (on first join)/reload KJS' Server script faster than the timer. Of course, this solution doesn't include loot that is managed by the LootJS modifiers() event, which was/still is an issue. However, so far I've only used it to remove all enchanted books from loot. Almost everything else can be put in lootTables()

EMI Loot 0.7.5
LootJS 3.1.1
KubeJS 119 (yes, really. No this has nothing to do with my results afaik)
Neoforge 21.1.90

@fzzyhmstrs (for visibility)

I'm definitely not adding an arbitrary timer to try and un-race KibeJS. But I will look into the event for sure.

I want to say that I and @ANormalRaft went through very similar experiences. I would love to see the loot tables be queried by EMI_Loot after LootJS edits them.