Brian Hamrick's Blog

The "Bad at Randomness" Fallacy

Wed, 17 Sep 2025 23:59:59 UTC

In this post I want to talk about something that I'm calling the "Humans are bad at randomness" fallacy. If you've read any discussions on a game with random mechanics, you've almost certainly seen a conversation that goes something like this:

Person 1: I just had happen to me multiple times in a row! Something has to be broken with the RNG.

Person 2: Nah, that's just how randomness works. Humans are bad at intuitively understanding randomness. It's just your confirmation bias / negativity bias driving you to think it's bugged when there's actually nothing wrong.

It's not wrong to say that humans have biases that cause them to have a hard time judging whether something is properly random, but in my observations of these discussions, this argument is invoked almost as a reflex. There's seemingly no real consideration given to the complaint before dismissing it as just "Humans are bad at randomness."

This often results in either no investigation or a very cursory investigation into the randomness, and as such even when there are, in fact, bugs that significantly affect the random outcomes, those bugs can live for an extremely long time.

Let's take a look at some real life examples.

PokÃ©mon Red/Blue/Yellow

This story takes place around 2013. The speedrun route for PokÃ©mon Yellow (the plan for beating the game as fast as possible) involves catching a level 6 Nidoran Male at the grass before Viridian Forest. Unfortunately, the chance for an encounter in that grass to be the desired level 6 Nidoran Male is only 5% (13/256, to be precise). Since each extra encounter adds a lot of time to a run where the goal is to be as fast as possible, speedrunners would typically only look at a couple encounters before starting over from the beginning.

The most active PokÃ©mon Yellow speedrunner at the time started noticing something interesting. If the first encounter they got was a level 6 Nidoran Female, and then they got the second encounter on the third step afterward (the game prevents you from getting an encounter on the first two steps, so this is the earliest possible time), then they swore that it was almost always a level 6 Nidoran Male.

In this story, I was Person 2, at least at first. I said that they must have just been remembering the coincidences. But, to no surprise to the reader given the topic of this post, I was wrong.

It turned out that the Tool-Assisted Speedrun community had noticed similar weirdness in the encounters being generated a few years prior. Tool-assisted speedruns, or TASs for short, are created with the help of emulators which allows the authors to select exactly which frame each button press lands on. For most random behaviors in the game, adjusting a button press by a frame or two could change the result entirely. But, for encounters, such changes might cause encounters to appear or disappear as expected, when there were encounters, the sequence of encounters would only change very mildly.

The culprit is that the game maintains two random bytes. Although the game isn't using anything like a modern RNG, each of the random bytes on its own is unpredictable enough to be considered random. However, due to the specifics of the RNG, the sum of the two random bytes only changes relatively slowly.

Most randomness in the game only used a single one of the two bytes, and so moving the event by a frame would result in a essentially unrelated result (although, in theory it would be possible to observe some patterns if you looked at the results on enough consecutive frames). But encounters used both random bytes, one to determine whether an encounter happens, and the other to determine which encounter it is.

The strange behavior that was noticed was because the fact that an encounter happens constrains the first random byte, which in combination with the sum also constrains the second random byte. Since the sum only changes slowly over time, so too does the subset of encounter types that are possible.

Release date: February 1996 (JP), September 1998 (US)

Behavior figured out: August 2007

Slay the Spire

The bug in this case was significantly more obvious than the one in the PokÃ©mon case, but given the ease with which it could have been identified, I think the time it lasted past the game's release is still surprisingly long!

Slay the Spire is a card game where each card has an energy cost to play. There are relics in the game which provide various effects. One of them, Snecko Eye, randomizes the cost of each drawn card to a uniform number from 0 to 3.

In a pattern quite typical of these issues, some players hated the relic, saying that they felt that it kept putting them in situations where all their cards cost 3 energy (the baseline maximum for a turn), and resulting in them losing the game. Other players countered with mathematical calculations that show that on average you'd be able to play more cards with Snecko Eye than without, and that it's just negativity bias that's causing the dislike.

The developer of the game also posted the line of code where the energy costs were being generated:

int newCost = AbstractDungeon.cardRandomRng.random(3); // random between 0-3

It's so simple, it couldn't possibly be wrong.

It turned out that the RNG in the game was being reseeded on every floor in such a way that the sequence of generated numbers was exactly the same, offset by one result per floor. So for fights on two adjacent floors, if you had Snecko Eye, you'd get the exact same sequence of energy costs, but offset by one card. There could be further deviations if other parts of the fight consumed random numbers as well.

The result of this bug is that if you look at the overall distribution of energy costs across a large number of runs, you'll see each one generated one quarter of the time, as expected. However, within a single run, since the generated costs were repeating floor after floor, lopsided distributions where one cost was favored over the other were significantly more likely than it would have been with independently random events.

