For each seed, 3 interior layout types can spawn: Facility, Mansion, and Mineshaft. Facilities provide an additional scrap in the form of an 80c Apparatus, and Mineshafts spawn an additional 6 scrap items to compensate for their difficulty. Every moon except March can spawn all three interiors.

March is the only moon to always spawn with Facility. On a technical level, this Facility is actually a different interior layout entirely due to 3 fire exits spawning instead of one, though it otherwise appears and functions identically to normal Facilities.

Total_Value/ represents the sum of all regular scrap values, plus 80c for the Apparatus if present. This value will also get an additional +600c on Nutcracker Infestations, as it effectively guarantees the maximum number of Nutcrackers, 10, will spawn. Each Nutcracker will drop a shotgun worth 60c, hence the +600c, though note that these shotguns do not contribue to the database's stored scrap count for the seed. The +600c is applied regardless of whether the infestation only happens on October 23rd. Note that this +600c is somewhat abritrary due to enemy spawns normally being ignored when generating the seed data.

The in-game terminal scan always overestimates, with inaccuracy, the moon's actual total value. According to the Lethal Company Fandom, you can get a more accurate value if you "multiply it by 0.41 if you're the host of the lobby or by 0.5 if you're not."

Gift boxes almost always provide a higher average value when opened versus closed even on SIDs, so this added value is reflected in a seed's stored total value. The only exception to this is Experimentation gift box SIDS. On this moon, gift boxes open to an average value of 43.87c, and since gift box SIDs always price each item at 50c (on experimentation this ends up as 69c), it is more valuable to not open them only in this instance. Every other moon has a gift box content average above 50c (the 69c boost only happens on Experimentation).

The total value is almost always inaccurate, as it is based on the average values of each scrap type (the average also accounts for SIDs, including the chance for a boost or reduction to occur). The sole exception to this are Mineshaft seeds, as the scrap items that spawn there have easily predictable exact values (gift boxes still add an average, unknown value). This is largely convienent for hunting the most valuable seeds due to the valuable +6 item count Mineshafts obtain, making a non-Mineshaft seed unlikely to be the most valuable seed (except on March where only Facility can generate). Below is a clearer breakdown on why only Mineshafts have predicatable scrap values:

After determining the scrap types to spawn, the game then assigns each scrap a value using a random number generator, AnomalyRandom. Generators are only predictable if is it known how many times they have already been used. However, before this can occur for each scrap item, the game checks if the item will spawn in a parent container (such as the locker shelves or bookshelves on Facility and Mansion, respectively). If it does spawn in a parent container, no further random calulations are needed to determine its position. But if it does not spawn in a parent container, AnomalyRandom is used to calulate the position. Since Mineshafts have no parent containers, this behavior is predicable: all items will use AnomalyRandom once before its price evaluation. But on Facilities and Mansions, the only way to know whether an item will use AnomalyRandom a second time is if the interior dungeon's layout is calculated, a computationally expensive and complex task. As of now, this database is unable to account for dungeon generation, so all Facility and Mansion seeds use average values in place of calculated ones.

The values of beehives and eggs are added to the scrap total, but this value is sometimes an underestimate, as explained in Day Scrap Potential (Beehives and Sap Eggs).

Scrap_Count/ represents how many unique scrap initially spawn into a level. On Facility interiors this will also include the Apparatus, as it spawns at the same time as regular scrap does. This also represents the very initial terminal scan when landing on a seed in the game, as beehives and Sapsucker eggs only spawn a few seconds after regular scrap spawns.

Scrap count does not include beehives, eggs, shotguns, knives, or corpses despite their in-game affect on the terminal scan count.

Each moon has a ranged interval that determines how much regular scrap spawns. For Experimentation, this inclusive range is [8-11]. If the interior is Facility, an additional +1 occurs due to the Apparatus spawning. If instead the interior is Mineshaft, an additional +6 regular scrap spawn (in order to balance the difficulty of the interior). Mansions have no effect on the scrap count. Due to correlations, Experimentation only spawns 10 regular scrap on Mansions and Mineshafts (the latter getting +6), and combined with the +1 on Facilities, Experimentation seeds can only ever spawn with 9, 10, 11, 12, or 16 items.

A Single Item Day (SID) is a start-of-level event that overwrites normal scrap generation by making all scrap spawn as the same item type (i.e. gold bars only). Special scrap such as the Apparatus, beehives, Giant Sapsucker eggs, shotguns, and knives are unaffected by SIDs and will generate as normal. SIDs are somewhat moon specific, as while a SID event will be tried on every moon, they will choose different scrap or fail instead.

