A thought about the line number "bug".

[Spidweb]

I think I might know what the problem people are having with line numbers is.

 

In software and in BoA, each carriage return marks a new line. If you hit Return five times, that's five new lines.

 

However, if you write a bit of dialogue longer than the width of the window and the text goes down a line, that is not a new line as far as BoA is concerned. If you write a very long message_dialog command that goes down 3 lines in your text editor, that's still just one line.

 

And I think it is obvious that it has to be that way. After all, each text editor will display text in a different way. Only counting the number of Returns is consistent from application to application.

 

A solution? if this is troubling you, get a text editor that it made for writing software code. BBEdit or any development environment (Visual C, CodeWarrior) work great.

 

If I am misunderstanding the problem, I eagerly await clarification. If this covers it, I'll add a note to the support page.

 

- Jeff Vogel

[Sir Alexander]

Fraid not, at least not for me. Here's one of the codes I was having trouble with a while back:

 

 

This code has 17 lines, as I counted out in Crimson Editor. The error is pretty visible as well, as I left in a break; where I shouldn't have. Yet, even though the error is on line 17, the error in the game displays as a dialog script error on line 33:

 

 

And there were other instances as well when it took me a while to debug my script because the line numbers did not match.

[Shyguy]

I've found that if you add 1 to the line number and then divide by 2, you get the correct line.

 

Take the example above...

 

It says "error on line 33." Add 1, which equals 34. Divide by 2. This equals 17!

 

This isn't always the case, but it's worked out like this several times for me.

[Spidweb]

As I've said in other threads, I can't do much with reports like this. I need the actual files that are causing the error, instructions to reproduce it, and to be told whether it's on Mac or Windows. Send the files to spidweb@spiderwebsoftware.com and I'll see what I can do.

 

Anyone who submits a report, also tell me what text editor you're using. It's possible that it is throwing in bonus, invisible carriage returns in there, which would muck things up.

 

- Jeff Vogel

[Sir Alexander]

Alright then, I've sent an email with the scenario as the attachment. Have fun looking at my one town, one building, one dialog script scenario.

[Kiexcolo]

I'm using visual C and I'm afraid it has the same line problem. Theres a different interpretation between line feed and carriage return I suppose since when I open your text files with notepad, its just one long continous line and I have a tendency to cut and paste.

[Kelandon]

Many Mac users use TextEdit to edit text documents. Jeff, at one point you suggested posting a link to the BBEdit site on the SW website somewhere, and I think this is a GREAT idea and should be done ASAP. BoA has certain problems locating the source of an error, but using BBEdit over TextEdit cut my debugging time in half or better. At minimum you should mention somewhere that you use BBEdit and that BBEdit Lite, which is free, is far better than TextEdit for BoA purposes.

 

EDIT: In a day or two, when I have Internet access not in the middle of the night, I will try to send you a few save files with errors that come from semi-bogus line numbers.

[Lilith]

The "*2 -1" bug (as in the example discussed in this thread) makes it sound a lot like BoA is counting a carriage return immediately followed by a line feed (the standard format on Windows) as two line breaks when it should count as one.

[Yellow Sub]

I came up with the line idea first.. Look at topic unknown command you in line 41 and look at one of my posts, under the code...

[UA]

Fast solution: turn off wordwrap. You can do this even in Notepad.

[Icshi]

Text editors were discussed in a different thread, and as per Jeff's suggestion I've downloaded and started using BBEdit. It's a wonderful tool and I heartily recommend getting it. The "show line number" function is particularly handy.

[Spidweb]

Can anyone recommend a good freeware text editor for Windows which is compatible with Blades line-numbers-wise? I'll link to it in the workshop.

 

- Jeff Vogel

[ef]

Wordpad works well for me, when I turn off the line break. I've had no problems so far.

[void*_dup1]

Editplus is a great editor for any kind of programming task. The line break format can be configured to Unix, Dos or Windows. And the evaluation version is free.

 

Besides, I've already made a syntax file for BoA Script syntax highlighting

[Sir Alexander]