Release date (EA): November 2017

Bug noticed and elaborated: February 2018

MapleStory

One of the features that MapleStory added is called "inner ability". Your character gets three lines which each can provide a stat bonus. You can reroll the lines to try to find more desirable stats, and while rerolling them you can lock the lines that you like by paying a bit more of the reroll currency.

I don't remember any suspicions of something being wrong with the system, until suddenly a Korean post showed a method of increasing the chances of the lines that you want, called the "recipe method".

Behind the scenes, there's a big list of all the possible inner ability lines. For illustrating the issue, let's just imagine that the list has 100 items, so we're generating three distinct numbers from 1 to 100.

When generating the first two numbers, everything was uniform as expected. However, when generating the last number, instead of picking uniformly from the remaining 98 numbers, the game would first make a 50-50 choice of whether the third number would be between the other two or not between them.

So if you locked lines 40 and 50, you'd have a 50 percent chance that the rolled third line would be between 41 and 49 (and then uniform between those nine), and a 50 percent chance that the rolled third line would be one of the other 89 options (1-39 and 51-100). This means that you're significantly more likely to get what you want if you first roll the two of your desired lines that "sandwich" your third desired line in a small interval.

Similar to the Slay the Spire example, if you were to look at the probabilities of each individual line appearing on no-lock rolls, you'd see a uniform distribution. You would see lopsided distributions if you looked specifically at rolls that locked lines, especially ones that locked two lines, because not all lines would be equally likely to be locked by players.

After this got publicized, it got patched out within a few months.

Inner ability added to the game: July 2012

Bug figured out: February 2021

Destiny 2

I don't personally play Destiny 2, so my narration for this example may be less reliable than the others.

Destiny 2 weapons have "perks", which are extra effects from a list of possibilities. Each weapon can have two ability perks, and players would grind looking for the best combination. At one point, a bunch of players started feeling that they couldn't find the combination they were looking for.

The two perks for a weapon typically have 6 options (although some have more or fewer), so the desired combination is expected to be a 1/36 chance. Some people started feeling like they were not getting it in a reasonable time and started thinking that the perks were weighted.

In keeping with the pattern, the initial responses were that the engine literally can't weight perks, and it's "just RNG" and "statements of feel".

Some members of the community were still not convinced, and built tools to crowd-source drop rates. Eventually the effort culminated in very convincing data indicating that perk combinations are non-uniform. (The linked document is probably a better narrator for this issue than my post).

Notice that it's perk combinations that are non-uniform. The individual perks are uniform, much like what happened in the other examples. Eventually, Bungie took another closer look at the perk generation code and confirmed that the issue was real. To their credit, they also posted a nice article describing the cause of the issue.

As an external observer, it's not clear to me exactly how long the bug was present in the game. It sounds like it may have been all the way starting from the release.

Release: September 2017

Bug found: October/November 2024

Takeaways

None of these examples appear to involve the game companies having any intent to deceive the players. Furthermore, looking at the random events in a one-dimensional fashion (looking at the distribution of a single variable) would not have revealed any of these problems.

Unfortunately, every time that I've seen a game company attempt an analysis of their own random systems without external guidance investigates solely along these one-dimensional lines. They collect the aggregate appearance rate of individual items, and if each of them appears at the expected rate, they conclude that there are no issues.

While it's true that people tend to be bad at evaluating randomness, it's important to realize that this applies just as much to the developers as to the players. The fact that the developers are bad at distinguishing fair randomness from unfair randomness means that when a bug is introduced that causes unfair randomness, that bug is disproportionately likely to go through testing without being noticed, get shipped to the final product, and then escape notice for a long time even after that.

Furthermore, game developers are generally not statisticians, cryptographers, randomized algorithm specialists, or anything similar. It's not expected that they have a lot of experience in the myriad of ways that random number generation could go subtly wrong. So when they miss these kinds of bugs, it's very understandable. But I do object to the way that the "Humans are bad at randomness" line frequently gets delivered in a very condescending way, despite the fact that many of the games probably do have statisticians, cryptographers, and such in their audience.

To sum up my current thoughts on the subject:

If the developer's aren't acting in bad faith (e.g. intentionally publishing false or misleading rates), then the appearance rates of individual items is likely to be correct, since it's relatively easy to test and notice devations.
We can expect that joint distributions of items are probably not tested, and because of the combinatorial explosion, each individual combination is less frequent and it is hard to notice if the rates are off without playing a lot. Players tend to play the game more than developers do, and sometimes the data required is even beyond a single player.
The fact that humans are bad at intuiting fair randomness means that the randomness can deviate from fair by a considerable amount before people start noticing it. There will be a baseline frequency of complaints due to the people who perceive fair as unfair, but when the complaints rise above that baseline, it probably means things are very wrong.
If a developer says they've investigated the RNG without explaining their methodology, it's likely that the investigation only looked at the most obvious ways that things could be broken (like individual item rates being wrong), and shouldn't be considered strong evidence that there aren't less obvious issues.
Even bugs that produce quite significant deviations from fair in joint distributions can live for months or years while people complaining are dismissed as simply being humans that are bad at understanding randomness.

How I use pronouns in 2025

Tue, 13 May 2025 23:59:59 UTC

I was recently in a discussion about singular "they". I have plenty of thoughts on the topic that I might turn into a separate post, but the discussion prompted me to look for research that had been done on questions such as:

What portion of people treat singular "they" as grammatical?
Are people of certain ages (e.g. younger) more likely to treat it as grammatical?

In the process of looking for answers to these questions, I found Kirby Conrod's PhD thesis on the topic, and discovered that there's way more going on with singular "they", and pronouns in general, than I had previously realized. I also realized that I could not reliably remember whether my personal idiolect's grammar had changed with regards to pronoun usage in the last 5, 10, or 20 years. As such, I thought it would be interesting to go through several of the examples in the literature and list whether they are grammatical for me. It will be interesting to see whether any of them change some number of years in the future.

I'm not going to write anything on the answers to the above questions in this post. If they interest you, I recommend reading Conrod's thesis that explores it in depth.

A very quick primer on notation

In texts about linguistics, example sentences are given, and it is important to be able to write out both grammatically correct and grammatically incorrect sentences. A grammatically correct example typically does not carry any additional marking, but here I'll be explicitly adding a check mark (âœ“) for sentences that I accept.

Sentences with incorrect grammar are marked with an asterisk (*). Sentences that are possibly grammatical but dispreferred are marked with a question mark (?). When I give an example with a question mark, I will try to also give a rephrasing that I believe I would be more likely to say. For sentences that some people will accept and some will reject, the research often uses a percent sign (%). Since I'm focusing on my personal idiolect, I won't use that here, but I expect that many readers will disagree with my judgments on some of the examples.

Singular they

Getting this topic out of the way first. In a 2017 paper, Bjorkman points out that "singular they" doesn't refer to a single usage pattern, but rather several different ones, and some English speakers will accept some usages while not accepting all of them.

Most commonly accepted is what's known as an epicene usage of "they", and I accept these usages as grammatical.

âœ“Everyone should know their own phone number.

When people say that singular they is hundreds of years old, it's usually backed up by an epicene example.