SID scrap also receive a change in their price value (each individual scrap still possess its own unique value). Scrap values are clamped to a value within 50-170c, meaning that every SID will boost the average value of its scrap. The upper bound of 170c only affects gold bars and Zed dogs. However, an additional boost or nerf may be applied to SID scrap. If the total value of all SID affected scrap is below 600c (or, if the SID scrap type is two-handed, below 1500c), a 1.4 multipler is applied to each scrap's value. (Note that due to floating point errors, a 1.4x boost to a value of 50c results in 69c instead of 70c. Many values in Lethal Company are affected by floating point errors). Likewise, if the total value of all SID affected scrap is above 4500c, a 0.7 multipler reduction is instead applied to each scrap's value. (Due to floating point errors, 50c * 0.7 results in 34c instead of 35c). The upper bound 4500c only matters on Artifice and Dine, and the lower bound of 600c only matters on Experimentation due to every other moon having at least 12 scrap (minimum worth of 600c). The secondary bound of 1500c does not matter on Dine.

In order for a SID event to occur, a 4.2% (21/500) check must be passed. Once passed, a random scrap type available to spawn on the current moon is chosen. Note that this is unaffected by rarity/spawn chance, so a gold bar is just as likely to be chosen as a metal sheet. However, if the chosen scrap is two-handed or has too low of a rarity (below a weight of 5), the scrap is randomly picked again. The new selection undergoes the same check criteria in which if it fails again, the scrap is randomly picked one last time. If the last selection still does not meet the criteria, it must pass a 30% (30/100) chance in order to remain. If this last check fails, the SID event is thrown out altogether and regular scrap generation occurs as normal. Otherwise, when a scrap selection meets the criteria or manages to pass the last 30% check, the SID event occurs, choosing the selection as the scrap type to overwrite regular generation. This means that very rare or two-handed scrap SIDs are significantly less likely, making up only ~3.71% (138,132/3,723,560) of all SIDs on Experimentation. Compounded, this means any Experimentation seed being a rare/two-handed SID is ~0.138% (138,132/99,999,999). Since 4.2% (4,199,999) of seeds attempt a SID, 476,439 SIDs (or 11.3% of SIDs) end up failing on Experimentation.

In the database, SID seeds have 0 for every regular scrap type count. Outdoor scrap such as beehives and Sapsucker Eggs are completely unaffected by SIDs.

The Scrap_Type/ field in the database represents how many of a particular scrap type spawn on a seed. For instance, filtering [Rubber_Ducky=3] searches for seeds with exactly 3 rubber ducky spawns. Note that SIDs are completely exempt from this data, as their item makeup is already defined by their SID type and item count (minus 1 for Apparatus on Facility). As such, filtering [Rubber_Ducky>3] will not return any rubber ducky SIDs.

While gift boxes are almost always assumed to be opened for greater value, this database does not store the scrap types generated by any gift boxes (due to complexity limitations and gift box manipulation strategies).

At the very bottom of the Scrap_Type/ list, Beehives and Sap Eggs are listed. These are considered Daytime/Outdoor scrap and generate differently from regular scrap. The most beehives that can ever spawn at once is 6, and the most eggs that can spawn at once is 3 (since only one Sapsucker can be present on a moon). Sapsuckers always come with 3 eggs, so 0 or 3 eggs are the only possible count values.

Day Scrap Potential Value (what a mouthful) represents how much additional value a seed's total scrap value may possess. Confused? Basically, beehives and Sapsucker eggs* have two possible values depending on their proximity to the ship's landing position. If they spawn close, their value is reduced. This database always adds the lower possible price of each outdoor scrap to the seed's scrap total, while the higher possible value is stored as a remaining difference in the column "Potential Value."

If a seed has a scrap total of 2579c and a Potential value of 48c, that means the beehive/eggs on that moon could be worth an additional 48c in total depending on their proximity to the ship.

For a more detailed explanation, beehives and eggs are part of a class of enemies called Daytime Enemies. There are two other classes: Indoor and Outdoor Enemies. Indoor refers to enemies that spawn inside the dungeon (e.i. Thumpers, Hoarding Bugs, Nutcrackers). Outdoor refers to enemies that spawn on the surface towards nighttime (e.i. Eyeless Dog, Baboon Hawks, Old Birds), and these are generally the dangerous ones (Note that while they are refered to as "Outdoor" Enemies, they do not include "Daytime" Enemies). Daytime Enemies refers to generally harmless day enemies such as Manticoils and Locust Bees, but they also include Circuit Bees and Sapsuckers. Those two enemies are unique in that they only spawn once at the begining of the day (around 7:51) and do not ever despawn.

