I didn't realize it until just now, but a lot of these AAs are already being utilized using the aa_effects 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: Code:
/* |
yeah it would be nice if i could reattach any given AA to any given spell wihout doing any recoding :D
|
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.
|
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?
|
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.
|
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: Code:
void Client::CalcBonuses() 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. |
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 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? |
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 Code:
#define MAX_AA_EFFECT_SLOTS 7 Code:
AA_Ability aa_effects[aaHighestID][MAX_AA_EFFECT_SLOTS]; |
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.
Code:
#include <stdio.h> |
Quote:
|
All times are GMT -4. The time now is 08:32 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.