Next is the use of "they" to refer to a definite person whose gender is known (and, for the purposes of this example, that person doesn't use "they" as a non-binary pronoun), but is referred to in a non-gendered way. This usage is also grammatical for me.

âœ“Our eldest child broke their leg.

Finally, there is the use of "they" to refer to a specific person that was named (again, assuming said person does not use non-binary "they"), or is referred to by a gender-specific noun.

?Janet said they cancelled the exam.

?My sister broke their leg.

Before I started writing this post, I thought I would judge these sentences as grammatical. Upon reading them again, I believe if I were producing the sentences myself, I would use gendered pronouns for both: "Janet said she cancelled the exam." and "My sister broke her leg." Thus, I've judged them as dispreferred here. In the case of a name that does not suggest a particular gender, I might use "they". This also includes cases where the person is referred to by their family name and without a gendered title.

âœ“Did Chris say that they would be late?

Conrod also briefly mentions a similar usage where "they" is variable, but with gender-specific semantics:

?Every male professor needs to be respectful to their TAs.

Similar to the above examples, this is somewhere between invalid and dispreferred for me. I believe I would say "Every male professor needs to be respectful to his TAs." instead.

Overall, this makes me what Bjorkman called an "innovative they user". Of course, it might be significantly less innovative in 2025 than it was in 2017.

Quality, Quantity, and Relation

In chapter 4 of their thesis, Conrod discusses pronoun choice for speakers for whom definite singular they is grammatical. Those speakers will regularly be producing sentences where either a gender specific pronoun (he/she/etc) or a gender non-specific (they) pronoun could be used, and Conrod lists three maxims that guide this choice.

Quantity - Give as much information as the speaker knows.
Quality - Don't give information that the speaker is not sure about.
Relation - Give information that is relevant to the discussion.

These maxims frequently conflict, and different speakers may prioritize them differently. For example, one speaker might value Relation over Quantity, and use "they" to refer to someone whose gender they know if they feel the gender is not relevant for the conversation. On the other hand, a different speaker might value Quantity over Relation, and use gendered pronouns in the same situation.

I am going to set aside the ranking of Quality for my speech for now. I believe that there have been cases that I've assigned an assumed gender to an anonymous person when it was unwarranted, but I also believe that I don't do it particularly frequently. It's hard to judge purely via introspection.

On the question of Quantity versus Relation, I believe I clearly rank Quantity above Relation. That is to say, I would prefer to say:

My friend visited her parents over the weekend.

over

My friend visited their parents over the weekend.

if I have a particular female friend in mind, even if the fact that she's female is not relevant. Interestingly, this example also shows the opposite ranking in a different aspect of the sentence: I wouldn't include the friend's name if I didn't feel it was relevant (e.g. if I didn't think said friend would be a continued topic of discussion).

Depronominalization

Conrod mentions a phenomenon of using a pronoun preceded by a determiner, which they call depronominalization. Surprisingly, these are marked as acceptable without further comment in Conrod's thesis, but they are all ungrammatical to me. I'm not sure whether these judgments were assigned by Conrod based on their own idiolect, or if there is evidence that a wider section of speakers use this construction.

*I was looking for the other he.

In contrast, if the pronoun is a name instead, I am perfectly happy to use this construction.

âœ“I was looking for the other Chris.

A 2009 paper by Cowper and Hall gives several examples, which I'll present here out-of-order and grouped based on my judgments. All of them are listed as grammatical in the paper.

?Is that a he or a she? Neither; it's an it.

This example is the closest to being acceptable to me. I think I've heard the construction "is a he" enough times as meaning "is appropriately referred to as 'he'" that it sounds not entirely wrong to me, but I would primarily use a different phrasing: "Is that a male or a female? It's neither." (Note: This sentence would refer to a non-human. For humans, the construction would be "Are they male or female?") I can't think of a parallel construction to "it's an it", but the answer using "it" as a pronoun would implicitly indicate that "it" is the appropriate pronoun.

*"Lady, you are the cruell'st she alive, If you will lead these graces to the grave And leave the world no copy" (William Shakespear, _Twelfth Night I.v.241-243).

This example is ungrammatical to me. I would use the construction "the cruell'st woman alive". I can understand what is being said here, likely because of the simplicity of being able to mentally substitute out "she" with a word meaning roughly "a person who can be appropriately referred to by 'she'".

*The theys are not individual hes and shes with votes (Jenkins 1973).

Like the previous example, this is ungrammatical to me. However, unlike the previous example, I struggle to even understand what is being said here to be able to rephrase it.

*"You say to me-wards, your affection's strong; Pray love me little, so you love me long" (Robert Herrick, "Love me little, love me long").

I can't say I've seen the construction "me-wards" before. I am guessing here that it means "in my direction", trying to be slightly different from "say to me".

âœ“"'Roses are worth more dried than alive' - such a you thing to say." (The Tragically Hip, "Impossibilium").

?It just looked absolutely us somehow.

"Such a you thing to say" is a construction that I might use, with the meaning of "That is a thing to say that features that would strongly suggest to me that the speaker is you." In the second example, trying to use "us" with a similar meaning is more difficult because of the number mismatch. There are no qualities that could strongly suggest that "it" is "us", because the use of "it" presupposes that the referent is singular, while "us" would require a plural referent.

*a she-wolf

*a he-man

*the Me-Decade, the We-Decade

I've marked these as ungrammatical because even if I did use these constructions, I do not believe it would be accurately described as a pronoun usage. Specifically, I believe I would only use these phrases if they were lexical items or, in other words, names for concepts that happen to have a pronoun as part of its etymology.

For example, I might expect that "the Me-Decade" would be a name given to a decade where there was a popular philosphical movement that put more emphasis on one's self, but to my knowledge no such decade exists (Actually, after writing that, on a whim I decided to do a search and it appears there is such a term referring to the 1970s). Upon some more reflection as I'm writing now, I wonder if the Cowper and Hall gave this example with the intention for "Me-Decade" to mean "The decade in which I was born", but that would not be an interpretation that I give to the phrase.

âœ“Mini-Me

This example differs from the previous three in where the pronoun appears. I would happily use this construction to mean "something that strongly resembles a smaller version of me."

Pronouns as pseudo-articles

In the same Cowper-Hall paper, they give these examples with judgments that match mine.

âœ“You linguists are an eccentric lot.

âœ“They won't have an easy time convincing us linguists.

*They linguists are an eccentric lot.

*They won't have an easy time convincing him linguist.

However, when I read these examples, I immediately reacted that a slight rephrasing of the third one is grammatical for me:

âœ“Them linguists are an eccentric lot.

I think this example is very strange! Later in the section, Cowper and Hall do mark that "them linguists" is accepted by part of the population as an accusative, but in the example I've given here, the accusative pronoun is used in a phrase that's in a position where we would expect the nominative case.

This strangeness also carries over to the plural first person pronouns. I, as I suspect is common, accept "we linguists" as a nominative:

âœ“We linguists are an eccentric lot.

However, I also accept "us linguists" in the same position, and maybe would even prefer that construction!

âœ“Us linguists are an eccentric lot.

I suspect that I'm in a tiny minority on this one.

In line with the judgments given by Cowper and Hall, all of the attempts at a singular construction are ungrammatical for me.

*I linguist am an eccentric person.

*You linguist are an eccentric person.

*(He/Him/She/Her) linguist is an eccentric person.

Closing

I found this an interesting exercise. I came across both constructions that I accept that typically aren't accepted, and constructions that I don't accept that typically are (or, at least were presented as uncontroversially accepted). It's also surprisingly difficult to read a sentence and apply a grammatical judgment, especially when the meaning is clear even if the sentence is ungrammatical.

I built a Voron

Fri, 31 May 2024 23:59:59 UTC

I've had my Voron 0 up and running for about two months now, and I wanted to write a bit about my build experience.

I had loved the look of the Voron 0 for a while, bought an LDO kit on Black Friday last year, and finally got around to building it. There's a lot of options for kits on the market, and LDO's is one of the priciest, if not the singular priciest. I was drawn to it over the other kit options for a few reasons:

LDO has an excellent reputation in the 3D printer community, with their kits having quality parts and nothing that is effectively mandatory to replace.
They provide a 100W bed heater, over the "stock" 60W option. The comparison videos that I saw between LDO's bed heater and the other bed heater options made this a likely upgrade that I'd want to do if I built a different kit.
LDO's kit comes with all the wire terminations already crimped. That's a huge time saver. Not only does it mean I don't have to do the crimping myself, but I think their crimping was more likely to be good than my attempts (I've only done a small amount of crimping and have had several of them fail), so it also probably saved me time on debugging bad wire connections.

Before moving on, I should also mention that buying a kit is a no-brainer choice for almost everyone. It will generally be cheaper to buy a kit and separately buy any part upgrades that you want than to self-source everything, even though it'll mean that you end up with extra parts that you aren't using. A lot of hardware parts are sold in packs that aren't conveniently close to the number required, and also may have cheaper bulk pricing. You also save a lot of shipping costs by getting everything in a single shipment.

Rather than a full self-source, there's another interesting option of buying sub-kits. For example, you can get a kit of frame components, a kit of motion components, and so on. I think that for this route to be worthwhile, you need to have a decent number of parts in mind that you're going to replace, and even then I would probably not recommend it for a first build, since it makes it much more likely that you overlook some key part when ordering and have to wait for a new delivery mid-build.

I've heard several people say that the Voron 0 is the most difficult Voron to build because of its small size, but overall I still wouldn't say it was that difficult. However, it does take a decent amount of time. I think I spent roughly 50 hours on the build process, though if I were to build a second one I'm confident I would be able to go much faster.

For someone looking to do their own build, I'd give two pieces of advice. First, take each step slow and understand what you're doing. Second, don't be afraid to go backwards in the process to change something. Even with reading the manual as closely as I could, I had to go back and fix mistakes multiple times. At least one was caused by misreading the manual, but there were other cases that were much harder to avoid. For example, I was using No Drop Nuts and would use them again, but there were a couple times that I found that the nut holders that I used were preventing the nuts from getting to the right positions, so I had to take apart part of the frame to swap them out. Even though it feels a bit demotivating to undo your precious work, it was never a particularly arduous task. Each step backwards just involved loosening a few screws, sliding out some extrusions, and then putting everything back into place.

After the mechanical parts of the build, there's also several steps involved in configuring the software, both the firmware running on the printer (Klipper), and the slicer. Steps like fine-tuning the Z offset and configuring the extrusion multiplier definitely require patience, but once I got through the full process, I felt like the parts I was getting out of the Voron were higher quality than the ones I've gotten out of the Bambu X1C.

It's likely that I could do a similar tuning process to improve the quality of my X1C prints, but I'd be relying on the Bambu firmware to have equivalent options to the ones in Klipper. This reminds me a lot of one of the advantages of running Linux: if there's something you don't like, it's extremely likely that you are able to change it, and also a reasonably high chance that someone else did it before you and you can reuse their work. With the Voron, this advantage also extends to the physical parts, and there's a huge set of mods in the community to pick from.

As for mods that I'm looking at incorporating into my build, the biggest one is ZeroPanels, which makes it much easier to un-enclose the printer for things like access to various parts. I'm also intrigued by the Pandora gantry, although I don't yet have plans that would require the extra travel room.

Finally, I already have components for a Galileo 2 standalone extruder, which I would install along with the Dragon Burner toolhead. I don't have any complaints about the print quality from the Mini Stealthburner, which is the "stock" Voron 0 toolhead, but during assembly I had a bit of trouble with the extruder parts where the shaft of the drive gear seemed to be a bit undersized so I could barely get it onto the extruder stepper, and couldn't get the set screw in at all. So far, the extruder seems to be working with no problem without the set screw (the gear is just holding itself in place as a result of it being a tight fit), but I wanted to have a backup extruder option on hand in case it ever started failing. The printed parts for both of these were some of the first prints I did after finishing the calibration.

I've been using my Voron 0 to print out the pieces of my new Face Turning Octahedron design. As I've been assembling it, I've already noticed even more places for possible improvements, but that will have to be the topic of a different post.

Of course, there's one last question: Will I be building another printer? Right now, I don't think I have the need. The Voron 0 and Bambu X1C cover the amount of printing that I do for myself, and also mean that I have redundancy if an issue arises with one of them. I had been eyeing the potential of building a Dueling Zero to give me access to faster and less wasteful two-material prints allowing the use of a different material for supports, but I've gotten the surface finish of supported surfaces beyond what I expected and good enough for my purposes right now, despite using only a single material.

It would be a fun build, though...

3D Printing a Computer Cover

Sun, 17 Mar 2024 23:59:59 UTC

The Problem

A while back, I got a new computer. Since the chip shortage was still ongoing, the easiest way to get a good graphics card was to buy a prebuilt PC. The PC overall was great, and even better after I installed liquid cooling which made it run effectively silently. The difference is so large that it feels similar to switching from a HDD to an SSD. I'll probably never run a desktop with air cooling again.

Anyway, the computer had a fatal flaw.

The power button sits flush with the top of the case. Inky, one of our cats, is fond of using my desktop tower as a stepping stone to get on top of my desk, and shortly after I got the PC, she stepped on the power button and it dutifully turned off.

For a while, I had been using a very simple solution of putting a book on top of the power button. The book distributed the force so that the power button wouldn't move enough to trigger. Unfortunately, recently Inky had been pushing the book to the side or off of the tower completely, leaving the power button exposed. So far I had managed to avoid any incidents, but it was only a matter of time. And, you know, what if I wanted to actually read the book?

Using FreeCAD

I started doing a bit of 3D modeling around a year and a half ago, but I had so far only done the modeling in OpenSCAD. OpenSCAD was great for me because I knew how to write code, but didn't know how to do CAD. However, I was starting to run into some of the limitations of OpenSCAD, most notably the difficulty of creating fillets due to it representing bodies as meshes, which means that it has no concept of an edge to be filleted.

I decided this would be a good project to try out a more standard CAD program, or at least one that uses boundary representation (B-rep) instead of meshes, so that I would have access to better fillets. From what I can tell, most people use Fusion 360 for this type of work, but I wanted to try out open alternatives before committing to Fusion, so FreeCAD it was. I used the main version of FreeCAD. I considered using realthunder's assembly3 fork, which I have heard makes some things more intuitive, but my attempts of getting it installed were failures, so I stuck with the main version.

The idea for the cover that I'd make was simple: It would be a piece of plastic slightly larger than the computer tower so that it would sit on top with minimal movement, and it would have cutouts for the power button, USB ports, etc, and a grid of holes above the fans. The idea is that when Inky jumps onto it, her paw won't go far enough into the power button cutout to actually hit the power button, but that it would still be easily accessible by human fingers.

Getting started was a bit rocky. I originally tried using the Part workbench because it had tools with the names I expected ("extrude"), but then when I wanted to make a hexagon grid pattern of holes above the computer fans, it seemed that the tool I wanted (MultiPattern) was only in the PartDesign workbench. After some confusing research, I decided that PartDesign was the workbench that I wanted to be using, and the "extrude" equivalent is called "pad".

Actually building the model wasn't too bad, except for the final step of selecting edges to fillet because rendering the model with the hexagon grid cut out was extremely slow. Some time after I finished the model, I found out that the rendering is greatly sped up by enabling the "Use OpenGL VBO" setting. However, even with that setting enabled, sometimes the rendered view still slows to single digit FPS and the rest of the UI also becomes unresponsive until it finishes whatever thinking it had to do (This could be a whole rant on its own, not specific to FreeCAD).

Model in hand, I went to print it out.

Slicing and Printing

For 3D printing, I'm currently using a Bambu X1C, which has a build area of 256mm x 256mm. The cover I designed was 432mm x 205mm. Clever use of diagonal orientation would not be enough to get it to fit into the build volume; I had to split it up into multiple parts. That's nothing unusual for 3D printing, but since I had previously only designed small parts, it was my first personal experience with cutting up a model.

I ended up cutting up the model into three parts, which each could be printed flat on the build plate. I liked this because the main exposed surface of the final product would be the first layer of the print. The first layer picks up the surface pattern of the build plate. I'm using a textured PEI sheet, and I really like the way that it makes first layers turn out.

For the two joints, I used different methods. The frontmost and middle pieces were separated in the middle of a featureless area, so I used a dovetail joint there. The middle and back pieces were cut in the middle of the grid of holes, so I didn't expect a dovetail joint to do well. I used connector pins, which make horizontal holes in the two pieces and two small cylinders to additionally print.

This was actually my second try at cutting up the model. I originally did dovetails on the thin sides of the part, and tried to print the three pieces standing up. This would have had the advantage that I could print all three pieces in the same print job, but it had downsides of exposing a side composed of layer lines and being a much more difficult print due to the hexagon grid being vertical. My attempt at printing this way ended up with a nozzle clog a few hours in (also a new experience!), which eventually resulted in me replacing the nozzle entirely when I kept getting partial clogs reappearing after trying less drastic unclogging methods.

Anyway, let's take a look at the final result.

The Verdicts

FreeCAD

I didn't find the UI of FreeCAD as bad as it's suggested by some of the reviews I found online. It did take some time to get used to it, and it wasn't obvious at the beginning whether I should expect to use Part or PartDesign. However, it was really frustrating to do an incidental action on the model viewer and have the entire application stall until the action was finished, meaning I couldn't access any menus, move to a different stage of the model (which would be simpler to render), and so on.

For my next design project, I will probably try a programmatic CAD option that still uses B-rep. I think it will be nice having three distinct and very separate steps of editing the model, calculating the model geometry, and viewing the model. Calculating the model geometry is expected to take a decent amount of time, and sometimes I noticed a mistake in my parameters while it was happening, so it would be useful to be able to kill the step and go straight back to editing. Also, FreeCAD mostly recalculates after every single change, which means that when updating multiple parts of the model, I had to wait a significant amount of time between each edit, even if I didn't actually care about visually inspecting the result.

Modeling based off of a photograph

When making the cutouts for the power button and ports, I imported a top-down photo of the computer top into FreeCAD and built the sketch based on the photograph. This technique lets you match the part that you're building on without making a lot of measurements.

It worked acceptably, but the power button is noticeably off center in its cutout. I'll probably just take the bunch of measurements in the future.

Joints for the 3D print

The dovetail joint was excellent. The two pieces fit together very cleanly and it doesn't show super obviously in the final result.

On the other hand, I don't like the way that the connector pin joint came out. The pins didn't slide into the holes easily, and I didn't want to try sanding or filing them down to a slightly smaller size, so I just pushed the two pieces together as much as I could, and there's a very clear gap still. In the future, if I want this kind of joint I'll plan to do it myself in the model instead of relying on the slicer. Doing it myself in CAD means that I can more easily control things like the amount of clearance to leave for the pins and a chamfer to help align it when pressing it into the part.

The slicer also only let me do a single dovetail joint in the middle of the part, but it might have also been a good solution to do two small dovetails outside the grid of holes, which is again something that I could do if I modeled the joint myself.

The Culprit

Of course I can't leave this post without a picture of the cat that caused the whole thing.

A 2024 Update

Fri, 1 Mar 2024 23:59:59 UTC

About two weeks ago was my last day working at Google. I'm still not sure to what extent I want to write about my time there, so at least in this post I won't be going into any details for why I left. One of the big effects the job had on me was that I generally had very little energy after getting home, and so all my personal projects ended up getting put aside.

Now that I've left the job, I'm looking forward to spending time working on a bunch of these personal projects that got more or less abandoned, and maybe some that I thought of but never started. One of them, as you might have guessed by the fact that you're reading this, is that I'm hoping to start writing on this blog again.

After I stopped regularly posting blog posts in 2017, I had multiple people tell me that they really enjoyed reading the posts and were hoping that I would revive the blog. I appreciate the support a lot, and unfortunately the blog was one of those projects that I felt like I couldn't dedicate much energy to due to work. So, now is a great time to write again!

Some things will be the same as before, and some will be different. I want the blog to be something that I enjoy updating, which will hopefully lead to it actually getting updated. I don't know how obvious it was to readers, but my old posts were generally written with very little proofreading or editing. That part will stay the same! I've seen plenty of people burn out on their hobbies from putting a high expectation of quality on themselves, and they end up not posting anything or focusing on an alternate venue where they feel they can get away from those expectations.

The big thing that will be different is that I'm not going to try to stick to any sort of schedule for writing and publishing posts. In the previous period of posts, I tried to have a post up every week on Wednesday. The result was that I didn't write much outside of Wednesdays, and I spent pretty much all of Wednesday writing to get something out. I don't know to what extent that directly contributed to me no longer updating the blog, but I'd like to try it differently this time. So updates will be irregular based around when I'm motivated to write.

The subject matters of my posts always varied quite widely, and I expect they'll have a big variety going forward as well, but I also want to try having series of posts around projects as I do work on them. One of those projects is this website itself.

The website is written in Haskell, using warp-tls as the underlying web server. It wouldn't have been particularly problematic to leave things as they were if all I wanted to do was add more blog posts, but for any more intensive code changes, I really wanted to be using an up-to-date version of Haskell, and I also thought it might be interesting to write about what I needed to do to get the code up to speed given that it was previously being compiled with GHC 7.10.3, a release from 2015.

It turned out that there was actually next to no work to be done: after installing ghcup and using it to install the lastest ghc and cabal, the only compile errors I had were from Data.Time.Calendar adding values named January, February, etc, which conflicted with values of the same name that my code defined. I also had a couple warnings about using tail (Aside: I'm extremely happy that the Haskell community decided to put warnings on the partial functions in Prelude), so I replaced them with drop 1, which was easier than refactoring with NonEmpty and fine for my use case.

Here is the entire diff:

diff --git a/src/Models/Blog.hs b/src/Models/Blog.hs
index c308c78..e87c424 100644
--- a/src/Models/Blog.hs
+++ b/src/Models/Blog.hs
@@ -92 +92 @@ older_entry =
-        (id_ b2, b1)) (zip entries (tail entries)))
+        (id_ b2, b1)) (zip entries (drop 1 entries)))
@@ -95 +95 @@ newer_entry =
-        (id_ b1, b2)) (zip entries (tail entries)))
+        (id_ b1, b2)) (zip entries (drop 1 entries)))
diff --git a/src/Util/Date.hs b/src/Util/Date.hs
index bd17106..d04582c 100644
--- a/src/Util/Date.hs
+++ b/src/Util/Date.hs
@@ -5 +5 @@ import Data.String
-import Data.Time.Calendar
+import Data.Time.Calendar hiding (January, February, March, April, May, June, July, August, September, October, November, December)

