25 May, 2008, Nash wrote in the 1st comment:
Votes: 0
I am not sure I understand how OLC handles the EDIT_X thing,
the issue is that when editing helpfiles, they seem to write over
the afile for the area I'm in, causing in a crash and loss of the area
in the next copyover. Where do I go to fix what to make this not happen?
02 Oct, 2008, Kratos wrote in the 2nd comment:
Votes: 0
First you have to tell what the error is. Then we can go from there.

02 Oct, 2008, Davion wrote in the 3rd comment:
Votes: 0
The problem isn't EDIT_*. All that is, is a fancy way of casting descriptor_data->pEdit. The problem with this is HAD_DATA (Help Area Data Data… ya :P) I never actually figured out where the problem was, as it was faster to simply replace this with a master list instead. So, first task would be to save all the helps to one file (help.dat, help.txt, help.are, even) and write it's own routines for loading/saving instead of using the built in ones. This is, of course, the Easy Way™. If you want to actually go about fixing the problem, you have to first, be able to recreate it at will, and then track it to see where it goes wrong.

First, I'd suggest tracking to see if a file is snarfed. A good way to do this is to add up what's written, and compare to the final version of the file. You can use the return value of fprintf to do this. It returns the number of characters written. A quick example

#include <stdio.h>
#include <sys/stat.h>
void main()
{ FILE *fp = fopen("./somefile.txt", "w");
int size = 0;
struct stat sfile;

size += fprintf(fp, "Some data %d", anint);
size += fprintf(fp, "More data to add to the file\n");
if( ( stat("./somefile.txt", &sfile ) ) == -1 )
{ //error here. The file wasn't even created.
if( sfile.st_size < size )
{ //Not all the file was written, error here too

Plug something like this into the area saving process (maybe have each individual save function return the size of what it wrote to sum up in the main save function.) Then, once you figure out how and when it truncates the file, simply use gdb to step through, and find out where it's fubaring the file.