The Crust Global Events Guide: Meteorites, Solar Flares and Epidemics

Named events

ThreeMeteorites, flares, epidemics

Laser cannon cost

1 Energy CellPer shot, then recharge

Cannon coverage

PartialCannot cover the whole base

Solar flare

Two outcomesBonus power, or damage

Epidemic fix

Showers + medicineBoth, per official text

"asteroid" in patch notes

0 hitsThe game says meteorite

What the game actually calls these events

Start here, because the terminology on this page is not decorative and one common search term does not exist in the game’s own vocabulary.

An official announcement search across all 147 posts in the patch history for app 1465470 returns these counts. Single words are matched as whole words, so “meteor” does not pick up “meteorite”, and “lag” would not pick up “slag”:

The last two rows are the honest version of what used to be a clean zero. Both words do occur, and neither is the game’s name for anything that hits your base: “catastrophe” appears in a developer diary about capitalising on a humanitarian crisis in the high-tech goods market, and “crisis” appears there too, plus once as a Sandbox setting for a customisable late-game crisis. A page that claimed zero hits for both would be wrong; a page that read them as event names would be worse.

So if you searched for “the crust asteroid,” the thing you are looking for is called a meteorite here. That is not a pedantic correction — it matters when you go looking for help, because the pages and videos that match your search may be talking about a different object than the one the game actually spawns.

The value of this table is the negative half. It shows what an announcement history cannot tell you. If a term is absent from the patch notes, that is evidence about what the developers chose to write about, not evidence that the thing does not exist in the game. Keep that distinction in mind for the next section.

Meteorites: from free resources to a real threat

The launch announcement gives the clearest statement of how this event is designed, and it is worth reading in full because it explains a change in how you feel about the same event over a single playthrough:

While your base is small, most rocks land on empty ground and leave behind debris rich in resources, including rare minerals, so for a while you will be happy about every impact. But over time, the base grows and there is less and less empty space. Before you know it, a meteorite will land exactly where you spent three hours in Planning Mode.

That is not flavour text. It is a description of the event’s difficulty curve, and it tells you two things you can act on.

Early game, meteorites are income. Impacts on empty ground leave debris with rare minerals in it. If you are in the first stretch of a save and an impact lands away from your modules, the economically correct reaction is to go and collect it rather than to wish it had not happened.

Late game, meteorites are a threat that scales with your own success. The probability of a hit does not change, but the consequences do, because a bigger base occupies more of the map. The developers are unusually direct about how the randomness is tuned: “The process is, of course, random, but our programmers have kept quiet about the probability they set.” There is no published rate, and any site quoting a percentage is inventing it.

The event also comes in two sizes: “They fall one at a time or in a whole shower, and you cannot choose when or where they land.” There is no warning you can act on and no way to influence the target, which means the only real lever you have is where your expensive modules sit.

The Anti-Meteorite Laser Cannon is a defensive module, not the endgame gun

This is the single most common piece of confusion around this event, and the naming does not help: the game contains both an Anti-Meteorite Laser Cannon, which you build to protect your base, and the laser cannon you spend the late campaign constructing as the story objective. They share two words and nothing else.

The defensive one is described with an explicit operating cost:

New module: Anti-Meteorite Laser Cannon. For this stage, there is the Anti-Meteorite Laser Cannon. It shoots down rocks as they approach, but not for free: each shot costs one Energy Cell, after which it needs to recharge. One cannon does not cover the whole base, so decide what to protect first: the reactor or the bar.

Three mechanical facts fall out of that paragraph, and each one changes how you should build.

It consumes a manufactured resource. Not power, not credits — Energy Cells, a thing your base produces. So a meteor shower is a resource drain on your production chain, and a base with a thin Energy Cell margin will find its defences quietly underperforming during the exact event that needs them.

It has a recharge cycle. The cannon is a rate-limited system, not a shield. A whole shower is the case it is worst at, which is also the case where the damage is highest.

Coverage is deliberately never total. The instruction to “decide what to protect first” is the design telling you the choice is the point. The two candidates the developers name — the reactor and the bar — are a fair summary of the trade-off: protect the thing that powers everything, or protect the thing that keeps your colonists functional.

There is a real late-game relief valve, stated as a plain reassurance: “Of course, in the late game you will have no trouble with the supply of Energy Cells.” So the cannon’s cost becomes irrelevant eventually, and the limiting factor becomes coverage instead. Plan the layout around that, because you cannot retrofit coverage cheaply onto a base you have already spread out.

Solar flares do two opposite things

The second named event is the one players most often describe incorrectly, usually because they saw the good outcome first. Here is the official text, with the section heading left where the developers put it — the quotation begins at the start of the body sentence:

