|
Zomborgon posted:An expansion on the big hint: See what happens when you try putting too-big argument integers into the parts that include the number 14 in their operation. seriously this is a spoiler: wow didn't think about using ROM, I did 180 with a logic gate instead
|
#
?
Dec 1, 2016 08:03
|
|
|
|
| # ? May 6, 2024 03:50 |
|
|
WhiskeyJuvenile posted:I just started playing this week so I don't remember it Reading simple I/O now clears any value written to it
|
|
#
?
Dec 1, 2016 08:16
|
|
|
GotLag posted:Reading simple I/O now clears any value written to it code follows: teq p0 25 + mov 50 p0 am I on the right track?
|
|
#
?
Dec 1, 2016 08:24
|
|
|
You've got the right amount but you might want to think about where you're putting it. Putting it all on that one wire is going to make it difficult (impossible?) to handle the other cases.
|
|
#
?
Dec 1, 2016 08:32
|
|
|
GotLag posted:You've got the right amount but you might want to think about where you're putting it. yay, got it e: 233 is fastest at 3¥? e2: on to speeding up infrared sensor past 285 WhiskeyJuvenile fucked around with this message at 08:45 on Dec 1, 2016 |
|
#
?
Dec 1, 2016 08:39
|
|
|
What are situations where tcp is useful?
|
|
#
?
Dec 1, 2016 09:47
|
|
|
Mostly when you have exactly three separate cases to consider, you can save a lot of lines of code over doing two tests to catch both halves. It's especially useful when you have data in your registers that you don't want to overwrite, but even if that's not the case it can still save lines of code and let you squeeze everything into fewer/smaller chips.
|
|
#
?
Dec 1, 2016 09:58
|
|
|
It's also useful for disabling both conditional branches.
|
|
#
?
Dec 1, 2016 10:27
|
|
|
Both good things. This game needs to compare your results with others who had the same metrics. Like, you click cost and it compares power and code in the other two and so on. Or am I miss something? edit: code:edit2: I'm an idiot, i've even done this before code:edit: vvv yeah, I have many. Maybe it would have been clearer with no '+' on #do things line. Sorry. Sillybones fucked around with this message at 13:40 on Dec 1, 2016 |
|
#
?
Dec 1, 2016 13:00
|
|
|
code:
|
|
#
?
Dec 1, 2016 13:30
|
|
|
GotLag posted:You've got the right amount but you might want to think about where you're putting it. I FINALLY got this one (signal amplifier in 4/133/3) That cellular scaffold though...none of you are there yet? I only have 3 steam friends that beat brain-computer interface, and Jabor is not one of them. 
|
|
#
?
Dec 2, 2016 03:05
|
|
|
GuavaMoment posted:I FINALLY got this one (signal amplifier in 4/133/3) I'm stuck on the scaffold right now (haven't attempted the interface yet). My first attempt looks like separate chips for each pattern - one chip handles pattern 5, one chip handles 6 (activate both for 4), one chip for 3, one chip for 1+2, one chip for 7+8. One more chip to activate the right things at the right time, and then some more for motor control. I just can't make everything fit though 
|
|
#
?
Dec 2, 2016 03:21
|
|
|
Despite doing the Vape Pen (Cool Dad) and Device 2A27 that come after it with relative ease, I am absolutely hitting the wall with Virtual Reality Buzzer and can't seem to do it. One issue is that while I can definitely check the incoming Xbus number I can't figure out how to keep the pulses going before a 0 comes in and while -999s are coming in. Trying to do this in 1x MC6000 and I don't have gen or @ available yet. Can somebody point me in the right direction? Would keeping a 1 or 0 in dat to denote whether a pulse was previously received and then doing something based on that be a good idea? Edit: Aren't gen and @ supposed to be available upon completing Cool Dad? thehustler fucked around with this message at 15:30 on Dec 2, 2016 |
|
#
?
Dec 2, 2016 14:47
|
|
|
If you already know about them you can just use them.
|
|
#
?
Dec 2, 2016 17:53
|
|
|
Jeffrey of YOSPOS posted:If you already know about them you can just use them. Yeah but I don't want to cheat  Maybe after I do Virtual Reality Buzzer it'll trigger. Maybe they all need to be completed up to a certain point.
|
|
#
?
Dec 2, 2016 19:46
|
|
|
thehustler posted:One issue is that while I can definitely check the incoming Xbus number I can't figure out how to keep the pulses going before a 0 comes in and while -999s are coming in. Llamadeus fucked around with this message at 20:37 on Dec 2, 2016 |
|
#
?
Dec 2, 2016 20:30
|
|
|
Llamadeus posted:There are lots of way to solve this so I'll just say that the non-blocking xbus holds on to values that aren't -999 in following cycles until you actually read from it, which made it a lot easier for me. Also you know about the jmp command right? Aye of course, don't think I'd get this far without it  I think I'm just having trouble laying out the logic for it. Also oooh, interesting...
|
|
#
?
Dec 2, 2016 20:50
|
|
|
thehustler posted:Despite doing the Vape Pen (Cool Dad) and Device 2A27 that come after it with relative ease, I am absolutely hitting the wall with Virtual Reality Buzzer and can't seem to do it. You don't need to save state, at least not in memory. Small hint: When the input is 1, that starts a loop until the input is -999. And remember that gen is just a concise stand-in for more verbose movs+slps.
|
|
#
?
Dec 2, 2016 22:54
|
|
|
Did you solve that god drat kelp harvesting robot yet? I did discover a couple of neat tricks today though. I've been getting a lot of use of out "@ teq 1 1" that Dancer posted a page back. It can be pretty useful to seed your internal test state right at the beginning. Also a neat trick in vape pen - when it comes time to clear your outputs, you could do mov 0 p0 mov 0 p1 Or you could just tcp p0 p1 and not give one single gently caress about the actual comparison. Similarly in sandwich maker, at the end I had 'mov 0 x3' (x3 being a DX300) and then 'gen p0 3 0' for the flag. Instead you can 'gen p0 3 x3' and do both things at once.
|
|
#
?
Dec 3, 2016 07:27
|
|
|
GuavaMoment posted:Did you solve that god drat kelp harvesting robot yet? From what I'm told, this is at least representative of the industry. Still, fuckin lol.
|
|
#
?
Dec 3, 2016 07:43
|
|
|
Shab posted:You don't need to save state, at least not in memory. Small hint: When the input is 1, that starts a loop until the input is -999. And remember that gen is just a concise stand-in for more verbose movs+slps. This might be the biggest hint of all. Are you basically saying that when reading a 1, I can do one pulse, check the next input, and if it's 0 I can dump out of the loop and turn the pulse off and if it's -999 I just cycle to the start of the loop?
|
|
#
?
Dec 3, 2016 12:08
|
|
|
I'm away from my laptop, will this work:code:iPhone codin' That'll be 1 x 6000 Edit: that first line can be tgt instead I guess thehustler fucked around with this message at 15:14 on Dec 3, 2016 |
|
#
?
Dec 3, 2016 14:59
|
|
|
thehustler posted:This might be the biggest hint of all. Are you basically saying that when reading a 1, I can do one pulse, check the next input, and if it's 0 I can dump out of the loop and turn the pulse off and if it's -999 I just cycle to the start of the loop? Pretty much yeah. Think of the 1 and 0 inputs as setting state. Not state as in state saved on a chip, but paths through your code. In that context you can ignore -999 because it just maintains whatever the state is already at (minor exception being the very beginning when it begins in the "0" state without having actually read in a 0). Since 0 state is basically slping until 1, well... Sorry if that hint was too big.
|
|
#
?
Dec 3, 2016 15:46
|
|
|
No, it wasn't really, I was like 90% of the way there, I just struggled with the code order until the hint helped me visualise it Thanks!
|
|
#
?
Dec 3, 2016 15:52
|
|
|
gently caress's sake it doesn't work.
|
|
#
?
Dec 3, 2016 17:01
|
|
|
Success!code:
|
|
#
?
Dec 3, 2016 17:18
|
|
|
I can't believe it took me this long to realize I don't need division for the pollution window puzzle. 
|
|
#
?
Dec 3, 2016 17:26
|
|
|
Working on the token kiosk and this seems too easy. Already got it counting the coins, calculating the change, and ringing the bell for the right amount of time. Now to dispense some coins...
|
|
#
?
Dec 3, 2016 17:32
|
|
|
SupSuper posted:I can't believe it took me this long to realize I don't need division for the pollution window puzzle. In software division has always been the enemy of performance anyway. Re-defining things as additions/shifts/ multiplications saves you a ton of cycles if possible.
|
|
#
?
Dec 3, 2016 18:20
|
|
|
thehustler posted:Success! You can fix this by a lot. You don't need any of those plus signs except for the one on 'mov 0 p1', for example. Notice that you will always get a 1 before you get a 0 in the input stream.
|
|
#
?
Dec 3, 2016 20:24
|
|
|
Oh, I see. I think I copied it from an earlier attempt where they were needed. Edit: that also means goodbye tcp 0 0 to trigger the +'s. Can't believe I let that slip through.
|
|
#
?
Dec 3, 2016 20:39
|
|
|
I really wish there was a mode that would let you at least *run* your solution without the size constraints. having to squeeze everything in while you are getting your head around the problem in the later puzzles is frustrating.
|
|
#
?
Dec 4, 2016 05:52
|
|
|
With security tracking badge is it necessary to use a memory module? or is there a simpler way to desynchronise the sector calculation from sending it?
|
|
#
?
Dec 4, 2016 07:39
|
|
|
norp posted:With security tracking badge is it necessary to use a memory module? or is there a simpler way to desynchronise the sector calculation from sending it? It's a good idea to use a ROM. If you put the proper values into the ROM, you can feed sync directly into it unchanged, then perform a few conditionals on your ping to find the correct sector from the ROM.
|
|
#
?
Dec 4, 2016 08:08
|
|
|
That's a massive hint, i hadn't quite worked that bit out. Now i'm not sure how i'm going to solve having the IC controlling the transmitter handle sleeping during audio but still signalling the other xbus stuff
|
|
#
?
Dec 4, 2016 08:59
|
|
|
norp posted:That's a massive hint, i hadn't quite worked that bit out. Nothing happens during audio, only audio.
|
|
#
?
Dec 4, 2016 15:46
|
|
|
Gah I'm so close to doing Remote Kill Switch. I can turn on and off individual motors in response to input, http://imgur.com/a/rq4i6 All I need is one more register to hold the current state. So I went with this: http://imgur.com/a/dS446 But reading from x2 when an input is on just returns 0. Is the issue that I can't read the status back because the I/O expander is connected to outputs, not inputs? I thought I could query the current state of it? thehustler fucked around with this message at 17:16 on Dec 4, 2016 |
|
#
?
Dec 4, 2016 17:12
|
|
|
The IO expander is slightly simplified so it can't hold state. So if you drive the xbus side, the simple side starts broadcasting but only the simple side. If you drive the simple side, the xbus side starts broadcasting non-blocking style. I haven't actually tried driving both at once to see what happens.
|
|
#
?
Dec 4, 2016 17:19
|
|
|
So any resolution will require a major reworking unless I can find space (either a register or another chip or something) to hold the current state. But then it would need to run every tick and not every chip does. Gah!
|
|
#
?
Dec 4, 2016 17:26
|
|
|
|
| # ? May 6, 2024 03:50 |
|
|
It seems reading on the xbus side clears the IO expander's previous xbus input which means you can stick a not gate on the end and make a volatile flipflop that reinitializes after reading. I bet that's useful... somewhere?
|
|
#
?
Dec 4, 2016 17:30
|
|