Crimson Editor is freeware and like editplus it can have customizable syntaxes and can switch from unix mode to windows mode and even to mac mode. If you remember the file I sent you, I believe it was actually formmated with a line feed, whereas you can switch it in this program to use a carriage return instead. I actually didn't find that option until now.

 

EDIT: I tested the script once again in BoA and the error now came up in line 17, where it should be.

[ef]

EditPad Lite is a text editor for Windows and Linux that's free for non-commercial use.

It does not limit the maximum length of a single line, settings such as word wrap, line numbering and auto indent can be made for each file type individually, and it reads and writes UNIX (LF only) and Mac (CR only) text files (in addition to DOS/Win CR+LF files, of course).

[Spidweb]

Excellent! I'll sort through the links and come up with some useful info for the site. Thanks!

 

- Jeff Vogel

[mrb]

You might also look at NoteTab Lite, in addition to understanding Mac CR and Windows CRLF issues, it also has a built in macro facility.

 

regards,

 

mrb

[Kelandon]

I just sent an e-mail with a scenario attached that demonstrates some instances when BoA will give a line number that is not the source of the problem or will give a kind of bogus error. In summary:

 

1. When an expression is missing one of its end parentheses, the line number given for the error is the line after the expression. If lines 16 and 17 of your code are

Code:

 if (get_flag(0,0) == 0print_str("blah"); 

then BoA will give an error for line number 17, not 16 where the problem is.

 

2. If a string is missing end quotes, then the line number will be correct, but the error will say something completely bizarre. If this is your code, starting on line 16 again:

Code:

 add_dialog_str(0,"This is a dialog string,0);dummy = run_dialog(1);set_flag(0,0,1);i = 0;while (i < 5){i = i + 1; }message_dialog("Error",""); 

then BoA will say something to the effect that you have an improper command Error in line 16. Line 16 doesn't contain the word Error. The problem is that line 16 is missing its end quotes.

 

3. If a state is not properly break-ed, then the script will keep running and start over at the beginning of the script. If the final lines of your script are:

Code:

 beginstate 20;print_str("20"); 

without a break after that, you get something along the lines of an improper command in line 0 or line 1 -- I think I've seen it vary. Those lines are not the problem; the problem is a missing break.

 

All of these errors are easy to recognize once you know what you're looking for, but they were mind-boggling the first time through.

[UA]

Eugh..don't bother with commercial text editors, they're usually 95% bloat.

 

I reccomend the following:

 

Metapad (google.)

Shalom Text ( http://www.danish-shareware.dk/soft/stxt/ )

[mrb]

This is a real problem, since scripts may be constantly revised in both Win and Mac versions. Is the game parser able to discriminate between these two types of line-ending tokens? ie CR for Mac, CRLF for Win. If not, this will occur, again and again.

 

Regards,

 

mrb

 

P.S. Asking Win users to convert to Mac text processors is not the solution, and a CRLF is the standard Win line-ender. I agree that a good text processor is needed by anyone serious about scripting - there are many available, freeware, shareware and commercial.

[Spidweb]

Kelandon, I appreciate your confusion in this situation. Lord knows, in my years of programming, I've been annoyed by my share of cryptic or misleading compiler messages. But it really is inevitable.

 

Consider example 2, in your case. You set a dialog string to be something long and strange, and then followed it with an unknown variable name (i.e. "Error"). The program correctly returned the line number where the error occured.

 

A human can look at that and instantly say, "Oh. That's not right. A string shouldn't look like that." But you seem to expect my compiler to have some sort of AI which can interpret that quote as not being what the user intends. That can't happen. Or maybe it can, but its far beyond what any compiler I know of does.

 

Example 3 is weird. Not sure why it's doing that.

 

And BoA's behavior in example 1 is correct. Line 17 is where the error is. That's where you're using the name of a procedure call in a mathematical expression, which is naughty. The code doesn't tell you where you made your mistake, but where the syntax goes bad. Different things. It's not possible to do the first one, only the second.

 

- Jeff Vogel

[Kelandon]

Meh, I'll release Irregularities to the public, then. If these error messages are going to stay the same, beginning scenario designers should at least know circumstances under which the error messages can be rather screwy.

 

I have a far better explanation of this in the demo scenario that I sent in to Spiderweb than in the previous post.

 

And again, it is a matter of interpretation. These error messages feel buggish, but they are not actually incorrect. I recognize that it would take a great deal of effort to correct them, but I do feel quite strongly that they (and other peculiarities like them) should be documented somewhere. If you know what to look for, they're not harmful; they're only bad if you're new to this.

 

But again, I think I'll just release Irregularities and possibly write an article on it.

 

EDIT: It does seem like you could check for line breaks in the middle of strings and expressions, but meh. I imagine it would take some serious programming in order to make it useful rather than limiting.

[Spidweb]

I'm putting up a long thing on the support page about line numbers. I'll probably expand it soon. Hopefully this will help.

 

If anyone wants to write an article on line numbers (perhaps incorporating my tech support message and some things from this thread), it would be hugely useful.

 

But I really have to stress that this is not an issue of something I can do but won't because it's hard. This is something that really can't be done. The game can only tell you where it finds an error, where it sees that the script has gone off the rails. That this is sometimes in a different line from where the actual typo is is unfortunate, but unavoidable.

 

- Jeff Vogel

[mrb]

Dear Jeff,

 

Your points about the compiler are well taken. I still believe the other issue, related to a huge difference in actual line numbers, has yet to be addressed.

 

It is a definite possibility that the parser cannot differentiate between a Mac generated script and a Windows generated script, ie it doesn't understand or make use of the CRLF that is the common line-ender for Windows.

 

Have you received any scripts from Windows users that show that problem? If not I will semd you one showing an error, just for example, at line number 476, when in fact the entire script has less than 230 lines.

 

Regards,

 

mrb

[Spidweb]

"Have you received any scripts from Windows users that show that problem? If not I will semd you one showing an error, just for example, at line number 476, when in fact the entire script has less than 230 lines."

 

Go ahead and E-mail me that example. And tell me what text editor you're using.

 

- Jeff Vogel

[mrb]

Dear Jeff,

 

E-mailed the script, but I neglected to say that I am mainly using Scintilla. I also use EditPad Pro and others - but each of them understands Mac/Windows line endings.

 

The problem is in the parser.

 

Regards,

 

mrb

[Spidweb]

"E-mailed the script, but I neglected to say that I am mainly using Scintilla. I also use EditPad Pro and others - but each of them understands Mac/Windows line endings."

 

Could you resend it? Never got it at my end.

 

"The problem is in the parser."

 

I feel that remains to be seen. That the reported line number is more than twice the length of the script makes me suspect that your text editor is doing something funky. I am not sure that I am going to be able to make BoA work with every text editor using every setting.

 

- Jeff Vogel

[Spidweb]

Hokay. I just put in some code that watches for Windows style line endings and adjusts for them appropriately. I'll probably upgrade the debug-version BoA soon.

 

However, this will do nothing for the weird situation where the given line number for the error is over twice the length of the file. I'll look at it, but that's something really odd.

 

- Jeff Vogel

[Kelandon]

Quote:

I am not sure that I am going to be able to make BoA work with every text editor using every setting.

You know, Jeff, all you have to do is guarantee it with a particular free text editor (say, BBEdit Lite for Mac and some other program for Windows) and then say tell everyone that if you don't use those programs, it's your own problem.

[Lilith]

It sounds as if that's what Jeff was planning to do when he first heard about the problem, and now people are trying to harangue him into finding increasingly perfect solutions. Honestly, I'm starting to see why he was reluctant to fix BoE. Even if we have good reasons for it, we can ask for a lot. The Blades community must be worse than Cordelia sometimes.

[Spidweb]

No, this all really was my bad. There was a genuine bug in there. Fix coming soon.

 

It just took a little time to sort the bug from other issues, that's all. And I wanted to get this sorted out before I recommended text editors.

 

- Jeff Vogel