This event occurs randomly and can either trigger increased power output from your solar panels (but that’s not certain =)) or damage your buildings and the colonists working at their posts on the surface.

Note what is being described: a single event with a random outcome, not two different events. There is no flare type you can identify in advance and prepare for. The good result raises solar output; the bad result damages structures and the colonists standing at surface posts.

That second clause is the one worth building around. Damage to “colonists working at their posts on the surface” means the flare interacts with your staffing, not just your structures — a base that runs surface modules around the clock has more exposure than one that batches surface work. The developers treat the bad outcome as temporary rather than permanent, since the same section promises that “your brave scientists will come up with an elegant defense against this event too.” That points to a research answer rather than a construction answer, which is the opposite of how the meteorite problem is solved.

If you want the timer to be legible, make sure you are on a current build. Hotfix 1.0.8 “Improved the timer display during a Solar Flare,” which is a quiet admission that reading it was previously unreliable during the window where it mattered most.

Epidemics are a hygiene problem, and the fix is stated outright

The third named event is the only one of the three with a fully published preventive answer:

Epidemics break out when the colony is in chaos and unsanitary conditions. They worsen colonist mood and work efficiency, and in the most neglected situations they can lead to colonist injuries and deaths. This event is easy to avoid by equipping rooms with showers and toilets and by keeping a positive balance of medicine on the base.

The causal chain here is worth reading carefully, because it inverts the usual assumption. Epidemics are not a random affliction you weather — they are described as the consequence of conditions you control. “Chaos and unsanitary conditions” is the trigger; the event is downstream of your colony management.

Two preventive levers, both explicit:

1. Showers and toilets in rooms. The launch notes introduce the Shower/Toilet module with the same reasoning: “Colonists need it to boost their mood and reduce the risk of an epidemic on the base.”
2. A positive medicine balance. Not a large stockpile — a positive one. Official phrasing is “keeping a positive balance of medicine on the base,” which suggests the requirement is continuity of supply rather than a buffer size.

The penalty escalates through three stages in the official description: mood and work efficiency first, then injuries, then deaths. So an epidemic you leave running is not a temporary morale debuff; it can remove colonists permanently. Given that hiring costs credits and rising CPU, treating showers as decoration is an expensive mistake.

“Meteorite Fall” and what the patch notes reveal about naming

Here is where the tiering matters, and it is a good example of why we separate sources on this site.

The community wiki lists a large family of storyline events — The Aftermath of the Disaster, Stable Income, A Million Opportunities, A Place to Live, Rescue Operation, Top Secret, Laser Gun, and more — and sorts events into random, timed, storyline and unconfirmed categories. That taxonomy is useful and the wiki does not claim developer endorsement.

But the name “Meteorite Fall” does not come from the wiki. It comes from an official hotfix, 0.99.90.3, which records fixing a bug in that quest where the quest “would automatically progress” and separately notes that the quest’s video was replaced with the correct one.

That is a developer-written quest name appearing in a patch note, which puts it on a firmer footing than any community list. It also demonstrates the general rule this site applies throughout: the announcement history documents changes, not existence. “Meteorite Fall” shows up in the notes because something about it broke. Events that never broke are invisible there — which is exactly why the zero-hit results in the terminology table above should not be read as “this does not exist.”

Troubleshooting: warnings that vanish

Two official fixes target the same confusion, and together they explain most “the event did not happen” reports.

The notification disappears after loading a save. Hotfix 1.0.10 fixed “an issue where the incoming meteorite notification and Solar Flare timer disappeared after loading a save.” If you save and reload during a warning window, the warning can go away while the event does not. The practical implication: do not use a missing banner as evidence that you are safe.

The Solar Flare timer was hard to read. Hotfix 1.0.8 “Improved the timer display during a Solar Flare.” Prior to that, the information existed but was presented poorly, which produces the same player experience as it not existing at all.

Neither of these is a mechanic. Both cost players real bases, which is why they are on this page rather than buried in a patch list.

Where this leaves you

Three events, three different responses: meteorites are answered by layout and by a defensive module with a running cost, solar flares are answered by research and by not over-committing colonists to surface posts, and epidemics are answered by hygiene and supply continuity.

The one thing none of them reward is reacting after the fact. Official text makes the meteorite case bluntly — by the time the base is large, “a meteorite will land exactly where you spent three hours in Planning Mode” — and the epidemic case even more so, since the stated trigger is a condition you either maintain or do not. Build for the event before it arrives, and the sentence about sparing “the nerves of the colonists who happen to be on duty outside at the moment of impact” stops being advice and starts being a description of a base that is not losing anything.