Detailed Notes on Subjects Above
AAs - Currently, there is a fair amount of work that needs to be done to get AAs fully functional and up-to-date in SoF. Most of them now work thanks to a structure issue that Derision found and corrected. In order to handle AAs properly for SoF, we need to create and use new tables just for SoF AAs. Right now, AAs load into the AA window and can be purchased without having to zone for them to update.
The total spent AA count in the AA window is temporarily being forced to show 500. This is because I do not know how to get an accurate count of the total spent AA points yet. This is a fairly minor issue, but worth mentioning. Derision found an issue with the encode of the RespondAA packet, which is what sends the spent AA points total. So far, I now have it able to show the correct number of AAs purchased, but not the total of AA Points spent to make those purchases.
The main priority on AAs right now is to get the table issues worked out. I have already collected every AA that a rogue gets on Live and have put them into a table format. I was able to get them working in game as well, but need to do some clean up on them before they are ready for other admins to use. The table I have so far for this is posted later in this thread. At some point, we will need to collect the AA info for each class and put them into the table as well. It seems that the AA data for Titanium still mostly exists in SoF (since AAs show up), but SoF seems to get descriptions and names and such from different places than Titanium does. Titanium uses the eqstr_en.txt file to get most of it's descriptions, but SoF uses the dbstr_us.txt file for them.
Something worth mentioning is that it seems like getting AAs set in the database might be easier for SoF. The dbstr_us.txt file is setup differently than the files that Titanium uses for AA names, descriptions, and maybe other info. Basically, it seems to use a list format for each ID. For example; Innate Strength is skill_id 2, and in SoF, the name and description in the table can both be set to 2. This is because the client knows that the name is always the 1st line in the list and description is always the 4th. Here is an example from the file to explain what I mean a bit better:
Code:
2^1^Innate Strength
2^4^This ability raises your base Strength by 2 points for each ability level.
So, skill_id, title_sid, and desc_sid all get set to 2. This just means a little less work for getting the AAs added to the alt_adv table. Nothing major, but seems like a better way to do it.
I think I have the alt_var table I have so far is looking pretty decent, but still need to look into the aa_effect and aa_action tables. Once all of the AAs are collected for all classes from Live, I am sure we will have to do some clean up to make sure everything matches up and is set properly.
Once the new tables are ready, I will probably need help from someone more experienced to get the SoF encode to use the new AA tables instead of the old ones. We will also need to have it send a couple new fields that didn't exist in Titanium. I figure I will deal with that once the tables are more ready, though it won't be long now.
It seems that with the change to how the AA window works since Titanium, it means that the way that the AA tables are sent works a bit differently. As far as I can tell, none of the actual AA IDs listed in AA.h have changed. But, since many AAs were combined/consolidated to reduce overhead, the way they are handled had to be changed as well. The most noticeable change is for stuff like the Innate stats, and other AAs that used to have direct upgrade line AAs for them, but are now combined into a single AA. The issue is that with the IDs remaining the same, it doesn't allow for them to be combined in the same manor that Titanium handles them individually. To use Innate Strength as an example, the ID for it is set to 2, and the next AA is Innate Stamina, which has an ID of 7. This means that there is only room for 5 levels of that particular AA. In Titanium, the max_level for that AA is 5, so that works fine. In EQLive (and probably SoF), the max is now 15 for Innate Strength. It seems that each time you train a point, it just moves up 1 in the AA effects table. And, to compensate for this restriction, it looks like EQLive just sends that same AA table 2 or 3 times so that the effects stack. So, if you had 1-5 points trained, it would send that AA 1 time, if you had 6-10 trained, it would send it 2 times, and if you had 11-15, it would send that same AA 3 times. I am not 100% sure that this is how it works, but it definitely sends multiples of some of these, and it only seems to do it when you have points trained in that stat. This will definitely be something we will have to understand fully before the new SoF AA tables can be completely finalized. I still have to figure out exactly how each table is supposed to be formatted to handle this new way of doing it. I think most things are still the same, but changes will definitely have to be made here and there.
I just noticed that the unknown0092 field in the SendAA structure seems to actually be a secondary category field. The first category field is currently labeled as "expansion", because it is the number that correlates to the expansion that the AA originated from. The unknown0092 field seems to override the expansion field if it is set to anything other than -1. I am going to do some testing with this in SoF and if it works, I will label the field "special_category". So far, I have identified that it will show the following if the field is set to any of these for SoF:
Code:
unknown0092
2 - Progression
6 - Tradeskill
7 - Expendable
8 - Racial Innate
As with the other new fields, this one will have to be added to the code for SoF AAs to have it sent properly. I already have them listed in the new tables I am working on.
That leaves the unknown0096 field as one of the only new unknown fields that hasn't been identified yet. The only AA I show as setting that field to anything other than 0 is Harmonic Dissonance. That is an AA on live that is free to purchase and will port the player to a zone. It is currently set to 16777216, but I am not sure what that number is supposed to relate to yet. This field probably isn't very important to us.
Recast Count-Down
Clicky items that have a recast delay on them all seem to show up as grayed out all of the time. This may be due to an issue with the serialization portion of the struct, or possibly something in the click effect portion that is not getting set properly. Interestingly, it seems that after my recent changes to the manachange encode, my click type 2 items now count down as they should. This could possibly mean that the manachange packet is what updates items to start the countdown after the click happens. If that is true, then we should just need to figure out the correct values to use in the unknown fields to correct this. I have it hard set to -1 right now, so I don't know why it would effect recast type 2 only. Maybe it is just coincidence that they work now or I may not have noticed that they started working after some other recent change. Either way, if we can figure out why type 2 works, then we should be able to figure out how to get the others all working. And if we can get it working in SoF, it could possibly be fixed in Titanium as well, because I know that feature was in Titanium. This system isn't crucial to get working, but it would be handy to have
