Jump to content
Toggle menu
  • 799 articles
  • 4.8K files
  • 4 users
  • 64.7K edits
2b2t Uncensored
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

2b2t Uncensored:Base Destruction

From 2b2t Uncensored

Base Destruction is an editing guideline meant to demonstrate what constitutes the leak of a base, what constitutes a grief, how a base specifically ends, and how a base could continue following a grief.

Leaks

What is a Leak?

Base leaks can take many shapes. Reduced to the most simple definition, leaks are when privileged information passes to someone that should not have it. Base leaks, as discussed here, deal specifically with the location of the base. Base leaks do not have to be conducted by a member of a base, although most tend to be from members. Leaks from members generally are the result of Insiding or mistakes (such as misplaced copy-pastes, failed /msg's, or misdirected streams).

As not all leaks are necessarily the result of malicious intent, it is important that the nature of any base's leak be discussed within the respective article in the 'Grief' section (or a section of similar nature, topic, or name) as to not convey an unfair understanding of the situation. Uninvited Residents or even outright nonmembers also certainly can leak a base as a leak is simply the exchange of privileged information from one person to someone else that is not meant to know have this information. Note that this definition does not take into account whether or not the conveyor of that information should have had that information to begin with, or whether they too were leaked it. It is also important to understand that a base leak that did not directly result in a bases destruction should not be listed in a respective page's infobox as to not provide a misleading understanding of what caused the base's destruction, although it should still be discussed in the body text of the article to provide background.

Exploits

Not all leaks have to be conducted by people at all. Coordinate Exploits are oftentimes a major source of leaks. For example, Hopen was leaked by the Nocom exploit; Nocom is therefore listed as the leaker of the base on the article. While at its face this may appear odd, it is written as so because it was the exploit that conveyed the location of the base to 0x22 to grief it; 0x22 did not convey the information to himself. As a general statement of caution, Coordinate Exploits (such as Nocom) sometimes remain unknown publicly for years.

What if the exact leaker is unknown?

Sometimes bases are leaked and the leaker is not easy to conclusively name. Oftentimes, this is the result of Insiding, and represents the main goal in doing such. It is important to refrain from picking a Scapegoat as this is unfair to the person blamed for leaking (e.g MagicEx being unfairly blamed for leaking Purgatory II) and also conveys a false narrative to the site itself.

If there is no proof for how a base was leaked, no leaker should be listed in the Base Template. Likewise, if the potential leakers have been reduced to a Short list through a simple process of elimination, it would be wholly unfair to those within that list to be placed on the wiki article in a list of potential leakers without proof they conveyed the base's location to outside parties. If significant proof exists that implicates one or more people as being the leakers of a base, it should be discussed within the article and also within the article's talk page if necessary, as with Corner Base. Likewise, bases are sometimes found by nonmembers and leaked by them, unbeknownst to the base members themselves, meaning that the true leaker in some cases is not easily knowable and may not appear on any short list.

For more niche situations

  • where there are a series of leakers, they should all be listed, and the chain of leaks should be elaborated on in the body text.
  • where there is a leaker that made a location public without reaching out directly to those who griefed it, they are still the leaker regardless of direct connection to the grief.
  • where a leak is demonstrably accidental, it should be labeled as accidental in the infobox and elaborated upon in the body text. It is important to note that simple statements concerning the accidental nature of a leak should be looked into with a healthy level of skepticism while also not straying from basic assumptions of good faith.

While the griefers of a base may be in a better position to know who leaked a base when compared with the residents of said base, the griefers have a vested interest in protecting the identity of the leaker. Conversely, base members may also jump to conclusions and publicly accuse other members of the base for leaking, correctly or incorrectly. Accusations of leaks ought not to be taken at face value as a result of a myriad of potential underlying motivations, and ought to be supported with evidence or proof. Accusations of leaks may be discussed in a base's article as events in an of themselves, where contextually sensible, although pure accusations alone should not be conveyed as fact.

Griefs

A base is griefed when it is meaningfully destroyed either fully or in part. Anyone can grief a base; this includes any players regardless of membership status within the base, Server Administration (when builds are worldedited or terrain is reverted), or even the environmentif griefing is done by mobs, lava, lightning, etc without conscious player intervention (such as happened with Ain's Forest). Only players who were themselves physically at a grief in-game should be listed as griefers of a base; this does not include players viewing through livestreams or spectating through third-party proxy softwares. Griefers of a location are at the location and damaging the location. Once the griefers are done griefing and leave the base, the grief is over; subsequent destructive activities are not part of that same event and should not be bundled together with it.

Self-Griefs

A self-grief occurs when the members of a base or players specifically invited by the members of the base grief it. Self-griefs tend to occur after a base becomes publicly known or is thought to have been leaked. Whether or not a base is griefed by nonmembers or members, it is still considered a grief, and should be listed in the Base Template as such, using the format 'Self-grief (List of players who self griefed)' in the event of a self grief.

Abandonment

Base abandonment is simply when a base is deliberately vacated by its builders. This on its own does not end the respective base as the members can return there and continue as long as it is still standing. In the event that a base is formally abandoned or goes inactive, it still remains 'owned' by its members, as base membership is irrevocable. By extension, this means bases cannot end by abandonment alone. If they are to return at a later date, the base simply continues.

How does a base end?

Bases generally end in both abandonment and grief, although the possibility for post-grief repairs complicates this somewhat. Upon being abandoned only, the base continues. Upon being griefed, the base can be repaired and continued by its members, in which case it simply continues to exist. Griefs in that case should be listed, numbered, and dated in the infobox and elaborated on in the body text. Bases cannot continue to exist indefinitely, however, following a grief and going public. Regardless of other factors, a base is considered ended if many of these criteria are met:

  • The base has been griefed
  • The base has been abandoned
  • The base's location is known by players with no direct or intentional ties with the base's members
  • The base's location is known by players with no direct or intentional ties with the base's griefers
  • The base's building materials have been removed from the location or destroyed (if applicable)
  • The base's Pearl bridges have all/mostly been loaded or destroyed
  • The base has been publicly announced as griefed by either the members, the griefers, or both

This should by no means be considered an exhaustive list; other factors along the same lines may and should be considered where necessary. It is also important to note that marginal repairs immediately after a grief and right before abandonment of the base likewise do not 'keep the clock ticking' so-to-speak.

Post-grief Repairs

Should a base be griefed and immediately start to be repaired by its builders, it continues to exist as the same base. It needs to continue in a meaningful capacity for an amount of time that allows for it to be reasonably be discovered by non-invited players traveling to the base's location. For example, continuing to build in the general area but not at the same physical location constitutes the foundation of a new base. Likewise, simply building quick structures before immediately abandoning does not constitute activity that ought to be considered the base continuing. In the event that a base successfully navigates all of these obstacles, it simply continues to exist. When the base continues and is met with subsequent griefs later on, they should be listed, numbered, and dated in the infobox and elaborated on in the body text.

Re-Griefs

Re-griefs occur when a base has already been griefed and abandoned (in other words, after the base has ended), and a player opts to, for whatever reason, grief it another time. Re-griefs should absolutely not be listed in any infoboxes as the respective base would have already been griefed and ended before the re-grief. Re-griefs as events may certainly be discussed in articles where narratively important, especially where the re-grief of a base results in something else, but they should clearly be labeled as re-griefs given the underlying circumstances.

Scapegoat Merriam-Webster Page

Short list Merriam-Webster Page