I've got to a point in my map where each time I try to modify certain strings, the editor crashes and talks about "string corruption". Is there any way to avoid/resolve this?

Assuming you've been using SCMDraft, your best option is probably loading a backup.

Perhaps if you can isolate the string(s) in question you could save your map as a .chk, change the string(s) to simple words with no special characters using a text editor like notepad++, then reload in SCMDraft to see if it gets better, but you're essentially shooting flys in the dark trying to troubleshoot SCMDraft's string handling.

You should also disable autosave and autobackup in profile settings. They cause all sorts of issues in my experience, one time I tried to save and ended up with a 1kb map that, needless to say, I couldn't open anymore.

For me, the best way to avoid this is.. don't use Starforge + SCMDraft2 together, as they hate each other.
If you must, save lots of backup

Disabling auto backup is not recommended. Often the backup database is what saves you from losing your work when a corruption occurs.

The database, however, does cause scmdraft to freeze when it tries to autosave a 2 gigabyte backup, causing the person to lose their progress by having to shut the program down.

I also have auto-backup turned off. The backup system is flawed pretty terribly. If the map size is too large, or if the backup database becomes too large, then you're going to experience crashes and other nasty critical bugs until you get it cleared (which often requires deleting the actual backup file).

It's up to the user's discretion, but if you're not going to disable auto-backup, at least make sure you're keeping your database cleared of unnecessary backups. You won't know the backup database file is too large until after it's too late.

Oh right, I wanted to mention that, but I got distracted.

Personally I've never experienced a 2GB database, but it's definitely something to keep in mind. I'm not sure if it happens purely over time or if it's a bug that, when triggered, writes a 2GB file (more likely).

If it's the latter then occasional manual backups are recommended. But I'd still use it because the bug is rare and the featire convenient

It happens over time. It's pretty easy to manage when you have sound files in your map.

As mentioned in the previous post, keeping the database cleared of unnecessary backups will prevent it from crashing.

I personally got tired of clearing them manually, and eventually opted to simply turn it off.

Id just rename or delete the db once it gets too big.

Ah wavs are the culprit! I never used them. Would be cool if there was a way to not store them in every backup file.

Yeah, I was also going to clear it when it got too big. The way I found out about this issue was pretty unfortunate though, I had done a lot on a map, only to have the client crash when I tried to save it. I lost a ton of work that day, and it's the sort of experience that leaves you unwilling to risk the same outcome again. Even now, I still open the backup database occasionally to ensure it's not filling up with backups

The thing with the backup database is most people don't even know it is there, which makes it especially annoying when it goes bad and ruins all your work. A feature that's designed to save your ass that you don't know about might as well not even be there.

Personally I just managed my own backups, as again I was one of the people that didn't know about the database until many months after I'd gotten into the routine of making backups anyway.

Running the map through an unprotector may fix the string corruption.

Wow guys, I found the problem. There's a 65530 bytes limit, and I'm only at 749 strings

stop commenting your triggers. IIRC you can remove location names as well.

Going backwards from a huge string size map is difficult, but not impossible.

I learned an even better way to save trigger space. In my text messages, I had lots of 'space bar' characters, so I changed them into 'tabs' instead. 1 tab = 4 spaces. All good

Locations always have a string, unless SCMDraft specifically is cool and has a default string.

You could set all the location names to the same thing, ideally a string that's already being used, so they wouldn't use any strings.

The problem with this is that you'll lose the ability to edit the text triggers unless you make all the location names unique again.

Wow Azrael, never thought of that. Good thinking!