• Implementing: Group Combat

Posted: **Tue Dec 03, 2013 3:55 am**

Starting this thread for anything and everything group combat related anybody does, as well as any planning that needs to be laid out.

Tasks

*~~Implied Targeting~~ - DONE

*~~Group buffs~~ - Done*(it works but not sure what else it will need yet)

*~~Detrimentals/cures~~ - DONE

*Resurrection - Almost done*(need to figure out how to get the rez animations to work right)

*~~Raid buff support for groups~~ - basic support

Posted: **Tue Dec 03, 2013 4:03 am**

Code for the following on dev svn

*Group spells are now properly added/removed only when in range of the caster, and more often than just when joining or leaving a group.

*I set a rule for the timer on how long to check for these updates, the rule name is GroupSpellsTimer, I defaulted it to 1 second. (NOTE: Besides this timer the player will be updated instantly anyway after joining or leaving a group.)

*I also fixed a bug where when leaving a group, a player that had cast a group spell would also have that spell removed from themselves.

EDIT: Found another bug which I'm assuming existed before these changes, sometimes when leaving a group where a player had a group buff active a crash could occur, this is fixed now.

Posted: **Tue Dec 03, 2013 11:11 pm**

So the next feature for this that pops into my mind is detrimentals/cures, I'm thinking this should be vectors with a detrimental struct rather than a hardcoded size but what are other's thoughts about this? The reason I prefer a vector vs hardcoded size atm is...hardcoded is hardcoded and who knows how many dets a player could possibly have on them.

For this same reason we'll need to eventually increase the number of slots we have for spell effects, just because the client's UI has 45 slots or w/e doesn't mean that effects past that number don't change a player's stats, but we obviously don't have to worry about that for awhile as I don't see anybody getting more than 45 spells right now

Posted: **Thu Dec 12, 2013 4:55 am**

Just committed some initial code to support resurrections, here are the features

.

1. Rezes are called from spellscripts only (planned on setting it up for spell or normal scripts but waaay too many params) the syntax is

Resurrect([float] hp_perc, [float] power_perc, [int8] send_window, [Spawn*] target, [string] "heal_name", [int8] crit_mod, [int8] no_calcs)

Every single param is basically optional, however if you want your target to rez with more than 1 hp, I suggest you set atleast the hp/power params

. These values are used as percentage of max hp/power. The if set to 1 the send_window param will send a choice window asking the player if they want the rez, if left 0 it just automatically accepts (only wanted for deathsaves really).

If target is set it overrides the rest of the spells server generated targets. The "heal_name" name string is the name of the actual heal spell, the server will send the spell's original name if not set. Crit_mod and no_calcs are the same as for spelldamage/spellheal, set crit mod = 1 to force crit, 2 to disable. No_calcs will disable all potency checks ect.

2. When a player accepts a rez, they must be within range of the caster or it will not work (the window will be resent don't worry

).

3. After accepting a rez the player will be ported to the caster.

NOTES: I haven't figured out how to get the spell visual to display correctly after the rez, I tried sending the packet again on rez but didn't work, if someone has any other ideas on this go for it

Wiki on this and the other stuff I've written this week will be coming later today.

Posted: **Thu Dec 12, 2013 12:49 pm**

thefoof wrote:NOTES: I haven't figured out how to get the spell visual to display correctly after the rez, I tried sending the packet again on rez but didn't work, if someone has any other ideas on this go for it

If the animation is the same for all rez's and there is a visual_state for them you could try the delayed action states

Posted: **Thu Dec 12, 2013 1:14 pm**

First, excellent work on the C++ stuff lately, Foof. You make a daddy proud

And not that I want to sound like I am questioning every change lately, but some of the things we're doing seem so very off-the-wall different than usual. Is this because we're running into majorly complex scenarios?

For example, if we know people need at least 1hp/power when we rez, why not just ensure that is the minimum?

And why is (Caster, Target) seeming to slide all over the parameter list? Seen this elsewhere as well.

And lastly, what's up with all this "heal_text" I see you and Jab doing lately? Are we parsing text inside functions to branch actions? Color me novice, but that doesn't seem horribly efficient or safe. Unless this is echoing something back somewhere, which I think Jab tried to explain to me before.

Understand, I am not being critical. I'm trying to comprehend why things are getting so complex, and I predict the answer will be "because Emu was retarded up until now"

Thanks, and keep up the great work!

JA shouts, "Rez pzl!"

Posted: **Thu Dec 12, 2013 1:31 pm**

John Adams wrote:For example, if we know people need at least 1hp/power when we rez, why not just ensure that is the minimum?

Can't answer for foof on why he did it the way he did but it would make sense to give a min of 1hp/power on rez if no value is given. Rezzing at 0hp may also cause issues in the server as we do a lot of checks to make sure hp is above 0

John Adams wrote:And why is (Caster, Target) seeming to slide all over the parameter list? Seen this elsewhere as well.

In a spell script only function Target is useless as that param is almost never used, we grab the target list from the spell itself, we only really need a Target param when we want to override the spells target list. Caster can also be pulled from the spell. If the function is to be used outside a spell script then Caster and Target will be needed.

