Jump to content

Cromage

Members
  • Posts

    5
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Cromage's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. Yup, same idea.
  2. Yeah, it does. Actually, the name you give assign it in the sound pool matters too. Check out SoundPool.addSound(). It appears to creates its own reference from the name you give it. It creates this reference as follows: 1) cuts off everything after the first "." character. 2) cuts off any digits at the end (this is so all similar sounds will be saved under the same reference) 3) transmutes all "/" to "." So if you give it the string mod/sound/hey.wav the reference it creates will be mod.sound.hey; it'll be that reference which you'll need to access later. Not only that, but it will save the "original" name you gave it as a SoundEntry field, and which will be read in the method SoundManager.playSound(). I think this is so that it can correctly choose a codec for the sound file. This is my code, which works with my files, even in the zip: // Initializes our entries into the Sound Pool public void onLoadSoundSettings(SoundManager soundManager) { String [] soundFiles = { "horse/whinny3.wav", "horse/whinny4.wav", "horse/snort.wav", "horse/snort2.wav", "horse/death.wav", "horse/hurt.wav"}; for (int i = 0; i < soundFiles.length; i++){ soundManager.getSoundsPool().addSound(soundFiles[i], this.getClass().getResource("/MountsMod/sound/" + soundFiles[i])); } } So to access a random whinny noise, I just reference "horse.whinny".
  3. btw, is there a reason why you used "Method.class.getClassLoader().getResource()" instead of the way the example did it? I don't know enough Java to know what the difference would be, but I was able to load sounds just fine in my zip file using the example code.
  4. Yeah, that does seem odd, though I haven't tried it myself. I do know that Atomicstryker does the same thing with his mods. His workaround isn't actually not that bad although it probably keeps the mod from being loadable via "automatic installers" or whatever.
  5. So I fiddled around with this a bit and took notes. Maybe it could become a tutorial eventually. Notes about how Forge handles custom sounds: 1) The modder overrides getLivingSound() in Entity class to return a string (let’s call it soundString) that represents the sound. 2) EntityLiving.playLivingSound() reads getLivingSound() of the Entity and calls World.playSoundAtEntity() with the Entity and soundString as arguments 3) World.playSoundAtEntity() passes the soundString to the static method ForgeHooksClient.onPlaySoundAtEntity, and asks for a string back. The string it receives depends on your implementation of ISoundHandler. Most of the time, it will just be soundString (see 5a). 4) ForgeHooksClient.onPlaySoundAtEntity checks static variable ForgeHooksClient.soundHandlers2, which is a linked list that contains objects of classes that implement ISoundHandler. If there are no entries in soundHandlers2 the method will return soundString. If there are entries in soundHandlers2 it will go through them and call ISoundHandler.onPlaySoundAtEntity() on each. If any of those handlers return null (even handlers declared by other mods for whatever reason), this method will return null as well. If not, method will return the result of onPlaySoundAtEntity() for the last entry in the list. 5a) The unimplemented method, ISoundHandler.onPlaySoundAtEntity() generally should return the namestring it is given--in other words, soundString will usually just propagate up to World.playSoundAtEntity if Forge has loaded no SoundHandlers (because you aren't using custom sounds) or your SoundHandler doesn't do anything fancy. 5b) soundHandlers2 is only altered by the method MinecraftForgeClient.registerSoundHandler(), which must be called by the modder. this method will add the given sound handler to soundHandlers2 ONLY if the method onPlaySoundAtEntity() has been declared in the sound handler class. 6) registerSoundHandler() also adds any soundHandler it is given to the linked list soundHandlers. When SoundManager invokes loadSoundSettings(), it calls onLoadSoundSettings for all registered soundHandlers. 7) The unimplemented ISoundHandler.onLoadSoundSettings() is invoked on all registered soundhandlers when the method SoundManager.loadSoundSettings() is called. The modder should put the sound file import code (as per LexManos’s example) in this method, in a class that implements ISoundHandler or extends SoundHandlerAdaptor, and then register the new SoundHandler. That about right?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.