Originally Posted by
Gleeok
Sure. You add an extra 10 byte array and read an older quest-> guy 0 gets loaded fine, guy 1 gets offset 10 bytes and is garbage, guy 2 gets offset 20 bytes and is garbage, guy 3 gets offset 30 bytes and is garbage. The old quest file here is the chicken, and the new format is the egg. You have to be able to load the chicken into the egg here. Without knowing that the quest file is a chicken you're just shoving an egg up the chicken's ass and turning a chicken into an egg by unnatural means, and then hilarity ensues as you have a messed up looking chicken that's bleeding all over your couch screaming in pain. You then beat it to death with a bat and try to figure out what's wrong with the chicken, but you can't. Make sense? :)
Oh, I know what's causing the offset. That's obvious. What I don't comprehend, is why when the loader reads the size of the defense array from the same place as the saver, why this occurs. Do I need to define a new guysversion for both sides, and load the new stuff only if guysversion is > N; because the editor panel doesn't do that at all for anything.
I fixed it, anyway; so now everything works and I need to verify that older quests work properly, next.
For any-one who might be curious, this is what I did in qst.cpp:
Code:
if(guyversion > 24) // Add new guyversion conditional statement
{
for(int j=0; j<scriptDEFLAST; j++)
{
if(!p_getc(&(tempguy.scriptdefense[j]),f,keepdata))
{
return qe_invalid;
}
}
}
//Forward the value from old quests to the new attributes.
if(guyversion <= 24) // Offset the values intentionally?
{
for(int j=0; j<scriptDEFLAST; j++)
{
tempguy.scriptdefense[j] = tempguy.defense[edefSCRIPT] ;
}
}