unforum

[Nighthawk]

OK then, they invited a programmer... guess I better act like one.

The Flash file adds the ASCII values of the input to generate a "seed", and it does it pretty plainly...

[KookieB]

Ok yeah I didn't think I should... I am still trying to crack the code as well. I think you are right Bruce, in that the numbers will have meaning. Maybe there will be a big clue on the show tonight?

ALSO... any sequence you try, be sure to try it leaving the sixth value off. Maybe since Mike talked about the sequence guessing the next value, that is the key? Just a thought.

[thebruce]

Nighthawk, that's a more concise explanation than mine, good work

yes, for creating the diagram, order of characters doesn't matter, but order of input values does, because the seed is based on the values of characters entered, whatever they may be, which removes necessity for order per field.

But yes, I neglected to make the point that the strings as entered are sent to the PHP checker which returns a right or wrong. So while the diagram may appear right, if the strings aren't what is required for the answer, it'll still say you're wrong.

[MrToasty]

So, from my last post does that give us the numerical totals for each entry at least?

[thebruce]

you know what, it looks like it is the right diagram...

[Nighthawk]

Well, it looks like the right diagram, but we don't know if that's the right ANSWER to begin with. Could have been Mike screwing with it in the same way you did.

Maybe we're not looking for an exact match to the drawing. I do know one thing: the "unexpected cascade" error is the Flash's response to a "no" from the server, and sometimes you actually have to wait for that response before the glyph even draws; the server does not provide a visual representation, the Flash client does that ahead of the server response.

[thebruce]

yes, when the check returns 'yes', we'll definitely have the right diagram. But not necessarily vice versa.


And to note - the diagram only appears correct when the letters for one through six are all in lower case. The letters can be in any order for each word, but they need to be lower case, and entered one through six in order.


I also just tested variant letters (+/- one for each pair)
PME
UVO
UGRFD
GNVQ
GHWD
THX

and it does also return the same diagram...


ETA: also, the character based just on the last entry field, because that's the last seed that was used for random generation.

[MrToasty]

[thebruce]

and see, the other problem is - if we change the string, it's not alphanumeric values that it uses, but -ascii- values of the characters... so even one or two characters different in length would throw off the seed dramatically (A is 65 for instance, not 1, so adding an A means balancing another character by removing 65 from its ascii value)

changing an E to an F is different however, because it's only 1 difference, so removing 1 from another character is fine.

So it seems that the diagram is built on the ascii sums of the lowercase characters that form "one" through "six" in order, and most likely with the same numbers of characters in each accordingly.

[Nighthawk]

OK, if you want to further reverse engineer that, here are the sums of those values:

"one" = 0x0142 = 322
"two" = 0x015A = 346
"three" = 0x0218 = 536
"four" = 0x01BC = 444
"five" = 0x01AA = 426
"six" = 0x0154 = 340

Again, I don't think that's the answer.

Basically, we have to ignore what it draws and focus on the result that makes sense and "clicks".

[thebruce]

ok, so here's an example...

"one" = 111+110+101 (ascii values) = 322
so in theory, any set of ascii characters adding to 322 should produce the same slice pattern.
"0" through "9" are ascii values 48 through 57

if we assume a gps location, at the very least 8 digits (eg, "37.947057" without the period), then at minimum, if we test with 8 "0"'s, we end up with 8 * 48 which = 388... much greater than 322.

This means that if it's a number string, it can't be any longer than 6 digits (and that's all 0's), which = 288, with 34 left over.

So, the first entry's base would be 000000, and for each digit, add values that would add up to 34.

eg, 956275 should give the same result as "one"
...and it DOES!

now we should come up with an algorithm, since each string could be any different number of digits (assuming it's digits we're entering )

of course I could be totally off on all this as well

[Nighthawk]

Since I'm not convinced Mike's message is the solution, I decided to play the clueless idiot... er... curious programmer interested in the inner workings of the system.

Sent to Dyson Trust:

[thebruce]

well, hopefully they'll listen to you - they haven't answered me yet

[Kelis]

[MrToasty]

Hmmm. 6*57 (ascii 9) = 342, so a six digit number is too small to match three, four, or five. I have a sneaking suspicion that Nighthawk is right.