"Uncaught Range Error: Maximum Call Stack Size Exceeded..." ?

Question

Hi all, sorry for posting twice in under an hour... :)

 

But when I was testing my story in Sugarcube 2 (in Google Chrome) I clicked a link to go to a passage and it gave me an error script that says the above. Why is this happening and how can I fix this?

Thanks!!

Answer 1

Which version of SugarCube 2 are you using?

What content does the target passage contain?
eg. Does it contain (or reference) code that is processing a large array/collection? or do you have a Task Object that is doing something similar.

Does the link itself contain code that is doing something similar?

Comments

I am using version 2.18.0 (on the online version of Twine). The passage has a large number of variables being changed, but as far as I am aware, no arrays bigger than 5 or 6 values. However, most of the variables are objects with about 50 values apiece, and there are about 15 of these. The link has no code, it is just a link to another passage.

 

Thanks for responding!

---

Is it possible that you've created some kind of a cyclical reference in your objects, like trying to stash a reference to object A in object B and vice versa? It'd be best to see the code, if you can post it.

---

The code is spread out over multiple passages. It would be difficult to send it all without uploading the project, which I am happy to do, if there is a way to do it. I will double-check the code to make sure I'm not cyclical referencing.

---

I do have quite a bit of code inside a "for" loop which is repeating it 10 times, which is probably harder for Sugarcube to process. Is it possible I have too much code, and if this is true, is there a way I can easily solve this without completely remaking the code?

 

Thanks again!

---

It might be best to post your html file to something like Dropbox or Google drive and leave the link here.

1. Your browser is doing the work, not sugarcube. It's possible that your code is too much, but that seems unlikely. I am not an expert, so I don't know at what point things start to fall apart, but I get the sense that in most cases, things like this are code errors, not browser limitations.

2. For loops in sugarcube will stop themselves after a certain number of iterations (1000 by default) to prevent overworking things like this.

---

https://drive.google.com/open?id=0BxxSWqyIW2_CTkhyeXBGclZhMms

 

That is the link to the code on Google Drive. Let me know if it doesn't work.

---

After looking at the multi-layered complexity of the data structures in your Start passage, how you embed both <<print>> macros and function calls within string properties of child and grandchild references objects, I can understand why SugerCube's passage traversal related functionality is crashing.

The code in your OK passage is also overly complex, with you using <<print>> macros to either dynamically access or assign values to your $playerX related variables. I would strongly suggest changing them from $player1, $player2, etc... to being elements of an array $player[0], $player[1], $player[2], etc... which should allow you to remove the usage of <<print>> totally.

---

OK. I took out the print macros from the strings. After that, the problem happens less frequently but it still happens. I am going to test some things, if I find a solution I will get back to you.

Thanks so much for responding so quickly!

---

https://drive.google.com/file/d/0BxxSWqyIW2_CQndnM244cFpvb28/view?usp=sharing

There is the link to the updated version. I tried using arrays, like you said, instead of printing the things out. Turns out the issue is still there. Is it because I'm using macros in strings?

Thanks again!

---

You should really try to space out and indent your code to make it more readable; you can use <<nobr>>, <<silently>>, and line-continues ('\') to manipulate your white space to where you want it.  It took me a while just to get it to a point where I can read it and start to understand what's happening/what you're going for.

There's a lot here and I'm still combing through it, but I'm pretty sure it's a code error.  I mean, sure, a lot's going on, but its really not that much.  I think a large part of the problem is just how opaque your code is, though; I can't imagine its easy for you to edit.

---

OK, I'll space it out. If I have a <<for>> loop inside a <<for>> loop, could that be the problem? Because that is there.

---

I experimented a little, and I don't think the <<for>> loop is the problem. I am still a little confused at what causes this problem.

Answer 2

The "call stack" is a data stack which stores information about function/method calls.  Exceeding its maximum size usually means that some bit of recursive code has gotten away from you.

We're likely going to need to see the code in question, however, one thing to look out for is using <<goto>> or <<include>>/<<display>> to create a pseudo-loop with recursion instead of using a proper loop via <<for>>.

Comments

I made sure to take out the goto macros, and I'm using all <<for>> for loops. Is it possible I'm actually making too many variables?

---

No.  Excessive variables would not cause a call stack error.  A call stack error exclusively means that there is too much recursion going on.

The parser (a.k.a. the Wikifier) itself operates recursively, so it's possible that you're doing something unwise in your code which is driving it off a cliff, figuratively speaking, which is why I mentioned the most common cause of the issue.

I have not had a chance to look at your code, so I cannot say more than that at present.

---

OK. My code is in the above discussion, there are 2 links- it is the lowermost one.

---

I don't think I'm using any of those macros, but I'm not 100% sure. Are there any other macros that can make that problem happen?