[1.7.10_pre4] No sound in eclipse build

[sarkahn]

As it says, sound doesn't work in the eclipse project. I get nonstop Unable to play unknown soundEvent errors. I've tried pointing the Working Space at different spots but it seems like the directory structure has changed since 1.7.2 and I couldn't get it working.

[jeffreykog]

Add --assetIndex 1.7.10 to the program arguments. That should fix it

[sarkahn]

Unfortunately not. Even with that argument added I'm still getting the same errors and no sound.

[LexManos]

the proper asset index and asset dir options should solve this. We are working on giving FG more control over the launch process for devs so we can fix things like this on the FG side.

[AbrarSyed]

Can be fixed with the following for now. Just add this to your run configuration as arguments.

--assetIndex 1.7.10 --assetsDir ~/.gradle/caches/minecraft/assets

[sarkahn]

Had to use the full path instead of the tilde. Using

--assetIndex 1.7.10 --assetsDir C:/Users/Sarkahn/.gradle/caches/minecraft/assets

The sound is working in my Eclipse build now. No reason to keep this open.

[Johnsmith0508]

I have found the same problem with Intellij. none of the mentoned fixes worked for me (I am using a mac 😦 )

[Parker8283]

So am I. For the Dir one, start with Users/xxx/.gradle/etc...

[einsteinsci]

Same problem here. Adding the argument mentioned in Sarkahn's fix (with my username instead) didn't work for me. Probably because I don't have a .gradle folder.

[LexManos]

No, closing it was just fine, you as a modder/programmer should know how to follow directions and provide the necessary parameters to the program you are trying to run.
However to combat people like you who don't know the basics, we will be introducing a new 'Start.java' which just does everything for you -.-

[maartenflippo]

I came across the arguments sarkahn gave as well, however when I try to launch the game now, it gives me a joptsimple.MultipleArgumentsForOptionException . How do I go about fixing that then?

[Parker8283]

By using the new GradleStart class and not passing in arguments.

[Relsig]

I chose to fix this issue by copying the contents of the assets folder (found in the project files folder /eclipse/assets) to ~/.gradle/caches/minecraft/assets. This was heavily hinted at when I received the "joptsimple.MultipleArgumentsForOptionException" error.

I wasn't able to find a non-bytecode GradleStart or a reference to one with a quick search through the references or code... editing a file that is partially bytecode probably isn't many people's strong suit.

Please consider these suggestions (if you haven't already):

1. Automatically copying the assets in eclipse/assets to ~/.gradle/caches/minecraft/assets/
2. Making a config file that is referenced by GradleStart which would allow easily changing these fields and placing it in an obvious location e.g. in the same folder as GradleStart.class

1 will prevent lots of "bug" reports about non-working sound
2 should be mandatory since GradleStart prevents us from changing arguments without editing GradleStart.class

[LexManos]

You do not edit GradleStart the entire point of GradleStart is to need NO arguments, NO editing, NOTHING. You just select it as your main class and DONE.

1. You do realize that the assets in the eclipse folder are copied FROM the cache folder... so copying the other direction is stupid.
2. NOTHING need to be configured so there needs to be no configuration file.

[Relsig]

1. Please accept my sincerest apologies for not being a Gradle expert. Regardless of the correctness of the request you didn't get the point. Neither setupDevWorkspace nor setupDecompWorkspace leave the sounds in the cache on windows 8.1pro x64 (if the OS/version matters, which I highly suspect it doesn't). This includes after cleaning the cache then running either command.

a more appropriate response would be "we are planning on addressing this as soon as possible" and then fixing it when you have time.

2. You're right, nothing should need to be configured, unless the sound files or other files are misplaced (which they are) or if you wish to configure things yourself (which some people do). Not wanting people to play with configurations is fine, in which case a more appropriate response would be "We don't plan on offering an easy way for developers to modify the run configuration using GradleStart but you could set it up manually or edit the bytecode if you have the knowledge/ability, however, we will only provide support for configurations using an unmodified GradleStart"

Also, if having to be social and/or helpful upsets you the solution is simple: Let other people be social and/or helpful.

[AbrarSyed]

My friend, you are mistaken on so many things.

1. this is simply wrong. They are there. That's all there is to it. The setup tasks correctly download the address to their correct locations for MC 1.7.10. If you believe I am wrong, make a new issue and silly all relevant information.

2. the gradle start does not need to be configurable. It is destined to be overrideable. Any arguments you supply should override the ones in the GradleStart file. If there are exceptions (which there are) that you think should not be exceptions, make a new issue and I will address it.

[LexManos]

And now you're telling me what I should do and say, no this just doesn't fly. Locked and g'day sir. Before you come back please do your homework so you do not sound like a complete moron and waste our time.