It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Not interested in the game, but just letting you know that I tried it. Got past step 1. Had trouble even finding online compilers. Might have gotten a single digit output at one point (but I moved on before your announcement about compiler choices) and going back couldn't remember what I had tried and could not repeat it/find it again.

Or in other words, I did try to solve it, but got stuck. Spent enough time at it anyway.

Eagerly awaiting the solution.
The code has been sent to and redeemed by te_lanus.

This means that there is no longer a game prize for solving this, however the much greater prize of "Yes! I got it!" feeling still remains.

Unfortunately I'll have to wait with posting the solution, since I want to give you a more detailed analysis of this one, and I'm slightly busy in the coming few days.
Looking forward to the solution revealed. I gave up at a point where I felt all I was doing was blindly groping around in the dark.

Anyway, I learned something, which I'm happy about. Sat down and stitched the following together; all I wanna say is this:

++++>++++++++[<++++++++++>-]<.>+++++[<++++>-]<.-------.+++++++++++++.---.>++[<++
++>-]<.->++++++++++[<------->-]<.------------.>+++++++++[>++++++++++<-]>.<+++ +++
++++[>--<-]>.++++++++++++.<<+.
Sorry, but a busy weekend evolved into a busy week. Please wait a bit before I post the solution. In the meantime, you're welcome to continue solving.
This has been postponed long enough. Sorry, guys. Really busy these days. Solution is up in post 1.

Now for the discussion.

First, here is the reason I thought this would be easiest. When I made the "Soon..." post, I only had a general idea in my head. Brainfuck tells you to use another language, and have ROT13 hidden in memory. Befunge gives you half of the answer, and gives you the other half after running the ROT13 on the code first.

This seemed easy, because essentially I was just re-using ideas from the first two challenges. There was nothing new here. I used memory-hiding in both of them. And used befunge in the last one. I figured someone will run code, run it in befunge, check memory, immediately figure out ROT13 and then get the other half.

As an extra challenge for myself, I thought I'd do it without any letters or numbers, except in the first line. This would make it slightly more difficult for those solving it to spot that ROT13 should be applied on the text itself (since it only changes the first line). And it might have made some of them do the mistake of not realizing the first line is part of the code. Also the coincidence that the ROT13 of "v" is "i" and they appear next to each other in "Giveaway" was too good to be missed.

Anyway, since I was not using any numbers or letters, the only way to get an output was to make use of the fact, that in befunge, popping an empty stack is not an error, but simply outputs a 0. So for example, in order to output a number you had to pop an empty stack to get a 0, apply logical NOT on it to get a 1 and then work from there. You could for example, duplicate 1 and add it to get 2. Duplicate 2 and multiply it to get a 4. Create 1 and add it to get 5... etc.

And this is where we come to the first interpreter problem. While most worked correctly, some of them would NOT output a 0 when popping an empty stack. Even though the documentation clearly states that that should be the case (and most interpreters follow that). This means, that there are some interpreters out there which wouldn't run my code in befunge, even before applying ROT13 on it.

It also created another unforseen issue. My original plan was that the befunge outputs a hexadecimal code like so "3AA78-A26A1". So you see it and you immediately know that it's half of the code and you have to find the other half. Unfortunately, given the way I was outputting numbers as described above, it would have taken long time to get to ASCII 65 to print those letters, so I decided to simply convert them to numbers. "3 10 10 7 8 10 2 6 10 1".
Some people on getting those numbers didn't realize it's just the hexadecimal code. It was never my intention to get you confused. This is also why I highlighted "hexadecimal" in my original post.

The second problem only appears after applying ROT13 and arises from the way interpreters handle "i". The idea is that the pointer should hit "i", reverse direction, and hit the "v" before it. Funge 98 specifies that it's for inputting files, and if that fails to reverse the flow. In fact, any error or any unknown letter should reverse the flow. Unfortunately, very few of the online interpreters available do this correctly. I don't expect them to do file input, but the flow reversal should have been done.
Ironically the only interpreter which does this properly, is a befunge one and not a Funge-98 one.
http://www.quirkster.com/iano/js/befunge.html

You have to copy code, then click "Show", then click "Run". Which might not be intuitive either.
But this interpreter does reverse the flow on hitting any unknown character, and it doesn't care about the rows limit for befunge, so it runs the code correctly.

Other Funge-98 that work properly are:
https://github.com/Deewiant/CCBI
https://github.com/tngreene/BefungeSharp
(both have to be downloaded). Generally most of the ones that have to be downloaded but which state they are fully conforming should work.

