FATAL fold_area bug

I'm running a heavily modified SWRiP codebase. The only modification to area data, however, is one variable called cylinder, which is an int used for do_clone stuff.

This bug has baffled me because I have compared it with other code bases and their code matches mine, except for that one variable, which is an extra ifcheck and an fprintf.

Upon folding an already installed area (such as omni_complex), the mud gets a segmentation fault, and is unable to recover because the folded area file gets corrupted, so when the crashover code executes, the mud shuts down because it can't load omni_complex -- it's corrupt. So I restore it from omni_complex.bak...

The corruption looks like this...
Normally an area file looks like...
<normal area data here...>
#SPECIALS
S

#$

That's what an area file should look like... the corrupted area file looks like this...

<normal area data here...>
#SPECIALS

<repeat of the normal area data!>


The stuff in #SPECIALS gets stripped out, and duplicate area data is appended to the end of the file!

Can anyone tell me what is going on? This bug could take me a while to track down.

When you add a new variable to be written in areas, you need to utilize the AREA_VERSION update or else many issues will occur. Do a search for AREA_VERSION, I asked about it a while back.

From what I can see, SMAUG 1.02a, which is what SWR broke off of (?) didn't utilize area versions. However I could quickly add this to the code.

I don't see this is a problem though considering that the areas saved with my minute code addition previous to this... mess...

Ahhh thanks Greven, you're a life saver. :)

Got it fixed.