lmarkus001 wrote:
You mean like:
Heh-heh, yeah.

You might consider requiring that the incoming data already be properly structured for your use. For example, the incoming JSON could contain an object that has the
range and other fields set up as necessary for use in the getTokens function.
And any field which might even remotely be used to hold more than one value should be an array. From the sample you posted I'm thinking of the "save1" actually being "saves" and the "id" field being an array of IDs, for example.
I'm thinking something like:
Code:
{
"processTarget": "Fire in the Hole",
"range": { range: 20, metric: "ONE_ONE_ONE", ... },
"difficulty": "10",
"caster_level": "1",
"cl_bonus": "0",
"sr": "1",
"saves": [
[ "reflex", 1, "halfdmg" ],
[ "will", 1, "sickened" ]
],
"id": [ "C0A801076801D181B023000080800100" ]
}
I'm thinking that the
saves entry would be one array for each possible save. Prior to rolling the saves invoke a "hook" UDF (that runs in the same scope) that normally does nothing. For some spells it might want/need to do extra processing. For example, spells like Unholy Blight need to know a creature's alignment and whether they are outsiders.
Each row in the save array is one save type. The second value is 0="no new roll" and 1="new roll". This allows a single Will save roll to be used multiple times because the third field is a macro that is called to process the saving throw. So the "halfdmg" macro would be passed true/false whether the save succeeded and the token ID of the current token. It applies damage as appropriate based on Evasion and similar feats. The second one makes a new roll (the second element == 1) and passes the true/false of that roll and the token IDs to the "sickened" macro (which applies the states as needed). If the second parameter == 0, it means the same d20 roll of the previous save gets used again. This allows a single Will save to be checked multiple times to see what affect it has. (Hm, maybe overkill. Maybe the roll result and the calculated DC would be enough if passed to the macro? The macro could process the incoming data however it wants.)
By using macros for those fields instead of modsets, more complex work can be done. (Although your modsets can do an awful lot as it is, so maybe just turning a modset on/off would be enough?)
Well, maybe that save stuff is overkill. But it'd be cool for it to be extensible by simply defining new macros when a new spell effect came along...