[11.1.4] Triggered to a state that will induce catastrophic failure - Syntax - 8/28/08

**Agent_Gray**

Thank you, operatives. While the detonation of Ouroboros's Creston Heights power plant has been averted, serious concerns as to potential dangers still posed by the company remain. We must see to it that another such accident cannot occur.

Efficiently,

Agent Gray

**eval**

That was fun, I enjoyed having to organize our efforts in order to cut through the security guards.

**jl10899** · 09/02/2008 20:21:44

No one can run from the Machines...No one.

**Bayamos**

(( Despite my eventual conclusion about the security system having infinite solutions, that was the most fun I've had in a while in MXO. ))

**LtCmdr_Tsusai**

Bayamos wrote:

(( Despite my eventual conclusion about the security system having infinite solutions, that was the most fun I've had in a while in MXO. ))

((As a programmer, I kinda wanna see what you guys were seeing just out of curiosity))

**Phluff**

((Phirst LE I've been available to attend in over a year. Looks like I picked a good one! It was great phun indeed. SMILEY

Adding one of my own screen shots phor good measure. SMILEY

))

**Tesma** · 09/03/2008 09:21:33

I enjoyed this event alot, my first kill on a level 60 character.

Croesis · 09/03/2008 01:39:02

LtCmdr_Tsusai wrote:

((As a programmer, I kinda wanna see what you guys were seeing just out of curiosity))

((If I still have the screens I took at the time I'll PM them to you.))

I was frustrated about not being able to help, my coding skills are based around clothing and abilities, which are simple compared to the override code we were faced with, so I was very little help when attempting to solve the equation.

Despite our best efforts cracking the code, the success of this operation was down to those below in making the area safe and protecting that bluepill without whom the plant would have gone into meltdown. Not only did they distract the attention of the Ouroboros security away from the infiltration group during our attempts, but they also allowed the Ouroboros (ex?) employee to feel safe enough to show up and get through the security to the terminal. So she, and by extention everyone below, saved untold numbers of innocent lives.

I wonder where she went after security eventually attacked us... Hopefully we'll see her again and see if she knows any more details about the current situation.

**Procurator**

Congratulations to my fellow Machinists for trying to crack the code, as it were, and making a path through security when that failed. I wonder if Ouroboros security will have learnt its lesson yet?

Tenshi

Well done operatives, apologies for my absence.

**Omega0** · 09/03/2008 13:53:34

LtCmdr_Tsusai wrote:

Bayamos wrote:
(( Despite my eventual conclusion about the security system having infinite solutions, that was the most fun I've had in a while in MXO. ))
((As a programmer, I kinda wanna see what you guys were seeing just out of curiosity))

OUROBOR-OS

PROCESSING...
LOADING PARAMETERS VALUES...
PROCESSING...
PROCESSING...
ERROR!!!

EXECUTION ERROR:UNKNOWN PARAMETER VALUE(S10)
PRINTING EXECUTION TRACE
----------------------------

int s1,s2,s4,s6,s8;
boolean s3,s5,s7,s9;

s10; //unknown type

//S1
int s1val;
for (int i=1;i<11;i++){
   if (!si.isNaN){ //si = s1, s2, ..., s10
      s1val+= si;
   }
}
s1 = s1val;

//S2
int s2val;
for (int i=1;i<11;i++){
   if (si){
      s2val++;
   }
}
s2 = s2val;

//S3
s3 = true;
for (int i=1;i<11;i++){
   if (si > s1){
      s3 = false;
   }
}

//S4
int s4val = 0;
for (int i=1;i<11;i++){
   if (si == s4){
      s4val++;
   }
}
s4=s4val;

//S5
s5 = true;
for (int i=1;i<11;i++){
   if (!si.isNaN){
      if (si < 0){
         s5 = false;
      }
   }
}

//S6
int s6sum;
int s6count;
for (int i=1;i<11;i++){
   if (!si.isNaN){
      s6sum += si;
      s6count++;
   }
}
s6 = s6sum / s6count;

//S7
if (s4 > s2){
   s7 = true;
}else{
   s7 = false;
}

//S8
s8 = s1/s8;

//S9
if (s6 == ((s2-s4)-(s8*s4))){
   s9 = true;
}else{
   s9 = false;
}

//S10 = ?

Please input S10:
>

PRESS [CTRL-H] OR DIAL #4559 FOR HELP
[ESC] EXIT TO DOS [UP / DOWN ARROW] MOVE CURSOR [ENTER] RUN

As far as I can tell, there is no unique solution to the value of s10.

**caillech**

So, how many real life computer programmer's chose to belong to the machine faction? Like someone there said, I boggled. I do not speak math!

Great job and thanks for saving the City.

**Bayamos**

(( Just a little note for anyone that decides to take a peek at it. It's written in Java. If you feel like porting it to C++ like I did for... "comfort," you'll need to include cmath, and the syntax becomes lowercase isnan(s[i]). Also, if(si) in Java checks if a variable is boolean true. In C++ that statement is syntactically correct but will check to see if the variable is not null. You gotta change it to if(s[i] == true)... or things like addition will fail epically.))

**LtCmdr_Tsusai** · 09/03/2008 17:46:37

((Well, after 10 minutes of tinkering. I have some thoughts on it.

You can't run it all the way through. Game over.

S8 = S1/S8

Nothing touches S8, and I believe in all languages, initializing a variable integer is setting it to 0 correct? And, even if it did get passed that, nothing touches S10, even if assigned.

S10 = 0 or false if you fix it, else null. Nothing touches that number unless I oversaw something.

My results: 0, 0, 0, 10, 1, 1, 1, rest nothing due to div / 0)

))

**Bayamos** · 09/03/2008 18:19:17

(( That's only true in Java. In Java if you don't initialize, it's set to 0 if it's an int, true if it's a boolean. In other languages the variable will either be undefined, null, or whatever random value is in the RAM block that's allocated. I considered that, then made the assumption that "we were supposed to be able to solve the puzzle." So then, making an excuse (error on the creator's part), we assume that s8 is initialized to something other than 1. After all, this is an "execution trace," analagous to the stack trace that prints out all the previous steps when an uncaught exception is thrown, this prints out all the previous steps before the program stopped. It got past s8, so we have to assume it didn't divide by 0, so that s8 wasn't 0. Going along with that, I looked at the constraints, and in that system the only constraint is that s8 != 0. You can generate infinite solutions for those bounds, so that doesn't have a "solution." If we keep assuming that this was supposed to be solvable, it requires a bit of thinking as to how it could be possible. Well clearly if the program got past s8 and s8 wasn't zero, the value was initialized to something but never said so. So perhaps Ouroboros has magical language capabilities that are different than what's currently out there. The only other thing I could think of that narrowed the constraints were the S8 and S6 "functions" -- if we didn't round on int/int division and required the modulus to be zero for an operation, that would narrow down the initial values significantly that worked. But I tried that too and there were still infinite solutions. So by exhausting all possibilities in my mind I've proved my initial assumption wrong; this was never "meant to be solved." ))