I got the problem recently, I couldn't open my ASL file neither in Quest nor in QDK, because there was a mismatching { } error. I couldn't trace it down, I looked in all my code but I had changed rather many things in it. Generally I changed only one or two things by hand, so with such an error it was quick to find it, but for some huger changes, it's much more difficult.
The log gave only :

11:02:19 FATAL ERROR: Missing }
11:02:19 INIT: Unable to open file

It would have helped much to get the line where it happen, or in which context.

In the case it happens to someone, this application helped me much to find the error :

ftp://ftp.flashnet.it/pub/simtelnet/win ... renmat.zip

but you have to change in a temporary file a few things :

remove all the ()
change { } to ()
remove all the ;

then you can trace the problem

I've had a couple of reports of this in the past, but I've never been able to reproduce the problem. If you save your ASL file with different names each time, then you can go back to the version before the file was saved incorrectly. If you could then send that to me and tell me exactly what you did next, I will be able to reproduce the problem and fix it.

If you don't have a copy of the file before it was broken, then if you can tell me what you were editing before you saved, I can try and have a go at reproducing it.

The problem wasn't produced by QDK, it was my own fault : I forgot a closing } in the ASL code I was editing by hand. It's just it'd be easier to trace such problem if the log could tell on which line in the ASL code it occured, instead of being forced to check all {} visually (I did this before finding the other software which can detect such error)

Oh I see - that's alright then. The bug I mentioned I had a couple of reports late last year, but none since, so maybe I fixed it "accidentally". Which is always nice

I would like to be able to implement something that would tell you where your } was missing, but I can't think of a good way for Quest to guess where something that's missing should be. It does quite a simple check, basically counting all the { and all the } to see if there are the same number of each. I suppose I could make it count for each "define" block separately, and then at least that would narrow it down to a particular part of the game.

