It would be a wall type. As with stickman element type, you can only place one at a time (no more than 1 onscreen simultaneously). It must be wall not element, because it measures pressure (an air block based value in TPT, not a pixel based value). When you place it on screen, it will pop up a menu asking for the file name to use for the wav file, the bit depth (8 or 16) and the sample rate (5512, 8000, 11025, 22050, 44100, or 48000) that you wish to be the sample rate of the wav file, and also the total number of samples you wish it to record. When you are done, you press the "ok" button and it will pause the game (allowing you to make any last minute changes before continuing). Unpausing the game will start it recording, start recording. After the specified number of samples has been recorded, it will pop up a message box stating that the recording is finished, and then the microphone block will delete itself, allowing it to be placed elsewhere later on (I can imagine this being also expanded to allow multiple mics, each recording a pressure event from a different point of view to its own wav file so that you'd have 0001.wav 0002.wav etc, so the "sound" of an explosion can be heard from different observer's points of view).

An example of how this would work is if you set it to 5512 and set it to record 11025 samples (2 second long wav file) it will record it as specified. Since TPT runs at 60hz to record 11025 samples will take 183.75 seconds to record. Thus the recorded sound plays faster than it records. Why is this good? Well for the most part this will record explosions or other "awesome" pressure phenomenon. Such pressure things as explosions take seconds to complete in TPT but in real life occur in milliseconds. So the resulting "speedup" of the faster playback rate really WOULD make the explosion sound be much more similar to its real life equivalent (since everything is slower than real life in TPT).

So that speedup wouldn't be so much as a distortion of TPT, but rather more of making the resulting sound file more accurately mimic real life.


As this is simply a measure of pressure, there is NO NEED to add an extra "sound" data layer to the simulation (remember, the idea of a sound layer had been rejected).

@Simon (View Post)
It could still make some interesting effects I think. Would it be possible to implement this?

@Simon (View Post)
Why would the sound not be audible?

mniip:

because 60hz

And if it recorded it into a wav file and the wav file header said 5512hz, then it would play it back fast and make a sound. In fact the factor by which the speed was increased would be very realitic because the explosions in this TPT happen about 1000 times slower than in real life, so 1000x increase in speed would mean that the audio playback would be realistic. THAT is what I'm saying, and I'm surprised that Simon didn't know that was what I was saying because I said it in PLAIN ENGLISH in my opening post. Heck, I'd put it in a mod myself if I knew how to code arrays in C, as I will need a recording array to put the data into when saving a wav file. I don't know much C, so any beta experiments I'd like to test, will have to be implemented by others (the TPT devs in this case) on my behalf so I can see how if my idea will work. And I'm sure it will but convincing Simon of something is going to be problematic when he couldn't even seem to understand the PLAIN ENGLISH description of my op post. If he understood it, he NEVER would have made the replies he had made. Instead he would have said, "WOW GREAT IDEA, I'll put it in the next version of TPT, I wish I had thought of that".