`no` should be a valid value for an optional parameter in scripted effects, values and triggers.

[adriangaro]

no is essentially treated as not passing a parameter in the context of conditional syntax [[PARAM] .... ]

It also means if a parameter is optional, passing no as value should work, even if not matching the inferred type.

For example i have the following script value, where a few of the parameters are optional

add = value:tec_automated_production|BASE|$BASE$|BASE_VALUE|$BASE_VALUE|no$|ECO_CAT|$ECO_CAT$|RESOURCE|$RESOURCE$|REQUISITION|$REQUISITION|no$|REQUISITION_AMOUNT|$REQUISITION_AMOUNT|no$|

Passing the default no should work here. Yes this could be rewritten with conditional blocks, but that would make this harder to read.

Essentially doing BASE_VALUE|$BASE_VALUE|no$| is equivalent to doing [[BASE_VALUE]BASE_VALUE|$BASE_VALUE$|] for the game. The first one is easier to read and shorter variant for all intents and purposed.

In scripted effect/trigger cases, the syntax is similarish, and shorter

tec_my_trigger = {
  PARAM = $PARAM|no$
}

# is equivalent of

tec_my_trigger = {
  [[PARAM] PARAM = $PARAM$ ]
}

[adriangaro]

Relevant documentation from common/scripted_effects/99_advanced_documentation.txt

# You can also use these parameters as booleans:
#   <scripted_effect> = {
#       PARAM = yes/no
#   }
# =>
# <scripted_effect> = {
#   [[ PARAM ] #executes enclosed effects if PARAM is present and not set to no ("PARAM = anything_else" defaults to "yes")
#       some_effect_or_other = yes
#   ]
#   [[ !PARAM ] #executes enclosed effects if PARAM = no or PARAM is not set (e.g. you call it via <scripted effect> = yes)
#       some_effect_or_other = yes
#   ]
# }