when it parses fhe files, and note the missing {, just to get the line where it's missing would be enough I think.
Or is it checking the whole file and send the error report at the end ?

It checks the whole file at once. There's no way it can "see" where a missing brace might be, because the brace isn't there! Consider the following:

command <something> {
if got <thing> then {
msg <Blah blah>
give <wotsit>
}

Where is the missing brace? Because the brace isn't there, you can't know where it, er, isn't! It could be missing after the msg command, or it might be missing after the give command.

Now in the above example we know the missing brace is somewhere in the code block after "command". If there was another "command" line following the code above, we could tell that the missing brace was in the first "command" block, because we know you can't nest one "command" line in another. But Quest isn't clever enough to put that much thought into it - it doesn't know that "command" isn't a script command for example, when it's checking the braces. After all, it could be something implemented in a future version, in which case it might make sense for a "command" script command to appear inside a "command" block. Quest only knows that "command" isn't a script command if you try to execute that command. So, when it's just checking braces, it doesn't look at things to see if they make sense - that's where you, the programmer, come in.

So this all basically means that it can't tell you the line where the brace is missing - it may be impossible to tell anyway, and even if it is possible for a human to tell, Quest's brace-checking code isn't sophisticated enough.

As I say though, it should be possible for Quest to tell you which "define" block the problem resides in, as you can't nest those. Quest's brace checking routines don't know that yet, but it should be reasonably easy and future-proof to make them know, so I think this would be a good addition. It's now on my ever-increasing "to do" list...

indenting ala...

	command <warp to #target-room#> if ( $objectproperty(player%userid%; usrlvl)$ >= 2 ) then msg <I don't understand what you typed.|n> else { 
			msg <You focus intently on your destination and begin to plane shift.|n>
			goto <#target-room#>
		}

Is a good way to keep track of your more complex pieces of ASL and where closing braces should be.... ala...

	command <take-do> if ( $objectproperty(player%userid%-r-hand; held)$ = null ) then {
		set string <target-object; $getobjectname(#target-object#)$>
		move <#target-object#; player%userid%-r-hand>
		property <player%userid%-r-hand; held=#target-object#>
		property <player%userid%-r-hand; held-name=$displayname(#target-object#)$>
		property <player%userid%-r-hand; held-short=$objectproperty(#target-object#; short)$>
		if property <#target-object#; prefix> then property <player%userid%-r-hand; held-display=$objectproperty(#target-object#; prefix)$ $displayname(#target-object#)$>
		if property <#target-object#; suffix> then property <player%userid%-r-hand; held-display=$objectproperty(#target-object#; prefix)$ $displayname(#target-object#)$$objectproperty(#target-object#; suffix)$>
		msg <You pick up the $displayname(#target-object#)$ with your right hand.|n>
	}
	else {
		if ( $objectproperty(player%userid%-l-hand; held)$ = null ) then {
			move <#target-object#; player%userid%-l-hand>
			property <player%userid%-l-hand; held=#target-object#>
			property <player%userid%-l-hand; held-name=$displayname(#target-object#)$>
			property <player%userid%-l-hand; held-short=$objectproperty(#target-object#; short)$>
			if property <#target-object#; prefix> then property <player%userid%-l-hand; held-display=$objectproperty(#target-object#; prefix)$ $displayname(#target-object#)$>
			if property <#target-object#; suffix> then property <player%userid%-l-hand; held-display=$objectproperty(#target-object#; prefix)$ $displayname(#target-object#)$$objectproperty(#target-object#; suffix)$>
			msg <You pick up the $displayname(#target-object#)$ with your left hand.|n>
		}
		else msg <Both of your hands are full.|n>
	}

Just a suggestion, it's what I do.

Yes, it's a very good idea to indent all code in braces. This lets you see easily which bit belongs where.

It's not very helpful as far as Quest's error checking goes though, as you don't have to indent your code, and if you do you might do it in a different way to other people. And indents are removed when Quest loads your ASL file anyway. So this means they're not very helpful to Quest for finding where a missing brace might be - however they can be very helpful to you so you don't miss them off in the first place.

As I say though, it should be possible for Quest to tell you which "define" block the problem resides in, as you can't nest those

I probably didn't think enough when I suggest the parser could tell where the missing {} is.
Of course knowing approximately where the problem occur is enough : if it can tell a "define" or a block has an odd number of brace then it's ok.

Alex maybe a good idea might be to add a line number for each and every line in the ASL code, and get QDK to add it to.

By doing this u can also add a goto function, but that means that the coder needs to know what the number is.

Matthew G.

Actually, and it should have been brought up, that if Quest gets an error because a bracket isn't there, then obviously the program knows where it should be. If only because it was expecting one to close an argument/piece of script/whatever. Also, most compilers include such a function and while I don't mean to be insulting or assume too much, Quest is basically a compiler(mayber interpreter?) for the asl syntax.

Actually Quest only knows a bracket isn't there because the number of { doesn't match the number of }. I've not implemented any artificial intelligence for Quest to guess where the missing bracket might be, so you'll have to add them yourself.

Line numbers and GOTO is a really horrible idea! There really is no need for them, they wouldn't sit well logically in the ASL structure and they'd be really inconvenient.

Haha - now I've moved on from line-numbered BASIC I wonder how I ever coped with it! It's quite horrific to look back to some of my older programs on the old Sinclair QL and see "spaghetti-code" .

Anyway, as Alex has said before, a game block identification would be helpful because often I change two or three blocks in different files and keeping track is quite hard in this occasion. But it is quite hard to tell exactly where a bracket is missing - but it shouldn't be too hard to tell roughly where the extra bracket that needs closing is.

Why would line numbers and a GOTO function be bad? And also, for the very first post, why couldn't you just open up the ASL file in Notepad or another text editor and correct the problem? Or you could use Computer Whizz's (I think) ASL editor.

Matthew G.

The first post was made back in August and he's probably fixed it - but you're right you'd open it in notepad or some other ASCII editor.

GOTO would create all hell, mess up readable code, generate all bugs and generally be a total mistake!

The first post was made back in August and he's probably fixed it - but you're right you'd open it in notepad or some other ASCII editor.

GOTO would create all hell, mess up readable code, generate all bugs and generally be a total mistake!

OK, but how?

Matthew G.