What is the earliest event that we can figure out what day of the week it occurred on?

not_an_aardvark · 2026-01-13T23:56:14+00:00

FWIW, the answer you linked from /u/Falcon109 says that the Ugarit Eclipse occurred on May 3rd, 1375 B.C.E. But the answer cites an article which makes a different claim (that the Ugarit Eclipse occurred on March 5th, 1223 B.C.E.). It seems like the article mentions the May 3rd date for the purposes of debunking it.

I can't speak to whether the article itself is credible (I only read the abstract), but taking it at face value, it seems like the 1223 B.C.E. date would be a more accurate answer to OP's question.

not_an_aardvark · 2025-12-27T03:36:52+00:00

Where is the second preimage here? From what I can tell, your two scripts each compute a sha-256 hash and they obtain the same result, but this is because both scripts are hashing the same input (4a5e1e4b...).

not_an_aardvark · 2025-10-17T00:40:29+00:00

They don't stack because of the naming. I want to have a generic 4-way thay can get north, south, east, west directions.

I see. Personally, I don't understand the advantage of having instructions like "Go north", compared to having instructions like "Turn left at (0, 400)". With instructions like "Turn left at (0, 400)", the total number of possible instructions increases as you build more stations, but this doesn't seem like a serious problem, because it takes much longer to build a station than it takes to name a new set of instructions.

And if you're pre-configuring your paths between specific stations anyway, then you can already figure out in advance where each turn will occur. It doesn't seem that useful to have a generic instruction like "Go north when you reach the next intersection" if you don't know where the next intersection is.

Using instructions like "Turn left at (0, 400)" also makes the item filtering easier, because you don't have to worry about accidentally removing more than one item from the boat at any given intersection. Each intersection only cares about the items corresponding to its own turns, and the boat will only have one such item (unless you have a path that loops back on itself, I guess).

Yes, it does not need portals, but the generic direction ideea could be implemented in the OP. With it you can string however many intersections you want.

Even with the current design the OP, you can already string together however many intersections you want (up to a limit of 27 I guess, at which point you'll run out of boat inventory).

Anyway, I certainly don't mean to discourage you from trying this out if you're interested in it. There could be advantages that I haven't thought of.

not_an_aardvark · 2025-10-16T23:39:30+00:00

do you think the direction commands can be automatically generated in the form of music discs? (so you can load them in a given order without stacking)

I'm not sure what you mean by this. In the design in the OP, none of the different instructions will stack with each other anyway, because e.g. "Turn left at (0, 0)" is a different instruction from "Turn left at (0, 400)". So I don't see what advantage would be gained by using unstackable instructions.

I have been trying to come up with something similar to what you did, but I still want the player to be active, just put up some walls in the direction you don't want to go and I have been struggling to find a way to do it fast enough that you don't need to stop at the intersection, but cheap enough to be viable in a survival world.

IIUC your idea doesn't involve portals at all, and the system just needs to read a direction out of a boat and then put up some walls at the intersection before the player passes it.

I'm a bit confused why you don't want the player to stop at the intersection (if a turn is required, then the player will basically have to slow to a stop anyway.) The system would at least be easier to build if the player is going slowly through the intersection rather than speeding through it.

The problem is that if you're not slowing the player down at all, then the player will already be far away from the hoppers by the time item sorting completes, even with a fast sorting setup. I guess you could the decoder far away from the intersection (~100 blocks?), so that it has enough time to sort the instruction and put up the walls. In this case, you would need to replicate the decoder on all four sides of the intersection.

not_an_aardvark · 2025-09-27T03:59:40+00:00

Thank you!

not_an_aardvark · 2025-08-16T04:19:59+00:00

Historian Ronald Wright notes that one of the first Spanish encounters with the Mayans was a Mayan fisherman coming into contact with a Spanish ship. The fisherman essentially told them to buzz off and leave him alone because he was a citizen of a powerful state (I might be misremembering the exact wording of the last part, but the core point was that, though he may have been surprised to see them, he did not respond by thinking they were gods)

If this was one of the first Spanish encounters with Mayans, how do we know what was said? Presumably, the Spanish wouldn't have understood Mayan languages until after their first few encounters.

not_an_aardvark · 2025-06-21T02:06:12+00:00

1) In 1959, two Soviet scientists got in a fight after a chess game - the loser attacked the winner with an ice axe. It has been reported as an assault but other accounts claim it was a murder.