John Adams wrote:And lastly, what's up with all this "heal_text" I see you and Jab doing lately? Are we parsing text inside functions to branch actions? Color me novice, but that doesn't seem horribly efficient or safe. Unless this is echoing something back somewhere, which I think Jab tried to explain to me before.

I haven't looked at foof's code but in my case for ProcDamage() I use that to override the spell text so when the proc goes off it will use the name you provided instead of the original spells name

Posted: **Thu Dec 12, 2013 3:57 pm**

Jabantiz wrote:
John Adams wrote:
John Adams wrote:And lastly, what's up with all this "heal_text" I see you and Jab doing lately? Are we parsing text inside functions to branch actions? Color me novice, but that doesn't seem horribly efficient or safe. Unless this is echoing something back somewhere, which I think Jab tried to explain to me before.
I haven't looked at foof's code but in my case for ProcDamage() I use that to override the spell text so when the proc goes off it will use the name you provided instead of the original spells name

Just clarifying this point that yes the heal_text is just for the heal packet, alot of rezes (almost all) use subspells on live, so the actual heal portion has a different name. This is just an appearance thing for combat logging. Everything else jab said was correct as well.

Also I did set hp to default to 1 basically because our alive checks check for hp > 0, the heal_amt is cast as an int32 so there shouldn't be any situations where the heal amt is less than 1. Power I left alone to be 0 as I think it is "possible" to have 0 power without causing any issues.

Lastly, the order is mainly because I think the first 3 will be used way more often than the latter params.

Posted: **Thu Dec 12, 2013 4:32 pm**

Okay, that all made sense (believe it or not)

Posted: **Sat Dec 21, 2013 6:07 am**

Just committed my initial code for detriments/cures. This is surprisingly functional, it isn't finished yet though, tweaks still need to be made with cancelling spells in the spellprocess.

Features

*Detriments will show in the player's ui

*Detriments have 5 useable types right now, custom types could be added easily, Trauma = 1, Arcane = 2, Noxious = 3, Elemental = 4, Curse = 5

*You may also assign a control effect so the det may be cured by special spells that only handle control spells, use the same control effect types used when adding an effect

*The detriment spell window functions

*On a cure the dispell/cure packet will be sent, the spell effect removed from the target - removing the effect from caster and spellprocess still needs work

*LUA functions CureByType() and CureByControlEffect(), both must be used in a spellscript and have the same syntax : ([int8] cure_count, [int8] cure_type, [string] "cure_name", [Spawn] target) where cure_count is the amount of dets the spell is allowed to cure, cure_type is either the detriment type or control effect type, depending on which function you're using, "cure_name" is an optional name override for the cure packet, target is optional and will override the spell targets if used.

***Extra Dev Info***
I added 3 new values to the spells table for this: det_type, control_effect_type and uncurable. Set det_type and control_effect_type to the desired types when needed, uncurable to 1 if you want the spell to be uncurable. Also note detriments will ONLY be applied if a det_type is set AND the spell's duration is > 0.

Posted: **Sat Dec 21, 2013 12:52 pm**

thefoof wrote:removing the effect from caster and spellprocess still needs work

In wards when I want to kill the spell early, from ward depleting, I call this and it seems to remove everything (calls the lua remove function and clears the icons)

Code: Select all

GetZone()->GetSpellProcess()->DeleteCasterSpell(ward->Spell);

Note: ward->Spell is a LuaSpell*

Is that what you are looking for?

Posted: **Sat Dec 21, 2013 3:47 pm**

Jabantiz wrote:
thefoof wrote:removing the effect from caster and spellprocess still needs work
In wards when I want to kill the spell early, from ward depleting, I call this and it seems to remove everything (calls the lua remove function and clears the icons)
Code: Select all
GetZone()->GetSpellProcess()->DeleteCasterSpell(ward->Spell);
Note: ward->Spell is a LuaSpell*

Is that what you are looking for?

That would work for spells with only 1 target, the issue is more with green aoes and things of that nature, it shouldn't be too hard to do I just wanted to get this code committed so I didn't bork anything up

Posted: **Sat Dec 21, 2013 5:02 pm**

That actually uses the lua spells targets so it will remove from all targets of the spell

Code: Select all

bool SpellProcess::DeleteCasterSpell(LuaSpell* spell){
	bool ret = false;
	if(spell) {
		if (active_spells.count(spell) > 0)
			active_spells.Remove(spell);
		if (spell->caster) {
			spell->caster->RemoveMaintainedSpell(spell->spell);
			for (int32 i = 0; i < spell->targets.size(); i++) {                <------ Removes spell from all targets

Posted: **Sat Dec 21, 2013 6:33 pm**

Jabantiz wrote:That actually uses the lua spells targets so it will remove from all targets of the spell

That's exactly what I want to avoid though

, curing a det on a single player shouldn't cancel every det originating from the same spell at once, but rather just remove the effect from that player. Then the spell should be removed from the caster's maintained if the targets that are left == 0.

Posted: **Sat Dec 21, 2013 6:53 pm**

I see now, sorry misread the problem, yea we would need support for that.

Implementing: Group Combat

Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Resurrection

Re: Resurrection

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Detriments and Cures

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat

Re: Implementing: Group Combat