Alternative Title: "Oops, I did it again!"

So uh, I have yet another bugfix update that just dropped (except on Google Play, 1.1.04 didn't even get approved there yet, so we'll be going straight to 1.1.05 once I get a payments "issue" sorted). There's two bugs fixed, so I figure I'll explain a little about how they happened, and what the fixes entail.

Bright White Hair & Train Cars

So this one seems simple enough to explain: in some situations, loading a save will cause some of the villagers to have bright white hair, and some of the train cars to be bright white. However, the cause has to do with commas, periods, and (parts of) Europe*. The main thing that concerns me is that none of this was new in 1.1, so this problem may have been in the game all along? And the people affected never said anything - I only found out from an unrelated bug report!

*As you'll see later, this applies outside of Europe as well, but that's where the bug was originally reported.

So a couple things need to be laid out to fully understand the issue. First of all, decimal separators. In the English speaking world, we use "." to separate everything above 1 and everything below, e.g. 2.7. However, many other parts of the world (not all of them) use a "," for this, e.g. 2,7. Things get a bit more complicated with the optional separators used for big numbers: two thousand seven hundred and 54 hundredths could be 2,700.54 in English, but 2.700,54 in other parts of the world.

Hold on to that, now it's time for the second part: storing colo(u)r in computers. If you're not printing (where CMYK is more useful), you want to store the red, green, and blue values (RGB) so that you know how much to light up each part of each pixel on the computer screen. There's a few different ways of doing this, sometimes you'll see a hex code (for instance, #ffffff is ff for red, ff for green, and ff for blue; combining these makes bright white), sometimes it'll be a value between 0 and 255 for red, green, and blue, and in our case Godot uses a number between 0.0 and 1.0. (It also stores an alpha value 0.0 to 1.0, where 0.0 is fully transparent and 1.0 is fully opaque.)

In Iron Village, train cars and villagers' hair and clothing have different colors applied to them. Rather than making separate images for each color, the game just stores the color as a separate variable. That way it can use the same texture to make different variations. In order to maintain this data when you save the game and load it later, we have to store this color in the save file. In Iron Village, that save is a "string", basically a bunch of words written out in a text file. It's not the most compressed, but it makes it much more easily readable by humans (or at least, me), which means it's way easier to find bugs.

So at this point, we need to take a number between 0.0 and 1.0 and store it in this text file. Or, we need to read some text and convert it to a number between 0.0 and 1.0. That's easy enough though, just about every common programming language has functionality built in to get this done, or at least some sort of standard library. Since I'm using C#, I just use the built in ToString() and Parse(). It seems to work pretty well, and I don't encounter any issues while developing the game or testing it.

At some point a few months ago, too late to avoid this problem but early enough that it saved me a lot of debugging time, I learned something kind of horrifying: the way C# handles converting numbers to strings and back can depend on the user's locale. That's right, the code behaves differently based on who is running it. My reaction when I discovered this boiled down to "WTF?!", but I hadn't yet realized my code was vulnerable. I had even wrote down a note to audit my code for this sort of thing, I just never got around to it.

With all of that prior knowledge, I open up the save that the bug reporter sent in, and see this:

"Shirt":{"color":"(0.0, 463000.0, 435000.0, 10000.0)"}

Loud Sounds

In comparison, this was such an easy bug to fix. At some point during development, I split up all of the sounds into two different channels, or "buses": Sounds and Music. Sounds also got split into regular and UI sounds, but the difference isn't user configurable. It turns out that a couple of sounds were missed, and were still on the Master bus, meaning they could be super loud even if you turned the sounds down. This was an easy fix - find the remaining sounds, and put them on a bus.

...and, now I've written a bunch of paragraphs about two bugs, lol. Hopefully that was at least somewhat interesting!