Page 4 of 9

Re: Designing Spells

Posted: Sat Dec 14, 2013 12:20 am
by Jabantiz
Your right, hadn't considered reapplying group buffs. We could add a param, like we were going to, but for class req and only apply that buff if they meet the req, however in this case of all except fighter we would need to call AddSpellBonus 3 times, for priest, mage, scout. This will require some more thought.

As for illusion I am doing basic support and have it working, including taking into account the player choosing to hide the illusion, just going to make some lua functions for it and will leave it at that for now.

Re: Designing Spells

Posted: Sat Dec 14, 2013 10:13 am
by John Adams
You guys are kicking ass here, with spell definitions as well as adding needed core functionality. I was hoping this task would be enlightening ;)

I apologize for not doing my own spells yet, but hopefully I'll get my classes done this weekend. Since I broke the DB Editor (for everything BUT Spells) I figured I'd better focus on that first. Hopefully finishing the Spawn/Quest editors this weekend.

Re: Designing Spells

Posted: Sun Dec 15, 2013 5:37 pm
by alfa
Amazing job :)

Re: Designing Spells

Posted: Sun Dec 15, 2013 7:04 pm
by thefoof
Jabantiz wrote:Your right, hadn't considered reapplying group buffs. We could add a param, like we were going to, but for class req and only apply that buff if they meet the req, however in this case of all except fighter we would need to call AddSpellBonus 3 times, for priest, mage, scout. This will require some more thought.

As for illusion I am doing basic support and have it working, including taking into account the player choosing to hide the illusion, just going to make some lua functions for it and will leave it at that for now.
Possibly add a value in spells to enable a check on the buffloop, that instead of returning true/false just applies the buff in the check itself? We should probably add another value to spells to disable the reapplying of group spells, at first I thought just adding a check for duration_until_cancelled as well but there are spells that wouldn't really work on still, such as tortoise shell.

Re: Designing Spells

Posted: Sun Dec 15, 2013 8:03 pm
by Jabantiz
Going to start swashbucklers, 1-20 again.


We could have AddSpellBonus take multiple params at the end for class req, add a bitmask to the bonus struct and finally check the entities 3 classes against the bitmask when applying or reapplying the bonus. That is all I have come up with so far, still trying to think of a different way.

Re: Designing Spells

Posted: Sun Dec 15, 2013 8:19 pm
by thefoof
Jabantiz wrote:We could have AddSpellBonus take multiple params at the end for class req, add a bitmask to the bonus struct and finally check the entities 3 classes against the bitmask when applying or reapplying the bonus. That is all I have come up with so far, still trying to think of a different way.
That, or possibly add a value in spells to enable a check on the buff loop, and add the spellbonuses in the script itself from the check called. Your way would probably be more efficient. Another thing we need to add is a way to disable the loop for certain spells, but that's easy :P.

For example the group wards from a shaman should only be applied once to targets in range on cast, but spells such as Tortoise Shell (aoe blocker) should be applied/removed when stepping in range, regardless of if they were in range on first cast (while the spell still has a duration).

Re: Designing Spells

Posted: Wed Dec 18, 2013 12:15 pm
by Jabantiz
Ran into an instance where target would have to be overridden on AddSpellBonus, also see issues with proc and AddSpellTimer, mainly Target in proc isn't the spells target and target in the spell timer is the spells target, will need to find a way to override it for the timer
Jabantiz wrote:Going to start swashbucklers, 1-20 again.
Done

Re: Designing Spells

Posted: Sat Dec 28, 2013 4:05 pm
by Jabantiz
Jabantiz wrote:Ran into an instance where target would have to be overridden on AddSpellBonus
I have been thinking about this a lot an I can't think of a good way to override the target, the two possible solutions I have is add a bool param to the function to override, would have to be before class req's though so would have to be set in order to use class req's.

The other is to just make another function like AddSpellBonus2() or AddSpellBonusToTarget() that would not use the spell's targets and only use the provided target. I am honestly not to fond of either solution.

Re: Designing Spells

Posted: Mon Dec 30, 2013 4:40 pm
by Jabantiz
John Adams wrote:Just looked in my old parser logs:

...

