Thoughts on Fixing the Prereq AA issue
Quote:
In regards to this problem. I have been thinking..... I believe I understand how it has to work, but correct me if I'm wrong: The client interprets the AA Index which is why we store that value in the DB. We pull the value for each AA from the DB and send it to the client in the process ZoneDatabase:GetAASkillVars() (aa.cpp). My question is this- would it not be a lot less of a headache to store the SKILL ID of the AA in the database and determine the so-called "index" at the time of sending it to the client? I.e: Code:
for (int i = 0; i < MAX_AAs; i++) { |
Quote:
Code:
RunQuery(query, MakeAnyLenString(&query, "SELECT cost, max_level, hotkey_sid, hotkey_sid2, " I'm wondering if we can do all of this with a modified DB query (using some sort of subquery probably) that translates a prereq_skill as a skill_id to the index #? After working over this for a bit (with some inspiration), here's the query I came up with: Code:
SET @row = 0; Code:
SET @row = 0; Code:
mysql> SELECT a.cost, a.max_level, a.hotkey_sid, a.hotkey_sid2, a.title_sid, a.desc_sid, a.type, COALESCE((SELECT prereq_index_num FROM (SELECT @row := @row + 1 AS prereq_index_num FROM altadv_vars) AS prereq_conv WHERE prereq_skill = prereq_index_num), 0) AS prereq_skill_index, a.prereq_minpoints, a.spell_type, a.spell_refresh, a.classes, a.berserker, a.spellid, a.class_type, a.name, a.cost_inc FROM altadv_vars a WHERE prereq_index_num > 0; We could definitely iterate through the possible AA IDs, but I think this would be a lot cleaner & less resource intensive (relatively, since we're only talking about a few hundred to a few thousand loops, depending on how quickly we find our match). So, if we decide to go this route, we can do this: in zone/AA.cpp, around line 1241 in ZoneDatabase::GetAASkillVars(), change Code:
if (RunQuery(query, MakeAnyLenString(&query, "SET @row = 0"), errbuf, &result)) { //initialize "row" variable in database for next query Any feedback? |
If this works as intended, it looks like a great solution to me! And I agree about the berserker field too.
Then, we could just have a single SQL update in the SVN that comes at the same time this code goes in that will drop the altadv_vars table and create a new modified one that includes all current AAs with the new prereq_skill, classes, and berserker fields information. And then any time a new AA is created, the associated SQL could be added to the /utils/sql/svn directory. This would keep everyone up to date on code and AAs, and the new way of setting prereq_skills would stop the risk of messing up AAs when adding new AAs to the table. The only other possible solution I can think of for the Indexing and prereq_skill field issues would be to fill in the skill_id for every possible AA in Titanium. I think this solution might not be too bad. We would just need to add the skill ID for each one (maybe a few hundred or so) and then leave the other fields blank and set the class to 0 for all of the blank ones so they don't show up for players. Then, we could even add 1 more column to the table that would increment by 1 for each row and match up with the indexing of the skill_id field. So, if someone wanted to add a new AA, all they would have to do is fill in the blank fields for the appropriate skill_id, and nothing else would need to be changed. And, if anyone felt like doing the work, they could even fill in names and other info for the blank ones. As long as class is left at 0 until the AA is actually implemented, we shouldn't have to worry about it. I would definitely consider doing the SQL work if it sounds like a good solution. |
To be honest I really don't see the point of all this. It doesn't fix any sort of real problem it just makes you lazy bastards happy. =p
|
Well, considering that adding AAs to the source actually requires SQL in order to use them, then IMO, the SQL does need to be added to the /util/sql/svn directory when an update is made. All other changes to the source that require SQL changes get posted that way. Sure, we could probably get the table from PEQ, but this is the only scenario where a change in the source requires SQL and isn't being included in the download.
I personally don't keep up-to-date with the PEQ database and don't really ever plan to. My server as many others are custom and the PEQ database is just used for grounds to start on and maybe allow extra content for players on the server. So, having to get the PEQ DB just to get new AAs seems a bit like an extra unneeded chore to me. I don't think it is as much about being lazy as it is about being consistent and having low risk updates. I am sure you don't think that using indexing for that table the way it is now is the best way to do it. All it would take is 1 little SQL mistake and some AAs could be broken. And given the number of AAs, it could be a while before it was even noticed to be corrected. I think it would be nice to have an option to let anyone update AAs purely through the SVN and not have to use an alternate site or upload or post or whatever to provide PEQ with the SQL for it. Then wait for it to be added to PEQ for it to be usable by all. It can be done by using your query here: Code:
SET @idindex = 0; Code:
UPDATE `altadv_vars` SET `prereq_skill`=`prereq_skill`+1 Where `prereq_skill`>=86; Code:
INSERT INTO altadv_vars (skill_id, name, cost, max_level, hotkey_sid, hotkey_sid2, title_sid, desc_sid, type, spellid, prereq_skill, prereq_minpoints, spell_type, spell_refresh, classes, berserker, class_type, cost_inc) VALUES And what is so bad about being lazy?! :P I like to think of it as more efficient. Who wants to do things the hard way? If we are going to continue to get a steady flow of AA additions, then IMO it would be well worth it to make it as painless and safe as possible. :) |
Quote:
Quote:
|
Finally broke down and downloaded to PEQ DB and found out I was missing about 60 AAs! That is both awesome and sad at the same time lol.
|
After working with the query a little bit, I figured out I was comparing index to index rather than skill_id to skill_id, so nothing was actually happening. I just had to change the prereq_skill_index part:
Code:
COALESCE((SELECT prereq_index_num FROM (SELECT skill_id, @row := @row + 1 AS prereq_index_num FROM altadv_vars) AS p WHERE p.skill_id = a.prereq_skill), 0) AS prereq_skill_index Code:
Index: Z:/svn/EQEmuServer/zone/AA.cpp |
Quote:
|
Quote:
|
I just meant I am going to get the AA tables as correct as possible before releasing them so other people can work with them. It's silly to have 4 or 5 different people working with AAs and not even working off a single DB.
|
Quote:
Code:
SET @row = 0; Code:
COALESCE((SELECT prereq_index_num FROM (SELECT skill_id, @row := @row + 1 AS prereq_index_num FROM altadv_vars) AS p WHERE p.skill_id = a.prereq_skill), a.prereq_skill) AS prereq_skill_index |
I am going to test this out on my server the next time I update to the SVN (probably this weekend). Figured it was worth asking the status of the possibility of getting this committed if it continues to test well. Does anyone have issues with this being committed as long as it works as intended? I really think it will make adding new SQL for AAs considerably easier.
Cavedude is right that we should all be working off the same table when creating or fixing AAs. But, with this code, we could be working from completely different tables and it shouldn't make any difference. |
Quote:
|
I would love to see this get implemented. I think cavedude should have the final word, since the PEQ database is the most important thing to have adjusted for this change. Once we have a good table to work from that has these modifications in it, it should make adding AAs quite a bit easier. Then, new AA SQL updates could be added to the /sql/svn directory when doing SVN commits just like any other SQL changes.
I think this just got forgotten about after the new AA additions on the SVN died down. I forget if I tested this or not yet. I would test it, but I don't really have much extra free time lately with all of the other stuff I have going :P |
Yeah, I've forgotten about this thread as well. Let me give the code a try, and work out a query to migrate the current AAs to the new system. If all goes well, I don't see a reason not to commit it.
|
Quote:
Quote:
I think the only thing I didn't do was combine the classes & berserker columns in the db, then separate them in the code (easy enough to do). |
I don't think we need to combine the classes and berserker columns. They are sent to the client that way, so it doesn't hurt having 1 extra field to fill out. It wouldn't hurt to do it, but there isn't really much point to do so. Even on EQLive, it is still sent that same way for some reason. They are probably to lazy to do it :P
EDIT: Woah, I am developer now, lol! Be afraid! |
Quote:
|
This works perfectly. I don't have a problem with the code and query being committed, unless anybody else has any objections. It even allowed me to correct a couple of Necro AAs that have been nagging at the back of my mind.
|
All times are GMT -4. The time now is 09:37 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.