As some of you know, many times when reading through the scripts, we've been replacing variables with a variable name that describes the use of that particular variable as best as possible. This is done by replacing the Q*** variable with variablename_Q***.
While the above method works somewhat decently, I think that it is limited in terms of really getting a good idea of the variable's purpose. In that stead, I propose that we actually attempt to reconstruct the sdb.txt file as best as possible, using variable names that approximate the real variable name as closely as possible.
I believe that this is something that can be done, given enough time and some ingenuity with variable names. This stems from three different factors.
1. sdb.txt is in alphabetical order.
The alphabetical listing is the basic idea for this task. Without an alphabetical listing, it would be impossible to reconstruct the real (or very closely approximated) variable names. Sdb.txt uses what looks to be the ascii ordering for alphabetical listings.
2. alphabetical order + context of the script = possible variable names.
Having started this myself on the side, I have found that the context of a script does a lot to identify a possible name for a variable. Here's an example....
From the pet script, we have a function that is called when a player is added to the friend list of a given pet. This is the script in it's raw form:
- Code: Select all
void Q458(object pet, object Q5CJ)
{
list myBoss;
if(!hasObjListVar(pet, "myBoss"))
{
setObjVar(pet, "myBoss", myBoss);
}
getObjListVar(myBoss, pet, "myBoss");
if(!isInList(myBoss, Q5CJ))
{
appendToList(myBoss, Q5CJ);
}
setObjVar(pet, "myBoss", myBoss);
return();
}
If we take a look at sdb.txt, the variable Q458 shows up here in the file:
- Code: Select all
add
Q457
Q458
addBounty
Looking at the above function, the word boss appears all over the place. That gives us the context of dealing with bosses. Since we also know that this script has to do with adding an object to the boss list of a pet, we can guess that the original variable might have been addBoss. Notice that this variable actually fits in the alphabetical listing in sdb.txt, and it makes sense to be there.
Additionally, look at the variable Q5CJ. It appears here in sdb.txt:
- Code: Select all
newType
Q5CC
Q5CD
Q5CE
Q5CF
Q5CG
Q5CH
Q5CI
Q5CJ
newcharges
Using the same concept as the addBoss variable, we can say that the variable name that Q5CJ represents is more than likely newboss. This too fits alphabetically with the sdb listing, and we now produce a resulting script that looks like this:
- Code: Select all
void addBoss(object pet, object newboss)
{
list myBoss;
if(!hasObjListVar(pet, "myBoss"))
{
setObjVar(pet, "myBoss", myBoss);
}
getObjListVar(myBoss, pet, "myBoss");
if(!isInList(myBoss, newboss))
{
appendToList(myBoss, newboss);
}
setObjVar(pet, "myBoss", myBoss);
return();
}
3. Over time, as variables are discovered, sdb.txt will become easier to decipher.
This is a natural bonus to the project itself. As the listing becomes more filled, later variables will become easier to fill in. Of course, this does assume that the variable we have in a specific position is correct, or approximately correct, and we may find that at times we did have an incorrect variable when another variable that is much more obvious would throw that variable into an incorrect location. However, the overall trend will be towards an easier to decipher sdb file over time.
In any case, this is the idea as it stands. Thoughts?