Choosers - Bug or a feature - top layer chooser overwrites "output struct" of an evaluate chooser row.

Development Programming & Scripting
, ,
1

Hey there,

I’ve noticed a possible bug (or intended?) while using OutputStruct and multi-layered choosers. When the result row is from within an evaluated chooser, the value of the OutputStruct is taken from the first Output struct in these layers. The repro below should explain the problem more clearly. I would expect this “overwrite” of the result row to happen only if the OutputStruct on the higher layer actually specifies a value - in the repro case, I would expect it to act as a fall-through.

Repro:

  1. Create a struct type that contains arbitrary data, in our example, just a single float
  2. Create 2 choosers with the same signature (same result, same parameters)
    1. One of the outputs is the struct from step 1.
  3. In the parent chooser, create 2 chooser rows and 2 chooser columns like so:
    1. [Image Removed]
      1. The 1st row is an evaluate chooser
      2. The 2nd row is an asset result
  4. In the child chooser (that’s used as an evaluate chooser), create 1 chooser row and 2 chooser columns:
    1. [Image Removed]
  5. Bug? When you evaluate this parent chooser with “UseEvaluate=true”, the value of the `OutputStruct` is taken from the parent chooser instead of the chosen row from the Evaluated chooser.
    1. [Image Removed] - once called with `UseEvaluate=true` once with `UseEvaluate=false`.

Hopefully the repro makes it clear, I can provide more information if not, thanks!

[Attachment Removed]

2

Steps to Reproduce[Attachment Removed]

3

Hi, sorry for the delay.

This is working as originally designed. It currently works this way because the chooser needs to know that it’s Result “succeeded” before writing outputs.

eg. if your nested chooser failed and had not fallback, it would return null… then the outer chooser would not run the outputs for that row, and would either try the next row that passed all filters, or the fallback row.

However we do understand that this is an issue and we have a couple of solutions which should be implemented soon.

One feature we will be adding is the ability to manually exclude output column cells from execution - something like right click->Disable, and the cell will be greyed out and do nothing.

This will allow you to disable the output column in the outer chooser for any rows which have a nested chooser in them, preventing the outer table from overwriting.

We will also be investigating the possibility of reversing the order, so the outer chooser writes outputs first (without checking if the child would succeed) - in the case of failing rows this would just mean the outputs might be set twice, but it would still work similarly. This change may be required anyway as part of supporting an array output mode for struct outputs (currently in multi-output mode only the first passing row’s output columns execute).

[Attachment Removed]