At least my solution seems to be unique... right?

Posted Jul 17, 2016, 1:25 AM UTC

Posted Jul 17, 2016, 1:25 AM UTC
Just wait till you get to that one problem when you take 6 hours bodging together a solution that eats up every single node and 90% of each line. It will be then when you are willing to hear the message of our lord and savoir, efficiency be his name
I wonder if I still have my pre-jro-enlightenment image puzzle 3 solution that was a brute
So just what is the benefit of the JRO instruction? I knew when I saw it in the manual that it had some potential, but I haven't been able to find any use for it. I'm now getting into the more difficult puzzles (>50% through the game) and I haven't used JRO yet.
Do you mind explaining what the advantage of it is?
"jro left" is a way to conditionally jump while still holding a value
Its a way to change a value on a different node
Its a way to have the node go in a condictional loop that can't be synced without outside help
"jro left" is a way to conditionally jump while still holding a value
This is game changing for me. The manual only showed examples with 0, -1, 2, and ACC, so it never occurred to me that it would work with other sources, and I dismissed the instruction as mostly useless.
I think that was intentional
JRO is one of the most useful instructions in my opinion. Basically, it allows you to create subroutines. You can start your node with:
JRO LEFT
Then your other node can feed numbers to it to jump to routines. For example:
JRO LEFT
MOV LEFT ACC
MOV ACC LEFT
MOV ACC LEFT
JRO -999
MOV LEFT LEFT
Now I can send 1 to this node to duplicate, or 5 to just send back my value.
And now I've learned that you can send a value from a node back to it without necessarily resulting in a deadlock. Thanks for the (unintentional?) additional insight.
I guess I can see the value, but I'm not sure I'd be comfortable with how ambiguous and unreadable I fear my code might become.
tis-100 is a game about assembly, and not even good assembly. it's a game about horrible hacks making a piece of shit, half broken terminal do the impossible.
if your code is readable you're playing it wrong :)
I always make sure to dedicate half of my nodes for unit testing, and let me tell you, this game is really difficult.
You can use comments (#<COMMENT>) and labels to help organize your JROs. I used to have a problem with organization as well, but I started really forcing myself to comment anything ambiguous and it really helped.
Maybe that approach will help you in a later problem by giving you an insight nobody else has had yet.
It most likely won't do anything of the sort, but even the naively-optimistic are correct every once in a great while.
http://www.motivateusnot.com/resize.php?name=LzM3OC9VbmlxdWUtSnVzdC1iZWNhdXNlLXlvdS1hcmUtdW5pcXVlLWRvZXMtbm90LW1lYW4teW91LWFyZS11c2VmdWwuanBn&w=550&h=9999&extension=.jpg