You gotta’ love’m.
It’s the kind of mistake you usually make when you’re overconfident. You know, that little edit in the code that is absolutely safe, right? And then the automated build fails because you didn’t bother to compile the code after that tiny change.
Or when you make that change, the code compiles fine. Then when running the app you face weird crashes, bad file formats and whatnot. All because you didn’t bother to test that said change.
So, here’s the story of such a change.
A few days ago I went on reviving an old piece of software called dirpack. I managed to figure out the issue of O_BINARY flag, and I happily compiled the tool. I did another change though that I didn’t bother to test properly. No, I’m not going to tell you what was the mistake, not yet at least.
I moved on with the development for MapTap, knowing that dirpack is compiled and it works (well, it worked when I tested it, but before making that change). So I clicked on the map I wanted to play, saw the .PAK file getting created, sweet! Now to open it with PakExplorer … and dang, the file is not right! The three BSP files were inside a folder called “maps”, and now they are listed at the top level, with a size of -1 KB ….
And then it hit me.
The innocent change I mentioned was changing throughout the code all uses of ‘/’ as path separator to ‘\\’. And you’d expect it to be ok, right? I mean that’s the path separator for Windows, so no harm done, right?
Because we’re not talking about the Windows operating system anymore and how it handles path separators. We’re talking about .PAK files, which is something slightly different. You have to play by the rules imposed by the people who defined how .PAK files work.
And you should always test your code changes. There’s no such thing as an innocent change.