User:JEC6789/Downgrading

In Minecraft, downgrading refers to reverting to an older version of the game.

$$, downgrading can generally be done through the Minecraft Launcher's backward compatibility feature. For versions not available via the launcher, links to download the client and server may be available on their respective version pages on this wiki.

$$, downgrading can be done by uninstalling the current version and searching for, downloading, and installing an unedited of an older version online.

Users may need to downgrade as newer versions drop support for older hardware. For example, dropped support for systems using  microprocessors, so anyone using them would have to downgrade to  to continue playing the game. Certain Minecraft servers may also downgrade due to technical changes in later versions that break the server software they use, such as the addition of block states in or "The Flattening" in.

Some users may also wish to downgrade due to changes in later versions that could be considered controversial, such as the combat changes in.

Issues
Since older versions of the game are not supported by Mojang, any issues associated with downgrading will be resolved as "Invalid" on the bug tracker.

Java Edition

 * If the player downgrades to any version from Beta 1.5 to 13w03a, their achievements get reset.
 * Downgrading may result in all inventories in loaded worlds getting reset.
 * Downgrading may result in dropped items getting converted into stone.
 * Downgrading from 14w04b may result in villager trades getting messed up.
 * If the player places a sign and then downgrades to 14w21b/1.7.10 or earlier, the block entity data for it gets corrupted. Empty lines display "null," filled lines get quotes around them, and certain characters are replaced with their Java source code values.
 * If the player changes the render distance setting to over 16 chunks and then downgrades to 14w29b/1.7.10 or earlier, the game may crash when a world is opened.
 * If the player places down red sandstone and then downgrades to 14w31a/1.7.10 or earlier, it gets replaced with regular chiseled sandstone.
 * Downgrading may result in the seed for loaded worlds getting reset to 0.
 * Downgrading may result in certain entities disappearing from loaded worlds, even if they exist in the version the player downgraded to.

Bedrock Edition

 * If the player saves a world under certain conditions in v0.2.0 or later and then loads in the world in v0.1.3 or earlier, the player gets moved to an extremely high Y-level, the world seed gets reset to 0, and the world's in-game name becomes blank.
 * This is so far confirmed to happen under any of the following circumstances:
 * The world is saved while the player is flying.
 * The game mode is Survival.
 * This glitch does not occur if the world was first created in 0.1.3 or earlier and the game mode was edited to Survival mode in a later version.
 * The world has entities other than the player in it.
 * The world was last opened in v0.9.0 (build 1) or later.
 * If the glitch was performed on a world using this method and the player updates to v0.2.1 – v0.3.3 or v0.6.0 – v0.7.1, the game crashes once the player presses the "Play" button. This occurs due to the world's level.dat file containing an invalid value at offset.
 * If the glitch was performed on a creative mode world using this method, opening the same world in v0.4.0 or later without opening it in v0.2.0 the first time generates a seed 0 old world, sets the game mode to survival mode, and enables the daylight cycle.
 * If the player exits the world without interacting with it in v0.9.0 (build 1) or later and then reopens it, a seed 0 infinite world that is on creative mode with default player abilities is generated.
 * If the world is opened first in v0.2.0 and the player then updates to and opens the world in any later version, the world's game mode remains as creative.
 * Performing this glitch on a creative world presents the following behavior:
 * If the player opens such a world in v0.9.0 (build 1) through v0.9.4 without opening it in v0.2.0 through v0.8.1, their position and respawn point are set to the lower-northwest corner of the world, resulting in them always immediately dying from the void on respawn. This effectively softlocks the world without the use of external editing.
 * If the player opens such a world in v0.9.5 without opening it in v0.2.0 through v0.9.4, the player's respawn point is initially Y=0, but gets set to Y=130 after the respawn button is pressed the third time.
 * If the player then opens the world in v0.10.0 (build 1, later builds not tested), their respawn point is initially set back to Y=0. Once the player dies after the Y=0 respawn, their respawn point is then set to approximately Y=200.
 * If the player opens such a world in v0.10.0 build 1 through build 3 without opening it in v0.2.0 through v0.9.5, the player's respawn point is set to the highest solid block at the exact northwest corner of the world, which places the player halfway in the invisible bedrock border.
 * If the player opens such a world in v0.10.0 (build 4, later builds not tested) without opening it in v0.2.0 through v0.10.0 build 3, the player's respawn point is set to on top of the invisible bedrock border at the exact northwest corner of the world.
 * If a given entity exists within a world and the player downgrades to a version where that entity was not yet added to the game, that entity disappears from the world completely.
 * Between v0.2.0 and v0.8.1, if the player places down a block and then downgrades to a version where it does not exist, it gets replaced with an info_update2 block. Updating back to a version where it exists does not change it back to its original form.
 * Since info_update blocks did not exist before Android v0.2.0/iOS v0.1.3, the game simply crashes instead once any chunks that had invalid block IDs get loaded in if the player downgrades to those versions.
 * This cannot be reproduced when downgrading from v0.9.0 (build 1) or later to v0.8.1 or earlier due to another downgrading bug.
 * The game also crashes if the player downgrades to v0.9.0 (build 1) – v0.9.5 from a later version. Updating back to v0.10.0 or later results in the world being the same as it was before downgrading.
 * Downgrading to v0.10.0 or later has not yet been tested.
 * If the player gets an item in Survival mode and then downgrades to a version where it does not have an item form, it permanently disappears from their inventory.
 * If the player gets an item in Survival mode with a damage value other than 0 and then downgrades to a version where its numerical ID is valid, but it has no defined damage values other than 0, its appearance and behavior changes to that of its 0 damage value form, and it displays a nonfunctional durability bar in the inventory.
 * If any options are changed in v0.7.0 or later and the user downgrades to v0.6.1 or earlier, every setting gets reset. This is due to a different method of setting storage being used instead of options.txt.
 * Downgrading to another version from any pre-0.7.0 version also resets all the settings. This is likely due to the settings being stored directly in the game itself instead of in the separate com.mojang folder.
 * Since downgrading does not delete the options.txt file, updating back to v0.7.0 or later changes the settings based on what is in it.
 * If the player places a sign between v0.7.2 and v0.8.1, enters non-[//www.rapidtables.com/code/text/ascii-table.html extended ASCII] characters on it, and downgrades to a version between v0.5.0 and v0.7.1, each unsupported character gets converted into multiple extended ASCII characters. If this conversion results in there being more than 15 characters on a given line, that line gets truncated.
 * Updating back to v0.7.2 or later does not detruncate any lines, though any text that still exists gets converted back into Unicode.
 * If a world is loaded in v0.9.0 (build 1) or later and is then loaded in v0.8.1 or earlier, its save gets corrupted and generates a new old world with the same seed. This is due to later versions using the LevelDB level format, which is not compatible with earlier versions.
 * The player's inventory and location are still saved if they downgraded from v0.9.0 build 1 - build 7 due to this data still being written to level.dat in those versions.
 * If the player's location is outside of the invisible bedrock border in the downgraded version, they get teleported to the closest edge of it at Y-level 128.
 * If the player upgrades back to v0.9.0 build 1 or later, they get teleported back to where they were before downgrading, even if they have moved since then. Since this does not change the world type back to what it originally was, the player will likely be on top of the invisible bedrock border, multiple-hundred blocks away from the downgraded world.
 * If the player obtains a set of items in v0.9.0 (build 1) or later, downgrades to v0.8.1 or earlier, adds or removes any items from their inventory, and then updates back to v0.9.0 (build 1) or later, their inventory reverts to containing just the aforementioned set of items.