And one more thing. A lot of the code if just junk brainfuck code, that I included because I needed the lines to run the befunge code. Initially, my limitation not to use letters meant that from the first line befunge had to go only downwards, because if I go sideways I won't be able to use "v" to go down again. This had a side effect of creating more lines that befunge should handle, so this was another indication that it's Funge-98.
Later I realized that the pipe character "|" can conditionally redirect downwards, and this helped me create my more compact version.

Also, the whole code contains only one period, placed in "GOG.COM" that is used to output all brainfuck and all funge-98 code.

avatar
yogsloth:
avatar
supplementscene: If OP or the puzzle solver could PM the solution at some stage that would be appreciated, thanks.
avatar
Gede: I would like to see your code working, so if you would point some on-line interpreter that can run it, it would be swell. I tried the first half-dozen I could find, but with no success.
avatar
RWarehall: Eagerly awaiting the solution.
avatar
chevkoch: Looking forward to the solution revealed.
Replying to people who wanted to see the solution, so they get a notifications. In case they gave up on this and forgot about it.
Post edited February 14, 2017 by ZFR
avatar
ZFR: This seemed easy
...

avatar
ZFR: Hopelessly labyrinthine and esoteric amalgamation of cruelly impenetrable solution steps
...

...

faaaaaaaaaaaaaaaaaaaaart
Post edited February 14, 2017 by yogsloth
There were a few things that caught me out and made this more difficult for me.

First was that I was actually expecting something different (language wise), particularly when I tried Befunge and got the first sequence of numbers but assumed it was random noise rather than anything deliberate.

So I spent ages looking for languages that used the non Brainfuck characters (things like the ? and %) assuming they were a second lot of code hidden amongst the more recognisable Brainfuck.

My second flaw, which was probably the fatal one, is that I didn't actually know what ROT13 was so didn't recognise that as a clue, again I just assumed it was random noise at the end of the Try.Another.Language message.
I only got it with enough prompting from ZFR that I googled ROT13 and realised what I had been missing.
avatar
ZFR: This seemed easy, because essentially I was just re-using ideas from the first two challenges. There was nothing new here. I used memory-hiding in both of them. And used befunge in the last one. I figured someone will run code, run it in befunge, check memory, immediately figure out ROT13 and then get the other half.
I ran into two problems here. Checking the memory locations came natural, as I remembered you had done the same thing in an earlier puzzle. However, since you didn't encode the number 13 as ASCII characters, but just as the byte value 13, it was not immediately obvious. It was made even less obvious by the fact that ASCII character 13 is Carriage Return, and so marks the end of a line, and since it was the last byte in the changed memory...

My second problem stemmed simply from the fact that I had never heard of ROT13, so it didn't mean anything to me.
avatar
ZFR: As an extra challenge for myself, I thought I'd do it without any letters or numbers, except in the first line. This would make it slightly more difficult for those solving it to spot that ROT13 should be applied on the text itself (since it only changes the first line). And it might have made some of them do the mistake of not realizing the first line is part of the code. Also the coincidence that the ROT13 of "v" is "i" and they appear next to each other in "Giveaway" was too good to be missed.
Yes, I thought that bit was very elegant. Another detail I enjoyed was precisely that they were next to each other, while all the other letters were separated by hashtags. Combined with the fact that the first line was one character shorter than the others, it looked like a simple typing mistake. However, knowing you and your attention to detail in these things, I knew it had to be deliberate, and so for me it shone a big fat spotlight on that "v", making it an obvious starting point for the Befunge code.
avatar
ZFR: It also created another unforseen issue. My original plan was that the befunge outputs a hexadecimal code like so "3AA78-A26A1". So you see it and you immediately know that it's half of the code and you have to find the other half. Unfortunately, given the way I was outputting numbers as described above, it would have taken long time to get to ASCII 65 to print those letters, so I decided to simply convert them to numbers. "3 10 10 7 8 10 2 6 10 1".
Some people on getting those numbers didn't realize it's just the hexadecimal code. It was never my intention to get you confused. This is also why I highlighted "hexadecimal" in my original post.
Another reason for confusion at this point is that some interpreters don't output any spaces between the numbers, meaning that the output they deliver is simply 31010781026101.
avatar
ZFR: * lengthy discussion about technical details of Funge-98 *
The problem here was that the Wikipedia entry that you have by now made us used to being the go-to place to look for information for these languages, is almost completely useless in this case. It does mention in passing that a 98 specification exists, but gives no examples of neither code nor syntax. There's a link to the specification at the bottom of the page (and the specification isn't very good, to be honest), but the Befunge Wikipedia page itself is all about the 93 version. As such, figuring out that the code was actually Funge-98 and not 93 required... Well, it required you telling me, as far as I remember ;-)
avatar
ZFR: Also, the whole code contains only one period, placed in "GOG.COM" that is used to output all brainfuck and all funge-98 code.
This was also very elegant :-)

