Hibbsi's Repository of Ideas

The only part that I'm not completely comfortable with is the binary encoder/decoder. Via rtm's teachings about binary adders, I was able to understand and come up with a low thermo solution to add two binary inputs. I'm supposed to keep how it's done on the down-low, but it's pretty simple (and physically small).

The only problem I have, then, is finding a way to convert to and from binary/decimal. I couldn't work out a low thermo way of doing it... if there is indeed a way.

If I may ask, how do you go about doing this?

---

As for preventing the player from changing the inputs, couldn't you just use winches to "lock" the input interface (3-way switch, right?) when the player is near the output button or when the device is "working". This would save you all sorts of hassle. You could also use pistons, but the point is that preventing them from changing the input would be easier than working out write states, no?

Get ready for a wall of text in 3, 2, 1...

Yeah, I've figured out a very simple full-adder device (only has 3 moving parts, 2 sensors, and 4 keys, and only the size of 3 big-grid squares), but what I had to do involved making adders that could handle multiple inputs (in one case, 7 bits + 3 carries). They sum the inputs and will send a carry to 1, 2, or 3 bits to the left (or a combination of carries or not at all). Kinda hard to explain, and I'm not great at explaining things in the first place anyway...


The decimal-to-binary conversion is actually rather straightforward, to an extent. To display numbers, I use dissolve blocks with number stickers on them. On these blocks, however, there are magnetic keys positioned and colored to correspond with its binary equivalent. Once again, I'm not sure that I will be able to explain this adequately. Then, behind where the dissolve blocks sit, there are sensors that are positioned and colored for each binary bit. The sensors of the 10's digit and the sensors of the 1's digit are then connected to a set of full adders. So, for example, for the number 99, the 10's digit will represent 90, and the magnetic keys on the block will represent 90 in binary, which is 1011010. The 1's digit will represent 9 in binary, which is 1001. The sensors behind the blocks will sense the bits where the mag key is present, and send the signal to the full adders, to get 1100011. The full adders' outputs are what the ANDs and modified-full-adders work with.


The binary-to-decimal conversion is a completely different process entirely. Each resulting bit from the multiplication has a separate value for each digit of its decimal equivalent. The decoder is 4 (one for each decimal digit of the answer display) sets of pistons arranged linearly. Each piston has a value of 1, 2, 3, 4, 5, 6, 7, 8, or 9. When a piston is not extended, it is at its minimum length of 5. When it is extended, its length is 5+(value of piston)*5. For example, for a piston that has a value of 7, the extended length would be (5+7*5=) 40. When a combination of pistons are extended, the end of the line of pistons will be at a certain value from 0-9. When the "answer" button is pressed, there is a slight delay to compensate for the line of pistons' moving (from what appears to be inertia), and then a key is emitted over a sensor which causes the output number to be emitted. The 0-9 sensors move in increments of "10 (55 units on pistons)" in order to always be where the end of the piston chain is, to get the correct value. If the piston chain extends over "10", then a carry is sent to a piston with a value of "1" in the next largest decimal digit. So, if the binary bit from the modified-full-adders that represents 128 was 'on', a piston in the 100's piston chain with a value of "1 (10 units on pistons)" would extend, a piston on the 10's piston chain with a value of "2 (15 units on pistons)" would extend, and a piston in the 1's piston chain with a value of "8 (45 units on pistons)" would extend, resulting in the output of 1, 2, and 8 in the appropriate digits.


As for preventing players from changing the inputs, I wanted to avoid physically manipulating the switches or the players so that they could not be changed, in order to maintain smooth operation. I have now finished (I'm going to test more, but I think it works fine) a way to do this. It involves moving the sensors that cause the number blocks to be emitted and the sensors that cause the blocks to be deleted. They are moved out of the way when the "answer" button is pressed, and move back when the answer is displayed. This way, there is no possible way the numbers can change, and it only involves 2 pistons for each digit. As you concluded also, employing write states would be a unnecessary hassle, so I ditched it and thought of this.


Phew. This is a long-winded response if I've ever seen one. At some other time I may make a new blog post that has all of this description along with whatever else needs explained, but that will be later. And I'll include pictures, which would be helpful.

Alright, I completely understand the decimal to binary conversion. I was lying before when I said I didn't get that (I had just forgotten). I was considering the same method, with dissolve and keys and such.

I'm not sure what your adder looks like, but I'll be sure you show you mine. It's very similar to what rtm came up with, but with one fewer key switch (I win this round, rtm!). In the end, it has 4 connectors (pistons), an L-shape of Dark Matter, a single key and two key switches. I am pretty happy with the design, and I may try and improve the size it takes up (which is already very small).

I'm completely lost in the binary to decimal conversion. I have no coding, CS, or engineering background, so it kind of went over my head. Once I can see what everything is doing in LBP, I will make sense of it.

We'll have to meet up and check this thing out sometime today. Sorry I ignored you last night - I was busy working on my stuff - which I'll show you when we meet up.

Cheers.

Edit: my adder had been reduced down to 1.25 x 1.5 in the large grid. The only thing preventing from going smaller is that I wanted to keep everything grid aligned. Are you going to be in game tonight? I have it set up to add numbers 0 - 9 right now, since I can't be bothered to wire it up further. Now I just need to know how to convert from binary to decimal, haha.

I'm interested in seeing that adder, actually, and what? Just one key? I only got mine down to three. Oh well, I can't figure everything out for myself I guess

And as for the binary to decimal conversion, the reason that my description might have been hard to grasp is most likely because it's hard to explain and I know I had trouble putting into words what happens. Believe me, I have no coding, computer science, or engineering background, either (hopefully I will when I go to college), I'm just a math nerd. So yeah, it's me, not you lol

As for getting on LBP tonight, it's a maybe. I have some stuff to do. (None of which is voluntary, I can assure you... how do I know these people that are blissfully unaware of their ability to kill every digital device they come in contact with? Oh, wait. I'm related to them.) If I am, I'll load up a copy of the current version of the level, and then remove all of the unnecessary lighting and other decorative stuff, because the fps really takes a dive in create mode around some areas. (Surprisingly enough, and thankfully, fps stays relatively normal when in play mode.)