|
Phssthpok posted:The infrared sensor always has an "on" time greater than the initial time... It seems like this is an intended theme of the narrative. I was waiting for the test cases 2-4 to switch that around and fully expected to have to botch in some kind of inversion logic for the other case. Then... it didn't. 100% TESTS PASSING, SHIP IT
|
#
?
Oct 8, 2016 09:28
|
|
|
|
| # ? Apr 19, 2024 05:50 |
|
|
nielsm posted:I also solved that puzzle now based on that idea, was definitely easier than my original one. However I think I simplified the design in two ways: First, instead of signalling strict -1/0/1 for destination, I just subtract the current and destination node IDs to get a negative/zero/positive number I think that saves one or two instructions. Second, I avoid counting in the output module, by using a simple I/O pin from the input to signal whether there are more data, so I keep the line high while there are data and set it low at the end. I was a little surprised you actually can use simple I/O lines like that within a single I/O cycle. Ah, I miswrote... I used subtraction as well... I meant <0/0/>0 really. I did not realize you could use a simple IO as a signal within a single cycle. Fascinating. Regarding memory elements, I discovered something rather late that's caused me to redesign some things: - you can read back the address register - the address register is modulo 14 -- writing 16 is effectively the same as writing 2, etc
|
|
#
?
Oct 8, 2016 09:55
|
|
|
Two Owls posted:I was waiting for the test cases 2-4 to switch that around and fully expected to have to botch in some kind of inversion logic for the other case. It's extremely sad/amusing to see everyone expect the beatings that never come. I definitely do the same thing! I get the impression there are many points in the game that used to be/could have been much, much more of a pain in the rear end, but he "let the people win" IMHO these kinds of 'hardcore bleeding edge cases' would have made for some great "bonus goals". I would be crucifying myself on unfair puzzles to unlock more parts for the free-build mode Much like real work, I am procrastinating as much as possible 
|
|
#
?
Oct 8, 2016 09:56
|
|
|
It's also quite possible that some of the puzzles will be tweaked before final release (that definitely happened in TIS-100 -- I'm still grumpy Zach retired the insane prime factor puzzle -- I was so proud of going from 600k cycles brute force to 6k cycles crazy-parallelized) and the validation data, etc might get tightened up disallowing certain shortcuts....
|
|
#
?
Oct 8, 2016 10:03
|
|
|
Quinton posted:Regarding memory elements, I discovered something rather late that's caused me to redesign some things: I was just about to post the same. I should probably try to optimize my Bitcoin ATM a bit with that, but more interested in solving the self-closing window for now. Planning to set the address pointers a fixed distance apart to use it as a ring buffer for a running sum.
|
|
#
?
Oct 8, 2016 10:04
|
|
|
I just had to go double check the store page, could not even tell this was an early access game. I wish more people were like Zach
|
|
#
?
Oct 8, 2016 10:09
|
|
|
nielsm posted:I was just about to post the same. I did something like that for the Deep Sea Sensor Grid... https://www.youtube.com/watch?v=cMIT5j1LPBM New Zealand can eat me posted:I just had to go double check the store page, could not even tell this was an early access game. I wish more people were like Zach Quinton fucked around with this message at 10:41 on Oct 8, 2016 |
|
#
?
Oct 8, 2016 10:38
|
|
|
I think I'm burning out on this game. The "part not sleeping" errors and undocumented instructions (what the hell is when????) are getting to me, the former in particular because I still don't understand how to program in a way that avoids it. This game needs a coding guide for dummies or something.
|
|
#
?
Oct 8, 2016 14:40
|
|
|
Pollyanna posted:I think I'm burning out on this game. The "part not sleeping" errors and undocumented instructions (what the hell is when????) are getting to me, the former in particular because I still don't understand how to program in a way that avoids it. This game needs a coding guide for dummies or something. Its a stricter but related phenomenon to desyncing different cores in TIS-100 and passing wrong values, except it will just hard lock because of the sleep requirement.
|
|
#
?
Oct 8, 2016 15:06
|
|
|
Another possiblility: it would work perfectly if you hadn't typed "slp x0" instead of "slx x0" yet again arrrrgh
|
|
#
?
Oct 8, 2016 15:24
|
|
|
Pollyanna posted:I think I'm burning out on this game. The "part not sleeping" errors and undocumented instructions (what the hell is when????) are getting to me, the former in particular because I still don't understand how to program in a way that avoids it. This game needs a coding guide for dummies or something. It will happen if a part is blocking on XBus I/O on a bus where everything else connected is also either blocking or sleeping. Keep in mind that every MC will need at least one sleep-instruction somewhere, otherwise the I/O clock can never proceed. When you get the error, look at the current instruction the MC is executing, and check what ports it uses. Check the state of the components connected to those ports. You should find that those components wouldn't be able to fulfill whatever I/O the port wants to do. Sometimes it's because you need an SLX instruction, sometimes it requires more changes, and sometimes the entire design is unworkable. Whenever you connect two components in one way or another, consider what they will be communicating, when, and what protocol they will use. E.g. will they communicate every I/O step or only once in a while. Is it one-way or two-way? Will you be sending commands, data, simple triggers, or maybe even more complex packets? Example of a protocol I made for one puzzle: "This MC will 'slx x0', when there is data there will always be two values. The first value will be set on p0 and the second value on p1. After setting those pins it will send a signal on x1, then return to sleep until x0 receives data again." Basically an output component that let me control two simple pins with a single XBus. Always think in protocols and components.
|
|
#
?
Oct 8, 2016 15:41
|
|
|
Hey, I actually did pretty well on the Aquaponics, for a change! 199 cycles. And 8 yuan. Edit: also, I am not getting histograms, only friendslist numbers. Broken on Linux, maybe? OddObserver fucked around with this message at 15:47 on Oct 8, 2016 |
|
#
?
Oct 8, 2016 15:44
|
|
|
OddObserver posted:Hey, I actually did pretty well on the Aquaponics, for a change! I've played a bit on mac and windows, and they only seem to work on windows.
|
|
#
?
Oct 8, 2016 15:53
|
|
|
Is there a way to invert gen without going through a second chip?
|
|
#
?
Oct 8, 2016 21:27
|
|
|
Well, the trivial way would be to use two instructions. Like, gen 0 x gen y 0
|
|
#
?
Oct 8, 2016 21:33
|
|
|
^^^ My suggestion creates less instructions than that.Shab posted:Is there a way to invert gen without going through a second chip? gen p# y x
|
|
#
?
Oct 8, 2016 21:39
|
|
|
Shab posted:Is there a way to invert gen without going through a second chip? pumpinglemma posted:Well, the trivial way would be to use two instructions. Like, mov 100 P slp X mov 0 P slp Y and a slp 0 is just a nop
|
|
#
?
Oct 8, 2016 21:43
|
|
|
Duh, thanks guys.
|
|
#
?
Oct 8, 2016 21:45
|
|
|
Puzzles sound like work, so since its Saturday I did more not work. I downloaded a tuner on my phone and found some sheet music and got to making the obvious choice of a short ditty. Its almost entirely not not in tune because the overlaps of the tone generator with the musical scale aren't quite common enough. Or I might have just downloaded a bum tuner or my TVs flat or I don't remember enough about music. My tonebank ROM is in a bit of a mess because this was an experiment firstly but if you are playing along at home, the addresses 3-4-5 correspond to A flat - B flat - C and the addresses 7-8-9-10 correspond to D - E flat - E - F. The songbank ROMs are in the form of note length - tone address. The length is somewhat hacky. It clips every note with a 1 time unit silence to enunciate the notes so a 4:4 measure is 24 time units long. In the specific example it uses 1 for triplet eighth notes, 5 for quarter notes, and 17 for a dotted half note. So that would make an eighth note 2, a half 11, and a whole 23. The two songbank controllers per speaker are lazily hacked together to just wait and don't do any signalling out of pure laziness. http://pastebin.com/Sy6Y9Luj
|
|
#
?
Oct 8, 2016 22:19
|
|
|
^ Did you do something to change the notes? When I used my tuner everything was way out of key
|
|
#
?
Oct 8, 2016 22:21
|
|
|
New Zealand can eat me posted:^ Did you do something to change the notes? When I used my tuner everything was way out of key e. If you're really enterprising you could give compositing a shot. If you have a tone thats 1/8 flat and a tone thats 1/8 sharp, if you play them simultaneously it should sound sort of like the on key note in a car crash. Pianists use the same idea to get blue notes out of a tuned piano. zedprime fucked around with this message at 22:38 on Oct 8, 2016 |
|
#
?
Oct 8, 2016 22:24
|
|
|
I'm really only interested in making usable DMTF tones, IME everything was 8-10 hz too flat/sharp
|
|
#
?
Oct 8, 2016 22:48
|
|
|
New Zealand can eat me posted:I'm really only interested in making usable DMTF tones, IME everything was 8-10 hz too flat/sharp If your tones are slightly sharp and your buzzer driver is like this: code:code:
|
|
#
?
Oct 8, 2016 23:00
|
|
|
I was trying to do that but the audio gets way too noisy to be useful when you're using more than 3 buzzers IME
|
|
#
?
Oct 8, 2016 23:26
|
|
|
nielsm posted:It will happen if a part is blocking on XBus I/O on a bus where everything else connected is also either blocking or sleeping. I guess my issue is that I can't think of components and their logic in isolation. Here's my incomplete solution for the wireless controller:  Each component does something clear and obvious. The buttons component checks the state of the inputs and pushes the resulting value to x0, then sleeps to be ready to push again. The stick component pushes the current states of x and y on two XBus outputs, and sleep to be ready to push again. The middle component waits for x, pushes x, waits for y, pushes y, waits for a+b, pushes a+b, and repeats. Each component does its job correctly in theory, but when they start talking to each other poo poo falls apart. That's when I get frustrated. I'll think more about the protocols and components approach, I guess. Also, you can completely ignore everything I said cause I found a stupid bug in my code and I hate my life.  I am too incompetent to be anything but a Rails monkey. EDIT: Fixing that bug didn't solve everything now I hate it even more.
|
|
#
?
Oct 8, 2016 23:45
|
|
|
 https://twitter.com/zachtronics/status/784891334553284608
