Yeah, I wiped out the automap folder altogether - repatched 1.6.2 with mcpatcher from a source 1.6.2 -
I looked up pack.mcmeta and found out it is a file for a resource pack. I was able to create one and put it in the mod_automap folder, which did clear the error, but it still doesn't work. Not sure what I'm doing wrong here.
Seems odd that MC seems to think it's a resource pack rather than a mod. I'm not getting the automap initialized when I start the game either - nor is .exe able to connect to the game when I run it - most odd. I must be missing something but at the moment I don't see it. Will look it all over again and try to see if I can straighten it out.
Well I'm stumped. Tried this on my work machine and got the same results. So I did a totally clean install. Wiped the .minecraft folder. Ran the launcher - ran mc once to generate the files. Made sure I had the absolute latest copy of modloader and mcpatcher. Patched mc with mcpatcher including the latest modloader. Ran the bat file in automap to patch, pointing it to the 1.6.2-mcpatcher.jar file. I run it up and do NOT get the Automap java initialization message and automap just shows the connection refused message and does not link to the game. What the hell am I doing wrong??
From the diagnostic screen on the launcher:
Client> C:\Users\Marsman\AppData\Roaming\.minecraft\versions\1.6.2-mcpatcher\mods
Client> ModLoader 1.6.2 Initializing...
Client> Mod Initialized: mod_automap 27
Client> Mod Loaded: mod_automap 27
Client> Done.
Client> 2013-07-23 19:27:19 [CLIENT] [WARNING] Unable to parse metadata section of resourcepack: mod_automap
Client> java.io.FileNotFoundException: C:\Users\Marsman\AppData\Roaming\.minecraft\versions\1.6.2-mcpatcher\mods\mod_automap\pack.mcmeta (The system cannot find the file specified)
Client> at java.io.FileInputStream.open(Native Method)
Client> at java.io.FileInputStream.<init>(Unknown Source)
Client> at bjg.a(SourceFile:16)
Client> at bjc.a(SourceFile:52)
Client> at bka.a(SourceFile:41)
Client> at ats.a(SourceFile:405)
Client> at ModLoader.init(ModLoader.java:756)
Client> at ModLoader.addAllRenderers(ModLoader.java:191)
Client> at bgi.<init>(RenderManager.java:98)
Client> at bgi.<clinit>(RenderManager.java:14)
Client> at ats.O(SourceFile:341)
Client> at ats.d(SourceFile:599)
Client> at net.minecraft.client.main.Main.main(SourceFile:101)
Client> 2013-07-23 19:27:19 [CLIENT] [INFO] Reloading ResourceManager: Default, mod_automap, mod_automap, Sphax PureBDcraft 128x MC16.zip
If I create a pack.mcmeta file, I can get this java.io error to go away but doesn't change anything. Nothing else has changed on 2 different machines that I had this running on under 1.5.2 ??
I'm really at a loss here as to what to try next - any insight anyone has would be greatly appreciated.
mcpatcher is unfamiliar to me. Try installing the old fashioned way.
1. Use a fresh copy of minecraft -- don't install any other mods or use any 3rd party patching tools like mcpatcher because there is no telling what they might be doing wrong.
2. Follow modloader's install instructions. This involves creating a "1.6.2ML" version in your versions folder.
3. Run PatchMinecraft.bat and point it at 1.6.2ML.jar
4. Choose the 1.6.2ML version in your minecraft launcher profile to ensure you are loading the correct minecraft code.
mcpatcher is just a tool that does exactly that - it integrates Modloader into the jar the exact same way as a manual install.does. I've used mcpatcher since the start to add modloader so I really doubt that is the issue, but on the wild chance the mcpatcher does add some weird new bug into the equation, I will try a vanilla copy of 1.6.2 with just modloader, no resource pack and automap and see what happens.
Nope - no change - the 1.6.2ML does exactly the same thing as my mcpatcher copy as I suspected.
I'm not getting the automap initialized message like I used to so somehow, despite that modloader reports that's it's loaded automap, it's not actually getting run - least that's my guess - shouldn't I see that message like I used to?
yes, that automap initialized message should still be there.
Something else odd is going on. ModLoader somehow has the impression that mod_automap contains a resource pack I think. This is of course wrong. You should perhaps look into that. See if Minecraft has automap mistakenly listed as a resource pack.
Another thought: your log from above has mod_automap listed twice. Search the .minecraft folder for "mod_automap" and if there is more than one, try deleting the extras. There should only be one mod_automap folder in 1.6.2ML/mods and nowhere else.
If all else fails, you could copy automap's mod files directly into the minecraft jar, thereby bypassing the normal mechanism of loading from the mods folder.
SOLVED!!! Finally - well BP wait till you hear this. I had pretty much given up that I'd ever make this work. I had tried everything and I mean EVERYTHING and just got nowhere. But I happen to be sitting here this morning when a thought hit me. "Wonder if automap would work under singleplayer?" So not expecting anything, I fired up automap, fired up MC and loaded up a single player world and OMG automap initalized and worked!!! I practically came unglued with all the attempts I'd made to try to get this working. So I disconnected from the single player world and hoped on my server in Multiplayer and it connected and worked!!!!
Now at this point I'm thinking, well for some reason automap needed to initialize once in single player mode and now it should work. So I shut everything down, and started from scratch. Launched automap, ran MC - went straight to my server in multiplayer and NOTHING
So I disconnected, went to a single player world - up comes the console automap initialized message and it starts working. Disconnect and back to multiplayer world and yup - connects and works.
This always used to work even if I went straight to multiplayer but now for some reason, automap will NOT initialize if you connect straight to a mutiplayer world right after launching the game. Hit a single player world and you're good to go, as long as you don't completely exit the game.
Interesting eh? Would have never guessed this was the issue, but am I glad I was bored and thought to try single player. This is a very acceptable work around and I have no issue with taking the extra step, however out of curiosity do you think this is something with 1.6 or an issue in your code? Would be interested to hear what you think about all this. At least I finally have an answer which is good cause this surely drove me nuts lol.
Nice find! I must assume it is ModLoader's doing, as AutoMap must rely on ModLoader to initialize it; whether it is a bug or intentional I don't know. But I'll try and keep that in mind next time I update AutoMap so I can investigate
Interesting - I'll look over the Modloader forum thread and see if anyone else reports any similar behavior. At least if anyone else comes to you with this issue, you'll have an answer for them. Thanks for all the patience and forum responses as I worked this out. Truly appreciate the support and if I come across any additional info, I'll be sure to pass it on. Thanks again!
I may have an answer. There is a post today on the ModLoader thread from ExoPandora who writes:
Thank you for making this mod BUT there are two things:
1. Resourcepacks/Sound does not work with modloader
2. The onTickInGame method only works in Multiplayer if you've already been in Singleplayer
These issues need to be fixed !
Issue #2 jumped out at me. I've posted a reply asking if this could affect mods failing to initialize if you don't go to singleplayer. Sure looks like the culprit.
Posted Today, 01:37 PM Marsman2k, on 30 July 2013 - 10:10 AM, said:
With regard to issue #2 - would this cause some mods to fail to initialize if you don't jump into single player once before connecting to a multiplayer world? I just discovered this behavior with AutoMap - could not get it to initialize if I went straight to multiplayer, but hop in a single player world and it initializes and works. Then if I disconnect and reconnect to a multiplayer world, Automap then connects and works as expected.
Indeed. I've the same issue with my own mod so i know the modloader is causing it. My mod has almost the same code fuction since last update so i cant fix it without changing base classes.
Just to let you know I had the same problem with MinecraftAM... it worked with the initial install, but a few days later I booted it up and got the "can't parse: pack.mcmeta" error too, with no Automap. I read through what Marsman2K did (going into Single Player and then Multiplayer) and that seemed to get it running. Weird.
Thanks Marsman2K for posting the solution... I always hate it when people are like "I solved the problem! Thanks" but don't post how they got it working.
Hi All - been a while so I thought I'd check into the issue with modloader where you have to load single player before automap works.
Seems someone got tired of waiting for it to be fixed and wrote a patch to modloader that solves this and other issues.
Check out this thread here: http://www.minecraftforum.net/topic/1888092-162fix-acomputerdogs-modloader-patch-fix-the-bugs-in-modloader/
I've tested it and sure enough it works. Hope this helps - Enjoy!
I've installed AutoMap today using 0.7.8.1 on Mincraft 1.6.2, and I'm having a problem with the "Teleportation Auto-Detection Protection" option in Power Toys.
Basically if I deselect the tick box and click Done, it is then re-selected when I open options again. As a result I'm only ever able to teleport 9.5 blocks.
I'm in survival mode running single player.
I have integrated AM into the jar file along with x-ray mod and mcpatcher so they may be causing a conflict. As a result I will create a new copy of my original jar and try again.
Thanks.
As I recall, the power toys, including teleportation over long distances, was broken around 1.5 (or maybe even earlier?). It was when they changed singleplayer mode internally to be just multiplayer with a local embedded server. I haven't had much reason to fix it as I think you are the first to even mention it was broken
How do i track sub ID blocks like 2145:5?
I want to track custom ores 2097:4
Never heard of sub ID blocks. Not supported I believe Minecraft will soon be using dynamically assigned block IDs so I imagine sub ID blocks will be going away soon anyway.
Never heard of sub ID blocks. Not supported I believe Minecraft will soon be using dynamically assigned block IDs so I imagine sub ID blocks will be going away soon anyway.
My partially educated thoughts -> It's not uncommon. I think that's how wool, etc specify their colours, isn't it? Just normally we don't care what the maps shows because they're all the same block. Unfortunately there's a few mods that produce ores that are of different uses but have the same base block ID.
Totally agree though - it's an issue that should go away once dynamic block IDs come into play.
Try a clean install ?
Have you tried Minecraft AutoMap?
I looked up pack.mcmeta and found out it is a file for a resource pack. I was able to create one and put it in the mod_automap folder, which did clear the error, but it still doesn't work. Not sure what I'm doing wrong here.
Seems odd that MC seems to think it's a resource pack rather than a mod. I'm not getting the automap initialized when I start the game either - nor is .exe able to connect to the game when I run it - most odd. I must be missing something but at the moment I don't see it. Will look it all over again and try to see if I can straighten it out.
From the diagnostic screen on the launcher:
Client> C:\Users\Marsman\AppData\Roaming\.minecraft\versions\1.6.2-mcpatcher\mods
Client> ModLoader 1.6.2 Initializing...
Client> Mod Initialized: mod_automap 27
Client> Mod Loaded: mod_automap 27
Client> Done.
Client> 2013-07-23 19:27:19 [CLIENT] [WARNING] Unable to parse metadata section of resourcepack: mod_automap
Client> java.io.FileNotFoundException: C:\Users\Marsman\AppData\Roaming\.minecraft\versions\1.6.2-mcpatcher\mods\mod_automap\pack.mcmeta (The system cannot find the file specified)
Client> at java.io.FileInputStream.open(Native Method)
Client> at java.io.FileInputStream.<init>(Unknown Source)
Client> at bjg.a(SourceFile:16)
Client> at bjc.a(SourceFile:52)
Client> at bka.a(SourceFile:41)
Client> at ats.a(SourceFile:405)
Client> at ModLoader.init(ModLoader.java:756)
Client> at ModLoader.addAllRenderers(ModLoader.java:191)
Client> at bgi.<init>(RenderManager.java:98)
Client> at bgi.<clinit>(RenderManager.java:14)
Client> at ats.O(SourceFile:341)
Client> at ats.d(SourceFile:599)
Client> at net.minecraft.client.main.Main.main(SourceFile:101)
Client> 2013-07-23 19:27:19 [CLIENT] [INFO] Reloading ResourceManager: Default, mod_automap, mod_automap, Sphax PureBDcraft 128x MC16.zip
If I create a pack.mcmeta file, I can get this java.io error to go away but doesn't change anything. Nothing else has changed on 2 different machines that I had this running on under 1.5.2 ??
I'm really at a loss here as to what to try next - any insight anyone has would be greatly appreciated.
I miss my automap *sniff*
1. Use a fresh copy of minecraft -- don't install any other mods or use any 3rd party patching tools like mcpatcher because there is no telling what they might be doing wrong.
2. Follow modloader's install instructions. This involves creating a "1.6.2ML" version in your versions folder.
3. Run PatchMinecraft.bat and point it at 1.6.2ML.jar
4. Choose the 1.6.2ML version in your minecraft launcher profile to ensure you are loading the correct minecraft code.
Have you tried Minecraft AutoMap?
I'm not getting the automap initialized message like I used to so somehow, despite that modloader reports that's it's loaded automap, it's not actually getting run - least that's my guess - shouldn't I see that message like I used to?
Something else odd is going on. ModLoader somehow has the impression that mod_automap contains a resource pack I think. This is of course wrong. You should perhaps look into that. See if Minecraft has automap mistakenly listed as a resource pack.
Another thought: your log from above has mod_automap listed twice. Search the .minecraft folder for "mod_automap" and if there is more than one, try deleting the extras. There should only be one mod_automap folder in 1.6.2ML/mods and nowhere else.
If all else fails, you could copy automap's mod files directly into the minecraft jar, thereby bypassing the normal mechanism of loading from the mods folder.
Have you tried Minecraft AutoMap?
Now at this point I'm thinking, well for some reason automap needed to initialize once in single player mode and now it should work. So I shut everything down, and started from scratch. Launched automap, ran MC - went straight to my server in multiplayer and NOTHING
So I disconnected, went to a single player world - up comes the console automap initialized message and it starts working. Disconnect and back to multiplayer world and yup - connects and works.
This always used to work even if I went straight to multiplayer but now for some reason, automap will NOT initialize if you connect straight to a mutiplayer world right after launching the game. Hit a single player world and you're good to go, as long as you don't completely exit the game.
Interesting eh? Would have never guessed this was the issue, but am I glad I was bored and thought to try single player. This is a very acceptable work around and I have no issue with taking the extra step, however out of curiosity do you think this is something with 1.6 or an issue in your code? Would be interested to hear what you think about all this. At least I finally have an answer which is good cause this surely drove me nuts lol.
Nice find! I must assume it is ModLoader's doing, as AutoMap must rely on ModLoader to initialize it; whether it is a bug or intentional I don't know. But I'll try and keep that in mind next time I update AutoMap so I can investigate
Have you tried Minecraft AutoMap?
Issue #2 jumped out at me. I've posted a reply asking if this could affect mods failing to initialize if you don't go to singleplayer. Sure looks like the culprit.
Posted Today, 01:37 PM
Marsman2k, on 30 July 2013 - 10:10 AM, said:
With regard to issue #2 - would this cause some mods to fail to initialize if you don't jump into single player once before connecting to a multiplayer world? I just discovered this behavior with AutoMap - could not get it to initialize if I went straight to multiplayer, but hop in a single player world and it initializes and works. Then if I disconnect and reconnect to a multiplayer world, Automap then connects and works as expected.
Indeed. I've the same issue with my own mod so i know the modloader is causing it. My mod has almost the same code fuction since last update so i cant fix it without changing base classes.
Have you tried Minecraft AutoMap?
Thanks Marsman2K for posting the solution... I always hate it when people are like "I solved the problem! Thanks" but don't post how they got it working.
Haha you and all the rest of us!
Especially when the fix is so simple.
Have you tried Minecraft AutoMap?
Seems someone got tired of waiting for it to be fixed and wrote a patch to modloader that solves this and other issues.
Check out this thread here: http://www.minecraftforum.net/topic/1888092-162fix-acomputerdogs-modloader-patch-fix-the-bugs-in-modloader/
I've tested it and sure enough it works. Hope this helps - Enjoy!
Thanks!
As I recall, the power toys, including teleportation over long distances, was broken around 1.5 (or maybe even earlier?). It was when they changed singleplayer mode internally to be just multiplayer with a local embedded server. I haven't had much reason to fix it as I think you are the first to even mention it was broken
Never heard of sub ID blocks. Not supported I believe Minecraft will soon be using dynamically assigned block IDs so I imagine sub ID blocks will be going away soon anyway.
Have you tried Minecraft AutoMap?
My partially educated thoughts -> It's not uncommon. I think that's how wool, etc specify their colours, isn't it? Just normally we don't care what the maps shows because they're all the same block. Unfortunately there's a few mods that produce ores that are of different uses but have the same base block ID.
Totally agree though - it's an issue that should go away once dynamic block IDs come into play.