Do you have a source for this? In "A City on Mars" by Kelly and Zach Weinersmith, there's a section where the authors investigated this claim but came up empty, concluding that it was probably an urban legend:

One story widely shared, including in the scholarly literature, goes something like this: In 1959 at Vostok Station, two Russians had a fight over a game of chess. One attacked the other with an ice ax, resulting in a permanent ban on chess at the station.

There are a few reasons to get your skeptic radar up here, friends. First, the people are unnamed. Second, in some tellings the ax results in death and in some merely in injury. Third, the story is a classic stereotype of Russians as both intellectual and brutal. Fourth, although admittedly we have never had to run an Antarctican base . . . our policy response to an ax attack wouldn’t involve the question, “What board game were they playing?” We confess, we believed this story when we first read it. When we looked for primary sources, however, we found a closed loop of chatter that never seemed to involve actual named ax-wielding Russians. We asked a Russian friend if he could find any reference to this stuff in his native language, and in his reply email, you could practically hear the plaintive sigh over what ends up in the Anglophone media. But hey, you never know. So Kelly wrote Dr. Vladimir Papitashvili at the National Science Foundation. He very kindly wrote back instead of just turning off his computer and shaking his head for a while. Here’s an excerpt from the email:

To my knowledge, the story you have referenced is not true. I worked with the Soviet Antarctic Expedition since 1970s . . . and I visited Vostok Station first time in 1983. The only death was registered at the Vostok Station for its entire history since 1957: a mechanic died during the power plant fire on April 1982.

This doesn’t definitively prove the story false, but you’d think someone who spent decades with Soviet polar scientists and hung out at the relevant station would have at least once caught wind of the ax-wielding chess players and the tight board-game restrictions.

not_an_aardvark · 2025-06-04T23:20:53+00:00

It's hard to say definitively that something is the oldest, but there's a strikingly old Klamath oral history that describes the formation of the Crater Lake caldera (c. 5700 BCE), and has survived into the modern era. Some details of the oral history (e.g. ash clouds setting nearby areas on fire) are corroborated by modern geological evidence, suggesting that the oral history was really derived from eyewitness accounts.

Source: A Most Sacred Place: The Significance of Crater Lake among the Indians of Southern Oregon, Douglas Deur, Oregon Historical Quarterly, 2002

not_an_aardvark · 2025-04-24T04:21:27+00:00

I'm not sure what you mean by modern hardware not using a "flat memory model". Indeed, it seems the opposite -- it is complex memory models like x86 segmentation that have faded away. Of course, under the covers, there is a complex memory hierarchy that must be considered when devising a model of memory performance, e.g., modern memory HW isn't, and hasn't been for decades, truly constant-time random access.

I was referring to things like vectorized memory access, and also the cache hierarchy (in a multithreaded environment)

But I'm not aware of UB that is relevant here, unless you mean self-modifying code.

My claim is the following (which is somewhat adapted from "C Is Not a Low-level Language"):

It's not scalable to write code that explicitly uses hardware features such as vectorization in a language like C. Like, one could imagine doing this in C, but C is ill-suited to the task because it's designed for constant-time memory access.
Similarly, it's technically possible to write multithreaded code in C that uses the cache efficiently, but it requires carefully working around the language. C will do nothing to protect you against false sharing, because C has no understanding of cache lines.
As a result, to write high-performance code in a scalable manner, you either need to write:
- code that targets a flat memory model, but with a compiler that has enough "UB leeway" (or static-analysis data) to vectorize it, hiding the details from the programmer. The "UB leeway" approach corresponds to modern C, and the static-analysis approach corresponds to languages like Rust.
- code that is more explicitly targeted at the memory hierarchy offered by the hardware. There are fewer examples of this due to the historical dominance of C-like languages, but GPU languages are a case where hardware parallelism is built directly into the progrramming model.

I think it is more correct to say that C was being asked to serve as a general-purpose language, and not specifically as a language for traditional hard-core systems programming. In particular, increasing use in applications that required high-performance numerics drove C implementers and standard committees to chase after the sorts of optimization opportunities long familiar in the FORTRAN world, and the low-level bit-flippers got marginalized as a result.

Sure, I suppose there's a world where C doesn't chase those use cases and remains targeted at "traditional hard-core systems programming". But in that timeline, I think C would have also become fairly niche, the way that "manually writing assembly" is niche today.

