 |
chris-74269
Magician
Joined: 23 Nov 2004
Posts: 364
|
 Posted: Tue Dec 12, 2006 4:46 am
oddity with if statement
|
having a setup like this will set off the parser with an unmatched braces error
| Code: |
#alarm +.01 {
#if ((@playercheck = 0) and (@picker = 1) {
get %item( @item, 1)
#if (@id = 1) {identify %item( @item, 1)}
#if (@disc = 1) {put %item( @item, 1) in disc}
#if (@bags = 1) {put %item( @item, 1) in bag @buse}
}
#delnitem item 1
} |
however, this doesn't
| Code: |
#alarm +.01 {
#if ((@playercheck = 0) and (@picker = 1)
{get %item( @item, 1)
#if (@id = 1) {identify %item( @item, 1)}
#if (@disc = 1) {put %item( @item, 1) in disc}
#if (@bags = 1) {put %item( @item, 1) in bag @buse}
}
#delnitem item 1
} |
Also this will give more brace errors
| Code: |
#alarm +.01 {
#if ((@playercheck = 0) and (@picker = 1)
{
get %item( @item, 1)
#if (@id = 1) {identify %item( @item, 1)}
#if (@disc = 1) {put %item( @item, 1) in disc}
#if (@bags = 1) {put %item( @item, 1) in bag @buse}
}
#delnitem item 1
} |
is there some new standard for if statements that is causing this behavior? |
|
|
|
|
Morgal
Beginner
Joined: 06 Nov 2006
Posts: 26
|
Posted: Tue Dec 12, 2006 7:28 am
|
The reason you are getting unmatched braces, is surprisingly that you have unmatched braces!
| Code: |
#alarm +.01 {
#if ((@playercheck = 0) and (@picker = 1) {
get %item( @item, 1)
#if (@id = 1) {identify %item( @item, 1)}
#if (@disc = 1) {put %item( @item, 1) in disc}
#if (@bags = 1) {put %item( @item, 1) in bag @buse}
}
#delnitem item 1
} |
Line 2.. double opening round bracket (parenthesis if you must, but im English, so bracket will have to do), one close, one open, one close = +1 opening bracket.
Call me crazy if im wrong but ive checked and double checked that this opening bracket is never closed.
This is also true in the other 2 cases you posted, so the issue here is not why you get an unmatched bracket, its why you aren't getting one in the second example.
Morgal
PS Just before i posted, i noticed there is a spare closing curly bracket. So check yer bracket types and then see if you get any errors. Im guessing the bracket on the line above the #DELNITEM item 1 is the culprit |
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Tue Dec 12, 2006 1:40 pm
|
You should also be aligning your brackets at the correct indent levels. Your last two closing curly brackets are both indented one level too far.
|
|
|
|
|
Seb
Wizard
Joined: 14 Aug 2004
Posts: 1269
|
Posted: Tue Dec 12, 2006 7:45 pm
|
Are you sure, Larkin? Isn't indentation only important when you are actually using the 'multi-line scripts' feature? In this case, the open braces (curly brackets) are on the same line as the #command so I don't believe this script uses the 'multi-line scripts' feature.
|
|
|
|
|
chris-74269
Magician
Joined: 23 Nov 2004
Posts: 364
|
Posted: Tue Dec 12, 2006 8:43 pm
|
well so there is an error in cmud, but oddly enough in my zmud script the missing ) is there so something with the conversion must have removed it. does the conversion ruin the alignment of brackets for everyone else too? in zmud they are aligned nicely but that hierarchy seems to be lost in most of my cmud converted settings
|
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Tue Dec 12, 2006 9:03 pm
|
Unless you put the whole command syntax on a single line, you're using the multi-line scripts feature, aren't you?
Chris, the "hierarchy" (or indentation) is lost because zMUD never stored those indentations. If you turn off pretty printing in zMUD, that's what your script really looks like. Most of my scripts are a collection of very long lines, with all commands separated only by semi-colons, so I'm now re-writing everything the new multi-line CMUD way. I've wished for a long time that I could code in a more structured text format, so I'm happy for this change. |
|
|
|
|
Seb
Wizard
Joined: 14 Aug 2004
Posts: 1269
|
Posted: Tue Dec 12, 2006 11:58 pm
|
| Larkin wrote: |
| Unless you put the whole command syntax on a single line, you're using the multi-line scripts feature, aren't you? |
I don't think so. In zMUD 7.x you could have scripts that were on multiple lines so long as the opening bracket or brace did not have a line-break before it. In this instance, the line-break after the opening brace was ignored by the parser.
| Larkin wrote: |
| Chris, the "hierarchy" (or indentation) is lost because zMUD never stored those indentations. If you turn off pretty printing in zMUD, that's what your script really looks like. Most of my scripts are a collection of very long lines, with all commands separated only by semi-colons, so I'm now re-writing everything the new multi-line CMUD way. I've wished for a long time that I could code in a more structured text format, so I'm happy for this change. |
That's not true in zMUD 7.x. (I don't know exactly which version it was changed in). If you have scripts you imported from earlier versions of zMUD, then yes, they are stored without line-breaks, and with semi-colons instead, and if you have Pretty Printing switched on, they are displayed prettily. However, if you have a script that you created in zMUD 7.x, switching off Pretty Printing has no effect, thereby showing that the line-break was stored. To test this (in zMUD 7.x), you can switch off Pretty Printing, delete the semi-colon, add a line-break and press save. Go back to the script (click on another setting and then go back - you can even close and re-open zMUD if you really want) and you'll see that it has saved the line-break. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