Whenever Circuit Bees or Sapsuckers spawn, their corresponding scrap items, Beehives and Eggs respectively, spawn with them (3 Eggs always spawn with a Sapsucker). When these scrap spawn, their distance from where the ship lands is calculated and factored into their pricing. For beehives, if they are within 40 units of the ship, they are priced 40-99c; otherwise they are priced 50-149. For Sapsucker Eggs, if they are within 100 units, they will be priced 40-69c. However, Sapsucker Eggs have a special third case. A 70% (0/100 >=30) check is ran for each egg. If the check passes, they are priced 70-119c, but if it fails (in other words, wins a 30% check), they are priced 70-199. For this database, the lower bound of 40-70c is added to the scrap total, and the higher bound of 70-199c is added to the Day Potential Value. Notably, this means a boost will affect the normal price as follows:

*For whatever reason, Giant Sapsucker eggs do not have values that are entirely determined by the level's seed. The last check in their pricing (70%) is purely random (using Unity.Random.Range) and is not determined by the level's seed. This means that going to the same moon's seed, when it has far Sapsucker Eggs, can vary in its total scrap value by as much as 240c. Since this database is concerned only with the lowest and highest possible values, a seed can have a Potential Value of up to 300 from just eggs (and up to 690 including 6 beehives).

But if the lower and higher possiblilites are ranges, how can the database be sure the higher ranger produces a higher value? This is because only one of these ranges is actually calculated in-game, meaning the same random number determining the lower range also would determine the higher range. Basically, beehives and Sapsucker Eggs use their own personal random number generators, and their price is always determined by the same particular usage of that generator. If a random number chooses the higher end of 40-69, it would have chosen the higher end of 70-199. This is also why there is a link between boosted eggs and nonboosted eggs since their ranges just interpret the random number differently.