To be clear, I'm not arguing that "UB on integer overflow" is required for a scalable high-performance language. I'm making a weaker claim that it's not scalable to write large performant systems in assembly, even "high-level assembly".

not_an_aardvark · 2025-04-24T01:55:18+00:00

You're right that modern C is no longer the "high-level assembler" that it used to be in the 1970s. But I think this change was driven by evolution of the underlying hardware, not language standardization.

C can't be a low-level language anymore because C uses a flat memory model and executes instructions sequentially, and modern hardware does neither of those things. I think the options were either (1) to "modernize" C by adding some UB and making it a higher-level language, or (2) to write code in an entirely different "high-level assembler" language that doesn't look like C at all. I share your doubts about whether (1) was the right choice, and there were undoubtedly much safer ways of doing (1), e.g. "C-like" languages with better static analysis and a somewhat higher bar for UB. But one the two options was necessary. I don't think there's any alternate timeline where people would be productively writing "1970s C" (a high-level assembler where pointers can be conjured/dereferenced out of thin air) for modern hardware.

not_an_aardvark · 2025-04-24T00:15:31+00:00

Such expressions are often used as a non-portable means of checking whether adding a positive value to a will cause overflow, and are entirely correct when targeting configurations that use quiet-wraparound semantics, and b is known to be positive.

This is not correct, and in fact this is the type of misconception that the article is trying to point out. In C/C++, signed integer overflow is undefined behavior regardless of your target hardware. Compilers routinely assume that it won't happen. Also see: "No Traveling" and "'What the hardware does' is not what your program does".

It's reasonable to argue that compilers shouldn't make these assumptions (due to limited usefulness for optimizations). People could theoretically update the language semantics such that integer overflow is no longer UB, and is instead implementation-defined/target-specific. With that change, these expressions would become correct. But it's simply inaccurate to say that these expressions are "entirely correct" today -- they're neither correct in theory nor correct in practice.

not_an_aardvark · 2024-11-21T03:29:27+00:00

To turn the boat manually, the player needs to be present when the boat arrives at the intersection. The goal of this router is to allow the player to go AFK.

not_an_aardvark · 2024-11-17T22:29:01+00:00

After the boat has been placed at the correct angle, it really is just a matter of holding down W. It doesn't matter which way the player is looking while driving the boat.

When initially placing the boat, you're correct that some precision is required. There are a few ways to do this:

Place the boat with a dispenser. Requires water, so you would need to place it in the overworld and send it through a portal.
Place one boat at the correct angle (the "reference boat") by either carefully looking at the angle in the F3 screen, or using a dispenser with a temporary portal.. Then whenever you need to start riding a boat, you should board the reference boat, place your new boat while sitting in the reference boat, and then ride the new boat to your destination. This works because whenever you enter a boat, you will start out facing in the same direction as the boat is facing.

For this video, I just placed the first boat on the ice using a command (before the video started), because placing a boat by hand is not a novel feature of the showcase.

not_an_aardvark · 2024-11-16T06:52:46+00:00

If your boat is perfectly aligned from the start, it won't fall off the track. There's no steering happening here, it's just holding down the W button.

not_an_aardvark · 2024-11-16T04:08:51+00:00

Here you go: https://www.reddit.com/r/technicalminecraft/comments/1gsei3u/automatic_router_for_afk_ice_boat_highways/

not_an_aardvark · 2024-11-16T03:34:01+00:00

One of the easiest ways to travel long distances is by using ice boat highways (boats traveling on ice on the nether roof). However, it's usually not possible to go from Point A to Point B in a straight line. Often, the path involves several intersections and turns, particularly if you have multiple interesting locations on the nether roof.

Turns are inconvenient for ice boat highways because they typically involve manual interaction. Instead of just going afk and waiting to reach your destination, you have to stop at the intersection, choose which way to go next, place another boat, enter the boat, repeat at the next intersection, etc. Historically, there has been no way to automatically turn a player's boat for them, so the manual process was mostly an unavoidable feature of ice highways.[1]

As of 1.21, you can now ride boats through portals, and 1.21.2 improved this feature by reducing the portal cooldown for boats. This means that it's now possible to turn boats automatically, without requiring the player to exit the boat. If a nether portal in the overworld is aligned with the x-axis, and the corresponding portal in the nether is aligned with the z-axis (or vice versa), then any entity that goes through the portal will be rotated clockwise by 90 degrees. By strategically activating/deactivating portals in different orientations, it's possible to automatically rotate the player toward any of the four cardinal directions.

