WARNING: This is an advanced feature and requires thorough understanding of the expression editor as well as basic table features and usage. Improper usage of these these new behaviors (particularly Save Table) can potentially result in your game becoming unplayable or unresponsive for the end user. Thorough testing is advised.
Let’s break these down one at a time!
Add/Remove Row Behavior: this behavior allows the user to select a table, and add or remove rows from the selected table.
When you first add the ‘Add/Remove Row’ behavior, if you have no tables created, the behavior’s drop down options will all be disabled.
When at least one table exists, you will be able to select a table from the drop down menu.
Add Row:
Once you have selected a table, you can select an “Action” to perform on the selected table. The default setting is ‘Add Row’. When you add a row to the table, you have the option to insert a row at the beginning of the table, at the end of the table, or at an index. If you select to add a row at an index, you can choose where you would like to add your ro based off of either a hard value (i.e 1,2,5,8, etc..) or using a self or game attribute, such as an integer or index. This will then add a row to the specified location, and shift the following rows down. For example, if you added a row at index 5, rows 1 through 4 would remain unaffected, while the previous row 5 (and all subsequent rows) would increment by 1.
Remove Row
Just as with the ‘Add Row’ action, the ‘Remove Row’ action can remove a row from the beginning of the table, the end of the table, or at an index. When you remove a row, the rows below (or after it) it will be shifted up in position by 1. In other words, if you removed the first row (either using ‘At Beginning’ or “At Index 1”) it would be removed from the table, deleting all values contained in that row, while subsequent rows would have their identifying number decrease by 1. So in this example rows 2 and 3 would now become rows 1 and 2.
NOTE: When you add or remove a row, specialized row names are also shifted or removed along with the row it was created for. So if you reference a row by a name, remember that if that row is removed, the reference by name to that row is no longer valid.
Change Table Value Behavior: this behavior allows the user to select a table, then change multiple column values based on a single row.
NOTE: If the type is not allowed by the column or the reference data is wrong, it will be ignored by the function.
When you first add the ‘Change Table Value’ behavior, if you have no tables created, the behavior’s drop down options will all be disabled.
When at least one table exists, you will be able to select a table from the drop down menu.
Once you have selected a table, you can select a specific row, or dynamically select the row by using an attribute, then select one or more columns of that row to change. Columns and the Values to be put into those columns can also be changed dynamically using the expression editor. Add or remove column fields with the (+) and (-) buttons.
Copy Table: this behavior allows the user to select a source table as well as a destination table. This behavior will copy the specified table in its entirety to the target table. Meaning, no matter what the contents of the target table, it will be completely overwritten by the source table. If the source table is 4×5 and the target is 1000×1000, the target will be reformatted to 4×5 and all of its contents will be overwritten by the source table values.
To use this behavior properly, you must have at least 2 tables that already exist. If there is not at least 1 table, both the drop down selections will be disabled.
Usage: The Copy Table behavior can be used to set and reset table data to its initial values. If you have saved a table with the Save Table behavior, or have changed data during game play, to reset the data, you would need a table that contains the default data and copy that table into the modified table. Alternatively, you can copy table data from one of many tables into the active table which all you actor prototype behaviors reference. For example, if your game has three save slots for different player data, you can copy the corresponding table for one of the three slots into the active game table. Having a blank table is also handy to clear an active table (such as a leaderboard) of all data.
Save Table Behavior: this behavior allows the user to select a table from the list of tables that have been created. This behavior will copy a local save file for the specified table. Currently there is only one save file per table, and each time it is saved, it overwrites the previous save file for that table.
Common uses for the ‘Save Table’ behavior are to store game state values that you have modified into the table.
NOTE: Since this behavior overwrites the original default data in the table, be very careful that you do not set up logic that will overwrite values that you might need later, as even restarting the game will not revert the table’s attribute to their original values. Unlike the Save Attribute behavior, Save Table will result in the saved table’s values being used immediately at time of game start.
Best practice states that it’s a good idea to have a separate table that contains the same original values as the table you’re editing, but does not get modified (basically creating a duplicate table), which then you can use the ‘Copy Table’ behavior on this duplicate to undo any changes made, followed by a ‘Save Table’ on the destination table that you’ve just copied your information to.