Dialogue file: 'nested functions not supported, you forget a closing brace?'

Started by bx83, Sun 11/02/2018 22:58:33

Previous topic - Next topic

bx83

Well, it's the most dreaded error of them all; a dialogue closing brace error.
It only tells you that a dialogue has a buffer overflow (but not where! You left out a closing " in 500 lines of code, which you now have to check); or a buffer overflow on the wrong dialogue (complains of dialogue 3 when it was dialogue 2); or 'nested function' - probably means you did something like this:

Code: ags

function foo (args) {
  some stuff;

//<--- MISSING CLOSING BRACE

function bar (args) {
  more stuff;
}


I have the 'line 1: nested functions are not supported' error for a dialog; but nothing of the above in my code.
I deleted everything in the dialogue; same error (but it can't be that dialog, because it has nothing in it!)
I checked the dDialog.Start() function, and all the code before and after it; no problems - unless someone can find the problem:

Code: ags

function cAlien_Talk()
{
  cJulius.Walk(256, 248, eBlock, eWalkableAreas);
  cJulius.FaceCharacter(cAlien, eBlock);
  dAlien.Start();        //talk to alien
}

function cHoF_Talk()
{
  dHoF.Start();    //talk to HoF - dialog 10
}

function gInventory_OnClick(GUI *theGui, MouseButton button)
{
  //some random function with nothing in it
}


Then I checked Dialog 9 and 11 (the error was with dHoF, dialog 10); nothing. Deleted everything in 9 10 and 11; stll had error for line 1 of dialog 10.

Deleted my most recent change to the GlobalScript.asc; no change, same error

My question is:
How are dialogs processed - one after the other (dialog 10, 11, 12...), or from the entry point (dialog.start()) or in some other way?

Why don't errors in them have a line number *in* the dialog, not just "there was an error in your dialog, or around it, idk"?

Why is it so impossible to find a nested function when it happens anywhere in your project, and the error refers to a dialog that doesn't have it?


Please help. I have a horrible feeling that this will make it impossible to F5/test the game until I'd been through 750,000 lines of code (not an exaggeration) :/

Crimson Wizard

Quote from: bx83 on Sun 11/02/2018 22:58:33
My question is:
How are dialogs processed - one after the other (dialog 10, 11, 12...), or from the entry point (dialog.start()) or in some other way?
I don't understand this question.


Quote from: bx83 on Sun 11/02/2018 22:58:33
Why don't errors in them have a line number *in* the dialog, not just "there was an error in your dialog, or around it, idk"?

Why is it so impossible to find a nested function when it happens anywhere in your project, and the error refers to a dialog that doesn't have it?[/b]

Because that's how AGS was made. This is how it compiles dialog scripts: it gathers ALL of them in a single temporary file and then compiles. When compiler finds an error it is not smart enough to backtrace it back to where the actual unpaired opening brace was.

Since the error is about exceeding buffer, this usually means that the unpaired brace is much earlier than the buffer was exceeded. That is - if buffer is exceeded at the dialog 10, the opening brace could be anywhere BEFORE it.
The buffer has a limit, of course, but it depends on how large your dialog scripts are. If your dialogs are small, the mistake could have been even in dialog 1.

Also definitely if the error is in the dialog script, then GlobalScript has nothing to do with it.

bx83

But what of a 'nested function' error?

What I meant was, how are dialog scripts compiled?
...But they're all put in a temp file and compiled this way; now I have to go through all 53 of them :/

Crimson Wizard

Quote from: bx83 on Sun 11/02/2018 23:21:03
But what of a 'nested function' error?
This means that there was a function after non-closed bracket, and for compiler it looked like you made a function inside another function.

Quote from: bx83 on Sun 11/02/2018 23:21:03
...But they're all put in a temp file and compiled this way; now I have to go through all 53 of them :/

You don't have to go through all 53. You need to begin with the one where the error was reported, and then go up, one by one.
Compiler buffer is limited. Depending on how large your dialog scripts are, the unpaired opening brace could be in the previous dialog, or 5 dialogs above it.

bx83

So it was dialog 34 (?), which I've edited recently with huge bunch of brackets. Added 1, game compiles :)
So no idea why it's 34, but there we are :/

Crimson Wizard

Quote from: bx83 on Sun 11/02/2018 23:25:49
So it was dialog 34 (?), which I've edited recently with huge bunch of brackets. Added 1, game compiles :)
So no idea why it's 34, but there we are :/

Umm, well, it was 34 because you made a mistake there?...

Could you tell what the actual error message was by the way, did it refer to the dialog number?
The thing is that your first post left me very confused about why did you began checking around dialog 10.

Also, speaking of the source control you discussed in another thread, that's exactly where it could come handy - because it shows what you've changed recently.

bx83

Sorry, I was confused about whether the error was before dialog 10 (dialog 1 2 3 4...); or after (dialog 11 12 13 14...).
Can it be both?

Crimson Wizard

Quote from: bx83 on Sun 11/02/2018 23:40:56
Sorry, I was confused about whether the error was before dialog 10 (dialog 1 2 3 4...); or after (dialog 11 12 13 14...).

So, error message mentioned dialog 10? If so, then it's very strange that you found missing brace in dialog 34.
Did you maybe changed the order of dialogs in the project tree, or put them in subfolders?

bx83

Yes, all separate sub-folders; so it goes by sub-folder order?

Update: The dialogue with the problem was just above dialog 10 :P

Crimson Wizard

Quote from: bx83 on Mon 12/02/2018 00:26:05
Yes, all separate sub-folders; so it goes by sub-folder order?

Update: The dialogue with the problem was just above dialog 10 :P

Well then, I guess it compiles them in the order of their positioning in the folder tree.

Cassiebsg

@bx83, here's a tip: When coding, code in small "batches" then test it, if it fails then all you need to check the last small batch you just did, and not hours of code. ;)
There are those who believe that life here began out there...

SMF spam blocked by CleanTalk