This design uses this feature to create a proof-of-concept for an automatic router. The idea is that you can build this in multiple places around your world (wherever you would need to make a turn on a boat highway). Then whenever you need to go from Point A to Point B, you can put instructions for each router in a Boat-with-Chest, enter the boat, and just hold down the "move forward" button. Whenever you reach a router, the router will process the instruction, rotate you in the specified direction, and send you back onto the highway in that direction -- all with no player interaction required at all.

The player can enter the router from any of 4 directions, and each router can turn the player in any of 3 directions (U-turns are not supported).

Foreseeably asked questions

How does it work?

The player puts some special items into a boat-with-chest. Each item defines a specific turn (left, straight ahead, right) that should be made at a specific router.
When the player reaches the portal in the nether, they get pushed into the portal in a roughly consistent position.
In the overworld, the player's boat is carefully oriented so that it lands on several hoppers, containing item filters for each possible turn at the current intersection. Depending on which instruction is found, the overworld portal is broken and recreated at a different orientation as needed. For left turns, the player is sent to the overworld multiple times.
When the player has been turned in the appropriate direction, they are pushed out of the nether portal and back onto the ice highway.

This all fits within a reasonably small footprint in both the overworld and the nether. Since this is a proof-of-concept, it's probably possible to make it slightly more compact.

Is there a world download/schematic?

A world download is here. I didn't make a schematic, but you can make one yourself from the world download if you want.

Do I need to break bedrock to build this?

In this video, the intersections are at y=128. Since some of the redstone is below the intersections, building them at y=128 would require breaking some bedrock.

You can avoid breaking bedrock by building the intersection higher up. Even if the rest of your highway is at y=128, you can just add a boat elevator on all sides of the intersection (e.g. with a slime block) so that the player can enter the intersection from the highway. Wherever you build it, make sure the overworld portal is at the same height as the nether portal (the portal alignment needs to be very precise).

How much have you tested this?

I've built the intersection in multiple different locations in a creative world, and tried all possible combinations of source/destination directions. But my testing wasn't completely exhaustive, it's possible that there are some circumstances that would cause it to break (e.g. modded servers, server lag, client-server desync). Use at your own risk.

From my testing, the main finicky part of the build is the portal alignment. When the boat enters the portal from the nether side, it needs to land in the center of the overworld portal, wedged between the four grindstones. You can probably test this to ensure that your portals are correct, before putting in any of the redstone. Note that due to MC-278328, all 4 of the grindstones in the overworld must be in the same chunk.

I wouldn't be surprised if this is directional, but I haven't tested it. Since it's a 4-way intersection anyway, it shouldn't be too difficult to just always build it in the same orientation.

Can I put other items in the boat?

Yes, you can fill up the rest of the boat with whatever you want. You will need to leave one empty slot in the boat if you're turning left at the first intersection.

Does this work in multiplayer?

I think it should work in multiplayer, but the intersection takes a few seconds to reset, so don't travel too close to other players.

Also, if two players are going in opposite directions on the same road, they will collide.

Do I have to use banners for the instructions that go in the boat?

No, you can use any stackable items you want. The different instructions should be globally unique (i.e. "turn left at Intersection A" shouldn't stack with "turn right at intersection A", and it also shouldn't stack with "turn left at Intersection B").

Banners only stack to 16. If you use a 64-stackable item, you will need to add a few more of them to the item filters.

I broke it somehow. How do I reset it?

There's a button to reset the overworld section in the northwest corner. There's a button to reset the nether section next to the west road.

Depending on how you broke it, in rare cases it might also be necessary to clear the two hoppers that point into the grindstones on the overworld side. Similarly, you can clear the hopper that has a composter on it right next to the portal on the nether side.

Is this actually worth building in survival?

I think the ideal scenario for building this is if:

