Hands-On Usage
In the research progression workflow of Special Projects, when a prototype reward has satisfied its unlock conditions, you can use this effect to programmatically complete that reward option within your script. This is commonly used to automate reward triggers or allow players to skip manual selection in event options. For example, directly redeeming a specified reward in a project completion event:
# In an event option within SPECIAL_PROJECT scope
complete_prototype_reward_option = {
prototype_reward = jet_engine_breakthrough
prototyp_reward_option = high_thrust_variant
show_modifiers = yes
}
Synergy
[has_project_flag](/wiki/trigger/has_project_flag): Check whether the project has reached a specific stage flag before executing the reward, preventing the reward from being triggered at the wrong time.[set_project_flag](/wiki/effect/set_project_flag): Immediately set a flag after completing the reward to prevent subsequent logic from executing the same reward branch repeatedly.[add_project_progress_ratio](/wiki/effect/add_project_progress_ratio): Commonly paired with reward completion to advance project progress further while redeeming the prototype reward, simulating the acceleration effect brought by research breakthroughs.[add_dynamic_modifier](/wiki/effect/add_dynamic_modifier): Attach dynamic modifiers after reward completion to further extend the actual gameplay impact of the reward.
Common Pitfalls
- The
prototyp_reward_option field name itself contains a spelling defect (missing an e). This is the original spelling as defined by the developers. New modders who spell it correctly as prototype_reward_option following standard English conventions will find the field unrecognized, causing the option to silently fall back to default values without throwing an error—making this difficult to detect.
- Overlooking the
fire only once constraint: This effect respects the "fire only once" attribute of the prototype reward itself. If your script logic calls the same reward multiple times, subsequent calls will be silently ignored rather than throwing an error or overwriting the previous result, leading to unexpected missing rewards. It is recommended to pair this with [set_project_flag](/wiki/effect/set_project_flag) and [has_project_flag](/wiki/trigger/has_project_flag) for explicit execution state management.