FWIW, the easiest thing might be to quasi-hack the entire 1.50 type loading code into ZQuest, as I had mentioned in the past. I had worked on an early version of this, which I was a bit unhappy about using, as I effectively duplicated a large number of objects that persist in memory at all times, such as maps, the combo tables, and whatnot from 1.5x.
Now I'm not sure where I saved that blasted thing, or if it was overwritten by a git pull. It would not be hard to write again, but the sheer amount of RAM wastage concerns me with that model.
I do not yet know if the 1.50 loading code would suffice, even if this worked, and then converting the data into usable data for 2.50.x would still be a chore. The main issue is the sizes and types of all of the structs, and data objects.
I do have to ask: How much of a chore is it, in relation/contrast to this amount of work needed to make a 1.84 quest loader, to manually fix the combos and the tiles in the quest files after you load them?
The culprits would be:
1.50
Code:
if(!pfread(combobuf,sizeof(combo)*512,f)) {
pack_fclose(f);
return qe_invalid;
}
///and
if(header->data_flags[0])
{
if(!pfread(tilebuf,TILEBUF_SIZE,f))
{
pack_fclose(f);
return qe_invalid;
}
}
else
{
for(int i=0; i<TILEBUF_SIZE/4; i++)
((long*)tilebuf)[i]=((long*)data[TIL_NES].dat)[i];
}
The actual data stored in *combobuf and *tilebug have changed, so ZQuest is likely trying to read values in the wrong data locations; and iit is a miracle that it does not outright crash in the process.