Is there a minimum reproducible case I can try to troubleshoot to see if any of the recent metascript updates impacted that, David? I just tried a simple forselected call and the deferral character works.
One thing you could try, Kaiyatsu, is to use a different deferral character. I wonder if you are running into a collision of what you're trying to use as a ScriptCard deferral character and what you're using as a forselected deferral character. I see you using the "^" character elsewhere in your macro, then you're using it in the forselected call...
What I think is happening is, in your macro you have ScriptCards sending a forselected call which will, in turn, issue a series of SmartAoE calls. Before SC issues the forselected command, it will remove its deferral characters (exposing syntax structures to the parsers when the new message gets sent through). Then, when SelectManager reads that forselected message and issues the series of SmartAoE calls, it will remove it's deferral character so that syntax structures will be exposed in the SmartAoE message. You can see how it would cause a problem if both SC and SelectManager (forselected) used the same deferral character... the things that shouldn't be detected until the SmartAoE messages are sent out will be detected and parsed out of the way too early.
I understand ScriptCards lets you define a SC deferral character, but it might just be quicker to do it in the forselected line. Whatever you use in the parentheses of the forselected handle will be your SelectManager deferral character, so you just have to pick something that isn't in the about-to-be-outbound command line. That would mean changing this:
--@forselected(^)
...to something like...
--@forselected(+)
...provided there were no "+" characters in what you wanted to send with forselected that needed to remain in the message.
That said, I see some things I think might be a problem... but I'll leave it to you and David to tell me whether these things are expected. Regarding this part of your macro:
--@forselected(^)|SmartAoE [&lbrack][&lbrack]
_title|Flame Strike
_leftsub|Slot level [&lvl]
_rightsub|DC @{selected|spell_save_dc} DEX
_aoeType|circle, float
_radius|10ft
_minGridArea|0.25
_minTokArea|0.25
_fx|burn-fire
_dc|@{selected|spell_save_dc}
_saveFormula|5eDEX
_damageFormula1|[&damForm1]
_damageType1|Fire
_damageFormula2|[&damForm2]
_damageType2|Radiant
_ignore|SmartAoE_Ignore,1
_instant|1
_autoApply|1
_bar|1
_zeroHPmarker|dead
[&rbrack][&rbrack]|
1) I see a closing pipe after the double [&rbrack] that bound the SmartAoE portion (the last character in the above snippet). Should that pipe be there?
2) You include a SelectManager deferral character... forselected(^)... but then you never actually use it in the outbound SmartAoE call SelectManager will issue. If you don't need it, you don't have to declare it. The handle for the forselected call can be simply:
--@forselected|SmartAoE...
...however...
3) In the above snippet, both of the @{selected|spell_save_dc} structures will get immediately parsed at the time that the ScriptCards message is sent. That's because they will be visible to the parser at that point (instead of deferred until the individual SmartAoE calls are sent via SelectManager). Unless I understand what you have going on, you don't want them parsed at this point. That will give every token the same value for the spell_save_dc. If you want individualized results, you have to hide these calls.
However (the venerable Sir However the Second)...
You can't use Roll20 standard syntax for selected tokens when you have a script issue a message calling another script, because the Script Moderator is the one issuing the command, not a player, and the Script Moderator doesn't have any tokens selected on the game board. Even deferring the syntax of the call won't help you, because when Roll20 *does* see it (after SelectManager strips off the deferral character), there is no token designated to be "selected" from which to pull the information.
This is where you need Fetch to supply the information, and you need to defer the Fetch construction until the SmartAoE messages are being sent. In other words, the Fetch construction for the spell_save_dc attribute would normally be:
@(selected.spell_save_dc)
Deferring it with a caret would be:
@^(selected.spell_save_dc)
Deferring it with a plus would be:
@+(selected.spell_save_dc)
So taking all of these concerns into account, I would wonder if this replacement for the above snippet would work better...?
--@forselected(+)|SmartAoE [&lbrack][&lbrack]
_title|Flame Strike
_leftsub|Slot level [&lvl]
_rightsub|DC @+(selected.spell_save_dc) DEX
_aoeType|circle, float
_radius|10ft
_minGridArea|0.25
_minTokArea|0.25
_fx|burn-fire
_dc|@+(selected|spell_save_dc)
_saveFormula|5eDEX
_damageFormula1|[&damForm1]
_damageType1|Fire
_damageFormula2|[&damForm2]
_damageType2|Radiant
_ignore|SmartAoE_Ignore,1
_instant|1
_autoApply|1
_bar|1
_zeroHPmarker|dead
[&rbrack][&rbrack]