Describe the bug
I have written a script to tweak various loot tables in the Aether, and Blue Skies dimensions, but when loading, the error "ERROR: No loot table with name [insert loot table name here] exists!" is printed in chat/the crafttweaker log (https://pastebin.com/4UdbT4DU). Oddly though, testing these loot tables with command blocks, the tweaks from the script have been applied, with the various extra items showing up. The log does not have any mention of the fact that that part of the script is working.

To Reproduce
I haven't tested with an isolated instance, but I suspect it simply requires trying to tweak loot tables from either Aether (legacy) or Blue Skies.

Expected behavior
No error, since the script is working

Logs & scripts
Errors as reported in crafttweaker log file: https://pastebin.com/4UdbT4DU
Script (it's a bit of a monster, sorry): https://github.com/thephoenixlodge/Heavens-of-Sorcery/blob/master/scripts/dungeon_loot.zs

Version Info (Exact versions only):
LootTweaker: 0.0.10.0
CraftTweaker/Minetweaker: 4.1.19
Forge: 2838
Minecraft: 1.12

Additional context
I suspect it may be related to the fix from #32
perhaps the error check wasn't moved to be later with the actual functional check for the loot table existing?

I suspect it may be related to the fix from #32
perhaps the error check wasn't moved to be later with the actual functional check for the loot table existing?

There's only the one check. LootTweaker checks the validity of all tables registered for tweaking when the first loot table is loaded. That's as late as I can do it.

This issue is deceptively complicated. It's difficult to check if a loot table exists. LT can't attempt to load the table and check if it works, that would create an infinite loop due to the way the hooks Forge provides work.
Instead it checks a registry which loot tables don't actually need to be registered with to work. In 1.12 Minecraft itself only uses it to load all vanilla loot tables at world start for some reason.
Consequently many mods don't register their tables with it at all. Even when they do, they often use a way that causes the tables to be registered at some arbitrary time during play, due to the way Java works. This is what's happening with both Aether and Blue Skies.
I'm experimenting with a more robust way to check loot table existence, as there are so many mods that I have to ask authors to change (they're very cooperative, there are just always more). I'm having issues implementing it though, and it will add to startup time (how much I'm not sure).

Tweaks made to loot tables that exist, but aren't registered yet/at all still occur due to an oversight on my part (invalid tables aren't removed from the list of tables to tweak) and the way the Forge hook works. This will change in the next release of LT.

There is a workaround, but unless you need this working right now I wouldn't recommend it, as it depends on a method I'll deprecate if my mentioned experiment works.

Also, how did you add the label to this issue? You're not supposed to be able to do that.

The label appeared automatically when the issue was created, I think cos I went through your reporting template?

If I'm understanding this correctly, you're looking for a way to handle this better, but you're also going to make it so the tweaks won't work if it errors like this?

How about a method to suppress the error (maybe also make it considered a warning as it may/may not actually be true?) as a mitigation in cases where say a modpack developer has confirmed it is loading okay but due to this timing, it doesn't catch it in the check?

Maybe even make this possible on a per mod basis?

@thephoenixlodge

The label appeared automatically when the issue was created, I think cos I went through your reporting template?

Oh right, that's fine then.

If I'm understanding this correctly, you're looking for a way to handle this better, but you're also going to make it so the tweaks won't work if it errors like this?

Yes, because it's confusing if LT says one thing and does another.
The experiment is currently working, I just need to test it with a large modpack.

@ewanm89
The ideal solution here would be for all mods to register their loot tables in preinit. It's easy to get other mod authors to do this, but there are always more mods needing this change.
The method you are suggesting in fact already exists, but for other reasons. It confuses users often. Using it to solve this problem would be a nasty hack, I'd only use it as a last resort solution.
My experiment should be able to validate any loot table id, whether the id is registered or not.

The fix has been released in 0.1.0