Stuart Walton

An alternate cause has been discovered, but nothing has been done to fix it yet.

Please check and vote up issue MCL-7178

A workaround is also detailed within.

The cause has been discovered and a workaround is detailed in issue MCL-7178

The cause has been discovered, but nothing has been done to fix it yet.

Please check and vote up issue MCL-7178

For each version of Minecraft there's a version json file. Inside there's a minecraftArguments key that tells the launcher what arguments to pass to the client jar:

Here's the one from 1.8.json, a version that works:

"minecraftArguments": "--username ${auth_player_name} --version ${version_name} --gameDir ${game_directory} --assetsDir ${assets_root} --assetIndex ${assets_index_name} --uuid ${auth_uuid} --accessToken ${auth_access_token} --userProperties ${user_properties} --userType ${user_type}"

Here's the one from 1.6.4.json:

"--username ${auth_player_name} --session ${auth_session} --version ${version_name} --gameDir ${game_directory} --assetsDir ${game_assets}"

1.6.4 uses the argument session and is passed the variable auth_session.
1.8 uses arguments uuid and accessToken and is passed the variables auth_uuid and auth_access_token respectively.

I suspect that the auth_session variable is not available in the new launcher. I tried editing the 1.6.4.json so that it passes the argument:

--session ${auth_uuid}:${auth_access_token}

but the launcher is pretty strict about the files not being messed with (for good reason) and re-downloads it if its hash is wrong.

The fix for this issue may be as simple as making sure that the auth_session variable is available for building the java arguments string.

For each version of Minecraft there's a version json file. Inside there's a minecraftArguments key that tells the launcher what arguments to pass to the client jar:

Here's the one from 1.8.json, a version that works:

"minecraftArguments": "--username ${auth_player_name} --version ${version_name} --gameDir ${game_directory} --assetsDir ${assets_root} --assetIndex ${assets_index_name} --uuid ${auth_uuid} --accessToken ${auth_access_token} --userProperties ${user_properties} --userType ${user_type}"

Here's the one from 1.6.4.json:

"--username ${auth_player_name} --session ${auth_session} --version ${version_name} --gameDir ${game_directory} --assetsDir ${game_assets}"

1.6.4 uses the argument session and is passed the variable auth_session.
1.8 uses arguments uuid and accessToken and is passed the variables auth_uuid and auth_access_token respectively.

I suspect that the auth_session variable is not available in the new launcher. I tried editing the 1.6.4.json so that it passes the argument:

--session ${auth_uuid}:${auth_access_token}

but the launcher is pretty strict about the files not being messed with (for good reason) and re-downloads it if its hash is wrong.

The fix for this issue may be as simple as making sure that the auth_session variable is available for building the java arguments string.

Tested MCL 2.0.934 and it is still an issue.

Tested MCL 2.0.895 and it is still an issue.

the file it is trying to download is the legacy asset:

"sound/mob/horse/zombie/hit3.ogg": {
  "hash": "ad126e435cca94054bf0d616301799a105526cde",
  "size": 7043
}

The URI is correct and the file can be downloaded using wget on Linux. Download failed in Chrome, possibly due to the Mime-Type that it is being served as.

The issue is likely a 3rd party firewall or antivirus.

Disable your antivirus and/or firewall while trying to launch Minecraft to confirm this.

I believe that this is caused by the player's authentication Session ID not being passed to the Minecraft Client by the launcher.

I created a ticket for it - MCL-7282

Other Duplicates
MCL-6223
MCL-6017

It looks like the manifest for library files required by Forge is also specifying hash files to verify the library file. Some of these hashes appear to be missing (or the URL is incorrect). The Minecraft Launcher therefore cannot verify these libraries and deletes them. The 3rd party launcher may by skipping the hash check, which is why it works.

00:46:29	launcher	main	warn	Couldn't get hash for com/typesafe/config/1.2.1/config-1.2.1.jar from http://files.minecraftforge.net/maven/com/typesafe/config/1.2.1/config-1.2.1.jar.sha1: HTTP 404: Not Found
00:46:29	launcher	main	warn	Couldn't get hash for org/scala-lang/scala-actors-migration_2.11/1.1.0/scala-actors-migration_2.11-1.1.0.jar from http://files.minecraftforge.net/maven/org/scala-lang/scala-actors-migration_2.11/1.1.0/scala-actors-migration_2.11-1.1.0.jar.sha1: HTTP 404: Not Found

Either the manifest needs to be corrected or those hash files need to be generated and made available at those URLs.

This is a request to reopen this issue because all Minecraft versions available in the launcher should be able to connect to their respective server versions.

This is not an issue with the old versions of Minecraft themselves. The issue lies with old versions when they are launched using the new launcher (2.0.806).

You can successfully connect to a server if you launch Minecraft using the old launcher or any 3rd party launcher.

Attempting to connect using the new launcher will return a 'Bad Login' error to the client if they are running Minecraft 1.6.4 or earlier.

This behaviour is observed whether connecting to a dedicated server in a data center or on the local machine.

It seems to me that the issue lies with the new Minecraft Launcher. Can we confirm if this behaviour is intended or not?

Thanks for your time.