There's also a test version of the upcoming 0.5 release available.
- - - original post - - -
illspirit and I were working on cleaning the SA map the last days, mainly for total conversions such as MI, but weren't very successful yet. When deleting too much, the game either crashes immediately after everything was loaded, or it enters an infinite loop of doom.
It's no problem to get the (visual) map clear. All you need to do is remove all ipl entries from the gta.dat and delete all binary ipls in gta3.img. It's even possible to remove the interior ide entries and delete the complete gta_int.img (!), but as soon as you start removing some of the city map ide files, the problems begin.
As far as we know, you can remove all of the \LA\ ide files, and very few of the others, without a crash. illy tried to delete single object defs in one ide that wasn't working, and eventually got it running, but only with half the defs still in, and it didn't seem to matter which half was deleted.
So then we went on with deleting unused files from the img, since that was a problem for VC. I even coded a tool for that. But still not more successful than before.
So that's why we are publishing this, and we hope someone might still have any idea we overlooked, or can do some more testing and maybe get it working by deleting just some more col files or anything. I've uploaded my tool and a stripped water file and mission script, all in the following package. Take a look at the readme before using the tool! And remember to have a complete backup copy of SanAn, YOU WILL NEED IT!!!
Edit: And on a side note, we know that there must be some data that define how items are grouped and replaced by LOD (parent objects and such). And I'm quite sure that's the cause of the above mentioned problems. But atm we have no idea where these are hidden. Possibly binary and text ipls, since they have a new parameter (which is -1 for LODs and non-child objects), and there could be some other data hidden in the binary ipls now. Or, it has something to do with the 64 nodes*.dat files, which might divide the map into a 8x8 (or deeper) grid, containing links and parameters to the item instances, which might be used by the engine for some sort of quadtree sorting. But that's only a wild guess, since I haven't really looked at those files yet.