Additionally, the whole idea of interleaving Brainfuck and Befunge code was also very clever, and made possible by the fact that both languages simply ignore any character not a part of their own syntax.

All in all, I think the puzzle was awesome. I hope you will continue to make them in the future. I do enjoy solving them :-)
Oh, I'm feeling a bit dumb. Even with all this exposition it still took me some time to get the ROT13 part.
I mean, I know ROT13, but I don't know by heart what translates into what, and in particular, that I turns into a V.

This was too clever in the puzzley part, and too amazing from the code part. I mean, like in Clarke's third law, but applied to code. I don't have much of a frame of reference anymore (well, the past puzzles helped a bit), and too little free time to try this and that. :-(

Sorry I was not up to the challenge, ZFR.
Thanks for posting the solution, I was about to poke you via chat about it :)

The main obstacle for me was that I fixated on getting the full 20 character code in one output (the way you worded it in the OP, I never questioned my initial assumption and didn't realize that it could be split up into parts). The next mistake I made was dumping the first ten numbers off Brainfuck into a decimal/hex converter as a whole and not each number separately, which I should have realized.

With a lot of help, I found the reference to rot in memory, but I am not a coder, so the 13 part eluded me. And even with more help getting to that point, I gave up in the end since whichever way I played around with rot13, I always expected to get a 20 character output, so anything other than that I discarded.

Like I mentioned before, I enjoyed this puzzle, particularly because I learned some stuff. Went through the Brainfuck part of your code step by step and it was fun to see how it worked/you'd constructed it. Thanks for the occasion!
Post edited February 14, 2017 by chevkoch
And finally, I'd like to thank everyone who has taken part.

My intention is always to get more people interested in esoteric languages in general, and brainfuck in particular. I'm happy that in this regard, the giveaway was successful since, again, some of the people who took part in this were dealing with brainfuck for the first time.

It's a really cool language. Contrary to what it seems, it need NOT produce obfuscated code. Quite the opposite in fact. The fact that you can write comments anywhere means you can create a very neat, well-organized program.
For example, you could substitute the commands as follows:

+INC -DEC >RIGHT <LEFT ,IN .OUT
and the code would still work

You can put text to explain your work every step of the way, pointing out exactly where your pointer is and what you're doing... etc.

And I would like to emphasize, that you don't have to be a coder/programmer to get into it. Quite the opposite; it could be a good starting point to get you into programming.

In fact, I have always been of the opinion that the usual order of teaching programming should be changed.

Usually in schools nowadays, students are first taught a simple high-level language, then more complex ones, and only later, if ever, are they taught assembly programming. And when they do, it's a "real" assembly language and it is taught in a way that assumes students are already familiar with higher level languages, and with concepts like binary mathematics... etc.

I think that kids who display interest in maths, coding and such, should begin learning at a much younger age; primary school in fact. And start with a low level language; only instead of taking a real assembly language, just make up one with 10 or so basic instructions only (input, output, add, subtract, conditional jump... etc). Let it be stack based (like befunge), tape based (like brainfuck), accumulator based like an assembly language, or even something like a Turing machine. Also, it would be helpful if there is graphical animation, so the kids can actually see how when their program runs, the pointers move, numbers get into accumulator and get added up... etc.
High level language can be taught later, and real assembly language will become much easier if you are familiar with basic stuff. In this regard, brainfuck is perfect for kids (apart from the name...).
Post edited February 15, 2017 by ZFR
avatar
Gede: Oh, I'm feeling a bit dumb. Even with all this exposition it still took me some time to get the ROT13 part.
I mean, I know ROT13, but I don't know by heart what translates into what, and in particular, that I turns into a V.

This was too clever in the puzzley part, and too amazing from the code part. I mean, like in Clarke's third law, but applied to code. I don't have much of a frame of reference anymore (well, the past puzzles helped a bit), and too little free time to try this and that. :-(

Sorry I was not up to the challenge, ZFR.
Maybe we can team up next time, Gede, sort of two semi-coherent thoughts make a whole ;)
Thanks for the solution! I'm actually quite happy I wasn't totally off the chart stupid, I managed to get at least some parts right. I think the main problem for me was that I didn't really get results that indicated that I was on the right track whatsoever. I know I tried Befunge at some point, but that didn't seem right, so, like Adaliabooks I went on to check out all kinds of languages that made use of the non-brainfuck characters (but never really got anything but garble).
Which was around the time I figured out this was way over my head since I really don't know my way around in the esoteric language world ;)
I know I used hex conversion at some point, but I missed the Rot 13 hint, which really is a shame since I actually should be familiar with that one...
Still, very interesting challenge! In hindsight, it doesn't look that difficult, even ;)
Post edited February 15, 2017 by WildHobgoblin
avatar
ZFR: [...] In this regard, brainfuck is perfect for kids (apart from the name...).
You could always write it like this: b***nfuck.

Ages ago, I played around with BASIC on the C64. Messing with Brainfuck was really fun and got me a step closer motivation-wise to teaching myself some Python, which I've been thinking about for a while.
Why would the name be a problem? If it wasn't for (some) grown ups, it would just be another word. But that's for a different debate.

What I do have a problem with is "[T]he idea is that the pointer should hit "i", reverse direction, and hit the "v" before it." I cannot find any information on this; that is, I couldn't find anything about this following the links to the respective specifications at the bottom of https://en.wikipedia.org/wiki/Befunge (except for the input file instruction). Where should I have looked instead?

On the positive side, this give away did make me write a rudimentary brainfuck interpreter in Python. Since it took me while to realize that a program needs some form of memorystack and there may be traces left after completing the code, combined with the fact that the online interpreter that I found - brainfuck.tk - worked perfectly except from dumping the memory after running the code, I figured I may as well write one myself. Only 8 instructions in brainfuck; how difficult could that be? Turns out, a little more difficult than I thought.
Well, it works, but not flawlessly. Must be something with my '[' and ']' routines. It prints out the memory dump both as integers and as text - uncovering '&rot' was really helpfull here - even without regarding the '13' I found/realized a few seconds later. Funny thing; the code from the previous giveaway did not return 'white ' but 'xddnd' (or rather [120, 100, 100, 110, 100, 30, 0]). Close, but not the same... ;)