Pretty boring!

The other thing I decided to update was the DigitalOcean droplet that the site is running on. I hadn't updated the Ubuntu distribution since I created the droplet nine years ago, so it was running Ubuntu 14.04.

The update procedure is theoretically pretty simple: sudo apt update, sudo apt upgrade, then do-release-upgrade to get to the next release. Since I was four releases behind, I'd have to do this procedure 4 times (14 to 16, 16 to 18, 18 to 20, and then 20 to 22). Unfortunately, when I got to updating from 18 to 20, things went wrong.

The droplet wasn't reachable over the internet, and eventually I figured out that it wasn't booting properly. It seemed to just hang at some point, with the last message on screen being Finished Helper to synchronize boot for ifupdown.... It wasn't clear what actually was going wrong, since there weren't any error logs, and I ended up restoring to the snapshot I made before doing any work, so after a few hours of frustration I was back to 14.04. At least my website was back up.

Upon retracing my steps, this time creating a new snapshot after each release update, I got the exact same failure trying to update from 18 to 20. Eventually, I stumbled across a post that suggested that the update might be on a bad kernel, which prompted me to look into updating the kernel without doing a release update. What I found was actually the opposite: My droplet was still using the same kernel after each release update!

This was because the droplet was still on the legacy kernel management, which meant that the kernel on the disk image was being totally ignored. A simple switch on the droplet configuration got me on the expected kernel, and from there the updates from 18 to 20 and 20 to 22 worked without incident.

Out of curiosity, after the updates were done I ran wrk to see how well the site handles load and found that it can indeed be hug-of-death'd. I humbly ask that readers don't try replicating my experiment. It's not at the top of the list of things I want to work on, but I might try to improve how it handles high load.

One of the projects that I have plans to work on is my 3D printed face turning octahedron, which I posted on Reddit a while ago. Since that post, I've figured out a way to solve one of its biggest flaws, but didn't have the energy to incorporate it into a new design. The puzzle already went through many design iterations to get it to turn as well as it does, and I plan to write up a dedicated post with more details.

Until next time!