I do not see any Spells from that log, just AA, Traits, Trainings. And I could not find Grim Embrace on SOE data either, probably because it's not a spell a player gets.
I just opened one of these logs in anal and the vast majority of it doesn't parse correctly, mostly ends up in unknown opcode, might be why it didn't get the info from the parser.

Re: Designing Spells

Posted: Tue Jan 07, 2014 1:07 pm
by Jabantiz
Jabantiz wrote:
Jabantiz wrote:Ran into an instance where target would have to be overridden on AddSpellBonus
I have been thinking about this a lot an I can't think of a good way to override the target, the two possible solutions I have is add a bool param to the function to override, would have to be before class req's though so would have to be set in order to use class req's.

The other is to just make another function like AddSpellBonus2() or AddSpellBonusToTarget() that would not use the spell's targets and only use the provided target. I am honestly not to fond of either solution.
Any thoughts on this? Modify the original function or make a new one that doesn't use spells targets?

Re: Designing Spells

Posted: Tue Jan 07, 2014 2:01 pm
by Zcoretri
Can you explain in more detail what the issue is? or what spell are you trying to emulate?

Re: Designing Spells

Posted: Tue Jan 07, 2014 4:14 pm
by Jabantiz
The first issue is AddSpellBonus() will apply the bonus to the targets of the spell that called this script, doesn't matter what you provide in the target param. There are some cases where we will want to apply a spell bonus to another spawn and we can't so we need to force AddSpellBonus() to ignore the spells targets and use the spawn provided. I would normally just add a bool to the end to force it to use the provided spawn but the second issue has made me try to think of another way.

The second issue is we need AddSpellBonus() to apply the buff to only certain classes, the best way I can think of doing that is to just provide a list of class id's at the end of the function, kind of like how we add spawns in a kill step for a quest. This list of class id's would have to be the last params of the function, so the bool solution for the first problem would have to be included every time when there is class restrictions.

Original idea of a bool to force a target would look like this

Code: Select all

function cast(Caster, Target)
    local Target2 = GetTarget(Target) -- Get target of the target
    if Target2 ~= nil then
        AddSpellBonus(Target2, Stat, Val, true)
    end
end
Code like this will probably never be used but is an easy to follow example, adding the bonus to the target of the spells target.

Adding the class id list on top of that would look something like

Code: Select all

function cast(Caster, Target)
    AddSpellBonus(Target, Stat, Val, false, 11, 21, 31) -- Add the bonus to all but fighter classes
end
Notice you would need the false before the class list

The other option would be a new function that just ignores the spells targets and uses the provided spawn to apply the bonus

Code: Select all

AddSpellBonus(Target, Stat, Val)
AddSpellBonus2(Target2, Stat, Val) -- ignore the spells targets and use the provided one

AddSpellBonus(Target, Stat, Val, 11, 21, 31)
AddSpellBonus2(Target2, Stat, Val, 11, 21, 31) -- ignore the spells targets and use the provided one
In both cases the params after Val would be optional, I am honestly not a fan of either way but they are the only options I have been able to think of so want input from others before I implement it.

Re: Designing Spells

Posted: Tue Jan 07, 2014 4:33 pm
by Zcoretri
I would opt for doing the latter...a new function, i could see an argument for each way though :mrgreen:

Re: Designing Spells

Posted: Wed Jan 08, 2014 3:49 pm
by Jabantiz
Started work on shadow knight spells level 1 - 20.
Zcoretri wrote:I would opt for doing the latter...a new function, i could see an argument for each way though :mrgreen:
So can I, I can also see how either option can cause confusion and is why I am not fond of either option. Will wait until the weekend to start work on the modifications to the function so others can voice their opinion.

Re: Designing Spells

Posted: Thu Jan 09, 2014 9:32 pm
by thefoof
Just an FYI for Jab mostly, I plan on putting spell targets in a Mutex and get proper removal of targets working and cancelling of spells in the next couple days if I get time (I should have time to get at least this done by the time the weekend is over). Also I would opt towards using a separate function as the constantly changing syntaxes does get confusing (but obviously necessary), I would say maybe change the name to AddSpawnSpellBonus() or something like that, rather than spellbonus2 though.