This content has been marked as final. Show 5 replies
I find I can fix something like that if I select from the end of the line to the next and hit enter to replace the line feed. I continue down the script until it corrects itself. I've had a lot of problems with the continuation symbol and am wary about using it for that reason. One problem that really messes up a script is adding a new line to a script with a continuation and having the indentation randomly corrupted even adding spaces within a line of script. I really hope Adobe have done an overhaul of the script editor for the next version.
Try inserting RETURN (Enter) at the end of the line that arouses this problem.
I usually do this whenever auto-indent (TAB key) doesn't work.
And if after inserting RETURN, it still doesn't auto-indent, I'll check the long codes for typing errors.
> Try inserting RETURN (Enter) at the end of the line that arouses this
> I usually do this whenever auto-indent (TAB key) doesn't work.
> And if after inserting RETURN, it still doesn't auto-indent, I'll check
> long codes for typing errors.
Yeah, there's no errors in the code, I've confirmed that several times.
(Both by the fact that there are no error messages, and that the code
functions exactly as it's supposed to.) Hitting Enter at the end of the
line has no effect either, nor does Ctrl-Enter, which usually solves this
sort of problem. The only way to fix it seems to be to get rid of the line
continuation altogether and just make it all one long line. (Annoying,
because there are three other nearly-identical long lines in the same
handler of the same script, all of which have a continuation and all of
which function perfectly.) I'm almost ready to file a bug-report on this,
because there's absolutely nothing wrong with the code. If you really want
to look at it, be my guest:
if sprite(393).locH < spr.locH + 60 and sprite(393).locH > spr.locH - 60 and
sprite(393).locV < spr.locV + 60 and sprite(393).locV > spr.locV - 60 then
"spr" is a property set on beginSprite to equal sprite(me.spriteNum). All
it's doing is checking if the two sprites are near eachother. (And yes, I'm
aware that this has a square rather than round area of effect, but a true
distance formula takes far more calculation (and thus runs slower) with only
a barely noticeable difference in behavior. Given that there can be dozens
or even up to hundreds of sprites running this behavior at once, I went with
the simpler calculation.)
I get the same indent problem pasting that line into a new script. Have you tried putting the continuation at the end of the first line rather than the start of the next?
if (sprite(393).locH < spr.locH + 60) and (sprite(393).locH > spr.locH - 60) and \
(sprite(393).locV < spr.locV + 60) and (sprite(393).locV > spr.locV - 60) then
>I get the same indent problem pasting that line into a new script. Have you
> tried putting the indent at the end of the first line rather than the
> start of
> the next?
> if (sprite(393).locH < spr.locH + 60) and (sprite(393).locH > spr.locH -
> and \
> (sprite(393).locV < spr.locV + 60) and (sprite(393).locV > spr.locV - 60)
Hmm, Usenet's auto-linebreaks are making this confusing. In my original
example, there wasn't supposed to be a return after the "and" and before the
"\". Likewise, I assume there isn't supposed to be one before the "and".
At any rate, it doesn't indent properly either way. Adding the parentheses
didn't make a difference either. I've now corrected the problem simply by
copying the entire script into Notepad, deleting the script member and
creating a new one, and then pasting the the exact same script back into it,
unchanged. No idea what caused the problem still, but at least it's solved
this time. Weird.