Damage over time spells

[Faux]

[quote="John Adams"]Well this:

Code: Select all

function cast(Caster, dmgType, dmgMin, dmgMax)
    SpellDamage(Caster, dmgType, 0)
end

is not going to do anything. dmgMin of 0 is not going to generate aggro.

When I say do the initial damage in cast, I mean the first mathematical split of the total / frequency, since the start of frequency should be the exact instant of casting (not 4 seconds later). [/quote]

That code won't do anything. I changed it locally to cause the initial tick of damage. I just haven't committed it yet because of a crashing bug. I know it applies the initial damage and agro now though.


[quote="John Adams"]

Code: Select all

function cast(Caster, dmgType, dmgMin, dmgMax)
    dmgMin = math.floor((dmgMin / ticks) + 0.5)
    dmgMax = math.floor((dmgMax / ticks) + 0.5)
    SpellDamage(Caster, dmgType, dmgMin, dmgMax)
end

And, all functions in the Spell Script should be receiving the exact same parameters, regardless of if cast uses "ticks" or not. Not really sure yet why you are passing "ticks" anyway, that should all be in c++ - meaning each min/max damage sent to function tick() should be calculated in code, not in Lua. Lua scripter should just pass SpellDamage(Caster, dmgType, dmgMin, dmgMax) then, without having to do math.[/quote]

I'm doing this because there is no guarantee which order the parameters will fall in from the LuaData. Take Sealed Fate again, it does initial damage and then applies a range of damage for 1 min and then another range of damage for 10 minutes after that. The LuaData is basically a vector of numbers. In a regular dot, the low and high damage could be spots 2 and 3 in the vector. For Sealed fate, its 3, 4, 5, 6, 7. When building the lua state, I may not be able to write an algorithm that handles all cases reliably.

I think this is a fairly generic tradeoff. Similarly, I am creating and passing the current runtime of the dot so that for Sealed Fate, I can put in the script if runtime > 6000 use the dmgMin2 and dmgMax2 values.

[John Adams]

Hmm, I may be confusing what you're saying, but we should absolutely know what "order" the spell_data is set up in, that's what the index value is for. Are we not storing that in the vector/map? Or is this some completely bizarre VG-spells sorcery that makes no sense in the real world?

[Faux]

[quote="John Adams"]Hmm, I may be confusing what you're saying, but we should absolutely know what "order" the spell_data is set up in, that's what the index value is for. Are we not storing that in the vector/map? Or is this some completely bizarre VG-spells sorcery that makes no sense in the real world? [/quote]

Well, I mean we know what order it is in because thats how we set up the script arguments. The data I put into the spell_data table was just in linear order of the description. I'm saying that order isn't consistent across all DoTs.

Using Devouring Shadows as a guide it would be:

dmgType, dmgMin, dmgMax.

Using Sealed Fate, it would be:

dmgType, initialdmgMin, initialdmgMax, dmgMin, dmgMax, HighdmgMin, HighdmgMax (pardon the naming conventions.

If I want to divide tick damage in code before sending to Lua so that we dont need to pass ticks and do math, it gets confusing which values to divide by tick numbers since clearly it won't be the same for the above 2 examples. I could divide indexes 2 and 3 by tick number in Devouring Shadows, but I would have to somehow know to only divide indexes 4-7 by tick number in Sealed Fate. Unless we start standardizing the data order, but I think that would be difficult to standardize.

I'm open to suggestions though.

[John Adams]

Let me think on it. Our parameters can be anything we want, so they could also include more than just numeric data. Also, we should definitely not over-complicate things by putting parameters into spell_data in the order they are in a string of text description.

I'll come up with something, or I'll concede

[Faux]

Well, in my defense, the order generally goes dmgType, dmgMin, dmgMax, but some spells have variety. I like linear order because its to see by the description, what order to put the script arguments in (for any script writers who are not familiar with the database.

[Faux]

[quote="John Adams"]Let me think on it. Our parameters can be anything we want, so they could also include more than just numeric data. Also, we should definitely not over-complicate things by putting parameters into spell_data in the order they are in a string of text description.

I'll come up with something, or I'll concede [/quote]

Its an excellent point that our parameters are not all numeric. We have bools and strings as non-numeric possibilities. This would further complicate dividing by tick numbers. I honestly think its simpler to just do the division in the lua_script, but I know how you don't want to

With so much to do, I just don't want to pass a point of diminishing returns on something like this.

Let me know what you think and we can get it done though.

[shargash]

You guys have the original question pretty well figured out, but just to be sure, the DoT damage does hit as soon as the spell does. Psis have a lot of DoTs. Here is a snippet of my combat log. All 3 DoTs in the snippet do damage with the same time stamp as spell affecting the mob.

[23:38:42] [23:38:42] Your <highlight>Temporal Shift VII</color> hits Imperial Guard.
[23:38:42] [23:38:42] The damage over time effect of your <highlight>Temporal Shift VII</color> deals <highlight>972</color> damage to Imperial Guard.
[23:38:45] [23:38:45] Your <highlight>Mindfire V</color> hits Imperial Guard.
[23:38:45] [23:38:45] The damage over time effect of your <highlight>Mindfire V</color> deals <highlight>3027</color> damage to Imperial Guard.
[23:38:46] [23:38:46] The damage over time effect of your <highlight>Temporal Shift VII</color> deals <highlight>699</color> damage to Imperial Guard.
[23:38:48] [23:38:48] Your <highlight>Compression Sphere IX</color> hits Imperial Guard.
[23:38:48] [23:38:48] The damage over time effect of your <highlight>Compression Sphere IX</color> deals <highlight>2459</color> damage to Imperial Guard.