|
SLX only exists to lull you into a false sense of security.
|
#
?
Nov 23, 2016 00:08
|
|
|
|
| # ? Jun 10, 2024 12:20 |
|
|
Sometimes when faced with a problem, you think "I know, I'll use SLX." Now you have two problems.
|
|
#
?
Nov 23, 2016 08:05
|
|
|
I've been banging my head against Safetynet Tracking Badge for hours and it's kicking my rear end. It feels like there are way too many special cases to make anything even close to efficient for calculating the badge's location. With the speaker logic taking up half the space in the puzzle, I'm not sure how I can fit enough MCs for the location tracking logic. EDIT: The answer is to use a ROM, isn't it? It always comes to you the second after you ask for help 
TheOneAndOnlyT fucked around with this message at 09:40 on Nov 23, 2016 |
|
#
?
Nov 23, 2016 09:31
|
|
|
TheOneAndOnlyT posted:I've been banging my head against Safetynet Tracking Badge for hours and it's kicking my rear end. It feels like there are way too many special cases to make anything even close to efficient for calculating the badge's location. With the speaker logic taking up half the space in the puzzle, I'm not sure how I can fit enough MCs for the location tracking logic. It can be solved without your spoilered technique, but using that is definitely simpler. Keep the modulo division property of the address lines in mind. But the audio playback part can be solved with a single MC6000. The radio RX buffers the data so you don't have to store it. Also there will be no location requests while playing out the audio.
|
|
#
?
Nov 23, 2016 10:55
|
|
|
Sometimes I wonder if the good power-use solutions I come up with are even close to other people's solutions. I just got down to 293 power on precision food scale but my final optimization was one that took me all the way from ~307 or something to 293, and I have no idea what sort of optimization would get you to a stopping point while still being under 300. Either it's a slightly worse version of mine, which would be okay, or its a completely different optimization, which would mean possibly combining them to get a crazy-good solution.
|
|
#
?
Nov 23, 2016 17:09
|
|
|
|
|
#
?
Nov 24, 2016 01:23
|
|
|
This game makes you pull the weirdest programming tricks. Here's my solution for Aquaponics Maintenance Robot Observe that pair of "teq 1 1" lines in the middle component. They are crucial to the part functioning properly  .
|
|
#
?
Nov 25, 2016 02:23
|
|
|
Unless there's a timing issue, I think you really only need the - side...
|
|
#
?
Nov 25, 2016 02:33
|
|
|
you should be able to skip the + teq 1 1 line, because it activates + lines if (and only if) + lines are already active.
|
|
#
?
Nov 25, 2016 02:34
|
|
|
Bonfire Lit posted:you should be able to skip the + teq 1 1 line, because it activates + lines if (and only if) + lines are already active. D'oh ! Yeah okay, you're entirely right. The addition of those lines was part of a mission to shorten the code on that chip to fit in just one extra line, and when I managed to do that I was so happy (and tickled by the idea of what I had just done) that I stopped thinking of further improvements.(edit: to explain, previously all those commands below "teq 1 1" were on both the + and - branches, and I couldn't take them out because they genuinely needed to be disabled when the motor had finished moving. No longer doubling up 3 commands, and adding the 2 "teq 1 1" meant saving one line which was all I needed) Dancer fucked around with this message at 02:40 on Nov 25, 2016 |
|
#
?
Nov 25, 2016 02:37
|
|
|
OK. Harvesting Robot. Let's try small baby steps to make this game fun again. My first questions: -Can I assume that in later test cases we'll get harvest locations at one of the coordinates being zero? -Are there any cases where you don't have anything to harvest and need to just sit still? I'm not out of ideas yet, I just want to know how deep the rabbit hole goes. And if I can cram 3 more MC6000s in there with me.
|
|
#
?
Nov 26, 2016 07:12
|
|
|
"Yes" and "Yes". Though AFAIK you never need to harvest (0, 0).
|
|
#
?
Nov 26, 2016 07:49
|
|
|
homeless snail posted:The circuit stuff is all abstracted bullshit though It's not that abstract 
|
|
#
?
Nov 26, 2016 08:34
|
|
|
Yeah I mean, synchronous buses and analog signals are real things...
|
|
#
?
Nov 27, 2016 03:36
|
|
|
Jeffrey of YOSPOS posted:Yeah I mean, synchronous buses and analog signals are real things...
|
|
#
?
Nov 27, 2016 04:39
|
|
|
Its close enough to life if you assume the traces are stand ins for a ring architecture. I don't know if you would trace rings like that on a circuit board unless absolutely necessary but its analogous to some real life wired architectures for different ways to network controllers.
|
|
#
?
Nov 27, 2016 20:50
|
|
|
How would you implement something like the XBus even? I'm thinking a ground, "ready to send", "ready to receive", a clock line, and a data line. Before attempting to set ready to send/receive high, you check if someone else has it high and back off. Since only one device can send and only one receive at a time, there needs to be some race condition resolution protocol, perhaps a kind of recipient sends a short, unique message out and sender has to echo it, if it comes back garbled, sender and receiver have to back off a random amount and start over. After resolving race conditions the sender can send the message. The magic non-blocking components would probably work by never setting their send or receive line high until they sense the other line being set, that way they don't end up talking to each other. I think that would work? (The MCx000 developers are assholes for not including TRS and TRR instructions, for "test ready send" and "test ready receive".)
|
|
#
?
Nov 27, 2016 21:16
|
|
|
I used to imagine it like an unaddressed ring. Idle state you repeat anything you get to next in line. Write you send a packet every clock cycle until you receive an ack. Read you wait to receive a packet at which point you broadcast an ack and repeat any acks you receive while waiting. Blocking components on write hang on receiving an ack, blocking components on read hang on waiting for data, non blocking just send stuff out every clock cycle. In exchange for a slightly insane sync requirement, you get low overhead lost packet correction. Of course the non determined read order sort of sinks that protocol. e. Also I guess non blocking components need a garbage collection terminating function which I would argue still flies in universe because its sort of rare and thus implied complicated. ee. I can't help myself from keeping on specifying. Write doesn't need to rebroadcast unless it catches its own packet so if the packet has a simple device ID it can tell if someone is listening or not by just rebroadcasting instead of reading its own packet. Same hanging behavior without the ring filling with repeated garbage. Can also specify behavior where memory doesn't read from non blocking components as well if non blocking components had a specific prefix in their id. zedprime fucked around with this message at 00:32 on Nov 28, 2016 |
|
#
?
Nov 28, 2016 00:21
|
|
|
Hey, just so you guys know, in test 17 of Aquatic Harvesting Robot, the first coordinate to harvest is at 9,9. Why yes, this the one and ONLY case that breaks my solution. No, I don't know how to fix it. gently caress  Though in good news I did discover that if you have a one or two digit number that you need to be positive, the best way to do it is with one command: dst 2 0 GuavaMoment fucked around with this message at 07:39 on Nov 28, 2016 |
|
#
?
Nov 28, 2016 05:04
|
|
|
GuavaMoment posted:Though in good news I did discover that if you have a one or two digit number that to need to be positive, the best way to do it is with one command: dst 2 0  If you knew how many times I had to redo everything due to being one line short... (Seriously, thanks. That's seriously useful.)
|
|
#
?
Nov 28, 2016 05:24
|
|
|
Jabor posted:(Seriously, thanks. That's seriously useful.) No problem. I did solve that harvest robot though! And then I had ten extra minutes to spare, so I figured I might as well bang out the #1 solution on my leaderboards for thorium reactor display. Fix your difficultly curve, Zach.
|
|
#
?
Nov 28, 2016 07:41
|
|
|
Jabor posted:
Let me get this straight... setting the hundreds digit of acc to 0 also makes it positive?? Is that a bug I wonder
|
|
#
?
Nov 29, 2016 10:29
|
|
|
bobbilljim posted:Let me get this straight... setting the hundreds digit of acc to 0 also makes it positive?? Is that a bug I wonder I think it's just undocumented side effects of the DST instruction.
|
|
#
?
Nov 29, 2016 11:11
|
|
|
nielsm posted:I think it's just undocumented side effects of the DST instruction. Yeah, my read is that it exposes that numbers in Shenzhen act like signed ints. The first (or last) bit stores the sign with 1 being negative and 0 being positive.
|
|
#
?
Nov 29, 2016 15:34
|
|
|
Shab posted:Yeah, my read is that it exposes that numbers in Shenzhen act like signed ints. The first (or last) bit stores the sign with 1 being negative and 0 being positive. Not really, DST always sets the sign bit of the destination to match that of the source, even if it doesn't change the destination otherwise. dst 2 -9 add 900 That sequence should force acc to be a negative number between -99 and 0.
|
|
#
?
Nov 29, 2016 15:52
|
|
|
nielsm posted:Not really, DST always sets the sign bit of the destination to match that of the source, even if it doesn't change the destination otherwise. Oh that's interesting. I'll have to play around with that, seems like it could be useful for some solutions.
|
|
#
?
Nov 29, 2016 15:57
|
|
|
Steam workshop integration is released. Make your own puzzles (with a bit of lua scripting to define inputs/outputs). Here's something quick I put together: http://steamcommunity.com/sharedfiles/filedetails/?id=809346938
|
|
#
?
Nov 30, 2016 11:35
|
|
|
Can I get some help with Unknown Optimization Device please? I am so, so close. Here's what I have: http://imgur.com/a/Io3ZI I am so, so close. There's an edge case where X=40 which screws up my TCP in the first MC4000. It's my mistake, i totally forgot that if TCP equals something it disables all + and - after it. So the test fails there and 50 never gets sent on to the second CPU. I can get through the entire sim run up until page 4 and it's pissing me off. Any tips? is that first CPU savable or do I need to completely overhaul everything? I will have no problems swapping it out for a 6000 if I need to, I don't care at this point. Edit: hahaha is this randomised data like some of the TIS-100 puzzles? I just replaced the MC4000 with a MC6000 to prepare for code modification and when I ran it it passed. Oh well. Still, anybody got any ideas how I could slightly improve what I already had? No massive overhauls, that's for later. thehustler fucked around with this message at 23:51 on Nov 30, 2016 |
|
#
?
Nov 30, 2016 23:45
|
|
|
Why use tcp instead of tgt? Shouldn't that drop in cover the case you're after? Sorry I forget the exact bounds in the spec, but if you want greater than or equal to, you can use tgt p1 39. The urge to optimize people's posted solutions is...strong. Jeffrey of YOSPOS fucked around with this message at 23:51 on Nov 30, 2016 |
|
#
?
Nov 30, 2016 23:48
|
|
|
Jeffrey of YOSPOS posted:Why use tcp instead of tgt? Shouldn't that drop in cover the case you're after? Sorry I forget the exact bounds in the spec, but if you want greater than or equal to, you can use tgt p1 39. Tried that, didn't always work. Probably triggers another edge case somewhere else I guess?
|
|
#
?
Nov 30, 2016 23:53
|
|
|
thehustler posted:Tried that, didn't always work. Probably triggers another edge case somewhere else I guess? Make sure you're being careful with greater than vs greater than or equal to - I'd have to look in the manual to be sure, but they will test those cases.
|
|
#
?
Nov 30, 2016 23:55
|
|
|
Jeffrey of YOSPOS posted:Make sure you're being careful with greater than vs greater than or equal to - I'd have to look in the manual to be sure, but they will test those cases. I'll make sure to go back and make sure it works properly, but I've just cracked the Vape Pen in 10 minutes. That's ridiculous. Using the same trick from TIS-100 of sending an output to multiple inputs one after the other turns out to be the key. Lots of SLXs until you actually get the data you want.
|
|
#
?
Dec 1, 2016 00:36
|
|
|
tgt p1 39 should work there, since it what's I've got in my solution (627 power, a rare better-than-average solution by me~)
Llamadeus fucked around with this message at 01:30 on Dec 1, 2016 |
|
#
?
Dec 1, 2016 01:05
|
|
|
I am at the point where I would appreciate help for cellular scaffold. My motors work. My psi valve works. I could use some help compressing the alpha and beta valve outputs into, well a single digit would be nice. That's a lot of data that needs compressing, AND it needs to run backwards every other time. I can give the xbus number to the alpha and beta chips at the right time, but don't know what to do with it.Jabor posted:Here's something quick I put together: I like this one a lot. It's harder than the challenge it's based off of, but is still quite manageable, and has multiple routes you can attack it from. Did you just take the input/output series from the original and reverse them for this?
|
|
#
?
Dec 1, 2016 06:04
|
|
|
GuavaMoment posted:I like this one a lot. It's harder than the challenge it's based off of, but is still quite manageable, and has multiple routes you can attack it from. Did you just take the input/output series from the original and reverse them for this? Thanks! It's surprisingly difficult to use pregenerated inputs and outputs if you want them to vary across runs - as far as I know, you don't actually get told which run you're generating, you just get a differently-seeded RNG for each one. I took the lowest-effort way of generating a random number that you'll be expected to output, and then computing the input that you'd get. I guess it might coincidentally line up with the original puzzle if the rng is seeded the same way across puzzles.
|
|
#
?
Dec 1, 2016 06:56
|
|
|
so I have the 3/180 solution to control signal amplifier but I think there's a 3/130-ish solution floating around and I'm really close but I can't quite get it because there isn't enough space to wire properly
|
|
#
?
Dec 1, 2016 07:40
|
|
|
GuavaMoment posted:
Giant hint: the documentation for slp is slp R/I
|
|
#
?
Dec 1, 2016 07:45
|
|
|
GuavaMoment posted:Big hint: Those three numbers mod 14 are 0, 11 and 8 I really don't get it
|
|
#
?
Dec 1, 2016 07:49
|
|
|
GotLag posted:Consider the behaviour change to simple I/O introduced a month ago I just started playing this week so I don't remember it
|
|
#
?
Dec 1, 2016 07:54
|
|
|
|
| # ? Jun 10, 2024 12:20 |
|
|
WhiskeyJuvenile posted:I really don't get it 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.
|
|
#
?
Dec 1, 2016 07:55
|
|