The last part was more of a thought experiment; ROT13 only working on ascii characters, would not tamper with the #-signs so maybe it would give me another entry point for the Befunge code. But running down the alphabet in my mind I ended up with an 'i' and that instruction - I thought - had to do with inputting a file. I never bothered to run the ROT13'ed code anyway, until I just read your hints and your explanation... Even befunge is a brainfuck!

Thanks for the challenge anyway!

edit: brainfuck.tk does not redirect anymore - changed href/url
Post edited February 15, 2017 by Namxas01
avatar
Namxas01: What I do have a problem with is "[T]he idea is that the pointer should hit "i", reverse direction, and hit the "v" before it." I cannot find any information on this; that is, I couldn't find anything about this following the links to the respective specifications at the bottom of https://en.wikipedia.org/wiki/Befunge (except for the input file instruction). Where should I have looked instead?
From the Funge-98 specification.
http://quadium.net/funge/spec98.html

Under File Input/Output:
i pops a null-terminated 0"gnirts" string for the filename, followed by a flags cell, then a vector Va telling it where to operate. If the file can be opened for reading, it is inserted into Funge-Space at Va, and immediately closed. Two vectors are then pushed onto the stack, Va and Vb, suitable arguments to a corresponding o instruction. If the file open failed, the instruction acts like r.

Under Instructions:
Also, any of the instructions t (concurrent execution,) = (execute,) i (input-file,) and o (output-file) may be unavailable in different interpreters for many reasons, and are routinely bound to (i.e. act just like) r as well. However, they may also act like r when they fail to execute. To test if they are actually supported, execute 1y and examine the cell it produces.

"r" is the Reverse instruction

If you download any of the fully conforming interpreters, like the two I linked to in the post above, you will notice that it does behave this way.


avatar
Namxas01: combined with the fact that the online interpreter that I found - brainfuck.tk - worked perfectly except from dumping the memory after running the code,
Try this one.
https://copy.sh/brainfuck/

It has built in memory dumping.
Post edited February 15, 2017 by ZFR