It seems like an oversight that the Select node does not have the option for a Default input pin to handle any case not enumerated by the other pins. Especially as the Switch node handles such scenarios with it’s outputs already.
In this example within my “Script” table I have rows of "Line"s which in these examples remind the player to pick up a laser gun before proceeding. The “Line” data includes things like who is talking, who they’re talking to, what their emotion is, etcetera. I have written three different barks to remind the player that they need to pick up a laser gun. When each of these lines are delivered the default response loops. This is a simple example, so before you wonder why I couldn’t just rewrite it (or point out the peculiar behavior of a Select node which will cause all four of the data table requests to be fired whenever any execution of the Display This node uses the data from the Select), let me give a few reasons why this use case is merely one example of many, as well as why the solution of a default input may be valuable in preventing bugs which can occur with any use of the Select node.
In this example I simply look up a line of dialog to deliver depending on how many times this dialogue’s instruction has been ignored by the player. I could make this basic logic more interesting by setting the “Start Index” on the Switch to “2”, and enabling the Default pin, leaving a Switch with only the [2] pin and the [Default] pin. Then I would expect for the code to play the same “Line” of text each time the player fails to pick up the laser, except for the third time when something unique was said and done (like adding a big sarcastic red arrow at the laser and changing the line to, “It’s right here! Pick it up!”), before returning to the default line read for every subsequent event. The problem in this example is the same as before, but now occurs for even more pins. The Switch would have two outputs, but the Select would need it’s [2] pin hooked up with the unique “Line” output, as well as pin [0], [1], and an infinite list of additional pins, all hooked up to the default “Line” output, in order to handle each of the cases which the Switch handled with only two pins.
Select nodes do actually already have a default that is used when it fails with unexpected index values. If your “Select By Int” handles 0-3 cases and the Int input is “4”, the Select will output the 0 case of the input data. Depending on what kind of data is being selected from the 0 case may be, the value 0.000, or False, or if it’s an array, a reference to the first item of that array. In the example above the 0 value will return, not the “Line” which is being input to the [0] input of the Select, but rather a reference to the “Line” at the 0th row of the “Script” table. Case in point, the 0th row of the script is a “Line” of dialog which is not any of the four options the Select node was provided with. This results in the delivery of a non sequitur line of dialog, and no error to indicate how or why it occurred.
Particular asks are:
-
{Feature request} The Select node should allow for the addition of a Default input pin, as Switch nodes do.
-
{Feature request} The Select node should allow for a Start Index to be set, as Switch nodes do, and use the default input for cases between 0 and and the Start Index.
-
{Bug report} In the absence of an explicit Default input, the Select node should default to using the last input, so as to never return unexpected data outside the scope of the provided inputs. (Alternatively, return the closest input. ie. X<S = S and X>L = L, where S is the Start Index, and L is the Index of the Last explicitly declared input)
-
{Bug report} In the absence of an explicit Default input, the Select node should log an error or warning at runtime. The error should include which Select node received the unexpected index input, and what the unexpected input value was.
-
{Feature request} The Select node should allow for any input pins to be removed (right click > “remove pin” under Pin Actions). Removed pins should all use the default input, and trigger an error at runtime if no default input was explicitly provided. (Example, a Select by Enum where only 5 of 30 cases matter in the context of this part of the code should only need to expose 5 pins, and a default, to cover all cases)