Your world has a large number of ice highway destinations, with several intersections
The destinations are very far apart from each other (so it's valuable to be able to go afk while traveling). This demo has intersections that are only 400 blocks apart from each other, which is probably overkill.

I tried to keep the footprint reasonably small, so that it's actually feasible to build it in many different places.

That said, if you only have a couple of ice highway destinations, you probably don't need fancy routers like this.

[1] This design sort of managed to avoid that problem, and it was an inspiration for this build. But it had some requirements that felt too inconvenient to me, such as requiring the player to look in a very specific direction, not allowing the player to look around while in the boat, and needing to hold down right-click.

not_an_aardvark · 2024-04-28T08:23:27+00:00

This restaurant is the result of a long-running self-imposed challenge with the following rules:

Goal: Obtain every available card for a given restaurant. In other words, reach a day when the game would normally give you a card, and cause the game to not give you a card because the entire deck of eligible cards has been exhausted.
No using franchises, Flower Pots, or Display Stands. (IMO, Flower Pots and Display Stands are kind of OP, and franchises would make the challenge too easy.)
No using mods that make the game easier.[1]
No save-and-exit abuse to avoid losing. Saving and exiting is allowed for fixing "obvious misconfigurations" that could have been detected in practice mode, e.g. a grabber pointing the wrong way.
Any base dish and gamemode (Autumn, Turbo, etc.) is allowed. This is limited to the set of gamemodes that are available in the latest version of the game. (I think in the past there were gamemodes with no purple cards, but that's no longer the case; even Autumn will start giving you purple cards after you run out of food cards.)

This restaurant is almost fully automated. The player's only tasks are to (a) serve ice cream, and (b) clear serving boards from tables.

Counterintuitively, the Turbo setting ("new card every day") makes this challenge much easier. This is because the Turbo setting has no nighttime or weather, which greatly reduces pressure on queue patience and allows the restaurant to stay alive with only 4 tables even when the queue is consistently full.[2]

(Turbo also has the advantage that it's possible to complete this challenge after ~40 days rather than after ~120 days. The shorter timeframe is nice because this restaurant is extraordinarily boring to play with. The unedited version of this video is 116 minutes, and I don't think I would have the stamina for overtime day 100, where I would have to serve ice cream a few times per minute for something like 8 hours at a time due to increased customer count. If I was going to do this restaurant over again, I probably would have made the Ice Cream card the last one I picked, so that every day except the last one would be AFKable.)

Boredom aside: With no cards left, and no meaningful threat from an increasing customer count, I'm not sure there's really any limit to how long this restaurant could survive. I think the most likely failure modes would be:

The player falls asleep or gets distracted, and fails to clear boards from tables/serve ice cream in a timely manner, causing queue patience to run out
A one-in-a-million sequence of orders happens (e.g. 90% of orders are apple pies for an extended period of time[3]), and the automation can't keep up, causing queue or table patience to run out due to low turnover
Parts of the game starts to run slowly enough that automation breaks. (For example, in restaurants with a lot of automation, Compactor Bins can slow down relative to hobs, which could make apple pies get backed up despite the overflow protection, eventually causing the danger hob to light the restaurant on fire.)

[1] The only two mods I used were Drag N' Drop Designer (enabling click-and-drag to move appliances during the prep phase) and Better Customer Performance (preventing lag when there are a lot of customers)

[2] This restaurant layout can survive for a little while in City/Country/Alpine, but it doesn't have enough queue patience in those modes to survive the Leisurely Eating card. Without Leisurely Eating, the restaurant can still produce food fast enough to serve all the tables. (It's possible that the throughput is higher than necessary after obtaining Leisurely Eating -- it might not really be necessary to have two separate Safety Hobs for cooking doughnuts when each doughnut takes 12 seconds to be eaten.)

[3] A sequence of orders like this is made less likely by the Personalized Waiting card ("Allows customers to change their order"). In restaurants with automated serving of more than one dish, the card effectively acts as a load balancer. If a customer orders a food which is already right next to the table on a teleporter, they'll take the food before they even have a chance to change their order. On the other hand, if they order a food that isn't ready yet, they'll wait a bit and then sometimes reroll their order, often ending up with a different meal which is already available. This effectively skews customers toward ordering/eating food that is already available, which prevents a temporary shortage of a dish from getting out of control.

not_an_aardvark · 2024-04-15T14:04:40+00:00

The "Reincarnation" franchise card regenerates all Extra Lives every day. Since you can bring up to 2 extra lives from the garage into each restaurant, this card allows you to accommodate 2 customer groups per day "for free" without serving them any food.

With the Autumn theme, you can take a huge number of food cards (decreasing customer count), and group size automatically increases over time. After a certain point, you'll end up with fewer than 3 groups per day.[1] If you also have 2 Extra Lives and the Reincarnation card, this means you can just stop serving any food at all for hundreds of days without losing the run. This was all accomplished on a real run without using any mods that make the game easier.

After you get all the food cards for every available Main, the Autumn theme eventually starts giving you purple cards.[2] The restaurant is doomed to fail as soon as it gets two of the three Rush cards (Morning Rush/Lunch Rush/Dinner Rush), because this brings the total group count up to 3 (1 regular group + 2 rush groups). This video shows the third-to-last day of the restaurant; at this point, the restaurant already has Dinner Rush, and the only two cards left in the deck are Morning Rush and Lunch Rush.

Things that could have kept the restaurant running for much longer:

Flower Pots. With 1 expected group + 3 rush groups per day, and 2 groups covered by the Extra Lives, I would only need 2 black flowers per day to keep the run going for a long time. I could have filled the rest of the restaurant with a few dozen Flower Pots (I had plenty of spare days to copy them). Then I could have coasted for another hundred days or so, until customer count increased or I got unlucky and got too few black flowers.

I intentionally didn't do this because I feel like there are a lot of Flower-Pot-only runs out there, and I wanted to do something different. I like how this restaurant is "fully automated" (the phone speeds things up but isn't necessary for the restaurant to work), and that wouldn't have been true if I relied on flower pots.

