@eli573 The input/output system is not perfect, especially if you hit the buttons too quickly. Be sure to mouseover the BRAY squares to see exactly what numbers are going into/coming out of the chip.
It works, well, it kinda does. I put in 555*12, and instead of 6660, I got 6600. Yes, I double checked my math, I also used online converters. Still, +1. I multiplied it again, and then it worked. PS) 1100111001000 was what I got the first time.
@PortalPlayer Weird, I don't get that regardless of what number I set them to. What number, specifically, gets displayed as an element name for you? If BRAY ctypes are indeed displayed as element names for specific numbers, that is a TPT bug and I would want to fix it.
Took me a while to see where the decimal representation was, going through the HUD looking for the property I was missing... until I realised that small ctypes display as an element name instead. Obviously you can't change that, so great work!
1. This is awesome, and I will struggle to eventually understand how it works! +1. 2. I tried to use your mod recently, but when I tried to open it, it instantly crashed. I went into more depth in the forum thread, but wanted to let you know. Thanks!
Subframe is such an amazing technology...
@mark2222 yeah if it were 33 bits then the MSB could be used to prevent killing of BRAY, and the next 32 bits..... x86!
@danieldan0 Yes, the I/O is not subframe. It was borrowed from FuriousWeasel's old adder save because I'm a lazy person. Proper subframe I/O is still an unsolved problem (though, due to the nature of I/O, I doubt there's any reason to solve it). As for why FILT only uses 29 bits... ask jacob1 xP.
@danieldan0 just attach a subframe dec->bin to the multiplier input and a bin->dec at the output