gMercProfiles wird in "Soldier Profile.h" definiert.
Initialisierung findet in "Soldier Profile.c" durch JA2EncryptedFileRead statt,
welches das verschlüsselte File "BINARYDATA\\Prof.dat" ausliest, entschlüsselt
und ein memcopy auf das globale Array macht !!! böse böse
sizeof(MERCPROFILESTRUCT) ist eigentlich 707 (nachzählen

)
dazu:
NAME_LENGTH=30 und NICKNAME_LENGTH=10 steht in "soldier profile type.h"
typedef CHAR8 PaletteRepID[ 30 ]; steht in "Overhead Types.h"
typedef unsigned char BOOLEAN; steht in "Types.h" wie auch die
restlichen Typen
Prof.dat hat nun jedoch eine Größe von 121.720 Bytes was zusammen mit
NUM_PROFILES = 170 (steht in "soldier profile type.h")
sizeof(MERCPROFILESTRUCT)=716 ergibt.
Es gibt also 9 Padding Bytes. Das erste ist zwischen 229 bSex (für Barry =00 ---
01 wäre weiblich) und 261 bMedical (Barry hat einen Wert von 20 in Medizin)
Wenn interesse besteht kann ich eine decryptete prof.dat an NItrat schicken,
damit er sie, wenn er so gütig ist, online stellen kann.
Ich hoffe ihr könnt mir helfen die genauen Positionen der Padding Bytes auszumachen.
Ich seh nur den Weg über das Debuggen der Original.exe
da ich z.B. nicht weiß wie ich meinem Compiler beibringe interne Paddings
in structs zu erstellen.
Generell ist im Source darauf zu achten das man memcopy nicht mit structs verwendet.
Jeder Compiler erzeugt andere Paddings und so kann eine selbst compilierte exe
schnell ein Fehlverhalten zeigen.
Daraufhin ist der bestehende Source zu untersuchen. Wahrscheinlich müssen
zusätzliche Ladefunktionen geschrieben werden.