I think it'd be reasonable to keep uber, but I had dropped it because it wasn't in /usr/share/dict/words on Linux or Mac. That was a quick&dirty way to filter out proper names, but it misses some other words too.

I was wondering why you involved that dictionary, but this makes sense.

I added the word list to the main article. The rule is for two words, ubiquitous and ubiquity, so maybe the rule should be tightened to word.startswith("ubiqu").

Uber and Ubuntu are not in my word list (which attempts to exclude proper nouns), but maybe I should add uber, uberant, uberous, uberously, uberousness, uberty, uberties.

I had a self-imposed time limit of 1 day for this side quest, but there are lots of ideas in the comments here so someday I may come back to this project and give it another day.

Good catch — "homes" wasn't in my /usr/share/dict/words for some reason so I missed this case!

*hones

That is my favorite podcast of all time!

Bookmarked! I love the interactive diagrams! I love that you have a touch-point larger than the drag handle. And I'm impressed that the label placement takes care to avoid the axes. Some feedback:

You have vector s in blue, and then vector u in teal, and then vector v in orange.

In the diagram, it's "Subject", "First Reflector", "Second Reflector". I think it'd be better if these labels were "Subject s", "First Reflector u", "Second Reflector v" so that we can match up the text to the diagram even without color.

Later you have "The pair of vector u and v is called a rotor". But these colors do not match the earlier colors, and it makes it hard to connect to the diagram.

In the 3D diagram, I think it would be better if you used the same color scheme as for the 2D diagram. Same for the circular reflection diagram.

Suggested colors:

- subject s - orange in every diagram (currently blue, blue, blue)

- first reflector - teal in every diagram (currently teal, magenta, pink)

- second reflector - blue in every diagram (currently orange, teal, orange)

This makes the rotor colors more similar to each other than to the subject.

Thank you very much! Those are all very good points I agree with. Reworking the color scheme is something I had already planned.

I have now reworked the colors and labels.

Thanks — yes, I'm still struggling to find a good way to explain the colors. The landmark is green. The blue tiles are the savings — the difference between using the landmark and not using it. I'll work on a different wording or maybe a visualization.

Changing the graph is another optimization that's commonly used. A graph of rooms is far smaller than a graph of tiles, and you can precompute paths on the small graph. The landmark heuristic can work on that graph too, although with the small examples on the page you probably wouldn't need to.

Yes, it's a bit weird! There are also optimizations that do what you describe, with landmarks along the way, but at least at the time I learned about it, road map pathfinding was using landmarks behind the target.

Good catch. I was thinking people would read that after they have moved the green L but I should handle both before and after moving L.

I'm also fairly certain I read a "helsp" instead of "helps" somewhere in the post

The landmark data can be calculated in a background thread. For DF I imagine you'd have a background thread running all the time, updating one landmark every so often. But what happens if you look for a path before the landmark data is updated? I haven't tested this yet but I believe this is how it'd work:

1. If the cost of a tile decreases, the precalculated heuristic will be too high, so A* might find a non-shortest but ok path. In game, you can think of the dorf as following the path they already know about, because they don't yet know that there's a shorter way.

2. If the cost of a tile increases, the precalculated heuristic will be too low, so A* will find the optimal path but it will take a little bit longer (still not as long as if we weren't using this heuristic). In game, you can think of the dorf as following the path they already know about, but running into a wall, so then they find a path around it.

One of the famous problems with df is that it's very much single threaded. At least the last time I checked, which is some years ago by now.

Besides that blocker, your idea sounds like a nice win.

Experimental multithreading was added in 2023 https://www.bay12forums.com/smf/index.php?topic=181776 I'm not sure if it's improved since then. Performance doesn't seem to be a priority for Tarn. It's kind of unfortunate, since I think DF would be an interesting problem space for optimizations, similar to Factorio, and it really needs it.

I found https://www.youtube.com/watch?v=a_rAXF_btvE to be more balanced than the LTT video, but I think it mostly depends on your expectations of the cameras. The videos themselves are stored locally, not in the cloud. But if you have thumbnails turned on in the notifications, then the thumbnails have to be stored somewhere temporarily (I think this is an Apple/Google requirement), and they're being stored on a cloud server rather than in your home network (which would require opening up a port).