For me it's always less than 1ms to write or read a sector parm. That's rarely a problem, but in some places (like a ptorp) where it might be you can always precache the parm list into a static array.
Code:
:start_fig_read
echo ANSI_14 "*One moment please, loading fig list.*"
setArray $figlist SECTORS
setVar $idx 11
while ($idx <= SECTORS)
getSectorParameter $idx "FIGSEC" $figged
isNumber $result $figged
if ($result < 1)
setVar $figged 0
end
if ($figged > 0)
setVar $figlist[$idx] TRUE
else
setVar $figlist[$idx] FALSE
end
add $idx 1
end
:end_of_fig_read
echo ANSI_14 "Fig list has been read.*"
return
Not too difficult at load, takes a few seconds at most and you can re-cache the data whenever you go to recheck the planet number or whatever every half hour or so.
Still, for me parms take so little time to load that the extra effort isn't worth it. Last time I checked my torper routine the whole thing took a whopping .3ms from start to finish. And I can't possibly think of any other situation where that kind of reaction time matters.
I use parms more while I grid tho than for grid defense. It allows me to update my figlist as I go and cut back on the number of refreshes. You can, of course, get similar results with a static array... but that requires that you stay within the script. When the script halts, the array is cleared... but with parms you can run a half-dozen different scripts or stop and restart the script as needed and only refresh when you're done.
The latter comes in handy when you're gridding in an early unlim and some bozo starts plowing figs... you need to shut it off and kill, then restart when you're done. If I had to refresh my figs every time it would really slow things down.