Hands-On Usage
resize_temp_array is commonly used in scripting scenarios where you need dynamic control over temporary array length, such as trimming excess elements after loop operations complete, or pre-allocating a fixed number of slots during initialization and populating them with default values. Typical use cases include: building fixed-length candidate country lists, or truncating to a specified size after data collection in for_each_scope_loop.
# After data collection, truncate the temporary array to the first 3 elements
resize_temp_array = {
array = candidate_array
size = 3
}
# Shorthand: set my_temp_array size to 5 (new elements default to 0)
resize_temp_array = { my_temp_array = 5 }
Synergy
[add_to_temp_array](/wiki/trigger/add_to_temp_array): Use it to batch-add elements to the array first, then use resize_temp_array to trim or expand the array to target length—this is the standard pattern for building fixed-length lists.
[clear_temp_array](/wiki/trigger/clear_temp_array): Clear the array before refilling; combined with resize_temp_array, you can achieve a "reset and pre-allocate" initialization pattern.
[find_highest_in_array](/wiki/trigger/find_highest_in_array): Perform maximum-value lookup on the resized array to ensure the search range meets expectations and avoid traversing into invalid default-value elements.
[collection_size](/wiki/trigger/collection_size): Check the actual current array length before calling resize_temp_array to decide whether expansion or contraction is needed, making your logic more robust.
Common Pitfalls
- Shrinking the array permanently loses trailing elements: Beginners often assume that shrinking and then expanding will recover the original values. In reality, elements beyond the new
size are removed during shrinking, and expansion afterward only fills in default values (0). Always confirm you no longer need those elements before shrinking.
- Misusing this command in trigger blocks:
resize_temp_array is fundamentally an operation with side effects (it modifies array state). Although technically allowed in trigger contexts, calling it in pure condition-checking code (such as limit/available) causes hard-to-track state pollution. You should aim to invoke it within effect blocks instead.