What the flying fuck

The first nested if only runs if its else statement is commented out…

if(this.characters[this.j*4+2]<this.oldSely && this.characters[this.j*4+2]>this.currentSely){
  if(this.oldSelx,this.oldSelx + npcs[this.currentSelIndex].width in |this.characters[this.j*4+1],this.characters[this.j*4+1]+npcs[this.characters[this.j*4+3]].width+1|){
    relocatePointer();
    this.found = 2;
    message #v(this.found);
  } else if (this.found == 1){
    relocatePointer();
    this.found = 1;
  }
}

Any ideas?

I don’t know exactly how Graal will handle it, but the following that you’re using isn’t valid syntax:

if (x,y in |x,y|) {}

“in” only checks one number in the specified range.

As a small complaint of something that people have done for over a decade now needlessly, variable prefixes like “this.” only need to be specified once. It basically serves as a definition.

Well, it works as long as the range between the two numbers of the first part is inside the range of the two numbers of the second part.
I tried it with plain numbers and it’s the behavior I get.
I was surprised it was correct syntax…

I’ll still try to write that part differently. Thanks.

If that truly works, the only other thing I can see might be the “else if”. Some languages require “elseif”, but I don’t think even GS1 was one of them. You might have broken the parser with the nested arrays or something. Or you fucked up brackets in the code enclosing what you posted.

Now that I’m on my computer, I just tried the “in” thing and am surprised to find that you’re correct. I certainly didn’t know that worked during the time I worked with Graal.

I’ve just tried replacing the in part to checking a variable that I know its value but is used for something else.
Now it works.
The problem is definitely in the condition but I don’t get why it runs when it has no code after it.

edit:
did it even really work?.. too late to try again

Ok, problem solved, thanks for the support codr.

The problem probably was the “in” statement. I still got weird behavior for a moment but it was because of the width of shownpcs which is larger than it appears on screen, as they are centered in a 3 by 3 field.