Actually, the script system doesn't return the line from the start of the XML file, it returns the line "into" the script. The actual error is on line 385 of the XML file, or the 189th line of the script itself. Unfortunately, due to how you needed to split up the file to post it here, it is hard to see what line its actually talking about. Pasting it back together myself in SciTE the problem seems to be in this:

for spell in string.gfind(spellist, "[^||]+") do --Line 189 with the "for" on it.
if spell == swanted then
sfound = 1
else
if count > 0 then
snewlist = snewlist .. "||"
end
count = count + 1 --The line mine "seems" to be saying is the problem??
snewlist = snewlist .. spell
end
end

I haven't the foggiest what the problem is, since I don't program in Lua. If it was VB I would have thought maybe you left out the "each" in the "for", i.e. "for each spell in string.gfind(spelllist, "[^\]+") do", but for all I know what you are using may be correct syntax. Someone else might be able to tell you if a) I have the right block and b) what the heck is wrong in there. ;)

I am puzzled about the line numbers being reported, to say the least, however what I did was copied and pasted the entire script into the Immediate window in MUSHclient, and hit Run. It then reported a problem at line 250 (??):

function somespells(sName,sLine,wildcards)
local curspells = cspells
local spellist = spells
local sfound = 0
count = 0
if v2skillcast == 1 then
Send(v2clanskill)
end if --> this is line 250

There is indeed a problem here, it should be:

end -- if

I am mystified about why the line number is so incorrect.

A few lines on, after fixing that I got an error on the line:

if sfound = 0 then

I corrected that to:

if sfound == 0 then

That got rid of the syntax errors, then it reported missing subroutine "listspells", so I changed this line to add the "s" to the function name:

I'll have to look into why the line numbers were so incorrect, however my technique of pasting the entire plugin script into the Immediate window, and trying to run it, at least gave me the correct line numbers for the errors.

As a side-note, when posting with the code tag in the forum you should do a "Quote Forum Codes" operation using MUSHclient's editor. The converts things like [ to \[ otherwise if you had a subscript like [b] it would show as bold text and not as it appeared in the script.

Thank you soooo much, like i said i was porting this from a working VBScript version, and guess i missed a few conversions.

Thank you Nick for the line number info.

And as for the stringsplit command you have made, inorder to traverse it using the each method you have to use table.foreach (table, f) and call a function to recieve the values, the method I have done is more like the VBScript for each statement. AND it only splits using a single character delimiter, my way has 'unlimited' length delimiters and uses a 'regular expression style syntax'.

It definitely represents a problem for using editors. Even if at some point you where to include such a thing, the editor would have to a) use something similar to a tree system to show imbedded imports or somehow correctly ID the line in the shorter version, so that adding an "Edit" button to the error dialog would correctly drop you into the editor at the error or b) just figure the right line. I think I have seen something similar of the former though, where the line containing the "import" command is without a line number, but there is a [+] below it, which when clicked shows the text of the imported part, with line numbers, in an uneditable form, with a different color, to indicate its not part of the script itself, sort of like:

Rather than directly putting the script into the plugin, make it a separate file like this:

<script>
<![CDATA[
dofile "C:\\spellup.lua"
]]>
</script>

Now if you get an error, the line number is exactly right, in the spellup.lua file. Once you have debugged, you can simply replace the "dofile" line with the file contents, so that you are distributing a single file.

Also, you get the correct syntax colouring (eg. in Crimson Editor) because you are editing a .lua file.