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

[Gleeok]

The tables have nothing to do with corrupted data though.

Have a look at some specs for the c language aggregate initialization rules: https://msdn.microsoft.com/en-us/library/81k8cwsz.aspx

The scriptdefense array at the end will be zero initialized.


[edit] Also, I have to ask it, (sorry if it seems obvious to you, just trying to help) not trying to sound like a ass or anything: Without properly reading the version correctly you'll never be able to read/write a quest file without it becoming corrupted. This is because without it you introduce a "chicken and egg" logic bug regardless. The only way around this is to compile two versions, one for saving and one for loading.

[ZoriaRPG]

The tables have nothing to do with corrupted data though.

Have a look at some specs for the c language aggregate initialization rules: https://msdn.microsoft.com/en-us/library/81k8cwsz.aspx

The scriptdefense array at the end will be zero initialized.

I was lookin at comments like this, and I wasn't sure if that dat table needed me to reserve the space; as this is the case for many entries, even with zero'd fields.

bool reset_guys()
{
    // The .dat file's guys definitions are always synchronised with defdata.cpp's - even the tile settings.
    init_guys(V_GUYS);
    return true;
}

Things like this tend to make me consider that proper synchronisation is mandatory at all times, and that the fields are explicitly prepared.

[edit] Also, I have to ask it, (sorry if it seems obvious to you, just trying to help) not trying to sound like a ass or anything: Without properly reading the version correctly you'll never be able to read/write a quest file without it becoming corrupted. This is because without it you introduce a "chicken and egg" logic bug regardless. The only way around this is to compile two versions, one for saving and one for loading.

No, that's something that I need to know. Could you expand on that, and specify: By version, do you mean the defined ZC version, V_GUYS, or something else? Have I done this somewhere, that you have observed?

Tell me this though: Why is expanding the enum with defLAST alone enough to corrupt this, when everything that thie packfile and editor generation code does relies on s size read fro this entry's placement?

If I add defs to the enum before edefLAST, and compile, with no other changes, the corruption still occurs. Is there anything with an explicit size that I missed? i simply fail to believe that the code can't resize itself around this, unless it's because it is shifting the values and the code isn't adaptive enough to comply. Even so, if it shifts the values, I'd expect it to mismatch when reading another quest, not the quest in memory, which is what led me to believe that the default values from defdata were involved.

Also, you said that the latest guyversion is 24, but in zdefs, it was 24 without my intervention.