|
|
#
?
Oct 9, 2016 00:01
|
|
|
Has anyone found a use for the mystery component? (The one with the spec-sheet in Chinese) I've more or less worked out what it does in the sandbox, but haven't found anywhere to use it. Can anyone suggest a puzzle where they used it?
|
|
#
?
Oct 9, 2016 00:18
|
|
|
I loved Spacechem, and Infinifactory to a lesser extent. Then he's got TIS-100 and this game. Maybe my grasp on time is bad but it seems like he can just pump games out like its nothing.
|
|
#
?
Oct 9, 2016 01:04
|
|
|
I think he was working for Valve for a while and then was not so the joke was that he really likes releasing games which was completely incompatible with Valve. Shenzhen is kind of the production mode to TIS 100 to analogize it to Spacechem. Different game with a lot of the same DNA. Still impressive because he's basically taking swathes of college math and computer science and turning them into games.
|
|
#
?
Oct 9, 2016 01:32
|
|
|
Pollyanna posted:I guess my issue is that I can't think of components and their logic in isolation. Here's my incomplete solution for the wireless controller: You're thinking about xbus backwards. Your x/y bottom left unit, for example, is producing 2 xbus packets every time unit. Someone would have to consume that data whether they want it or not. In other words, you are pushing data up from x & y spontaneously, all the time. That's ok for simple inputs, but for xbus you want to be doing that just once as necessary. Think of the logic flow as a V. When your upper layers receive a command, they then tell the lower layers to fulfill the command. Only when the lower layers receive a command do they activate, then respond back once. The key to this is usually the slx instruction. Here is an unoptimized but straightforward solution to show what I'm talking about :  One unit's job is to check the radio. It has a convention that it will send something to wake up the other units, then get two responses from x/y and one from a/b. You'll get there!
|
|
#
?
Oct 9, 2016 01:53
|
|
|
Pollyanna posted:I guess my issue is that I can't think of components and their logic in isolation. Here's my incomplete solution for the wireless controller: Don't use slx. I'm serious. You can do all the early puzzles with lockstep implementations. If you're not really understanding how the xbus works, stick to solving everything lockstep until you do understand it.
|
|
#
?
Oct 9, 2016 01:55
|
|
|
Pollyanna posted:I guess my issue is that I can't think of components and their logic in isolation. Here's my incomplete solution for the wireless controller: If you added a slp to the middle CPU you could take out all the slxes and it would work exactly the same as it does now (and actually use less power). Remember, its perfectly okay to block on xbus for a bit, so long as you don't deadlock and try to carry that block into the next time unit. The #1 and kind of only rule in this game is that everything must be put to sleep before the time unit can end.
|
|
#
?
Oct 9, 2016 02:27
|
|
|
Thinking about that puzzle gave me an idea for a new solution, and it makes me sad that its not more efficient than it is because it looks loving stupid. 286 power though (or 
homeless snail fucked around with this message at 02:55 on Oct 9, 2016 |
|
#
?
Oct 9, 2016 02:37
|
|
|
I'm pretty bad at these kinds of games usually, but I loving love playing them and I can't pull myself away. The I Ching took me loving hours, I wiped out everything and restarted about 4 times, but I got it.  I don't care how efficient or cheap it is right now, it works. I'm going to go lie down and veg out now, my brain is dead.
|
|
#
?
Oct 9, 2016 04:49
|
|
|
Was getting really mad that my poo poo wasn't working, came to the heart-sinking realization that I had been typing 'tgt p0 40' when I actually meant 'tgt p0 39' 
|
|
#
?
Oct 9, 2016 05:19
|
|
|
469 on the cryptocurrency deposit terminal. One instruction short of a pretty big final optimization. This game is so good you just want to keep revisiting old problems and revising them over and over.
|
|
#
?
Oct 9, 2016 10:34
|
|
|
I'm toying around with the game prototyping/free play mode, it's a bit annoying you seemingly can't set an initial value on the N4DL-1000 static XBus input. But I found a way to abuse the memory chips as modulo division to limit the range of a random generator: 
|
|
#
?
Oct 9, 2016 10:58
|
|
|
piece of poo poo version of this thread for less pretension http://forums.somethingawful.com/showthread.php?threadid=3793577
|
|
#
?
Oct 9, 2016 11:54
|
|
|
Made a game of that range-limited random generator, hit the button when it buzzes, but don't hit it when it does not. 
|
|
#
?
Oct 9, 2016 12:02
|
|
|
|
| # ? Apr 19, 2024 05:50 |
|
|
Holy gently caress Device 2A27. I've dropped 24 yuan and 11.6k power on it and I still can't loving 
|
|
#
?
Oct 9, 2016 13:45
|
|