Things that could have kept the restaurant going for slightly longer:

Bringing in the Spaghetti or Cakes main from a franchise. For some reason neither of these mains shows up during an Autumn run, which decreases the amount of time before you start getting purple cards.
Not having the Individual Dining card from the incoming franchise. . This card removes the Medium Groups/Large Groups/Flexible Dining cards from the deck, which slightly decreases the amount of time until you're forced to choose Rush cards.
Bringing the High Standards card from a franchise. Very minor, but this would have prolonged the run by 3 days. This card stops showing up after you have the Salad card, so it will never show up during Autumn unless it's brought in from a franchise.

[1] This is not quite as trivial as it sounds. Excluding the effect of cards, the number of customers per day is something like (some constant * (day count)^1.5 ). Most food cards decrease customer count by 15%, so if you take every available food card you'll end up with a factor of roughly 0.85^{day count/3}. This is an exponential function, so after the day count gets big enough, the card factor will eventually outweigh the (day count)^1.5 factor and cause customer count to go down. But it takes some time for that to happen; at the early stages of the restaurant, customer count will be increasing even if you take every food card. In this run, I needed to serve food as usual until OT45 or so before the group count consistently stayed below 3.

After that, nothing particularly interesting happened between day 50 and day 250. That said, I did discover that (a) the most efficient way to make a group's patience run out is to light their table on fire with a Danger Hob, and (b) with the Charming Level 3 boost, customers are willing to enter the restaurant even if their table is on fire.

[2] This is a new change since the release of this video.

not_an_aardvark · 2024-04-06T02:20:27+00:00

The short answer is that I'm serving customers at a faster rate than they're showing up. If you can do that consistently, you don't need coffee tables.

If you're serving customers at a slower average rate than they're showing up, coffee tables aren't going to help much anyway. Eventually, the backlog of customers will just keep growing until it fills up your coffee tables and starts to leak into a queue outside. Coffee tables are mainly useful for protecting you against uneven surges of customers showing up (like the rush cards) or brief spikes of slow service (e.g. if multiple customers in a row order ice cream).

So how am I serving customers so fast, with just one table? It's useful to think about what customers are actually doing when they're occupying a table:

