There are some bugs/issues that occur only with compiled ChooserTables, for example, [Content removed] Or the one, where property binding breaks if you reorder the ChooserTable Parameters list, and you don’t know about it until you reload the asset because it’s the only thing that triggers recompilation.
It would be really helpful to be able to manually trigger ChooserTable compilation to see all the issues immediately.
A few answeres to this:
Yes we have work in progress to improve compile error handling. The system is intended to trigger a recompile any time any input binding is changed, as well as whenever the parameters list changes… however as you’ve found, that is not happening. That should be fixed soon, along with the addition of an Errors tab, which will show all the errors for the chooser in one place, and pop up when you open a chooser with errors.
We can add a Compile button as well, for handling other cases (such as if you add or delete a variable from a referenced struct or blueprint, and you want to verify your chooser is still valid)
Also considering removing the ordering constraint you mentioned (ie “where property binding breaks if you reorder the ChooserTable Parameters list”) so that would no longer be an issue. Even if we decide to keep the index based binding system, I have plans to implement an auto-rebinding step after parameters change, so that you don’t have to do that manually.
As well… we may change certain in editor behavior in the future. Currently in editor, a non-compiled codepath is used for accessing properties (where it does a more expensive name based lookup every time, for reliable stability in the case where blueprints change during the editor session). Because of this, you can evaluate a chooser on two unrelated types of objects, and though it will throw an error in the log saying the chooser is being evaluated on a class that is different than it was compiled for, it may still “work” if the two classes have properties with identical names - but it will fail in a game runtime using compiled lookups. We may change this to either have a much louder error message, or to just also fail in editor.
Thank you for such a comprehensive response.