Regen AAs (discussion)

[AndMetal]

I didn't realize it until just now, but a lot of these AAs are already being utilized using the aa_effects (http://www.eqemulator.net/wiki/wikka.php?wakka=EQEmuDBSchemaaaeffects) table in the database, so as a result, we're double dipping the benefit.

They use the ZoneDatabase::FillAAEffects() function in zone/AA.cpp to apply any stats, etc, basically as a spell without any stacking issues. So, it looks like a lot of these AA checks will need to be taken from the source and integrated into the DB, then any missing spell effects will just need to be added into the source.

Anyways, mainly wanted to make note of this so I didn't forget...

Edit: actually, now I'm confused, because the source indicates it's just for the client's benefit:

/*
Every AA can send the client effects, which are purely for client side effects.
Essentially it's like being able to attach a very simple version of a spell to
Any given AA, it has 4 fields:
skill_id = spell effect id
slot = ID slot, doesn't appear to have any impact on stacking like real spells, just needs to be unique.
base1 = the base field of a spell
base2 = base field 2 of a spell, most AAs do not utilize this
example:
skill_id = SE_STA
slot = 1
base1 = 15
This would if you filled the abilities struct with this make the client show if it had
that AA an additional 15 stamina on the client's stats
*/

[ChaosSlayer]

yeah it would be nice if i could reattach any given AA to any given spell wihout doing any recoding :D

[KLS]

Yes those are basically what the client will show. Just because you have it in the db there wont mean it will be implemented. Like if you want the client to have an enduring breath AA you set it to happen there. Yet if you want something like spell casting mastery it has to happen in the server. Some need both clientside and serverside effects so you do both.

[AndMetal]

Ok, that makes sense. I am a little curious though as to way we don't iterate through these on the server side instead of adding manual code changes for each AA. Maybe too much overhead from having to parse through each AA?

[KLS]

I had a plan to do it tbh but never got around to implementing it. Someday we probably will, it will require identifying and implementing a lot of missing spell effects though.

[AndMetal]

That sounds like a good place for me to start :-)

If we can get it moved to a system that iterates through the values, we can always have a default case, just like we do currently in spell_effects.cpp, that doesn't do anything. That way, we can get the AAs in, then focus on the spells effects.

Just thinking out loud, but from what I can see & remember, bonuses for the client are called from Client::CalcBonuses() in zone/bonuses.cpp:

void Client::CalcBonuses()
{
_ZP(Client_CalcBonuses);
memset(&itembonuses, 0, sizeof(StatBonuses));
CalcItemBonuses(&itembonuses);
CalcEdibleBonuses(&itembonuses);

RecalcWeight();

CalcSpellBonuses(&spellbonuses);

CalcAC();
CalcATK();
CalcHaste();

CalcSTR();
CalcSTA();
CalcDEX();
CalcAGI();
CalcINT();
CalcWIS();
CalcCHA();

CalcMR();
CalcFR();
CalcDR();
CalcPR();
CalcCR();

CalcMaxHP();
CalcMaxMana();
CalcMaxEndurance();

rooted = FindType(SE_Root);
}

so we already have functions for the big stuff. I would think we could then start with a similar function for AAs. I'm sure we could have it piggyback spellbonuses, although it might be better to add aabonuses into the Mob class in zone/mob.h, just in case we want to count it separately (but have to change several places in the source to look at itembonuses + spellbonuses + aabonuses).

I've been working on it, but don't have anything usable yet.

P.S. I moved the discussion since it doesn't really apply to just the Regen AA anymore.

[AndMetal]

Wow, I can't believe it's been 9 months... But I finally got this worked out (for the most part), although there's something I'm struggling with.

The way I have it setup currently, we'll load the aa_effects from the database into an array when the zone boots up. However, it's a fairly static array (1628 AA IDs * 7 slots per), which uses more memory that it really needs to (182,336 bytes per zone per my calculations). I don't think it's really necessary to load into Shared Memory (although it wouldn't hurt), but I think we'd be better off using a map (http://www.yolinux.com/TUTORIALS/CppStlMultiMap.html) instead.

The biggest hurdle is trying to figure out how to nest 1 map inside another (I think VS2008 is trying to make it a tree). I want to be able to access it via aa_effects[aaid][slot] and have it return an AA_Ability struct (or maybe even a new struct that doesn't have the slot).

Could someone with a little more C++ knowledge help point me in the right direction?

[AndMetal]

Well, I went ahead and committed this to SVN, but if anyone has a suggestion on how to do this better, let me know. Here's the array:

zone/AA.h (http://code.google.com/p/projecteqemu/source/browse/trunk/EQEmuServer/zone/AA.h?r=746#724)

#define MAX_AA_EFFECT_SLOTS 7
extern AA_Ability aa_effects[aaHighestID][MAX_AA_EFFECT_SLOTS];

zone/AA.cpp (http://code.google.com/p/projecteqemu/source/browse/trunk/EQEmuServer/zone/AA.cpp?r=746#48)
AA_Ability aa_effects[aaHighestID][MAX_AA_EFFECT_SLOTS];

[KLS]

I wrote up a simple example that should be fairly informative with regards to nesting one map in another. Keep in mind something the >> on the end of the map decl doesn't compile on g++, which is why it's > >, gnu translates it as an operator instead of apart of the declaration. At least last time I tried it this was the case.

#include <stdio.h>
#include <iostream>
#include <string>
#include <map>

int main()
{
std::map<int, std::map<int, std::string> > some_double_map;

std::map<int, std::string> string_map;
string_map[1] = "Wow";
string_map[9] = "Bonk";

std::map<int, std::string> string_map_two;
string_map_two[3] = "Rich";
string_map_two[1] = "Test";

some_double_map[0] = string_map;
some_double_map[1] = string_map_two;

std::map<int, std::map<int, std::string> >::iterator iter = some_double_map.find(0);

if(iter != some_double_map.end())
{
std::map<int, std::string>::iterator iter_inner = iter->second.find(1);
if(iter_inner != iter->second.end())
{
printf("Found string %s\n", iter_inner->second.c_str());
}
else
{
printf("Failed to find string =(\n");
}
}
else
{
printf("Failed to find std::map =(\n");
}

iter = some_double_map.find(1);
if(iter != some_double_map.end())
{
std::map<int, std::string>::iterator iter_inner = iter->second.find(1);
if(iter_inner != iter->second.end())
{
printf("Found string %s\n", iter_inner->second.c_str());
}
else
{
printf("Failed to find string =(\n");
}
}
else
{
printf("Failed to find std::map =(\n");
}

std::cin.get();
return 0;
}

[gaeorn]

I wrote up a simple example that should be fairly informative with regards to nesting one map in another. Keep in mind something the >> on the end of the map decl doesn't compile on g++, which is why it's > >, gnu translates it as an operator instead of apart of the declaration. At least last time I tried it this was the case.

That is correct. If you write it as >>, g++ will throw an error. Writing it as > > with a space between them will work find with g++. I'm using g++ 4.3.2, so fairly recent.