hldj.org

Would it be possible to implement a feature, that would let you pause, not stop the song and then resume it from the place you paused it?

It's definitely possible... but perhaps unfeasibly complex. The game controls playback, so it would require that HLDJ monitor when/where you start and pause a song, then on unpause, it would have to scan through the voice_input.wav file, find the time frame of the pause, and reconstruct the file so that that frame is now the beginning. Possible, but a lot of work.
It's been brought up once or twice before in the past. One thing's for sure, I will need a decent wav parser (which is in the works), but after that, the next priority would be the built-in mp3->wav convertor (I could implement it after then, if it's high-need).

Actually, if you can count the waits, this would be easy to do.

Just use the following formula:

( ( wav file size in bytes - 44 ) / 37.5) rounded up == wav length in waits

Same thing works in reverse. Just get the number of waits that passed, and find how far the game read in bytes (Rounding back a few of course, to help iron out latency) . Then, keeping the wav header in place, remove that number of bytes. Of course, you would need to place the file back (The whole thing) after it was all done, so this would be a pain. Now, if only wav files had a start at header to use, this would be easy and practical.

EDIT: Crap, I didn't notice how old this was. I was looking at another thread and lost track because I had to go and register

Are you referring to the wait command? I'm not sure how that would factor into any sort of solution... firstly, the wait command counts system "tick"s - which is frame/CPU dependent, and not constant in time. Also, if I have the time-lapse given in seconds, why would I want to convert it to waits (even if I could)? I'd still have to convert back to seconds in order to skip the necessary amount of chunks in the wav file...

Renegade wrote:Are you referring to the wait command? I'm not sure how that would factor into any sort of solution... firstly, the wait command counts system "tick"s - which is frame/CPU dependent, and not constant in time. Also, if I have the time-lapse given in seconds, why would I want to convert it to waits (even if I could)? I'd still have to convert back to seconds in order to skip the necessary amount of chunks in the wav file...

Well, it's generally constant in time, but the idea was thrown out anyways. The reason I used waits is because there's no way in source to could exact time as far as I know.