atypicaluser

So indeed it may be related to my Xerces installations. I tried option A: letting MC sit for a while to download sounds; no joy. However, option B: hide my installed Xerces implementations - I now have sound! I got a new, seemingly non-fatal error but it appears to be unrelated. New, innocuous error:

It is. See spoiler.

Thanks for the help; it was quite insightful! And you are correct; I do have a JDK installed. It's funny that you ask if the sound works in vanilla MC. When I do a fresh, vanilla install, sometimes I have sound immediately, sometimes not. Within one or two minutes of sitting at the "home" screen, sound always works. I've been unable to replicate this small hiccup in any predictable way. I simply wrote it off as the sound system taking a bit of time to initialize and become available. Perhaps it is related to sound downloads. Are these sounds downloaded once, at first run? If so, perhaps giving my vanilla MC "first run" plenty of time to complete the download before installing Forge would be helpful. If that doesn't work, I'll temporarily hide my installed Xerces implementations and try it all again.

I'm not using the archive capabilities of the OSX Finder; I'm not doing drag-n-drop to add mods to Minecraft. I'm at the command line, un-jar'g, un-zip'g, and jar'g myself. I use rsync (w/o --delete & w/o --update) so that directories are merged and not overwritten, timestamps are ignored. My tools are fine. They've worked for ... ages. In vanilla MC, there are two codecs: CodecJOrbis (8,100 bytes) and CodecWav (5,338 bytes) In Forge 608, there are three codecs: CodecIBXM (7,898 bytes), CodecJOrbis (8,229 bytes), and CodecWav (5,459 bytes) Once my tools are done merging MC and Forge, I have three codecs: CodecIBXM (7,898 bytes), CodecJOrbis (8,229 bytes), and CodecWav (5,459 bytes) Seems right to me. So how am I supposed to know if "paulscode" was installed (in)correctly? I've watched several videos on how to avoid the "paulscode" issue. They're all basically the same. I've done it. I do it. It doesn't help. The issue is not with "bad archivers." The issue is the assumption that everyone uses a Windows-like GUI to moves files via drag-n-drop. Windows is the only OS that "merges" directories when you drag-n-drop a directory onto one with the same name. (Not true: OSX 1.7/1.8 now has a "merge" option in this situation.) But that's not the point ... I don't nor ever have used the OS file GUI to tweak Minecraft. If there are newer/different codecs (for example) in Forge, then they SHOULD overwrite what's in vanilla MC. What SHOULDN'T happen is a Forge directory shouldn't REPLACE an existing MC directory, it should MERGE with it. Again, that's not an "archiver" issue, that's a file GUI drag/drop issue. Since I don't use the OS's file GUI and I've worked hard to make sure that directories are merged, the "bad archiver" issue is not my issue. And I don't understand your statement: "We replace a class in that folder so it got overwritten when you installed forge." "It" = "a class" -- isn't that exactly what's supposed to happen?

Trying to keep this alive ... Still no joy - not even with MC 1.5.1 and Forge 7.7.0 608 ... Forge log ...

Downloaded the barest and most vanilla Minecraft 1.5 client from Mojang. Ran it once. Ran as expected. Downloaded Forge "Build 7.7.0.595: 2013-03-18 14:40:03 for MC: 1.5". Installed it per Forge wiki @ http://www.minecraftforge.net/wiki/Installation/Universal. Ran it once. Forge "did its thing." No game sounds whatsoever. Ran through this process three times, each time fully blowing away MC and restarting with a fresh install. I got the same results. This was after trying it several other times with both Forge build 579 and 583. Same results. I'd say it's rather reproducible. OS = OSX 10.6.8 Java = version 1.6.0_43 JRE SE (build 1.6.0_43-b01-447-10M4203), HotSpot 64-Bit Server VM (build 20.14-b01-447, mixed mode) Anyone have any ideas? Minecraft log here ... Forge log here ...