I think there should be an element called SENS that would be a type of wall. It would not in any way affect moving air or particles. It would be "transparent" to everything in TPT (though it wouldn't be literally transparent or invisible to the user running TPT, as it would be a ceartain visible color, for example green).

Each time you placed a pixel (or should I say a 4x4 pixel block) of this, it would bring up a dialog box asking what you wanted that specific sensor to measure, the file name you wanted to save the data to, and the format you wanted the data stored in. Also an optional header can be selected to be used (suggested header format is at the bottom of this post). Available measurements would be:
Pressure
Absolute Value of Pressure
AIR X Velocity
Absolute Value of AIR X Velocity
AIR Y Velocity
Absolute Value of AIR YVelocity
Magnitude of Air Velocity SQRT(Air Vel X^2 + Air Vel Y^2)
Air Temperature (when Ambient Heat is turned on)

Available Data Formats (all multibyte integer types be "little endian" types) would be:
Ascii Text of numerical data
Byte (8bit unsigned integer)
Short Int (signed 16bit integer)
Long Int (signed 32bit integer)
Single Precision IEEE Floating Point (32bit FP value)

Notes about data types:
There will be no Double Precision IEEE as TPT never uses any values with that much precision.
Regardless of how any given quantity is handled internally, the output of the SENS "wall" can be any of the above data types.



This is how the data type conversions are supposed to take place.

Floating Point values to Integer values will be converted by rounding the values to the nearest whole number ( 1.5 becomes 2, but 1.499999 becomes 1; -1.5 will become -2 and -1.499999 will become -1). The maximum possible positive finite value of the SP-FP number will be mapped to the maximum possible value of the integer data type in question. +0 and -0 of the SP-FP number will be mapped to 0 of the integer. For negative SP-FP values, they will be mapped to negative integer values in the same way that positive SP-FP values were mapped to positive integer values. That is unless the case is that the desired integer data type is the Byte (no negative numbers) in which case the negative SP-FP values will simply be mapped to 0 for the Byte data type.

For conversion from integer data types to SP-FP values, the values are scaled from the integer data range to the SP-FP data range (just the reverse operation of the above paragraph, with the exceptions that no rounding will be done to force whole number values as it is going into a floating point format, and that the 0 of the integer 0 will randomly be mapped to +0 or -0 of the SP-FP value).

For conversion between the 2 signed integer data types their range is simply scaled from one into the other, and any needed rounding to the nearest whole number is performed.

For conversion from a signed integer to byte (8bit unsigned integer) data type, the negative numbers are forced to 0 and the positive numbers are scaled as needed and any rounding that's needed is performed.

For conversion from byte to a signed integer everything mentioned in the above sentence is done except for truncating as that isn't needed when converting TO a signed integer.

For converting byte to SP-FP, scaling is done as needed but no rounding or truncating of negative values is performed.



Header Format:
4byte ID code = "TPTD" (which means The Powder Toy Data)
1byte data type ID (0=8bit unsigned int, 1=16bit signed int, 2=32bit signed int, 3=IEEE Single Precision Floating Point)
4byte unsigned int = number of data points


There would be an option in the dialog box for a given sensor that would allow it to have a header (using the above specs), or to not have a header.

Default values for the dialog box are

Measurement = Air Pressure
Data Type = IEEE Single Precision Floating Point
Header = yes
Filename = %powder.exe's own flolder%\sensor data\data.ptd (where ptd stands for Powder Toy Data)


If you draw a line of sensors (shift+draw) it will be assumed you want to make a linear array of sensors so you will only be shown one dialog box. If you choose a file name of mydata.ptd it will automatically generate an array of names for the sensors from mydata00.ptd to mydataXX.ptd (where XX is the last sensor in the linear array and the max number of sensors is 100 as XX can only be as high as 99). The place that your mouse button goes down will be the first sensor in the linear array for file numbering purposes. The place where your mouse button goes back up will set the last sensor in the array for file numbering purposes. All sensors in this array will have the same properties for Measurement Type, Data Format, and Header (or No Header)

If you draw a rectangle of sensors (ctrl+draw), it will be assumed that you want to make a 2d array of sensors so you will only be shown one dialog box. The auto naming convention will be filenameXX,YY.tpd where the upper left sensor in the array is labeled filename00,00.tpd and the lower right sensor will be labeled filenameXMAX,YMAX.ptd (maximum number of sensors in such an array is 100x100 which is 10000 sensors).

I think this would be a really awesome feature as it would mean that one could perform experiments in TPT and get data that could then actually be analyzed with other software.

code1949:

@Videogamer555 (View Post)
So basically it records information into a text file so that a person with the right program can analyze it?

Yes, it could do ascii text, but if you read the whole description it can also have the option of writing raw data (which would mean if the value the sensor read was 1-byte value that had the value decimal33 (hex21) and wrote it to a file reading it in a text viewer would just show the symbol "@" which I believe is the text character for ascii-code 33, and would NOT display the actual number text "33").

I proposed these 4 raw data types be supported.
Byte (unsigned 8-bit integer)
Short Int (signed 16-bit integer, little endian)
Long Int (signed 32-bit integer, little endian)
Single (32-bit IEEE single precision floating point value, little endian)

bump. This is too epic. The devs need to see this. Have you ever posted a pressure sensor sign and wished it could log the data to a file? Well that's basically what I'm suggesting, but a bit fancier (allowing for arrays of sensors to be drawn, and multiple data formats, and even its own header for the unique log file so that a reader software would know how to interpret the data).