Implementing: Group Combat

[John Adams]

Couple things -

*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

Adding these fields to the editor today, need to know what the options for control_effect_type are. I thought it was a toggle because you made it a tinyint(1) which is usually only 0 or 1, but your det_type is also a tinyint(1) and is definitely > 1.

I would prefer data types be tinyint(1) for bool, and tinyint(3) for anything not true/false but <= 255. For future reference.

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.

Do not be afraid to be descriptive. `det_type` makes sense to you, but `detriment_type` is clearer if that's what it truly is.

Also, I am not sure what I am seeing in code, where you load the `det_type` data -

Code: Select all

data->det_type                  = (result.GetInt8Str("det_type") == 1);

Do you mean this to be turned into a bool?


`uncurable`? That ranks right up there with casted_on `incurable` might have been more accurate.


Our schema is pretty old, so lots of stuff is typed wrong only because we had no idea originally what the data would involve. When in doubt, ask your data guy... aka, me.

I will fix a few of these issues today, because I needed a commit for 73000 anyway.

[thefoof]

Type 1 = Mez, 2 = Stifle, 3 = Daze, 4 = Stun.

The setting det_type as a bool is a copy and paste error, I (of course) was using trauma dets (type 1) to test so that problem didn't arise. Will go ahead and commit a fix for this. As for the det_type name, I don't really care what it's named so if detriment_type would be better go for it.

The uncurable thing, keep in mind I grew up in GA lol that's how people talk. And damnit untreatable is correct! English r confusing. But again, go ahead and change this db side, (I do like proper spelling/grammar, this one just got past me). I'm going to add further support for removing the spells from targets sometime this week when I have time so I'll fix the variable name serverside when I do that.

[thefoof]

Changed:Revamped the group buff loop
Fixed: fixed a bug where only one spellbonus would be applied per spell in the buffloop
Added: implied target support for group/raid ae - initial target defaults to caster
Added: a mutex for spell targets
Fixed: mispelled incurable as uncurable
Added: some support for removing targets from spells upon curing, not completed yet



Just committed the changes listed above, I rewrote the buffloop and moved it to the world process instead of calling it individually from clients, this should be a lot more efficient and easier to modify when we need to. Everything else is fairly self explanatory, the spell target mutex can be accessed through Spell::GetTargetMutex(), I won't guarantee I got every single place that could use this mutex but should be good enough for now.

[John Adams]

And, linux won't compile... which I shake my finger at you mister because I know you have a linux server

g++ -c -Wall -g -march=i686 -O -pthread -pipe -DFX -D_GNU_SOURCE -DINVERSEXY -DEQ2 -DWORLD -I/usr/include/mysql -I/usr/mysql/include -I./LUA/include Combat.cpp -o Combat.o
In file included from Combat.cpp:32:
SpellProcess.h:368: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
SpellProcess.h:368: warning: suggest parentheses around ‘>>’ expression
SpellProcess.h:368: error: ‘remove_target_list’ was not declared in this scope
SpellProcess.h:368: error: ‘>>’ should be ‘> >’ within a nested template argument list
make: *** [Combat.o] Error 1

The new stuff at the end if SpellProcess.h

Beware your >> vs > > (with a space)


Edit: Similar issue in SpellProcess.cpp, line 88. Fixing both now.

[thefoof]

Thanks for fixing the linux issues John. I bought myself a new computer and haven't setup vmware yet sorry about that.

Just committed more support for removing targets from spells. In the process I found and fixed a crash bug which I assume has been around forever where if a spawn was killed with a spell that had a longish duration (atleast 30ish seconds) left when the spawn was killed, the spellprocess would use this spawn later after it was deleted and cause a crash. I remedied this by removing targets from spells upon death, as well as now cancelling all spells on an entity when dead.

Removing all targets from a spell should correctly remove the spell from the caster's maintained as well now.

[thefoof]

Next on the agenda are cure levels - I totally forgot about this. In other words most cures have levels associated with them to the max level effect they can cure. This should be super easy to patch in. Will require a new param for my cure LUA functions though, shouldn't be a problem as I don't know if it's even been used yet.

[thefoof]

Added: cure levels
Added: toggle spell recast now starts after the spell ends
Added: interrupted spells no longer have a recast timer
Changed: you can now cancel maintained hostile spells
Added: you may now cancel the spellcast of an uninterruptable spell


Just committed the above changes. New syntax for the 2 cure functions is (cure_count, cure_type, "cure_name", cure_level, target_override), the params are the same except target_override moved to the 5th position.

Also added some checks so that interrupted spells don't have a recast and some more toggle spell support, since it was only like 5 lines total. Cancelling a spellcast with the esc key will override whether a spell is interruptable as well.

[thefoof]

Just committed support so that player pets can receive group buffs when their owner is in a group, I need to figure out how to handle group buffs while not in a group for owners/pets before I can add support for the pet's buffs to apply to their owner and group.

Also fixed a ton of stability bugs, added a change I (hope) will fix the crash caused by players being deleted in a client. Trying to call the functions RemoveDazeSpell(), RemoveStunSpell() and RemoveStifleSpell() when no spells were in these lists would cause a zone deadlock 100% of the time, RemoveMezSpell() was fine. I changed these over to MutexLists and fixed the logic errors. Control effects will also be removed when a spell is cured now.

[Jabantiz]

Quick question on cures, is there a way to cure more than a single type?

For example, Heal Servant

Dispels (Y) levels of any hostile effects on target

Cures any type but curse spells I believe

Another example would be Indomitable Will

Dispels (X) levels of any physical and arcane hostile effects on caster

Cures physical and arcane

On both of these I believe it will only cure 1 spell

[thefoof]

You can make multiple calls to the cure function and it shouldn't cause any ill effects, since spells are only allowed to have 1 det type and cures typically cure 1 or 2 of all detrimental effects that the spell supports. IE, if you cast the normal cure spell it will cure 1 detriment of each type. That could be a cool custom feature though, there's only a few cure spells in the game so wouldn't be a big deal to change it. Let me know if this is something we may want.

If you know for a fact that those spells only cure 1 effect total though I can change it regardless, just speaking from the toons I've played in the past cures didn't seem to behave that way

[Jabantiz]

It has been so long since I played live so not sure on how cures work, and never really watched them when I did play...

Will just go with multiple calls for each type, quick easy way to do it.

[Zcoretri]

I remember that one single cure call will cure more than one detriment as long as the cure was sufficient to do so i.e. it had enough cure levels to cure the sum of the detriments.