If *params is the first non comment or label line in a scene file, it generates the “TypeError: Cannot read property ‘length’ of undefined” error. Moving that code block below something that doesn’t use *params fixes it.
Could you show us the
for the ‘length’ variable?
I have no ‘length’ variable. For this test I had no *create statements at all. Here’s the total code in the startup scene.
*gosub_scene code test “hello world!”
And the code in the test scene which fails till you put a non *params line above it:
I’m trying to find if it is looking for a length variable, or for something else.
adding three `above and below the code formats it.
though I think it’s stumbling over the ‘hello world’?
What does it do if you removed that bit after test?
Thanks for looking into it
It generates that error if I use *params as the first non label or comment line in any scene that I use gosub_scene to get to. Doesn’t seem to matter what else there is around it. Just putting the code block with *params under another code block that doesn’t use parameters clears the error. It’s difficult to see how it could be anything in the scene files. The code works perfectly, by the way. Its just Quicktest that doesn’t like it.
Not sure if it’s the case, but try putting
*ending to actually end your scene.
I’ll try that when I can get things working again. It’s now decided that it can’t open “code.txt” although the file is in the same directory as the others, it’s called directly with a gosub_scene statement and nothing changed since the last time I ran the test. I might just see how far a mouse can fly today…
Ok, sorry, something did change, I took out the scenes_list - for some reason that made the file invisible.
Thanks Szaal, that made no difference at all though. It’s not a major issue, it can be sorted simply by not making a *params statement the first one in a scene file. It’s just an oddityl
Well, my educated guess is the structure of your
Code goes into
startup.txt, follows the
*gosub normally, returned, reaches the
*finish, and then follow the
Hmm. I added a *finish at the end of the startup file. Made no difference.
I created a new dummy file with a *finish statement and put a goto_scene to it in startup after the gosub_scene to the code file. Made no difference.
If I remove ‘code’ from the scene file it says it can’t find it. I put ‘code’ above ‘startup’ in the scenes list, still runs perfectly but quicktest still produces that error. Putting an empty label…return code block at the head of the scene file clears the error.
I’m flummoxed. I created this little test project because I was having the very same issue in another project I was working on.
If you have a separate subroutine scene, you need to have a
*bug Subroutine scene called without label. Make sure to specify the subroutine to be called by label. at the top (I mean, technically you only need the
*bug, but I like to make sure all my bugs are correctly labeled). Quicktest just goes in at the top of the scene and tries to run it directly, and that won’t work because it doesn’t have any parameters when it starts (because it starts every scene fresh).
Nope. Thought I understood but I think the only way I’m going to work around this is to just not have a *params statement as the first real command in a file.
I mean, your code goes into
code.txt again after it finished reading the
startup.txt, just like @RETowers indicated.
That’s why you need
*ending; to force the quicktest end.
There’s nowhere I can put *ending that affects this issue in any way at all.
Anyway, I’ll just make sure that I don’t use *params at the first actual command in a scene file. That seems to be the only way to stop Quicktest failing on this without also breaking Randomtest.
Ahhhhhh. It’s taken me all this time to finally understand what you were trying to tell me!
Quicktest tries to treat a code only scene like a normal one and gets confused when it can’t find anything in it that it can ‘go to.’ I put ‘*ending’ right after a comment at the top of the file and that sorted it out.
Thanks, and apologies for being a bit dim witted lol
It’s better to put
*ending, because that way if something does accidentally end up getting into the subroutines scene it will just crash.