Page 5 of 9
Re: Designing Spells
Posted: Thu Jan 09, 2014 10:13 pm
by Jabantiz
I don't think the changes I have in mind will conflict with what you plan to do (I hope), less likely if I make a function that doesn't use the spells target, but thanks for the heads up.
AddSpellBonus2 was just a quick example, wouldn't name it that as it would be confusing.
Will still wait till the weekend but looks like I will be going with a new function.
Re: Designing Spells
Posted: Sat Jan 11, 2014 8:58 pm
by Jabantiz
SK 1 - 20 is done, the only spell I wasn't able to do is
Unholy Blessing as we need support for a spell to only be triggered set amount of times.
Also spell visuals are probably wrong on most of these as the spell name and effect names in spell_revamp->fighter->shadowknight were not matching like they have in all the other classes I have done.
For trigger count I am thinking something simple like AddTriggerCount(int) to set the base trigger amount and something like ModifyTriggerCount(sint) to add or subtract from it. Thoughts?
Re: Designing Spells
Posted: Sun Jan 12, 2014 12:32 am
by Jabantiz
Added the ability for AddSpellBonus() to only apply to given classes, works like a quest kill step, just add the list of classes at the end. An example of only on fighters would be
Code: Select all
AddSpellBonus(Target, Stat, BonusAmt, 1)
For every one but fighters it would be
Code: Select all
AddSpellBonus(Target, Stat, BonusAmt, 11, 21, 31)
It uses the class id's found in classes.h
Also added AddSpawnSpellBonus(), same as AddSpellBonus() but will only be applied to the given spawn
Re: Designing Spells
Posted: Sun Jan 12, 2014 4:05 pm
by Jabantiz
Started work on monks 1-20
Re: Designing Spells
Posted: Sun Jan 12, 2014 11:35 pm
by thefoof
Jabantiz wrote:For trigger count I am thinking something simple like AddTriggerCount(int) to set the base trigger amount and something like ModifyTriggerCount(sint) to add or subtract from it. Thoughts?
That sounds good, we could set up a proc for these spells and remove triggers via the proc() function call.
Re: Designing Spells
Posted: Mon Jan 13, 2014 12:18 am
by thefoof
Now that I've got a lot of the group related stuff out of the way for spells, something else that I've been mulling over are subspells, because some spells will definitely need these. One way I've thought of this is do something like ApplySubspell() from a script, and this will add a spell to a list in the spellprocess to apply instantly to whatever it's supposed to affect, skipping avoidance/resists checks, the player's spellqueue ect. Thoughts?
Re: Designing Spells
Posted: Mon Jan 13, 2014 12:25 pm
by John Adams
I thought "subspells" was the whole point of Jab implementing the procs sooner than later?
Assuming you are talking about an ability ("Kick Booty", example) that when cast, has the potential to cast "Kick Booty Harder", which is an entirely different spell with it's own set of effects, on top of all the other stuff the original spell. We did discuss this at length before. Unless it's something different.
Re: Designing Spells
Posted: Mon Jan 13, 2014 12:27 pm
by John Adams
Jabantiz wrote:For trigger count I am thinking something simple like AddTriggerCount(int) to set the base trigger amount and something like ModifyTriggerCount(sint) to add or subtract from it.
Unless you just add a field to spells (tiers?) for max_cast or something, similar to items and such with "charges" as an option?
Function is fine as well. So much in LUA now, one more isn't going to matter vs DB

Re: Designing Spells
Posted: Mon Jan 13, 2014 7:32 pm
by thefoof
John Adams wrote:I thought "subspells" was the whole point of Jab implementing the procs sooner than later?
Assuming you are talking about an ability ("Kick Booty", example) that when cast, has the potential to cast "Kick Booty Harder", which is an entirely different spell with it's own set of effects, on top of all the other stuff the original spell. We did discuss this at length before. Unless it's something different.
Yup that's what I'm talking about, the reason the proc system alone won't work is take for example a proc that causes a root effect, just applying a root on proc with a timer to get rid of it won't allow it to be cured, or show up in the player's spell effects. The proc system would be required to trigger something like that however. For spells that just have a simple damage proc what we have now works fine.
Also keep in mind that with these procs it's not something the player really "casts" it just happens instantly so we would need to bypass the spellqueue as well.
Another example are the berserker spells War Cry and Berserk Rage, these have a chance to proc a buff during certain combat actions, but again it gives the target a separate spell for this.
I'm looking for opinions on this though I haven't started it yet, this is just one way I've thought about doing it. If that sounds good with everyone I'll get it fleshed out when I can.
Re: Designing Spells
Posted: Mon Jan 13, 2014 8:06 pm
by Jabantiz
Monk 1-20 is done, only spell I couldn't do was
Lightning Palm because it has triggers as well.
Was hoping we could avoid making spells for various procs but looks like we will have to, however is there a reason why CastSpell() won't work, may need a few extra parameters for some stuff like skipping resist checks but should still work to apply the spell.
Re: Designing Spells
Posted: Mon Jan 13, 2014 8:16 pm
by thefoof
Jabantiz wrote:Was hoping we could avoid making spells for various procs but looks like we will have to, however is there a reason why CastSpell() won't work, may need a few extra parameters for some stuff like skipping resist checks but should still work to apply the spell.
I thought John said something about there wouldn't be spell dialogue if we called a spell through a spellscript but I could have imagined that

, I'll look at it in detail later tonight.
Re: Designing Spells
Posted: Tue Jan 14, 2014 2:19 pm
by Jabantiz
Going to work on Fury 1-20.
-- 30% chance to dispel when target takes damage
-- Resistibility increases against targets higher than level 34.
-- 15% chance to dispel when target takes damage
Just had an idea about how to handle this, have the spell add a defensive proc with the % chance and in the proc function kill the spell and cast the new one. Only thing we would need to add is the ability to cancel the spell from within the script, should be easy to do. Thoughts?
Re: Designing Spells
Posted: Tue Jan 14, 2014 4:33 pm
by Zcoretri
Jabantiz wrote:Going to work on Fury 1-20.
-- 30% chance to dispel when target takes damage
-- Resistibility increases against targets higher than level 34.
-- 15% chance to dispel when target takes damage
Just had an idea about how to handle this, have the spell add a defensive proc with the % chance and in the proc function kill the spell and cast the new one. Only thing we would need to add is the ability to cancel the spell from within the script, should be easy to do. Thoughts?
How come it's not done already then?
How is the resistibilty handled?
Re: Designing Spells
Posted: Tue Jan 14, 2014 5:08 pm
by Jabantiz
No clue how to handle resistibility, would probably have to be handled server side with normal resist checks. Will look into a lua function to kill the spell.
Also fury 1-20 is done, only issues were the same from other classes, mainly see stealth and bonus damage to a spawn type. Going to start warlock 1-20.
Re: Designing Spells
Posted: Thu Jan 16, 2014 3:11 pm
by Jabantiz
I added
CancelSpell() to kill a spell early so we should now be able to do these roots. It should be something like this
Code: Select all
function cast (Caster, Target)
SetSpeedMultiplier(Target, 0.0)
AddProc(Target, 2, 5.0) -- %5 chance to break
end
function remove(Caster, Target)
SetSpeedMultiplier(Target, 1.0)
end
function proc(Caster, Target, Type)
if Type == 2 then
CancelSpell()
CastSpell(snare spell goes here)
end
end
This code is untested but I have tested CancelSpell and it does kill the spell early.