Beehives are currently bugged in the game in that each beehive uses the same instances of their random number generator. See, the intention in the game's code is that for each beehive that has spawned, an extra 1 is added to the generator's seed value: random = new System.Random([seed] + 1314 + [#_of_circuit_bees_spawned]). Each beehive creates its own random number generator and uses it to determine its own exact spawn location and price (the price is the 4th usage of the generator). But instead of each beehive adding a different for [#_of_circuit_bees_spawned], they each add the same, total number (presumably an oversight that all bees spawn before this price code is ran). So since they use the same generator at the same time, their prices are all the same, except for their proximity boost. This means all beehives on a seed will either have the lower possible price or the higher possible price depending on if they are close to the ship.

Sapsucker eggs use their own random number generator, but unlike beehives, each egg uses a different instance of it since all 3 egg prices are calculated within the same function. They create the generator, random = new System.Random([seed] + 1316 + 1), where 1 represents 1 Sapsucker having spawned. Also unlike beehives, this generator only determines their price and nothing else. So, the first instance is used by one egg, the 2nd instance by the next, and the third by the last egg, where each egg's 70% check has no influence on the generator "random" (since the 70% check is just using Unity.Random.Range). Since eggs and beehives use generator seeds close to each other (+ 1314 and + 1316), they are closely linked/correleated.

For ease of interpretaion, the price ranges discussed so far use inclusive bounds. But for those curious, here are the price ranges as they appear in the code. Beehives: Next(40, 100), Next(50, 150). Eggs: Next(40, 70), Next(70, 120), Next(70, 200). Next() just calls for a random integer in the given range, where the upper bound is exclusive.

For those REALLY curious, here is a breakdown of how the number of bees that spawn is determined. The game first uses the random number generator, DaytimeEnemySpawnRandom (yes thats actually what it's called), to decide the number of daytime enemies to spawn in the first wave (7:51 AM). This generator was only recently added in Version 81, and it is the reason why Daytime Enemies are now predictable. They used to use a combination of EnemySpawnRandom and AnomalyRandom, which due to their widespread usages, required the dungeon's interior to be calculated. (Ironically, the position of where Daytime enemies spawn still uses one instance of AnomalyRandom, which combined with the complexity of calculating position, is part of the reason why this database does not know how close eggs/beehives will be to the ship).

The number of Daytime enemies that spawns depends on the time of day. All classes of enemies spawn in exactly 9 waves across a moon's day: once at 7:51 AM, once at 9:00 AM, and once every 2 hour intervals after that until 11:00 PM. Enemy calculations, including the number of which try to spawn, sometimes use Unity curves that are evaluated based on time, but since the time can only be 1 of 9 possibilities, this curve is stored in the seed data generator as 9 decimal values (the exact value the game evaluates the curve to be at). For Daytime enemies, the number that tries to spawn is determined by: Mathf.Clamp(DaytimeEnemySpawnRandom.Next((int)(num2 - currentLevel.daytimeEnemiesProbabilityRange), (int)(num2 + currentLevel.daytimeEnemiesProbabilityRange)), 0, 20), where num2 is the daytimeEnemySpawnChanceThroughDay curve evaluated at the current time.

Then for each Daytime enemy spawn attempt, the weight rarities of each Daytime enemy are added to a list (if their maxCount has been reach, their power level is too high for the currentDaytimeEnemyPower, or its too late into the day, their weight is set to 0). This rarity is also multipled by that Daytime enemy's spawn probability curve of the current hour. For determing bees and eggs, this array of values represents each Daytime enemy's curve evaluation [0.9651623, 1.001262, 0.6463307, 0.6489306,0.9651623] for Circuit Bees, Manticoils, Locust Bees, Tulip Snakes, and Sapsuckers, respectively. This means the effective rarity of each Daytime enemy is different from what the game's data lists and changes throughout the day. Once a list of weights is calculated, GetRandomWeightedIndex is called using DaytimeEnemySpawnRandom to decide what enemy spawns. Calculating the weights and deciding a random enemy are both repeated until every spawn attempt is tried. As evident, this makes Daytime enemy spawns quite complex and different from moon to moon. Indoor enemies are even more complicated than daytime enemies, as they are concerned with Eclipsed Weather, survival/wellbeing of the ship's crew, and the diversity level of the moon. Despite these external factors, they too are predictable, though they are not yet included inside the database (except for Nutcracker Infestations).

The maxCount of an enemy refers to how many times that enemy has spawned so far, and it does not go down whenever enemies are killed. This is the reason why Nutcracker Infestations are capped to 10 Nutcrackers, beehives are capped to 6, and Sapsuckers are capped to 1.

The currentDaytimeEnemyPower refers to the total power level of all Daytime enemies (there are respective values for other enemy classes as well). Whenever an enemy spawns, its power level is added to a total value such as "currentDaytimeEnemyPower", and future enemies can then only spawn if its power level does not push the current power total over a certain cap. When enemies die (except for Butlers), their power level is subtracted from the current level, making room for more enemies to spawn. Power levels explain why Experimentation can only spawn up to 5 bees; its Daytime power cap is 5 and each Circuit bee takes up 1. In Version 81, Sapsuckers were changed to have a power level of 4 instead of 2. This only makes a difference on Assurance, as its Daytime Enemy Power cap of 7 (but high enemy spawn attempts) is low enough for the first wave of enemies to reach. Now, either 6 Circuit Bees can spawn, or 3 Circuit Bees and 1 Sapsucker can spawn.

The daytimeEnemiesProbabilityRange that determines how many Daytime enemies can spawn has an interesting affect on Artifice. Because this range on Artifice is equal to 4 while the curve evaluation of daytimeEnemySpawnChanceThroughDay is 1.732826, the maximum amount of Daytime enemies that can spawn on the first wave is 4 (the upper bound rounds down and is exclusive), so the maximum number of beehives that can spawn is 4 despite the Daytime Power level being 15.

Rend, Dine, Titan, and Embrion all do not have Daytime enemies. Sapsuckers only spawn on Assurance, Vow, and Adamance. Beehives only spawn on Experimentation, Assurance, Vow, March, Adamance, and Artifice. Here are the spawn chances of beehives and Sapsuckers (based on the database) for each moon:

Infestations are a very rare, start-of-level enemy event that can either choose Nutcrackers or Hoarding Bugs as the dominant enemy type in a level. They heavily influence enemy spawning and generally will make the level harder. Infestations are generally not moon specific, meaning a seed with an infestation will still possess one on all moons, with small exceptions for Vow and Rend. Nutcracker infestations are instead the Hoarding Bug type on Vow, and Hoarding Bug infestations simply fail on Rend.

Infestations are much more likely when the system clock reads October 23rd, since that is the anniversary of Lethal Company's early access launch. Before Version 81, the code was bugged, making the infestation chances inversed (more likely on normal days and less likely on 10/23).

Infestations alter enemy spawns by establishing the minimum amount of enemies to spawn per wave to 2 (waves occur every 2 hours starting at 9 AM (the very first wave happens at 7:51 AM)). Then, infestations raise the indoor power to 30 (if it is type Hoarding Bug) or 20 (if it is type Nutcracker). Indoor power limits the maximum amount of "powerful" enemies that can exist alive at once, which means that a power cap of 20-30 allows significantly more indoor enemies to be alive at once. The last thing infestations affect is enemy rarity: the infestation's enemy type will have its rarity weight set to 100 while all other eligible enemies will have a weight multiplier reduction of 0.075 (making the weight usually less than 10). For Nutcracker infestations, this usually spawns the maximum number of 10, making for an additional 600c worth of scrap that can be collected on the moon. While this is not a complete guarantee, this database simply assumes the upper limit of 10 will always spawn, adding 600c to the total value.

The checks that determine whether an infestation occur are complicated, as they change depending on whether the date is 10/23 or not. In essence, 10/23 has a 4.93% (5/110 or 4/1000) for an infestation to occur, while days that are not 10/23 have a 0.4% (4/1000) chance. Because of how the checks are set up, there can NEVER be an instance where an infestation does not occur on 10/23 but does occur on a normal date. Also, if infestations can occur on any day, the type, Nutcracker or Hoarding Bug, will ALWAYS be the same regardless of the date being 10/23 or not. In other words, a seed cannot have a Nutcracker infestation on 10/23 and a Hoarding Bug infestation on regular dates.

Once an infestation occurs, a 25% (25/100) check is ran. If it succeeds, the game chooses Nutcrackers as the infestation type. Otherwise, it defaults to Hoarding Bugs. However, these both depend on whether the moon can spawn either of these enemy types. The only moon that cannot spawn Nutcrackers is Vow, so the first 25% check always defaults to Hoarding Bugs regardless of it succeeding or not. The only moon that cannot spawn Hoarding Bugs is Rend. However, Rend's infestations still need to pass the 25% to choose Nutcrackers, meaning that 75% of its infestations fail and have no effect on enemy spawns.

Indoor Fog is related to infestations only because they are 10 times more common when an infestation occurs (and they use the same random number generator). The fog is purely visual and otherwise unrelated. The odds of indoor fog on an infested day is 20% (20/100), and on non-infestation days, the odds are 2% (3/150). Because of the ways the checks are set up, there CAN be an instance where indoor fog does not occur on 10/23 but does occur on a normal date.

Here is a more detailed explanation on how the checks work and how the seed data generator is able to distinguish 10/23 events from normal events. The two checks are part of this "if" statement: [(num && random2.Next(0, 110) < 5) || random2.Next(0, 1000) < 4)], where random2 is a random number generator. "num" is only true when the date is 10/23. Because of how C# handles statements, once a statement must be true or false, the rest of its parts are skipped. When "num" is false (not 10/23), the only check ran is random2.Next(0, 1000) < 4 (0.4% chance). If "num" is true (10/23), the first check ran is random2.Next(0, 110) < 5 (4.55% chance), and only when it fails, does it also run the second check. When any check succeeds, an infestation will occur. An important element to notice is how many usages of random2 are being used in every possibility.

When "num" is true or false, one check is ran regardless, meaning that the success of the harder check (0.4%) always implies the easier check (4.55%) would have succeeded. That is why all infestations occur on 10/23, and only some of them occur on other dates. The only time two checks are ran is when the date is 10/23 and the first check fails. Since it is the easier check failing, dates that are not 10/23 must always fail in this case. This means that when an infestation occurs not on 10/23 by passing one check, the same infestation on 10/23 also occurs by passing one check. Basically, 10/23 and non-10/23 infestations are in sync with their random number generators, causing the subsequent indoor fog check and infestation check to be the same outcome on any date, hence why infestation types cannot be mismatched.

After an infestation is determined to occur, the next random number determines the check random2.Next(0, 100) < 20 (20% chance) for whether indoor fog occurs. The next check random2.Next(0, 100) < 25 (25% chance) then determines whether the infestation type is Nutcracker (if they can spawn). Otherwise, it defaults to Hoarding Bug if available. However, if an infestation is determined to not occur, the next random number check random2.Next(0, 150) < 3 (2% chance) determines whether indoor fog occurs.

This is how the seed data program tracks these possibilities. Establish two random numbers, eval0 = random2.Next(0, 2750) and eval1 = random2.Next(0, 1000). If eval0 < 11, infestations occur any day; otherwise if eval0 < 125 or eval1 is < 4, infestations only occur on 10/23. When eval0 succeeds the infestation: if eval1 < 20, indoor fog occurs any day; otherwise if eval1 < 200, indoor fog occurs only on 10/23; then, if random2.Next(0, 100) < 25 and the moon is not Vow, the infestation is set to Nutcracker; otherwise if the moon is not Rend, the infestation is set to Hoarding Bug.

When instead eval1 succeeds the infestation: if random2.Next(0, 100) < 20, the indoor fog occurs any day; otherwise, the indoor fog occurs not on 10/23; then, if (new) random2.Next(0, 100) < 25 and the moon is not Vow, the infestation is set to Nutcracker; otherwise if the moon is not Rend, the infestation is set to Hoarding Bug.

When instead both eval0 and eval 1 fail the infestation: set eval2 = random2.Next(0, 150); if eval1 < 20 and eval2 < 3, indoor fog occurs any day; otherwise, if eval1 < 20, indoor fog occurs not on 10/23; otherwise, if eval2 < 3, indoor fog occurs only on 10/23; otherwise, indoor fog does not occur.

Meteor Shower is a rare level event where a deadly barage of meteor impacts devastate the moon's surface. Apart from damaging the player and outdoor entities, they do not influence other aspects of a level, including its interior. They can start anywhere between 7:51 (AM) and 20:25 (8:25 PM) and will last several hours.

A given seed has a 0.7% (7/1000) chance to contain a meteor shower event, and it is not moon specific, meaning a seed that produces a meteor shower event will do so on all moons. This event is sometimes referred to as a weather event, but it has no relation/confliction with the current weather event on the moon. Whenever the event starts (as depicted by the times listed in the database), a warning message is played over the HUD of all players, including those inside the dungeon. The time that is listed in the database reflects when the message is played, not when the meteors will land.

The time of when the meteors first spawn is calculated by a random number generator, "random", using the following code: (float)random.Next(5, 80) / 100f. However, this is an internal representation of game-time; it is easier to understand by multipling it by 17, adding 7, and separating the digits on both sides of the decimal point. The whole number digits represent the hour of the day. The decimal digits represent the fraction of the current hour, so multipling it by 3/5 (60/100) results the minutes value. For instance, if random.Next(5, 80) returned 5, 5 / 100 * 17 + 7 equals 7.85, which represents 7:51 AM (85 / 60 = 51). This also means that possible meteor shower times are separated by gaps of 10.2 minutes; the next meteor shower time is at 8:01 AM. Random number generators also never choose the upper bound of a ranged interval, so the latest start time is 20:25 (79 / 100 * 17 + 7 = 20.43), or 8:25 PM.

This is one of the strangest quirks of Lethal Company's scrap generation. A cycle seed is an extremely rare, unintended event where the scrap types that generate will cycle through a loop of possibilities. For instance, if the cycle has a loop of 3, the scrap generator will alternate between three scrap types.

To explain cycle seeds, regular scrap generation needs to be examined first. Scrap types and enemy types use a weighted rarity system to determine which type gets chosen. It is essentially a lottery system, where the more tickets (rarity weight) an item has, the more likely it is to be chosen. On a more in-depth level, game runs a list of rarity weights through a GetRandomWeightedIndex function that evaluates each item in the list. Initally, a random decimal number is chosen between 0 and 1 which is designated as the target value to be reached. Then, all the rarity weights in the list are added up to a total sum. Next, for each item in the list, its rarity is divided by the weight sum (essentially calculating its spawn chance percentage) and is added to a new "sum" stack. If the stack has reached or passed the target decimal value, the most recent item added to it is chosen.

Visually, this stack can be thought of as a tower of slices. Each slice added to the tower represents the relative weight of an item, and it increases the tower's total height. Since each slice is a percentage of a whole, all the slices will add up to equal 1, hence why the target is a random decimal from 0-1 acting as the target height of the tower.

Each moon has its own list of scrap rarities and enemy rarities, so the power of any item's rarity weight depends on the weight sum of that moon. This means that specific scrap, such as gold bars, have different spawn chances on different moons. An important reminder, this does not affect scrap prices; each scrap type will always have the same possible prices on any moon (except for SID prices).

However, due to floating point errors introduced by converting each list item into a decimal percentage of the total weight sum, this sum stack (tower of slices) can sometimes not add to exactly 1. Whenever the sum stack of all scrap rarities on a moon adds to slightly less than 1 (such as 0.9999998 for Experimentation), a cycle seed can be possible on the moon. In order for it to occur, the target decimal goal needs to be greater than the total sum stack. Since the total sum stack is very close to 1, this makes generating a random number within that range very unlikely. However, each new scrap item generates a new target goal using the random number generator named "AnomalyRandom", so it will happen eventually. Whenever it does, the target is considered a "bugged" value.

But why does the target goal being above the total sum stack cause a cycle? This is because the code that chooses the random weighted scrap only checks for the current sum stack being greater than or equal to the target goal, so a target goal above the maximum value is unreachable. The code loop that builds the sum stack fails to return any value, causing a backup system to take effect. This backup system resets all random number generators, including AnomalyRandom, (they now behave as though they have not been used yet), and a new random scrap is chosen from the list without considering its rarity (much like how SIDs choose a scrap type). Strangely, this backup system is flawed, as resetting the random number generators inadvertently causes the problematic AnomalyRandom usage to happen again, creating a loop.

But how exactly does this create a loop? The usages of AnomalyRandom need to be outlined, as they are predictable according to how many times they have been used so far. After the AnomalyRandom number generator is created for the first time, it is used once to calculate the amount of regular scrap to spawn on the moon. Next, it is used to calculate whether a SID event occurs (SID events do not produce cycles, but failed SIDs can). When failed, the very first scrap item's type is determined by using the function GetRandomWeightedIndex and passing AnomalyRandom through it. Essentially, the third usage and onwards of AnomalyRandom is where the cycle bug occurs.

For example, let's examine the smallest possible cycle, a loop of 3 scrap, on this Experimentation seed, 28015016. The AnomalyRandom generator is created using System.Random(28015016 + 5), and its first 4 usages produce these decimal values: [0.8741834, 0.55090183, 0.99999994, 0.740814]. When the first scrap gets decided, the function GetRandomWeightedIndex is used by passing AnomalyRandom through it. However, instead of directly using AnomalyRandom, the current instance of AnomalyRandom is mapped to a new variable called "randomSeed". randomSeed essentially acts as an alternative name for AnomalyRandom, meaning that randomSeed usages will progress AnomalyRandom since they are the same object. Here in this function, the scrap item uses the third and problematic value, 0.99999994, as its target goal, causing the backup system to reset AnomalyRandom.

However, whenever AnomalyRandom gets reset, randomSeed still retains the old instance of AnomalyRandom, which breaks their "link" to each other. So when randomSeed is called upon again by executing randomSeed.Next(0, weights.Length) (this chooses a purely random scrap type regardless of rarity), it effectively calls upon the forth usage of AnomalyRandom without progressing the "true" AnomalyRandom. That is why when the random scrap gets decided and the function concludes, AnomalyRandom is still at zero uses. The forth usage in this example, 0.740814, corresponds to the Gold Bar item type. The next scrap then also executes the function GetRandomWeightedIndex by passing this reset AnomalyRandom, so its scrap type is determined by the first AnomalyRandom value, 0.8741834, corresponding to Homemade-Flashbang in the sum stack. Following the next value, 0.55090183 determines the third scrap to be Big Bolt.

Now, the next usage, 0.99999994, causes the backup system to fail again, thus repeating the pattern of the same random values for the rest of the scrap items. The cycle is created: [Gold Bar, Homemade-Flashbang, Big Bolt]. This seed spawns 11 regular items, so 4 Gold Bars, 4 Homemade-Flashbangs, and 3 Big Bolts are decided since Big Bolts are the last one to be decided. Notice too that since the first scrap is attempted at the 3rd usage of AnomalyRandom, cycles technically start at the third item in their loop (Gold Bar in this case is actually the third item of the loop despite being decided first). Another interesting detail is that because the bugged scrap does not care about rarity weights, something very unlikely such as a Gold Bar ends up being picked when it otherwise would not show up, especially since there are only 43 3-loop cycle seeds on Experimentation. Cycle seeds of loops greater than 3 simply take longer to encounter the bugged AnomalyRandom value during each loop.

Cycle seeds are recorded whenever a scrap item reaches the backup code. That means a cycle loop of 13 can occur on a seed that only spawns 11 regular scrap, so the loop never repeats. This also technically indicates, on a cycle-capable moon, that all seeds are actually cycle seeds. They will produce a bugged AnomalyRandom value at some point, but their loop size is so large that it is well beyond the maximum scrap count. It would barely resemble a loop even if it did repeat at that scale.

Since cycles always start at the third entry, cycles shorter than a loop of 3 do not exist (although some cycle seeds, such as 46531739 on Experimentation, end up choosing the same scrap twice in their loop, making 2/3 of the item pool one scrap type and the other 1/3 a different type). But couldn't a cycle less than 3 happen if two AnomalyRandom values were bugged, such as a list looking like [0.99999994, 0.55090183, 0.99999994]? Generating a value as specific as 0.99999994 is so rare that cycle seeds in general are impossibly rare to begin with. In theory, if there were more seeds to choose from, or the scrap count was high enough to make a second instance of a bugged number more likely, a cycle length of 1 or 2 could exist (but any values inbetween the bugged numbers would produce unrelated random scrap).

A cycle that occurs after a failed SID event will have a minimum loop of 7 due to AnomalyRandom being called 4 times within the SID code.

Because cycle seeds are not restricted by SID value rules, a cycle seed on Artifice that looked like [Gold Bar, Gold Bar, Gold Bar] would be the most valuable seed possible. Unfortunately, such a seed does not exist due to its extreme rarity, so SID seeds remain the most valuable. Before SIDs were introduced in Version 60, cycles could actually be size 2 since AnomalyRandom was used one less time before scrap determination. This made cycle seeds that chose rare, high priced loot the most valuable seeds of a moon back then.

Only the following moons produce cycle seeds: Experimentation, Assurance, March, Titan, and Artifice. Here are their sum stacks in order that allow a bugged value to occur: [0.9999998, 0.9999998, 0.99999994, 0.9999999, 0.99999994]. These are hard to compare, so let's remove the first 6 "9"s in each: [8, 8, 94, 9 , 94]. A smaller number makes cycles more common. Titan has the most cycle seeds due to its high item count, allowing for more cycle chances. On Version 73, only Artifice was capable of cycle seeds, but due to the gift box rarity weight changed in Version 81, many more moons became capable as well. As such, cycle-capable moons constantly change between versions whenever a moon's scrap rarities are changed even in the slightest bit.

Cycle errors can technically happen at any time the game calls for GetRandomWeightedIndex (which is often), but the rarity sum of the list has to have a floating point error that sets it slightly below 1. This error can only realistically happen with larger lists, hence why scrap items are the only, as far as I know, example of cycle errors.

These determine the random generators that govern the various events that occur on a moon from scrap generation to where and what enemies spawn. Upon landing on a moon, the game chooses a Unity random number from the inclusive range [1-99,999,999] and sets that as the game's seed. This seed also determines the weather events of the next day. Nearly everything is determined by the seed, the major exceptions of which are enemy pathfinding, Quota values, and the value of Giant Sapsucker eggs (see Day Scrap Potential (Beehives and Sap Eggs) for more info).

Random number generators, as evident, produce random values; the catch is that each use of a generator is predictable. Whenever a generator is initialized, or created, it uses System.Random(seed) to produce a unique but calculatable result based on the value used as the "seed". Lethal Company bases nearly all of its random number generators on the level seed, sometimes adding arbitrary numbers to the level's seed in order to produce a different generator.

When a generator produces a random value in an interval such as (0, 100), the lower bound is inclusive but the upper bound is exclusive. A random integer from (0, 100) can choose 0 but not 100. In many places of this page, the parenthesis following a percent chance such as (0/100 >=30) indicate the integer interval the generator chooses from along with the comparison statement, using the default method of [generator].Next(). Remember that since the range, (0, 100), includes 0, 0-29 represents 30 possibilities or 30%, so >=30 looks at 70 possibilities, 30-99.

These generators (below) are discussed within this website, and the value that is passed within their parantheses is their unique seed value that makes them different from other generators. In other words, two generators with the same seed will function identically and produce the same "random" numbers.

Random number generators simply perform lots of complicated calculations to produce numbers that appear random without making calculations too taxing. This makes them easy to simulate and repeat, but it has the downside of producing results that are not completely random. However, this system of just adding an abritrary value to the generator's seed is flawed, as it leads to correlations between different generators. For example, on Experimentation, all seeds that have Mansion or Mineshaft interiors will always have exactly 10 scrap (+6 for Mineshafts).

Due to the complexity of the calculations, it is difficult to know exactly how these generators will be correlated. But with a database containing all seed information, queries can reveal strange relationships and patterns in this "randomness".

Below is a link to a public Google Sheets file containing the full lists of scrap and dungeon rarity data for all moons, including other versions.

Sheets File: LC Rarity Analysis