Comparison operators are broken for record (struct) data types in the trigger module.
Create a record someRecord.
Create an integer variable for someRecord.
In a trigger, create an If statement.
Create a comparison for the If statement.
On the left side of the comparison, select someRecord.
Click the 'member' field. No members of the record can be selected, even though the integer member created in step 2 is a valid data type for comparison operators.
Additionally, no values can be selected on the right-hand side.
Workarounds
Until this is fixed, you can:
Enter the comparison directly as custom text
If you want to compare the member to a variable, you can place the variable on the left-hand side and the record on the right-hand side.
However, it is impossible to compare the member to a value directly in the editor with > and < operators. Only boolean data types appear to not be broken.
A record I use has an array and the size of the array's current usage stored within it. Due to the above problem, this simple statement cannot be done in the galaxy editor:
if(someStruct.arraysize>4){
This requires either custom scripting or creating a local variable for every record member the user wishes to compare data to. This behavior is likely an error since boolean data members work, but others don't, and record members are valid on the right side of a comparison operator, but not on the left side. This sort of bizzare inconsistency leads me to believe there's a bug somewhere.
An even bigger problem is I've discovered it's impossible to check the non-boolean values of records that have sub-records, even using the switch-sides workaround discussed above.
Either way this very simple operation can't be done, because struct2 doesn't match the type of someIntegerVariable, thus cannot be selected and it's impossible to do any comparison operations with struct2's member values.
The solution to this is simply: do no type checking for records with the comparison operator until compile time. Allow us to pick any member of a records and check it against anything else... if we mess it up, it'll be our fault. Currently, structs are basically unusuable in the editor.
Comparison operators are broken for record (struct) data types in the trigger module.
Workarounds
Until this is fixed, you can:
However, it is impossible to compare the member to a value directly in the editor with > and < operators. Only boolean data types appear to not be broken.
What are you trying to do?
Do you want to do something like that? {int, int} < {int, int}
@vjeux: Go
A record I use has an array and the size of the array's current usage stored within it. Due to the above problem, this simple statement cannot be done in the galaxy editor:
This requires either custom scripting or creating a local variable for every record member the user wishes to compare data to. This behavior is likely an error since boolean data members work, but others don't, and record members are valid on the right side of a comparison operator, but not on the left side. This sort of bizzare inconsistency leads me to believe there's a bug somewhere.
@Thalassicus: Go
An even bigger problem is I've discovered it's impossible to check the non-boolean values of records that have sub-records, even using the switch-sides workaround discussed above.
Either way this very simple operation can't be done, because struct2 doesn't match the type of someIntegerVariable, thus cannot be selected and it's impossible to do any comparison operations with struct2's member values.
The solution to this is simply: do no type checking for records with the comparison operator until compile time. Allow us to pick any member of a records and check it against anything else... if we mess it up, it'll be our fault. Currently, structs are basically unusuable in the editor.
I've discovered a workaround to the bug I indicated in the first post. For step 6, do the following:
nice workaround there :) was just battling with this my self
i am kinda having even more trouble with Within Bounds... can't really seem to add a Record at all... so i have to use a Local Variable...