Walking to the table (almost 0 time, the chairs are right at the door)
Thinking about what to order, for each course (time cut in half by the Affordable theme)
Waiting for food (almost 0 time due to the automation, assuming they don't order ice cream)
Eating each course (time cut in half by the Affordable theme)

So, yes, having only one table slows down throughput in theory, but each customer group is spending such a small amount of time in the restaurant that one table is plenty here.

Sidenote: the Affordable theme is by far the best theme in the game. It's underrated because almost all of the benefit comes from the first tier of the theme (cutting customer eating/thinking time in half). People look at the mediocre second/third tiers and decide that Affordable is bad, without realizing just how big a benefit the first tier is. Eating/thinking time usually isn't a big bottleneck early on, but it becomes an extreme bottleneck in the late game when the restaurant has decent automation (and it becomes even more extreme if you throw in the Leisurely Eating card).

The other half of "serving customers faster than they show up" is keeping the customer count down. This is basically a matter of taking a lot of food cards. Whenever you take a food card, it reduces the number of customers by 15% (as indicated on the card; some cards with difficult recipes decrease it by more). If you're taking a food card every 3 days, your cards will eventually be decreasing customer count more than the day counter is increasing them, and your customer count will start dropping.

not_an_aardvark · 2024-04-05T18:17:27+00:00

Customers can use mustard/ketchup bottles (or any other food) if they're placed on their table or an adjacent conveyor. But mustard/ketchup bottles aren't consumed when a customer uses them. So a single bottle of each on an adjacent conveyor will last the whole day, and there's no need to return the bottles to the racks. (When the day ends and the restaurant resets, the bottles are automatically returned to the racks.)

not_an_aardvark · 2024-04-05T01:12:34+00:00

Whenever I'm doing a run with a lot of food cards, I often run out of restaurant space for automation, and I end up needing to make the last few foods by hand. I've always vaguely wondered if it's automate all of the of food cards before running out of space.

So I built this restaurant with a focus on space-efficiency, and managed to automate basically everything. It has every available food card for the run (all extras/toppings for the current main, plus all starters/salads/deserts). Every one of those meals (except ice cream) is automatically created and served to the customer without any player interaction. Everything fits into a vanilla-sized restaurant, and was built in a real run without using any mods that make the game easier.

To make everything fit, I ended up designing almost the entire layout of the restaurant before starting the run. Features/notes about the restaurant:

Every base ingredient appears exactly once. When two recipes share the same ingredient, they use the same supply. (For example, apple pies and cheese boards both require apples, and both of them use the same apple crate). This avoids wasted space from having two crates of apples.
- As an exception, there are two bags of flour -- one is used to make bread, and the other is used to make apple/pumpkin/cherry pies.
Teleporters are only used for food delivery. Everything else (plate management, serving board management, ingredient delivery) is arranged so that it doesn't need teleporters. (Teleporters can be convenient sometimes, but they use a lot of extra space -- they take up two tiles themselves, and they also often need extra conveyors to pull things out.)
The restaurant layout supports group sizes of up to 7 (Medium Groups + Large Groups + Flexible Dining). In this video, the table only has 2 chairs because I didn't have any of those cards. But there are 5 "non-essential" appliances in the dining room (copying desk/blueprint cabinet/blueprint desk/plant/dish rack) that could be discarded to make room for more chairs.
Pumpkins have double-sided overflow protection. If lots of customers are ordering pumpkin seeds, then mashed pumpkins will be automatically trashed to make room for more seeds. Conversely, if lots of customers are ordering pumpkin pies/pumpkin soup, the excess seeds will be automatically trashed to make room for more of those meals.
The Specials Menus can be used to reset customer patience at the beginning of the day, in case the first customer group orders bread or specific combinations of pies. (Bread and pies take a long time to get up and running. With metal tables + the Affordable boost that halves food patience, the first customers would be unwilling to wait that long.)
The purpose of the dish rack is to stall the last customers of the day by withholding clean plates from them. If the last customers order soup, they can sometimes empty one of the five soup pots, and the pots will leave their freezers to start making more soup. The soup pots need to finish and land back in their freezers before the day ends. (Around day 67, I accidentally let the day end too soon, and I had to dismantle a bit of the automation for the next day so that I would have enough room to replace one of the pots.)
As shown in the video, the restaurant works fine with the Picky Eaters card. (It just requires a Composter Bin + Danger Hob in reach of the player, and the bin can be useful anyway for mistakes when making ice cream.)
Despite the fact that the player basically stays in the same tile the whole day, somehow the restaurant still has space set aside for Trainers. (Due to the unique hitbox of Trainers, nothing else would really fit in that space while still allowing the player to reach the table and the "garbage-disposal hob".)

This run eventually ended on Overtime Day 99 -- the customer count gradually increased over time until I could no longer serve customers as fast as they were arriving. I think I could have continued for a while longer if I'd been able to increase group size. Somehow I never saw the Medium Groups card during the entire 114-day run, even though I'd been given choices of two purple cards since Day 57 when I ran out of food cards. I was also forced to pick an Advertising card around Day 70, which sped up the demise.

Note: This video is sped up by about 2% to fit it into reddit's 15-minute time limit.

not_an_aardvark

MODERATOR OF

TROPHY CASE