Sounds like what you're up against isn't compression: it's metadata.

Could be something as simple as text pointers, which every romhacker should know how to work with (and the famed Atlas contains functions for handling). If it's anything more complicated, though, like checksums or file length headers, you may have to write your own custom script editor/inserter.

"When flipped". What you mean to say is that it's in little-endian format; the LSB ("Least Significant Byte") comes first (as opposed to the MSB, "Most Significant Byte").

Take a look at the "compressed" data and see if it follows any kind of pattern.

Filenames, huh? Sounds like my experience with Death Note: The Kira Game for DS. ^_^

Okay. Repeating patterns. Do the LSBs of any patterns correspond with the starting offsets of any of the strings in the file? If so, those are string pointers. You may have to write a custom script inserter/extractor to deal with this...

Does the data appear after the script text? Before the script text? In the middle of the script text?

If the data is wrapped in text, then There's Your Problem: either you're stomping on this data by accident, or the game expects to find this data in a specific place and you're moving it. In either case, you need to find the pointer - or pointers - that point to the data.

Wait. "Script Length"...as in, the length of the script up to the unreadable data at the end?

Okay, let me see if I've got your situation understood.

You can edit the script, but you're limited to the space available: if your script takes up less space than required, that's fine, but if it takes up more, then the game crashes.

Do your expanded scripts overwrite any of the non-script data, or do you have things set up so that everything gets repositioned to its proper place after the script?

That's classic. What you're up against is that time-honored foe of romhackers everywhere: pointers. Can't believe it took me so long to pick it out; you seem to have a grip on everything else, so I didn't think it would be something this simple.

Here's the bottom line: the pointer table is a great big block of numbers that tells the game where each string begins. How it's formatted will vary from game to game, but somewhere in your mystery data - or perhaps in a related file - there should be pointers which indicate where each string begins. They might not be sequential: in Death Note, there are pointers padded with miscellaneous data that point to other pointers which actually point to the strings, and in Patlabor for SNES, the pointers are apparently mixed in with event code. But they should be there.

Try this for a test run. Use your hex editor's Hex Search function to look for the beginning offset of a string. In little-endian format, mind you. For example, if a string begins at 007F, you'd search for 7F00. If it begins at 1648, you'd search for 4816. And so on. Things might get complicated if the pointers count words instead of bytes or something: are the strings all packed in one after another, or are they padded so that they're aligned by a multiple of 4? If you can't find any pointers using the above method and the strings are indeed padded, try dividing the offset by 4 (the word offset as opposed to the byte offset) and try again. (If each string is prefixed by its length or other data, then you should count the offset where the header begins, not the offset where the text begins, as the string offset.)