NPCs fail to appear after writing new values to the packfile.

[DarkDragon]

Oh, sweet dear little baby infant Jesus.....

Please, please, pleeeease, be extremely careful when changing packfile formats. Even I go into "serious mode" when doing anything with that file.

This exactly.

There is unfortunately nothing "automatic" about the quest file format. The procedure for adding a field to the quest file is

1. Increment the appropriate section version number
2. Write the save code. Ensure you use the right packfile write command (bit length, endianness, etc) for the type of data you're trying to save.
3. In the quest loading code (in qst.cpp) in the place where you want to read in the new data, add a check for the section version number
- if it's less than the new version number, do NOT attempt to read the new data, but set the values for the new field to some reasonable default instead;
-- IMPORTANT: you might need to do this in several places in the code. Here is some fairly typical code structure:

if(s_version <= 2.0)
{
   // some code for loading legacy 1.90 quests
}
else
{
  // a **huge** block of code for loading modern quests
  
  if(s_version <= 6.0)
  {
    // some code for handling 2.10 quests
  }
  else
  {
    // another huge block

    // here is where you want to read in your new field
  }
}

You need to make sure you cover *all possible* code paths when reading in the quest, and set default values correctly for all cases. In the example above, you will have to add code to set defaults in at least three places. There have been dozens of bugs in the past due to the old quest loading code not being updated properly as new fields are added.
- otherwise, read in the data from the file (using a matching command to the write command, obviously).

Then you test the shit out of the code, on both old quests and newly-created ones. The best-case scenario for a bug here is massive corruption when you try to load old quests. The worst case is a subtle bug that corrupts a quest only when it is loaded and then re-saved in ZQuest, totally screwing any quest author who encounters the bug and doesn't have regular backups of their WIP (yes, we tell them not to work on major projects using betas or RCs, but...)

[ZoriaRPG]

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:

 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] ;
                }
            }