Implementing: Procs

[John Adams]

One more decision, see if you agree. Lots of spells seem to have what I had been calling "sub-spell" or an effect that procs conditionally -

On a melee hit this spell may cast Furious Assault on target of attack. Triggers about 2.0 times per minute.

• Inflicts 9 - 16 melee damage on target encounter

I was considering making these into spells of their own so they can be re-used whenever we need... but the more I think about it, that might be overkill too. Should we just process this in the script of the originating spell? Ie., queue up a check that on melee hit, fire this baby off for damage between 9 and 16, up to twice per minute?

I have no idea the specs of "Furious Assault", but if the indented bullet is any indication, it's a straight forward melee damage to all targets in the encounter. Though I am sure there are other "procs" that are far more complex... and there are many of these... so I'd like to decide sooner than later.

Thanks

[thefoof]

I was considering making these into spells of their own so they can be re-used whenever we need... but the more I think about it, that might be overkill too. Should we just process this in the script of the originating spell? Ie., queue up a check that on melee hit, fire this baby off for damage between 9 and 16, up to twice per minute?

I have no idea the specs of "Furious Assault", but if the indented bullet is any indication, it's a straight forward melee damage to all targets in the encounter. Though I am sure there are other "procs" that are far more complex... and there are many of these... so I'd like to decide sooner than later.

Thanks

You're the data guy so whatever you think will work. If it's something we can just run from scripts we can always just write one script per subspell and include it in spells that use that effect. We don't have proc support (I think? ) so it's hard for me to lean either way without knowing that implementation.

[Jabantiz]

I would vote for separate spells as it would make proc's easier to implement, could also reuse the proc for other spell scripts instead of having the same code in multiple scripts for the same proc.

Kind of off topic but I had a plan for procs but never got around to it, basically it was just 2 map's in the entity class, one for offensive procs the other for defensive. It was basically map<%chance, spell id> and on a hit, or being hit check the appropriate map and cast the given spell if we want the proc to go off.

[Zcoretri]

My vote would be to have them as seperate spells as well.

[John Adams]

You guys are trying to kill me

I would vote for separate spells as it would make proc's easier to implement, could also reuse the proc for other spell scripts instead of having the same code in multiple scripts for the same proc.

I think what theFoof was implying was still write them as separate scripts, but whenever they are needed, just include the LUA into the parent spell that procs it (maybe?)

Example:

Code: Select all

dofile("SpawnScripts/Generic/GenericVoiceOvers.lua")

Unless you are saying the way you intend to process procs will require a completely unique Spell_ID, params and Script? If so, I can head down that road... reluctantly. I was hoping for a short cut.

Couldn't we also add a lua function to cast, tick and remove... called "proc"? process them that way?

[Zcoretri]

Might have to test which way will perform better? if that is all possible

[Jabantiz]

Unless you are saying the way you intend to process procs will require a completely unique Spell_ID, params and Script? If so, I can head down that road... reluctantly. I was hoping for a short cut.

Yes that is what I had intended, was an early concept floating around in my mind that I never got to working on though.

Couldn't we also add a lua function to cast, tick and remove... called "proc"? process them that way?

Never considered this, surprising as I am usually the one looking to lua for new stuff not you. We could add "proc" to item and spell scripts pass it the item/spell, caster, target, type, and a roll value?

Code: Select all

function proc(Item, Caster, Target, Type, Roll)
    if Type == Offensive and Roll > 90 then
        -- Do proc damage
    end
end

Item/Spell = for use in the script just incase we need it for something
Caster = spawn casting the proc
Target = spawn being hit by the proc
Type = type of proc to trigger, offensive or defensive
Roll = float, random number from server core from 0 - 100 (float for smaller chances then 1%)

The one issue I see with this is on every single hit we will have to loop through active spells and equipped items calling this new "proc" function on all of them. This was a quick design off the top of my head after reading your post so probably needs to be refined some...

Any one else have thoughts on this or another possible way to do procs? I actually like John's idea of a lua function more as it would allow us more flexibility then what I had originally planned.

[John Adams]

I would vote for separate spells as it would make proc's easier to implement, could also reuse the proc for other spell scripts instead of having the same code in multiple scripts for the same proc.

Now that I've done a few of these, here's a problem I just ran into while trying to implement separate spells; it seems the called spell visuals/text does not display back through the chain, so I have no feedback if it's even working. If I /useability 5001, I see the effect and spell text from spell 5001 (Knockdown). But if I cast it as the proc of Bash, I see only Bash's effects.

Points against separate spells:

• No visual effects in SpellCast() spells
• No text feedback in SpellCast() spells
• Console not reporting that a second spell was even cast(ed)
• Enormous effort to manually create 1 new spell per proc (spells, spell_tiers, spell_data, spell_classes and LUA) vs. just using the parameters that already exist in the current spell...
• Troubleshooting: Spell 2 errored, well who called it? I dunno, let's search 17,000 scripts for where it is SpellCast()'d
• A whole new spell just for 1 lua function?

  Code: Select all

  function cast(Caster, Target)
      --Stuns target
      AddControlEffect(Target, 4)
  end
  
  function remove(Caster, Target)
      RemoveControlEffect(Target, 4)
  end

• Spells are going to be very complex as it is... and just fiddling with the first level of all classes spells has taken me over a week. There's no way I will get 10,000 spells and 40,000 tiers done if I have to stop and add new spells each time there's a subspell effect.
• If Proc's was the reason, then I believe I suggested an alternative to the original thought, and would like to pursue that when it's time.

I realize ultimately it is my call, but I want [any of] you to tell me (aside from redundant lines of LUA) if there is any actual reason to not include Knockdown inside Bash as a combined spell (just 1 example).

[xinux]

If i knew what would work best i would gladly tell you.

[John Adams]

Just agree with me then, you'll live longer.

[Jabantiz]

When I said proc I was thinking of a buff or debuff spell that can trigger multiple times over a given period. In the case of bash, knockdown is just a component of that spell that goes off right away, I didn't think of that as a proc and I agree that there is no reason for that to have its own spell.

Also I am leaning towards the lua idea of a proc function instead of separate spells now, was waiting for feedback on my post a couple up before developing it.

[John Adams]

Right on. If you don't think it's too involved, go ahead with your lua proc idea, see how it pans out before I get too far into making these separate spells. I'll stop for now, I only have a few.

Sorry, I meant to respond to your question above

The one issue I see with this is on every single hit we will have to loop through active spells and equipped items calling this new "proc" function on all of them.

How crazy busy will this get in (worst case scenario) there are 100 players and 1,000 spawns and multiple zones all going on at once, casting spells and proc'ing things? If you suspect a performance problem, we should talk it out more.

But as far as your initial parameters, that sounds like a good place to start. We can always embellish from there. Would these also become spell_data entries, I presume? Things we'll be making up, regardless? Or instead of params, we know they're going to be static value, perhaps.

[Jabantiz]

We can have the spell data be passed as well, the first time around I am just going to assume hardcoded info for now to see the impact this will have.

I do need some clarification on how proc's work though. I assume offensive procs (procs that go off when you hit something) will only come from spells and the actual weapon, there are none from armor or anything correct? Also these will only go off when you actually hit, if you miss they won't? Is it also possible for the proc to go off on each hit of a multi attack?

Can multiple defensive procs (procs that go off when you are hit) go off at once, say you have a proc on a helm, chest, and from a spell, is it possible for all 3 to go off or can only 1 go off per hit?

EDIT: Items don't have lua data so we couldn't pass data as params so all item procs will probably have to be hard coded, still have the option for procs from spells to pass the data though

[thefoof]

We can have the spell data be passed as well, the first time around I am just going to assume hardcoded info for now to see the impact this will have.

I do need some clarification on how proc's work though. I assume offensive procs (procs that go off when you hit something) will only come from spells and the actual weapon, there are none from armor or anything correct? Also these will only go off when you actually hit, if you miss they won't? Is it also possible for the proc to go off on each hit of a multi attack?

Can multiple defensive procs (procs that go off when you are hit) go off at once, say you have a proc on a helm, chest, and from a spell, is it possible for all 3 to go off or can only 1 go off per hit?

There are offensive procs from armor pieces, actually.

Procs can only go off on the first hit, multiple procs can go off at once but not the same spell, having multiple procs of the same spell means each has a chance to proc..but I don't think it can happen at the same time (could be wrong, it would be extremely rare if they can).

Buff procs of the same name also never stack unless the description specifically states that it does...however procs like Stoneskin and Stoneskin II will stack. You also have to take into consideration that some procs are conditional in the type of hit, for instance a proc may be for if a spawn is blocked specifically, or on a beneficial spellcast.

Most offensive procs (I don't know if all) can only be triggered by the primary weapon (or ranged weapon) if dual wielding. If a proc says your proc triggers 1.8 times per minute, that means based on the delay of your weapon it should proc about 1.8 times per minute, I'm unsure if haste changes the proc rate or not.

[thefoof]

Also a design suggestion, procs are super complicated . Rather than looping through all equipped items and spells, maybe we just make a list and save it on entities. Something like map<int8 (ProcType), vector<Proc*>*>, and have the datastruct for Proc contain chance to proc and the spell itself, along with any other variables it needs (stacks with itself). Then make a call to iterate through the list on certain things happening in combat code.

When an item is equipped call to add a proc, when unequipped remove it, like we do with spell bonuses. Same in spell scripts.