Designing Spells

Creating the Spells and Abilities for EQ2Emulator

Moderator: Team Members

Post Reply
Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Sat Dec 14, 2013 12:20 am

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.

User avatar
John Adams
Retired
Posts: 9684
Joined: Thu Jul 26, 2007 6:27 am
EQ2Emu Server: EQ2Emulator Test Center
Characters: John
Location: Arizona
Contact:

Re: Designing Spells

Post by John Adams » Sat Dec 14, 2013 10:13 am

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.

User avatar
alfa
Team Member
Posts: 550
Joined: Fri Jul 27, 2007 6:24 pm
Location: France
Contact:

Re: Designing Spells

Post by alfa » Sun Dec 15, 2013 5:37 pm

Amazing job :)
Fight with me... Or die, like the rest.
J.A. say: "I think Xinux tried to tell me this, but I ignore most things he suggests."

User avatar
thefoof
Retired
Posts: 630
Joined: Wed Nov 07, 2012 7:36 pm
Location: Florida

Re: Designing Spells

Post by thefoof » Sun Dec 15, 2013 7:04 pm

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.

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Sun Dec 15, 2013 8:03 pm

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.

User avatar
thefoof
Retired
Posts: 630
Joined: Wed Nov 07, 2012 7:36 pm
Location: Florida

Re: Designing Spells

Post by thefoof » Sun Dec 15, 2013 8:19 pm

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).

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Wed Dec 18, 2013 12:15 pm

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

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Sat Dec 28, 2013 4:05 pm

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.

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Mon Dec 30, 2013 4:40 pm

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.

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Tue Jan 07, 2014 1:07 pm

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?

User avatar
Zcoretri
Team Member
Posts: 1642
Joined: Fri Jul 27, 2007 12:55 pm
Location: SoCal

Re: Designing Spells

Post by Zcoretri » Tue Jan 07, 2014 2:01 pm

Can you explain in more detail what the issue is? or what spell are you trying to emulate?

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Tue Jan 07, 2014 4:14 pm

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.

User avatar
Zcoretri
Team Member
Posts: 1642
Joined: Fri Jul 27, 2007 12:55 pm
Location: SoCal

Re: Designing Spells

Post by Zcoretri » Tue Jan 07, 2014 4:33 pm

I would opt for doing the latter...a new function, i could see an argument for each way though :mrgreen:

Jabantiz
Lead Developer
Posts: 2912
Joined: Wed Jul 25, 2007 2:52 pm
Location: California

Re: Designing Spells

Post by Jabantiz » Wed Jan 08, 2014 3:49 pm

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.

User avatar
thefoof
Retired
Posts: 630
Joined: Wed Nov 07, 2012 7:36 pm
Location: Florida

Re: Designing Spells

Post by thefoof » Thu Jan 09, 2014 9:32 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests